SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI: keys/parameter dependence



    
    Julian:
    
    
    > 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.
    
    No problem -- sorry we didn't discover it sooner.
    
    Although this will probably not get into the draft,
    could you confirm (or not) my interpretation of what
    a "step" is in the context of an authentication exchange,
    and also could you confirm (or not) my interpretation of
    how these keys can be distributed over several pdus
    (as in the examples I cited)?  Your confirmation would
    be extremely useful to us in constructing
    conformance and interoperability tests.
    
    Thanks again,
    Bob Russell
    
    >
    >
    >
    > "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
    >
    >
    


Home

Last updated: Tue Jan 28 16:19:03 2003
12267 messages in chronological order