Re: iscsi: comments to iSCSI rev 6

["Matt Wakeley" <matt_wakeley@agilent.com>]

julian_satran@il.ibm.com wrote:

> +++ residual counts are not necessarily errors. Interpretation is by target
> and many commands for undefined length transfer end having a residual
> count. The space is available in the header so I see no point in not
> sending the counts. SAM2 is somewhat ambivalent about overflow though. +++

But residuals are generally not normal behavior right?  So then make them only
in the response.  That makes just one less option to implement (I don't care
about if there is space in the header or not, the issue is implementing,
testing and interoperating options).  Status within a data PDU would then mean
success with a residue of zero.  Anything else is reported in a response PDU.

> Section 2.8.3: Keys not understood by the target should be expicitely
> indicated as not being understood.  Silence is not a good way to indicate
> that one does not understand something.
>
> +++ as for keys not understood the intent is to have new or vendor specific
> keys not interfering with the old or standrd only implementations  +++

How will returning "key=*not understood*" going to interfer with anything? 
It's much better than silence.

> Section 2.12.3: indicate that the LUN is copied from the NOP-IN.  This is
> much more clear than "the correct value for the task".
> 
> +++ and open it up to strange thing like LU5 asking a nop-out to LU7 ? +++

How will that occur?  The target sent the NOP-IN ping request.  The target
includes a LUN.  The only "correct value" that the initiator can return for
the LUN in the NOP-OUT ping response is the value the target sent in the
original request.

> Section 2.14: Why is there no CmdSN for the logout command?  Also, 2 ways
> of performing the same operation (cleaning up) are stated in the 3rd
> paragraph.
> In the interest of reducing "options", I suggest that one be picked as the
> only method.
> +++ silly mistake - i've fixed it +++

I assume you're talking about the missing CmdSN.  You didn't address the issue
of eliminating one of the two ways of cleaning up.

> Section 2.17.4: "The target assigns" should be "The target may assign".
> +++ ??? it always put something there +++

Yes, it must always put something there.  But "assign" means it picks a unique
value and is actively using it.  Unassigned means that it is not used, and the
unassigned value of 0xffffffff is used.  

> Appendix: "Initial Marker-less Interval" - I say again, there should not be
> a "minimum markerless interval".  This should be whatever is negotiated.
> +++ The negotiation itself can't proceed if there are markers that nobody
> knows how to take out +++

Julian, you just keep missing my point.  There are no markers until after
login negotiation.  Part of the negotiation is to say where the first marker
will be.  If I only use 100 bytes to log in, and I want markers every 1024
bytes, I should not have to wait 3900 bytes to get to the first one just
because the spec arbitrarily picked 4K as the minimum amount of markerless
space.

-Matt Wakeley
Agilent Technologies