Re: iscsi: comments to iSCSI rev 6

[julian_satran@il.ibm.com]

Matt,

Comments in text.

I still did not hear any comment from you on the commad codes you where so
concerned about.

Julo

"Matt Wakeley" <matt_wakeley@agilent.com> on 01-05-2001 23:46:26

Please respond to Matt Wakeley <matt_wakeley@agilent.com>

To:   IPS Reflector <ips@ece.cmu.edu>
cc:
Subject:  Re: iscsi: comments to iSCSI rev 6




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.

+++ On the contrary for some devices  residual counts are normal and
frequent. Reading from a tape with a variable length block will usually
result in an underrun. Besides - except for the mapping the path for
handling is the same as for a separate response so that I have a hard time
understanding the implementation argument.
++++

> 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  +++

+++ yet another way for a DOS attack - but I will change it. The text will
read now:

Any other key not understood by the target may be ignored by the target
without affecting basic function. However the Text Response for a key that
was not understood MUST be key=NotUnderstood.

   If the Text Response does not contain the key requested, the initiator
   must assume, whenever appropriate, that the response was "none".


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.

+++ OK +++

> 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.

+++ That seems to be an endless discussion. Whever I take it out there is
somebody that asks for the colapse. The only good argument for the colapse
is single connection targets that whithout this option in login will reject
the second login +++

> 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.

+++ my english dictionary - Webster - shows no such connotation +++

> 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.


+++ OK and analyzers will take care of themselves

The new part will read:

01   Initial Marker-less Interval

   To enable the connection setup including the login phase negotiation,
   marking (if any) is started only at the first marker interval after the
   end of the login phase.

-Matt Wakeley
Agilent Technologies