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 h0RN9IU28709 for ips-outgoing; Mon, 27 Jan 2003 18:09:18 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h0RN9EW28705 for ; Mon, 27 Jan 2003 18:09:15 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0RN8r36019844; Tue, 28 Jan 2003 00:08:53 +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 h0RN8rKt181948; Tue, 28 Jan 2003 00:08:53 +0100 In-Reply-To: To: "Robert D. Russell" Cc: "" 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 01:08:51 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 28/01/2003 01:08:52, Serialize complete at 28/01/2003 01:08:52 Content-Type: multipart/alternative; boundary="=_alternative 007EE5CDC2256CBB_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 007EE5CDC2256CBB_= Content-Type: text/plain; charset="US-ASCII" 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" 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 007EE5CDC2256CBB_= Content-Type: text/html; charset="US-ASCII"
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
--=_alternative 007EE5CDC2256CBB_=--