Re: MaxRecvPDULength question

[Ken Sandars <ksandars@eurologic.com>]

Hi Julo & Bob,

I support Bob on this change to the completely unambiguous 

      "MaxRecvDataSegmentLength"

Cheers,
Ken

-- 
Ken Sandars
Eurologic Systems Ltd
ksandars@eurologic.com



On Monday 10 June 2002 1:51 pm, Julian Satran wrote:
> Bob,
>
>  I can do that too - and if we wait for consensus for a name - well that
> will be forever.
> So  if at least one more person wants the change and nobody is against we
> will have it as you wish if not then not.
>
> Julo
>
>
>
>
> "Robert D. Russell" <rdr@io.iol.unh.edu>
> 06/10/2002 10:42 AM
> Please respond to "Robert D. Russell"
>
>
>         To:     Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
>         cc:
>         Subject:        Re: MaxRecvPDULength question
>
>
>
>
> Julian:
>
> It has been stated several times that at this late stage we
> should not be requesting changes that are just preferences.
>
> Nevertheless, due to apparent misunderstandings of its meaning,
> the key named MaxRecvPDULength in draft 12 is apparently going
> to have its name changed in draft 13.
>
> Fine.  No problem.
>
> However, to remove all possibility of future misunderstandings,
> why don't we give it a name that says precisely what it is:
>
> MaxRecvDataSegmentLength
>
> That way, the first sentence in the third paragraph of section
> 9.7.1 would begin:
>
> "DataSegmentLength MUST not exceed MaxRecvDataSegmentLength
>  for the direction it is sent ..."
>
> which seems to me to be the classic definition of a maximum.
>
> The issue of changing the name from MaxRecvPDULength started with an
> e-mail sent by Luben Tuikov on 21 May (who, by the way, did NOT want
> to change the name, just its meaning), and was followed by a short
> flurry of e-mails under the thread "MaxRecvPDULength question".
>
> Some of the names suggested on that thread were:
>   MaxRecvDataLength        (21 May by Paul Konig)
>   MaxRecvDataSegmentSize   (21 May by Pat Thaler)
>   MaxRecvDataSegSize       (21 May by Pat Thaler)
>   MaxRecvPDUDataSize       (22 May by Pat Thaler)
>
> and what got into the draft was this last suggestion by Pat.
>
> I don't believe there was a consensus for this choice (probably, as
> was stated by Pat several times, because most people don't really see
> the need for a renaming and didn't bother to participate in the thread).
> Therefore, I would ask you to reconsider the new name and ask for
> consensus on the new choice.
>
> I believe the name MaxRecvDataSegmentLength is so closely linked to the
> name DataSegmentLength that its meaning should be clear to even a
> first-time reader, especially given the statement in section 9.7.1
> quoted above.
>
> Furthermore, there clearly is the concept of DataSegmentLength elsewhere
> in the standard -- every PDU has a DataSegmentLength field.
> I could find no concept of PDUDataSize (or even "data size") elsewhere in
> the current draft.
>
>
> Whether or not this renaming happens (again), I believe there should be
> the following rewordings to be more precise in order to avoid any
> ambiguities and/or future misinterpretations.
>
> The first sentence in section 9.10.5 should be changed to read:
>
>  "The DataSegmentLength in a Text Request MUST NOT exceed the
>  iSCSI target's MaxRecvDataSegmentLength (a per connection and per
>  direction negotiated parameter)."
>
> and the first sentence in section 9.11.6 should be changed to read:
>
>  "The DataSegmentLength in a Text Request MUST NOT exceed the
>  iSCSI initiator's MaxRecvDataSegmentLength (a per connection and per
>  direction negotiated parameter)."
>
> Finally, two sentences in section 11.13 should be changed to read:
>
>  "The initiator or target declares the maximum DataSegmentLength in
>  bytes it can receive in an iSCSI PDU."
>
> and
>
>  "The transmitter (initiator or target) is required to send PDUs with a
>  DataSegmentLength not exceeding MaxRecvDataSegmentLength of the
> receiver."
>
>
> Thank you for your consideration,
>
>
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774