Re: iSCSI: plugfest4 issues

["Julian Satran" <Julian_Satran@il.ibm.com>]

Comments in text - thanks - Julo

"Robert D. Russell" <rdr@io.iol.unh.edu> 07/30/2002 02:49 AM

To:        Julian Satran/Haifa/IBM@IBMIL         cc:        ips@ece.cmu.edu         Subject:        iSCSI: plugfest4 issues

Julian:

iSCSI plugfest 4 got underway today at UNH with 26 companies participating,
all testing at draft 13 of the standard.

Two issues came up today:

1. There appears to be a minor inconsistency in wording in draft 15:

Section 11.4 TargetName labels the Use of TargetName as:
  "ALL by target".

The very last sentence in this same section says:
 "The TargetName key may also be returned by the "SendTargets" text
 request (which is its only use when issued by a target)."

These 2 statements are inconsistent, because ALL implies there are other
times the target can send a TargetName key.

Either the "ALL" is wrong or the "only" is wrong.

I believe it is probably the word "only" that is wrong, and that it
should probably be replaced with a word like "principal", since, in
fact, the principal use of the TargetName key (but not its only use)
is as a reply to the "SendTargets".

+++ The only is lower-case and is meant to say that this is the only use the target has for the key
ALL is meant to show that the target can use it in all stages I will see how I can rephrase it and set is FFPO +++

2. Section 4.3 is clear that unless explicitly stated otherwise, keys can
only be sent during a specific stage.  What does not seem to be stated
anywhere is what should a receiver do if it receives a key in the wrong
stage.  Is this a "protocol error", or can the receiver just silently
throw the erroneous key way or, if the key is an operational key received
during security stage, can the receiver simply postpone responding to it
until after the transition into operational stage?  Also, in this
latter case, what happens if the key is also sent (again) during the
(proper) operational stage?  Is that an attempt at renegotiation?

I believe the simplest solution would be for the standard to explicitly
state in section 4.3 that sending a key outside the stage in which it
is allowed is a "protocol error", and that during login the Initiator
MUST close the connection and that the Target MUST send a Login Reject
and then close the connection (i.e., wording along the lines of that
in section 4.4 in the paragraph detailing what happens when there is
an attempt to negotiate a parameter more than once).
+++ will add a statement ++++
Thank you for your consideration.

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774