RE: iSCSI: keys/parameter dependence

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

Bob,

I agree that the wording for 1 that
you suggest is better than the current text and If I will have a chance
I will do it (during the last correction pass of the RFC editor - called
48 Hours). For your second point  things are more complex and we will
probably have to live with the current text.

Regards,
Julo

"Robert D. Russell" <rdr@io.iol.unh.edu>

27/01/03 21:43

To	Julian Satran/Haifa/IBM@IBMIL, "" <ips@ece.cmu.edu>
cc
Subject	RE: iSCSI: keys/parameter dependence

Julian:

A request for clarification on some wording in the current standard
(draft 20).

1.  In section 5 on page 50, in the 4th paragraph (the one starting:
        "For the keys that require negotiation
...")
    the second sentence says:
        "The other party (the accepting party)
makes a selection
        based on the value or list of values proposed
and includes
        the selected value in a key=value in the data
part of the
        following Login or Text Response or Request."

    The problem is with the word "following".  A
very long discussion
    on the mailing list last June, under the thread
        "iSCSI: keys/parameter dependence"
    made it clear that the reply key=value to an offer does not
have
    to be given in the immediately following response pdu, but
can be
    delayed until some later time before the end of the negotiation
    stage.  In other words, responses can be saved up and
"batched"
    in a later response pdu.

    Therefore, I believe this intent would be better conveyed
if the
    words:
        "in the data part of the following Login
or Text Response or
        Request"
    in the current text on page 50 quoted above were changed
to:
        "in the data part of one of the following
Login or Text
                    
        ^^^^^^
        Responses or Requests"
                ^    
      ^


2.  There is a similar problem with some wording in section 8.2, in
    the fourth paragraph (the one starting with "Section
11 ...").
    The discussion in this paragraph talks about "steps",
and
    "exact steps", without defining what a "step"
is, and I believe
    this may need some clarification.

    Looking at section 11.1.4, the first step is taken by the
initiator
    when it sends:
        CHAP_A=<A1,A2...>
    to the target.
    The second step is taken by the target when it answers with
a
    Login reject or with:
        CHAP_A=<A> CHAP_I=<I> CHAP_C=<C>


    It is my understanding that in the second step, these 3 keys
could
    be sent by the target in any order, for example:
        CHAP_C=<C> CHAP_I=<I> CHAP_A=<A>
    and further, that they could be sent in separate pdus --
that
    is, the target could send
        CHAP_C=<C>
    in one Login Response pdu,
        CHAP_A=<A>
    in the next Login Response pdu, and finally
        CHAP_I=<I>
    in the final Login Response pdu.  All these pdus would
belong
    to the same step, and the step would not be completed until
    all the keys had been received, regardless of the number
of
    pdus that had to be exchanged to achieve this.

    Is this the correct interpretation of a "step"?

    And are the example exchanges shown above correct
    implementations of the first and second "steps"?

    Perhaps it would be clearer if the word "step"
were actually
    used in section 11.1.4.  For example, it could say:

        "For CHAP {RFC1994], in the first step,
the initiator
        sends:
            CHAP_A=<A1,A2...>"

        "In the second step, the target MUST answer
with .. "

        "In the third step, the initiator MUST
continue with ..."

    I believe it is already clear from the wording in section
8.2
    that a new step cannot be started until the previous step
is
    completed.


Thank you for your consideration.

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