Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id h0SKi5h10728 for ips-outgoing; Tue, 28 Jan 2003 15:44:05 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h0SKhuW10714; Tue, 28 Jan 2003 15:43:56 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0SKhM5Q070032; Tue, 28 Jan 2003 21:43:23 +0100 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0SKhMnr087592; Tue, 28 Jan 2003 21:43:22 +0100 In-Reply-To: To: "Robert D. Russell" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: "Julian Satran" Message-ID: Date: Tue, 28 Jan 2003 22:43:19 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 28/01/2003 22:43:22, Serialize complete at 28/01/2003 22:43:22 Content-Type: multipart/alternative; boundary="=_alternative 007151E5C2256CBC_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 007151E5C2256CBC_= Content-Type: text/plain; charset="US-ASCII" Bob, Your interpretation is correct. The keys can be batched or distributed but the stated order must be maintained. Thanks, Julo "Robert D. Russell" Sent by: owner-ips@ece.cmu.edu 28/01/03 16:50 To Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc Subject 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" > 27/01/03 21:43 > > To > Julian Satran/Haifa/IBM@IBMIL, "" > 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= > to the target. > The second step is taken by the target when it answers with a > Login reject or with: > CHAP_A= CHAP_I= CHAP_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= CHAP_I= CHAP_A= > and further, that they could be sent in separate pdus -- that > is, the target could send > CHAP_C= > in one Login Response pdu, > CHAP_A= > in the next Login Response pdu, and finally > CHAP_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=" > > "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 > > --=_alternative 007151E5C2256CBC_= Content-Type: text/html; charset="US-ASCII"
Bob,

Your interpretation is correct. The keys can be batched  or distributed but the stated order must be maintained.

Thanks,
Julo


"Robert D. Russell" <rdr@io.iol.unh.edu>
Sent by: owner-ips@ece.cmu.edu

28/01/03 16:50

To
Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc
Subject
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
>
>
--=_alternative 007151E5C2256CBC_=--