From owner-ips@ece.cmu.edu Wed May 1 01:55:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22678 for ; Wed, 1 May 2002 01:55:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g415GEA15745 for ips-outgoing; Wed, 1 May 2002 01:16:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g415GAw15735; Wed, 1 May 2002 01:16:10 -0400 (EDT) Received: from russian.wrs.com (russian [147.11.45.28]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id WAA07596; Tue, 30 Apr 2002 22:15:09 -0700 (PDT) From: andy currid Received: (from andy@localhost) by russian.wrs.com (8.9.1/8.9.0) id WAA19606; Tue, 30 Apr 2002 22:16:00 -0700 (PDT) Message-Id: <200205010516.WAA19606@russian.wrs.com> Subject: Re: iSCSI: large keys during login? To: Julian_Satran@il.ibm.com (Julian Satran) Date: Tue, 30 Apr 2002 22:15:59 -0700 (PDT) Cc: pat_thaler@agilent.com ("THALER,PAT (A-Roseville,ex1)"), andy@windriver.com (andy currid), ips@ece.cmu.edu, owner-ips@ece.cmu.edu, wrstuden@wasabisystems.com (Bill Studenmund) In-Reply-To: from "Julian Satran" at Apr 30, 2002 03:34:47 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian The sections you refer to describe Text Request and Text Response PDUs. Unless I've misunderstood the spec, neither of those PDUs can be used during login; the only PDUs that are valid for use during login are Login Request and Login Response. I was under the impression that login phase was a very simple exchange; initiator sends a single Login Request PDU, target replies with a single Login Response PDU, repeat until logged in or rejected. How can you have a key value span multiple Login Request or Response PDUs? Unlike the Text PDUs, the Login PDUs do not contain the fields required to permit text to span PDUs (target tag, final bit, etc.). So there's no defined way to determine a text payload is being continued in a subsequent Login Request or Response PDU. Regards Andy > Pat, > > For spanning look at 9.10.4 and 9.11.4. > > I assume that the text covers whatever does not fit. > > > Regards, > Julo > > > > > "THALER,PAT (A-Roseville,ex1)" > 04/30/2002 02:24 AM > Please respond to "THALER,PAT (A-Roseville,ex1)" > > > To: Julian Satran/Haifa/IBM@IBMIL, Bill Studenmund > > cc: andy currid , ips@ece.cmu.edu, owner-ips@ece.cmu.edu > Subject: RE: iSCSI: large keys during login? > > > > Julian, > > I assume you mean that keys can span requests as well. I can't find > anything in the draft that says that they can though there also isn't > anything that says they can't. Does this only apply to key-value pairs too > long to fit in a single response or can a short key-value pair span a > request/response when multiple key-value pairs are packed into a PDU? > > The draft should clarify. > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, April 29, 2002 3:54 PM > To: Bill Studenmund > Cc: andy currid; ips@ece.cmu.edu; owner-ips@ece.cmu.edu > Subject: Re: iSCSI: large keys during login? > > > Key can span responses. Bookmarking is for things that have multiple > answers - like the SendTargets - Julo > > > > Bill Studenmund > Sent by: owner-ips@ece.cmu.edu > 04/30/2002 01:15 AM > Please respond to Bill Studenmund > > To: andy currid > cc: > Subject: Re: iSCSI: large keys during login? > > > > > On Mon, 29 Apr 2002, andy currid wrote: > > > > > Hi > > > > In iSCSI draft 12, chapter 10, the Kerberos and SPKM authentication > > mechanisms specify a limit of 64k on their unencoded key values. > > > > Given that these keys are only used during login and, during login, > > the PDU size in use is 8k and, unlike text commands, there is no > > bookmarking, how can you send a key value of this size during login? > > I thought that was covered. If you say you can do kerberos or SPKM, you > are saying you can do 64k. > > Take care, > > Bill > -- Andy Currid andy@windriver.com Server Products Group http://www.windriver.com Wind River Networks Phone : (1) 510 749 2191 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 From owner-ips@ece.cmu.edu Wed May 1 01:55:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22692 for ; Wed, 1 May 2002 01:55:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g415aZJ16590 for ips-outgoing; Wed, 1 May 2002 01:36:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g415aWw16584; Wed, 1 May 2002 01:36:32 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id HAA27448; Wed, 1 May 2002 07:36:15 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g415aDT163104; Wed, 1 May 2002 07:36:13 +0200 To: andy currid Cc: andy@windriver.com (andy currid), ips@ece.cmu.edu, owner-ips@ece.cmu.edu, pat_thaler@agilent.com ("THALER,PAT (A-Roseville,ex1)"), wrstuden@wasabisystems.com (Bill Studenmund) MIME-Version: 1.0 Subject: Re: iSCSI: large keys during login? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 1 May 2002 08:36:11 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/05/2002 08:36:14, Serialize complete at 01/05/2002 08:36:14 Content-Type: multipart/alternative; boundary="=_alternative 001EB8E7C2256BAC_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001EB8E7C2256BAC_= Content-Type: text/plain; charset="us-ascii" Andy, The data part is the same on both text and login. I will make o note to say this again in chapter 9. Julo andy currid 05/01/2002 08:15 AM Please respond to andy currid To: Julian Satran/Haifa/IBM@IBMIL cc: pat_thaler@agilent.com ("THALER,PAT (A-Roseville,ex1)"), andy@windriver.com (andy currid), ips@ece.cmu.edu, owner-ips@ece.cmu.edu, wrstuden@wasabisystems.com (Bill Studenmund) Subject: Re: iSCSI: large keys during login? Julian The sections you refer to describe Text Request and Text Response PDUs. Unless I've misunderstood the spec, neither of those PDUs can be used during login; the only PDUs that are valid for use during login are Login Request and Login Response. I was under the impression that login phase was a very simple exchange; initiator sends a single Login Request PDU, target replies with a single Login Response PDU, repeat until logged in or rejected. How can you have a key value span multiple Login Request or Response PDUs? Unlike the Text PDUs, the Login PDUs do not contain the fields required to permit text to span PDUs (target tag, final bit, etc.). So there's no defined way to determine a text payload is being continued in a subsequent Login Request or Response PDU. Regards Andy > Pat, > > For spanning look at 9.10.4 and 9.11.4. > > I assume that the text covers whatever does not fit. > > > Regards, > Julo > > > > > "THALER,PAT (A-Roseville,ex1)" > 04/30/2002 02:24 AM > Please respond to "THALER,PAT (A-Roseville,ex1)" > > > To: Julian Satran/Haifa/IBM@IBMIL, Bill Studenmund > > cc: andy currid , ips@ece.cmu.edu, owner-ips@ece.cmu.edu > Subject: RE: iSCSI: large keys during login? > > > > Julian, > > I assume you mean that keys can span requests as well. I can't find > anything in the draft that says that they can though there also isn't > anything that says they can't. Does this only apply to key-value pairs too > long to fit in a single response or can a short key-value pair span a > request/response when multiple key-value pairs are packed into a PDU? > > The draft should clarify. > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, April 29, 2002 3:54 PM > To: Bill Studenmund > Cc: andy currid; ips@ece.cmu.edu; owner-ips@ece.cmu.edu > Subject: Re: iSCSI: large keys during login? > > > Key can span responses. Bookmarking is for things that have multiple > answers - like the SendTargets - Julo > > > > Bill Studenmund > Sent by: owner-ips@ece.cmu.edu > 04/30/2002 01:15 AM > Please respond to Bill Studenmund > > To: andy currid > cc: > Subject: Re: iSCSI: large keys during login? > > > > > On Mon, 29 Apr 2002, andy currid wrote: > > > > > Hi > > > > In iSCSI draft 12, chapter 10, the Kerberos and SPKM authentication > > mechanisms specify a limit of 64k on their unencoded key values. > > > > Given that these keys are only used during login and, during login, > > the PDU size in use is 8k and, unlike text commands, there is no > > bookmarking, how can you send a key value of this size during login? > > I thought that was covered. If you say you can do kerberos or SPKM, you > are saying you can do 64k. > > Take care, > > Bill > -- Andy Currid andy@windriver.com Server Products Group http://www.windriver.com Wind River Networks Phone : (1) 510 749 2191 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 --=_alternative 001EB8E7C2256BAC_= Content-Type: text/html; charset="us-ascii"
Andy,

The data part is the same on both text and login.
I will make o note to say this again in chapter 9.

Julo


andy currid <andy@windriver.com>

05/01/2002 08:15 AM
Please respond to andy currid

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        pat_thaler@agilent.com ("THALER,PAT (A-Roseville,ex1)"), andy@windriver.com (andy currid), ips@ece.cmu.edu, owner-ips@ece.cmu.edu, wrstuden@wasabisystems.com (Bill Studenmund)
        Subject:        Re: iSCSI: large keys during login?

       



Julian

The sections you refer to describe Text Request and Text Response PDUs.
Unless I've misunderstood the spec, neither of those PDUs can be used
during login; the only PDUs that are valid for use during login are Login
Request and Login Response.

I was under the impression that login phase was a very simple
exchange; initiator sends a single Login Request PDU, target replies
with a single Login Response PDU, repeat until logged in or rejected.

How can you have a key value span multiple Login Request or Response
PDUs? Unlike the Text PDUs, the Login PDUs do not contain the fields
required to permit text to span PDUs (target tag, final bit, etc.). So
there's no defined way to determine a text payload is being continued
in a subsequent Login Request or Response PDU.

Regards

Andy


> Pat,
>
> For spanning look at 9.10.4 and 9.11.4.
>
> I assume that the text covers whatever does not fit.
>
>
> Regards,
> Julo
>
>
>
>
> "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
> 04/30/2002 02:24 AM
> Please respond to "THALER,PAT (A-Roseville,ex1)"
>
>  
>         To:     Julian Satran/Haifa/IBM@IBMIL, Bill Studenmund
> <wrstuden@wasabisystems.com>
>         cc:     andy currid <andy@windriver.com>, ips@ece.cmu.edu, owner-ips@ece.cmu.edu
>         Subject:        RE: iSCSI: large keys during login?
>
>  
>
> Julian,
>  
> I assume you mean that keys can span requests as well. I can't find
> anything in the draft that says that they can though there also isn't
> anything that says they can't. Does this only apply to key-value pairs too
> long to fit in a single response or can a short key-value pair span a
> request/response when multiple key-value pairs are packed into a PDU?
>  
> The draft should clarify.
>  
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Monday, April 29, 2002 3:54 PM
> To: Bill Studenmund
> Cc: andy currid; ips@ece.cmu.edu; owner-ips@ece.cmu.edu
> Subject: Re: iSCSI: large keys during login?
>
>
> Key can span responses. Bookmarking is for things that have multiple
> answers - like the SendTargets - Julo
>
>
>
> Bill Studenmund <wrstuden@wasabisystems.com>
> Sent by: owner-ips@ece.cmu.edu
> 04/30/2002 01:15 AM
> Please respond to Bill Studenmund
>        
>         To:        andy currid <andy@windriver.com>
>         cc:        <ips@ece.cmu.edu>
>         Subject:        Re: iSCSI: large keys during login?
>
>  
>
>
> On Mon, 29 Apr 2002, andy currid wrote:
>
> >
> > Hi
> >
> > In iSCSI draft 12, chapter 10, the Kerberos and SPKM authentication
> > mechanisms specify a limit of 64k on their unencoded key values.
> >
> > Given that these keys are only used during login and, during login,
> > the PDU size in use is 8k and, unlike text commands, there is no
> > bookmarking, how can you send a key value of this size during login?
>
> I thought that was covered. If you say you can do kerberos or SPKM, you
> are saying you can do 64k.
>
> Take care,
>
> Bill
>


--
Andy Currid                                       andy@windriver.com
Server Products Group                       http://www.windriver.com
Wind River Networks                         Phone : (1) 510 749 2191
500 Wind River Way, Alameda, CA 94501       Fax   : (1) 510 749 2560

--=_alternative 001EB8E7C2256BAC_=-- From owner-ips@ece.cmu.edu Wed May 1 10:13:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28781 for ; Wed, 1 May 2002 10:13:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41DBOG16470 for ips-outgoing; Wed, 1 May 2002 09:11:24 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41DBKw16463 for ; Wed, 1 May 2002 09:11:20 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id PAA11710 for ; Wed, 1 May 2002 15:11:13 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g41DBDT53246 for ; Wed, 1 May 2002 15:11:13 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: large keys during login? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 1 May 2002 16:11:07 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/05/2002 16:11:13, Serialize complete at 01/05/2002 16:11:13 Content-Type: multipart/alternative; boundary="=_alternative 004850D2C2256BAC_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004850D2C2256BAC_= Content-Type: text/plain; charset="us-ascii" In fact itis there at 9.12.10. I will add the same to 9.13 Julo ----- Forwarded by Julian Satran/Haifa/IBM on 05/01/2002 04:08 PM ----- Julian Satran 05/01/2002 08:35 AM To: andy currid cc: andy@windriver.com (andy currid), ips@ece.cmu.edu, owner-ips@ece.cmu.edu, pat_thaler@agilent.com ("THALER,PAT (A-Roseville,ex1)"), wrstuden@wasabisystems.com (Bill Studenmund) From: Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI: large keys during login? Andy, The data part is the same on both text and login. I will make o note to say this again in chapter 9. Julo andy currid 05/01/2002 08:15 AM Please respond to andy currid To: Julian Satran/Haifa/IBM@IBMIL cc: pat_thaler@agilent.com ("THALER,PAT (A-Roseville,ex1)"), andy@windriver.com (andy currid), ips@ece.cmu.edu, owner-ips@ece.cmu.edu, wrstuden@wasabisystems.com (Bill Studenmund) Subject: Re: iSCSI: large keys during login? Julian The sections you refer to describe Text Request and Text Response PDUs. Unless I've misunderstood the spec, neither of those PDUs can be used during login; the only PDUs that are valid for use during login are Login Request and Login Response. I was under the impression that login phase was a very simple exchange; initiator sends a single Login Request PDU, target replies with a single Login Response PDU, repeat until logged in or rejected. How can you have a key value span multiple Login Request or Response PDUs? Unlike the Text PDUs, the Login PDUs do not contain the fields required to permit text to span PDUs (target tag, final bit, etc.). So there's no defined way to determine a text payload is being continued in a subsequent Login Request or Response PDU. Regards Andy > Pat, > > For spanning look at 9.10.4 and 9.11.4. > > I assume that the text covers whatever does not fit. > > > Regards, > Julo > > > > > "THALER,PAT (A-Roseville,ex1)" > 04/30/2002 02:24 AM > Please respond to "THALER,PAT (A-Roseville,ex1)" > > > To: Julian Satran/Haifa/IBM@IBMIL, Bill Studenmund > > cc: andy currid , ips@ece.cmu.edu, owner-ips@ece.cmu.edu > Subject: RE: iSCSI: large keys during login? > > > > Julian, > > I assume you mean that keys can span requests as well. I can't find > anything in the draft that says that they can though there also isn't > anything that says they can't. Does this only apply to key-value pairs too > long to fit in a single response or can a short key-value pair span a > request/response when multiple key-value pairs are packed into a PDU? > > The draft should clarify. > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Monday, April 29, 2002 3:54 PM > To: Bill Studenmund > Cc: andy currid; ips@ece.cmu.edu; owner-ips@ece.cmu.edu > Subject: Re: iSCSI: large keys during login? > > > Key can span responses. Bookmarking is for things that have multiple > answers - like the SendTargets - Julo > > > > Bill Studenmund > Sent by: owner-ips@ece.cmu.edu > 04/30/2002 01:15 AM > Please respond to Bill Studenmund > > To: andy currid > cc: > Subject: Re: iSCSI: large keys during login? > > > > > On Mon, 29 Apr 2002, andy currid wrote: > > > > > Hi > > > > In iSCSI draft 12, chapter 10, the Kerberos and SPKM authentication > > mechanisms specify a limit of 64k on their unencoded key values. > > > > Given that these keys are only used during login and, during login, > > the PDU size in use is 8k and, unlike text commands, there is no > > bookmarking, how can you send a key value of this size during login? > > I thought that was covered. If you say you can do kerberos or SPKM, you > are saying you can do 64k. > > Take care, > > Bill > -- Andy Currid andy@windriver.com Server Products Group http://www.windriver.com Wind River Networks Phone : (1) 510 749 2191 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 --=_alternative 004850D2C2256BAC_= Content-Type: text/html; charset="us-ascii"
In fact itis there at 9.12.10. I will add the same to 9.13 Julo
----- Forwarded by Julian Satran/Haifa/IBM on 05/01/2002 04:08 PM -----
Julian Satran

05/01/2002 08:35 AM


        To:        andy currid <andy@windriver.com>
        cc:        andy@windriver.com (andy currid), ips@ece.cmu.edu, owner-ips@ece.cmu.edu, pat_thaler@agilent.com ("THALER,PAT (A-Roseville,ex1)"), wrstuden@wasabisystems.com (Bill Studenmund)
        From:        Julian Satran/Haifa/IBM@IBMIL
        Subject:        Re: iSCSI: large keys during login?Link
 





Andy,

The data part is the same on both text and login.
I will make o note to say this again in chapter 9.

Julo


andy currid <andy@windriver.com>

05/01/2002 08:15 AM
Please respond to andy currid

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        pat_thaler@agilent.com ("THALER,PAT (A-Roseville,ex1)"), andy@windriver.com (andy currid), ips@ece.cmu.edu, owner-ips@ece.cmu.edu, wrstuden@wasabisystems.com (Bill Studenmund)
        Subject:        Re: iSCSI: large keys during login?

       



Julian

The sections you refer to describe Text Request and Text Response PDUs.
Unless I've misunderstood the spec, neither of those PDUs can be used
during login; the only PDUs that are valid for use during login are Login
Request and Login Response.

I was under the impression that login phase was a very simple
exchange; initiator sends a single Login Request PDU, target replies
with a single Login Response PDU, repeat until logged in or rejected.

How can you have a key value span multiple Login Request or Response
PDUs? Unlike the Text PDUs, the Login PDUs do not contain the fields
required to permit text to span PDUs (target tag, final bit, etc.). So
there's no defined way to determine a text payload is being continued
in a subsequent Login Request or Response PDU.

Regards

Andy


> Pat,
>
> For spanning look at 9.10.4 and 9.11.4.
>
> I assume that the text covers whatever does not fit.
>
>
> Regards,
> Julo
>
>
>
>
> "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
> 04/30/2002 02:24 AM
> Please respond to "THALER,PAT (A-Roseville,ex1)"
>
>  
>         To:     Julian Satran/Haifa/IBM@IBMIL, Bill Studenmund
> <wrstuden@wasabisystems.com>
>         cc:     andy currid <andy@windriver.com>, ips@ece.cmu.edu, owner-ips@ece.cmu.edu
>         Subject:        RE: iSCSI: large keys during login?
>
>  
>
> Julian,
>  
> I assume you mean that keys can span requests as well. I can't find
> anything in the draft that says that they can though there also isn't
> anything that says they can't. Does this only apply to key-value pairs too
> long to fit in a single response or can a short key-value pair span a
> request/response when multiple key-value pairs are packed into a PDU?
>  
> The draft should clarify.
>  
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Monday, April 29, 2002 3:54 PM
> To: Bill Studenmund
> Cc: andy currid; ips@ece.cmu.edu; owner-ips@ece.cmu.edu
> Subject: Re: iSCSI: large keys during login?
>
>
> Key can span responses. Bookmarking is for things that have multiple
> answers - like the SendTargets - Julo
>
>
>
> Bill Studenmund <wrstuden@wasabisystems.com>
> Sent by: owner-ips@ece.cmu.edu
> 04/30/2002 01:15 AM
> Please respond to Bill Studenmund
>        
>         To:        andy currid <andy@windriver.com>
>         cc:        <ips@ece.cmu.edu>
>         Subject:        Re: iSCSI: large keys during login?
>
>  
>
>
> On Mon, 29 Apr 2002, andy currid wrote:
>
> >
> > Hi
> >
> > In iSCSI draft 12, chapter 10, the Kerberos and SPKM authentication
> > mechanisms specify a limit of 64k on their unencoded key values.
> >
> > Given that these keys are only used during login and, during login,
> > the PDU size in use is 8k and, unlike text commands, there is no
> > bookmarking, how can you send a key value of this size during login?
>
> I thought that was covered. If you say you can do kerberos or SPKM, you
> are saying you can do 64k.
>
> Take care,
>
> Bill
>


--
Andy Currid                                       andy@windriver.com
Server Products Group                       http://www.windriver.com
Wind River Networks                         Phone : (1) 510 749 2191
500 Wind River Way, Alameda, CA 94501       Fax   : (1) 510 749 2560



--=_alternative 004850D2C2256BAC_=-- From owner-ips@ece.cmu.edu Wed May 1 12:59:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08447 for ; Wed, 1 May 2002 12:59:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41GEwV01084 for ips-outgoing; Wed, 1 May 2002 12:14:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41GEtw01076; Wed, 1 May 2002 12:14:55 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id B11A030706; Wed, 1 May 2002 12:14:54 -0400 (EDT) Date: Wed, 1 May 2002 09:14:18 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: andy currid , , , "THALER,PAT (A-Roseville,ex1)" Subject: Re: iSCSI: large keys during login? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 1 May 2002, Julian Satran wrote: > Andy, > > The data part is the same on both text and login. > I will make o note to say this again in chapter 9. Julian, I think the grit of Andy's question still stands. At least I'm now puzzled by a question he raised. :-) I agree that the section you quote, 9.12.10, describes what keys can be used when & refers to the correct chapters. I think Andy's question, or the question I now have, is how do we do the equivalent of the multi-part exchange shown in section 9.10.3 (towards the bottom of page 156) with Login PDU's? We don't have a Target Transfer Tag field? Do we need to add one? Take care, Bill From owner-ips@ece.cmu.edu Wed May 1 13:00:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08519 for ; Wed, 1 May 2002 13:00:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41GdcL03407 for ips-outgoing; Wed, 1 May 2002 12:39:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41GdYw03396; Wed, 1 May 2002 12:39:34 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id SAA156868; Wed, 1 May 2002 18:39:25 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g41GdOT36002; Wed, 1 May 2002 18:39:24 +0200 To: Bill Studenmund Cc: andy currid , ips@ece.cmu.edu, owner-ips@ece.cmu.edu, "THALER,PAT (A-Roseville,ex1)" MIME-Version: 1.0 Subject: Re: iSCSI: large keys during login? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 1 May 2002 19:39:20 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/05/2002 19:39:24, Serialize complete at 01/05/2002 19:39:24 Content-Type: multipart/alternative; boundary="=_alternative 005B5677C2256BAC_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005B5677C2256BAC_= Content-Type: text/plain; charset="us-ascii" I pointed to that earlier. TTT are needed only for multiple answers to one query (like SendTargets). Spanning responses over several PDUs can be handled in different ways. Here is a simple example: I->T Key=a T-> Key=bbbbb (and does not end here i.e., no null in the PDU) I->T (empty or something else) T->I bbbb(0) .... (something else) Julo Bill Studenmund 05/01/2002 07:14 PM Please respond to Bill Studenmund To: Julian Satran/Haifa/IBM@IBMIL cc: andy currid , , , "THALER,PAT (A-Roseville,ex1)" Subject: Re: iSCSI: large keys during login? On Wed, 1 May 2002, Julian Satran wrote: > Andy, > > The data part is the same on both text and login. > I will make o note to say this again in chapter 9. Julian, I think the grit of Andy's question still stands. At least I'm now puzzled by a question he raised. :-) I agree that the section you quote, 9.12.10, describes what keys can be used when & refers to the correct chapters. I think Andy's question, or the question I now have, is how do we do the equivalent of the multi-part exchange shown in section 9.10.3 (towards the bottom of page 156) with Login PDU's? We don't have a Target Transfer Tag field? Do we need to add one? Take care, Bill --=_alternative 005B5677C2256BAC_= Content-Type: text/html; charset="us-ascii"
I pointed to that earlier. TTT are needed only for multiple answers to one query (like SendTargets).
Spanning responses  over several PDUs can be handled in different ways.
Here is a simple example:

I->T Key=a
T-> Key=bbbbb (and does not end here i.e., no null in the PDU)

I->T      (empty or something else)
T->I bbbb(0) .... (something else)

Julo


Bill Studenmund <wrstuden@wasabisystems.com>

05/01/2002 07:14 PM
Please respond to Bill Studenmund

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        andy currid <andy@windriver.com>, <ips@ece.cmu.edu>, <owner-ips@ece.cmu.edu>, "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
        Subject:        Re: iSCSI: large keys during login?

       


On Wed, 1 May 2002, Julian Satran wrote:

> Andy,
>
> The data part is the same on both text and login.
> I will make o note to say this again in chapter 9.

Julian, I think the grit of Andy's question still stands. At least I'm now
puzzled by a question he raised. :-)

I agree that the section you quote, 9.12.10, describes what keys can be
used when & refers to the correct chapters.

I think Andy's question, or the question I now have, is how do we do the
equivalent of the multi-part exchange shown in section 9.10.3 (towards the
bottom of page 156) with Login PDU's? We don't have a Target Transfer Tag
field?

Do we need to add one?

Take care,

Bill

--=_alternative 005B5677C2256BAC_=-- From owner-ips@ece.cmu.edu Wed May 1 13:01:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08652 for ; Wed, 1 May 2002 13:01:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41GXvB02838 for ips-outgoing; Wed, 1 May 2002 12:33:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41GXow02827 for ; Wed, 1 May 2002 12:33:50 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id A723B3070C; Wed, 1 May 2002 12:33:49 -0400 (EDT) Date: Wed, 1 May 2002 09:33:14 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Martins Krikis Cc: Subject: Re: iSCSI: RE: iSCSI 4.1 & 4.2 In-Reply-To: <20020430215811.10794.qmail@web13709.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 30 Apr 2002, Martins Krikis wrote: > I simply don't think that it is nice that iSCSI > regards 017 as decimal 17 while the rest of the > world would treat it as decimal 15. Stating that > non-zero decimals must not start with 0 would > leave less room for confusion. Agreed. It also means we can, as was mentioned, use strtol(). :-) Take care, Bill From owner-ips@ece.cmu.edu Wed May 1 13:22:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09637 for ; Wed, 1 May 2002 13:22:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41GsZZ04743 for ips-outgoing; Wed, 1 May 2002 12:54:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41GsXw04738; Wed, 1 May 2002 12:54:33 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 1D45530706; Wed, 1 May 2002 12:54:33 -0400 (EDT) Date: Wed, 1 May 2002 09:53:57 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: andy currid , , , "THALER,PAT (A-Roseville,ex1)" Subject: Re: iSCSI: large keys during login? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 1 May 2002, Julian Satran wrote: > I pointed to that earlier. TTT are needed only for multiple answers to one > query (like SendTargets). > Spanning responses over several PDUs can be handled in different ways. > Here is a simple example: > > I->T Key=a > T-> Key=bbbbb (and does not end here i.e., no null in the PDU) ^^^^^^^^^^^^^^^^^^^^^^^^ That's the part that was missing! Thanks. Could we please clarify this in the text? > I->T (empty or something else) > T->I bbbb(0) .... (something else) Could we have an example of this please? Also, I'd like to suggest that the I->T PDU be empty, or at least not include new negotiations. For one side to be able to inject new negotiations while the other is trying to send its last negotiated set will make negotiation handling complicated. Take care, Bill From owner-ips@ece.cmu.edu Wed May 1 13:42:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10321 for ; Wed, 1 May 2002 13:42:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41HE5E06351 for ips-outgoing; Wed, 1 May 2002 13:14:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41HE2w06346 for ; Wed, 1 May 2002 13:14:02 -0400 (EDT) Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.110.250.119]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id E6847B9F; Wed, 1 May 2002 12:13:56 -0500 (CDT) Received: from cxoexc12.americas.cpqcorp.net ([16.112.144.135]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 1 May 2002 12:13:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: questions about FCIP connection failure detection Date: Wed, 1 May 2002 11:13:55 -0600 Message-ID: <08DC7D0912B46D4EBF224A34371D7BC201AAF31C@cxoexc12.americas.cpqcorp.net> Thread-Topic: questions about FCIP connection failure detection Thread-Index: AcHsmcmVHRllCleqEdaUgACw0PIHqQAlDA9AABJpNrAAvNTZEAAxDzywAADGIfA= From: "Fraser, Don" To: "Chong Peng" Cc: X-OriginalArrivalTime: 01 May 2002 17:13:56.0900 (UTC) FILETIME=[93D63640:01C1F133] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g41HE2w06348 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Chong: The other techniques that I mention are all local to one gateway as they presume that the TCP link is out and there is no way to communicate with the other end. Thus it is not required that they be interoperable, just predictable in their behavior across any implementation. Don.. -----Original Message----- From: Chong Peng [mailto:ChongPeng@MaXXan.com] Sent: Wednesday, May 01, 2002 10:53 AM To: Fraser, Don Cc: ips@ece.cmu.edu Subject: RE: questions about FCIP connection failure detection Don: My thought is that "there are several other link outage detection techniques" might cause interoperability problem. Are those link outage detection techniques interoperable? Because if they are not, and the FCIP spec does not specify which should be used, we will have interoperability problem. Chong Peng -----Original Message----- From: Fraser, Don [mailto:Don.Fraser@COMPAQ.com] Sent: Tuesday, April 30, 2002 11:17 AM To: Chong Peng; ips@ece.cmu.edu Subject: RE: questions about FCIP connection failure detection Hi; I don't think you missed anything in your understanding of the FCIP keep-alive timer. And yes it is true that for it to work, both sides must use the same messages. Please remember that there are several other link outage detection techniques intended to detect outages much faster than 2 hours. All of these are listed in the table at the very end of the FCIP draft. Then upon detecting an outage of the TCP connect, the FCIP entity is to report those to the FC entity which in turn informs the FC fabric of the FCIP link outage. In addition at the Fibre Channel fabric level, one should also expect the basic Fibre Channel hello protocol to also periodically test the status of the same TCP connection but between FCIP switching elements, not at the TCP stack level. Don -----Original Message----- From: Chong Peng [mailto:ChongPeng@MaXXan.com] Sent: Friday, April 26, 2002 5:25 PM To: Fraser, Don; ips@ece.cmu.edu Subject: RE: questions about FCIP connection failure detection Don: Thanks for the explaination. But I do have another question. Here is my understanding: A TCP connection can fail in two different situations. (1) TCP connection fails when data flows across it. (2) TCP connection fails when there is no data flows across it. For example, the one end of a TCP connection crashes/reboot while no data exchanged across the TCP connection. Failure (1) is relatively easy to detect. For example, after TCP does re-transmit for a few times, it will send a RST. So, eventually, both ends of the TCP connection will notice the failure. Failure (2) is relatively hard to handle. When one end get rebooted, there is a possiblity that the other end never notice the failure. This is especially true when the end get rebooted is the TCP client, because usually, when the TCP clients do not send service requests to the TCP servers, the TCP servers would not send anything to the TCP clients. That is why TCP keep-alive timer, although not defined in RFC 793, come into the place in some of the TCP implementations. I believe the purpose of the TCP keep-alive timer is to guranteer that both ends of the TCP connection eventually detect failure (2), enev though it is after a long time (max two hours). Now look at the TCP failures in the context of FC over TCPIP. The first paragraph of Section 9.4 in FCIP spec basically says that, in order to detect failure (2) in FC over TCPIP, means other than TCP keep-alive timer is needed because two hours is too long. And the spec then suggests that "In order to facilitate faster detection of loss of connectivity, FC Entities SHOULD implement some form of Fibre Channel connection failure detection (see FC-BB-2 [4])". Here, my understanding is that the spec suggests some sort of "keep-alive like" scheme can be implemented in the FC entity. The question is: how can we keep the interoperability among FCIP devices from different vendors if we let vendors to implement their own "keep-alive like" scheme in the FC entity? My understanding is that any "keep-alive like" scheme involves message exchanges between two ends, in other word, for any "keep-alive like" scheme to work properly, both ends of the connection have to talk the same language. Do I understand this wrong or miss something here? chong peng -----Original Message----- From: Fraser, Don [mailto:Don.Fraser@compaq.com] Sent: Friday, April 26, 2002 7:29 AM To: Chong Peng; ips@ece.cmu.edu Subject: RE: questions about FCIP connection failure detection Hi: > In idle mode, a TCP Connection "keep alive" option of TCP is normally used to keep a connection alive. However, this timeout is fairly large and may prevent early detection of loss of connectivity. In order to facilitate faster detection of loss of connectivity, FC Entities SHOULD implement some form of Fibre Channel connection failure detection (see FC-BB-2 [4]). This is a not required to implement to pass interoperability with other FCIP gateways devices and is not in error. A vendor may choose to implement their own keep-alive to be used whenever there is no traffic received for the keep-alive time internal. > When an FCIP Entity discovers that TCP connectivity has been lost, the FCIP Entity SHALL notify the FC Entity of the failure including information about the reason for the failure. On the other hand the FCIP entity being closer to the TCP stack than the FC entity and is therefore able to detect and report the loss of TCP connectivity. The method of reporting this loss to the FC entity is left up to the implementer. In a revision of the FC-BB-2 made at the last T11 meeting in Vancouver it was approved to add the following to a new clause in section 16.3: 16.3.x FCIP Error Reporting The FC entity will receive notifications from the FCIP entity due to a number of errors detected by the FCIP entity. As a result, the E_Port implementation of the FC entity must report those errors to the local FC switch element via the local VE_port (see Fig 23). Similarly the B_Port implementation must report the error to the local VB_access port (see figure 26). In addition the FC entity may pass these error reports to the local PMM for inclusion in a local event log. In both cases, the FC entity shall convert the error message received from the FCIP entity into a Registered Link Incident Report (FC-FS RLIR). It is the RLIR that is forwarded from the FC entity to either the VE_Port (figure 23) or VB_Access (figure 26). On receipt of the message from the FC Entity, the VE_Port or VB_Access shall immediately forward the RLIR to the FC Switch Entity. As a minimum the FC Entity shall accept the following messages from the FCIP entity and shall transfer them as an RLIR to the FC Switching Element by the VE_Port or to the FC Network by the VB_Access: FCIP RFC Section 6.6.2.3: Loss of FC frame synchronization FCIP RFC Section 9.1.2.3: Failure to setup TCP connection FCIP RFC Section 9.1.3: TCP connect request timeout or Duplicate connect request FCIP RFC Section 9.2: Successful completion of FC Entity request to close TCP connection FCIP RFC Section 9.4: Loss of TCP connectivity FCIP RFC Section 10.4.3: Excessive number of dropped datagrams or Any confidentiality violations FCIP RFC Section 10.4.4: SA parameter mis-match Don Fraser Contributor to FCIP -----Original Message----- From: Chong Peng [mailto:ChongPeng@MaXXan.com] Sent: Thursday, April 25, 2002 2:48 PM To: ips@ece.cmu.edu Subject: questions about FCIP connection failure detection Hi, all The Section 9.4 (TCP Connection Considerations) of draft-ietf-ips-fcovertcpip-09 says: In idle mode, a TCP Connection "keep alive" option of TCP is normally used to keep a connection alive. However, this timeout is fairly large and may prevent early detection of loss of connectivity. In order to facilitate faster detection of loss of connectivity, FC Entities SHOULD implement some form of Fibre Channel connection failure detection (see FC-BB-2 [4]). When an FCIP Entity discovers that TCP connectivity has been lost, the FCIP Entity SHALL notify the FC Entity of the failure including information about the reason for the failure. I have a couple of questions regarding this section: 1. The first pragraph states that the FC entity is responsable to discover the connection failure. But the second paragraph implys the FCIP entity discovers the connection failure first and then notifies the FC entity. Is there an editorial error? 2. If we let the application protocol on the top of TCP to discover the connection failure, what scheme are we going to use? Are we planning to define some "FCIP keep alive" frames in the future? I checked FC-BB-2, in the section related to discovery (13.2.2.4.2), it says "TBD". Chong Peng This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized use; review, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by return email and destroy all copies of the original message. Copyright © 2002 MaXXan Systems, Inc. All rights reserved. This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized use; review, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by return email and destroy all copies of the original message. Copyright © 2002 MaXXan Systems, Inc. All rights reserved. This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized use; review, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by return email and destroy all copies of the original message. Copyright © 2002 MaXXan Systems, Inc. All rights reserved. From owner-ips@ece.cmu.edu Wed May 1 13:47:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10510 for ; Wed, 1 May 2002 13:47:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41Gr3E04606 for ips-outgoing; Wed, 1 May 2002 12:53:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from Relay1.MaXXan.com (63-203-52-246.makesans.com [63.203.52.246] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41Gr0w04599 for ; Wed, 1 May 2002 12:53:00 -0400 (EDT) Received: from mail pickup service by Relay1.MaXXan.com with Microsoft SMTPSVC; Wed, 1 May 2002 09:52:53 -0700 x-gfisavedcharset: iso-8859-1 Content-Type: text/plain; charset="iso-8859-1" Received: from kingler.MaXXan.com ([10.100.100.49]) by relay1.maxxan.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 1 May 2002 09:52:50 -0700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: questions about FCIP connection failure detection Content-Transfer-Encoding: quoted-printable Date: Wed, 1 May 2002 09:52:49 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: questions about FCIP connection failure detection thread-index: AcHsmcmVHRllCleqEdaUgACw0PIHqQAlDA9AABJpNrAAvNTZEAAxDzyw From: "Chong Peng" To: "Fraser, Don" Cc: X-OriginalArrivalTime: 01 May 2002 16:52:50.0258 (UTC) FILETIME=[A0DBFB20:01C1F130] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Don: My thought is that "there are several other link outage detection = techniques" might cause=20 interoperability problem. Are those link outage detection techniques = interoperable? Because=20 if they are not, and the FCIP spec does not specify which should be = used, we will have interoperability problem. Chong Peng -----Original Message----- From: Fraser, Don [mailto:Don.Fraser@COMPAQ.com] Sent: Tuesday, April 30, 2002 11:17 AM To: Chong Peng; ips@ece.cmu.edu Subject: RE: questions about FCIP connection failure detection Hi; I don't think you missed anything in your understanding of the FCIP = keep-alive timer. And yes it is true that for it to work, both sides = must use the same messages. =20 Please remember that there are several other link outage detection = techniques intended to detect outages much faster than 2 hours. All of = these are listed in the table at the very end of the FCIP draft. Then = upon detecting an outage of the TCP connect, the FCIP entity is to = report those to the FC entity which in turn informs the FC fabric of the = FCIP link outage. In addition at the Fibre Channel fabric level, one = should also expect the basic Fibre Channel hello protocol to also = periodically test the status of the same TCP connection but between FCIP = switching elements, not at the TCP stack level. Don -----Original Message----- From: Chong Peng [mailto:ChongPeng@MaXXan.com] Sent: Friday, April 26, 2002 5:25 PM To: Fraser, Don; ips@ece.cmu.edu Subject: RE: questions about FCIP connection failure detection Don: Thanks for the explaination. But I do have another question. Here is my understanding: A TCP connection can fail in two different situations. (1) TCP connection fails when data flows across it. (2) TCP connection fails when there is no data flows across it. For = example,=20 the one end of a TCP connection crashes/reboot while no data = exchanged=20 across the TCP connection. Failure (1) is relatively easy to detect. For example, after TCP does=20 re-transmit for a few times, it will send a RST. So, eventually, both ends of the TCP connection will notice the failure. Failure (2) is relatively hard to handle. When one end get rebooted, = there=20 is a possiblity that the other end never notice the failure. This is = especially=20 true when the end get rebooted is the TCP client, because usually, when the TCP clients do not send service requests to the TCP servers, the TCP = servers would not send anything to the TCP clients. That is why TCP = keep-alive=20 timer, although not defined in RFC 793, come into the place in some of = the=20 TCP implementations. I believe the purpose of the TCP keep-alive timer = is to=20 guranteer that both ends of the TCP connection eventually detect failure = (2),=20 enev though it is after a long time (max two hours). Now look at the TCP failures in the context of FC over TCPIP. The first = paragraph=20 of Section 9.4 in FCIP spec basically says that, in order to detect = failure (2) in FC over TCPIP, means other than TCP keep-alive timer is needed because = two hours=20 is too long. And the spec then suggests that "In order to facilitate = faster=20 detection of loss of connectivity, FC Entities SHOULD implement some = form of=20 Fibre Channel connection failure detection (see FC-BB-2 [4])". Here, my=20 understanding is that the spec suggests some sort of "keep-alive like" = scheme can be=20 implemented in the FC entity. The question is: how can we keep the = interoperability=20 among FCIP devices from different vendors if we let vendors to implement = their own=20 "keep-alive like" scheme in the FC entity? My understanding is that any=20 "keep-alive like" scheme involves message exchanges between two ends, in = other=20 word, for any "keep-alive like" scheme to work properly, both ends of = the=20 connection have to talk the same language. Do I understand this wrong or miss something here? chong peng -----Original Message----- From: Fraser, Don [mailto:Don.Fraser@compaq.com] Sent: Friday, April 26, 2002 7:29 AM To: Chong Peng; ips@ece.cmu.edu Subject: RE: questions about FCIP connection failure detection Hi: > In idle mode, a TCP Connection "keep alive" option of TCP is normally used to keep a connection alive. However, this timeout is fairly large and may prevent early detection of loss of connectivity. In order to facilitate faster detection of loss of connectivity, FC Entities SHOULD implement some form of Fibre Channel connection failure detection (see FC-BB-2 [4]). This is a not required to implement to pass interoperability with other = FCIP gateways devices and is not in error. A vendor may choose to = implement their own keep-alive to be used whenever there is no traffic = received for the keep-alive time internal. > When an FCIP Entity discovers that TCP connectivity has been lost, the FCIP Entity SHALL notify the FC Entity of the failure including information about the reason for the failure. On the other hand the FCIP entity being closer to the TCP stack than the = FC entity and is therefore able to detect and report the loss of TCP = connectivity. The method of reporting this loss to the FC entity is = left up to the implementer. In a revision of the FC-BB-2 made at the = last T11 meeting in Vancouver it was approved to add the following to a = new clause in section 16.3: 16.3.x FCIP Error Reporting The FC entity will receive notifications from the FCIP entity due to a = number of errors detected by the FCIP entity. As a result, the E_Port = implementation of the FC entity must report those errors to the local FC = switch element via the local VE_port (see Fig 23). Similarly the B_Port = implementation must report the error to the local VB_access port (see = figure 26). In addition the FC entity may pass these error reports to = the local PMM for inclusion in a local event log. In both cases, the FC entity shall convert the error message received = from the FCIP entity into a Registered Link Incident Report (FC-FS = RLIR). It is the RLIR that is forwarded from the FC entity to either = the VE_Port (figure 23) or VB_Access (figure 26). On receipt of the = message from the FC Entity, the VE_Port or VB_Access shall immediately = forward the RLIR to the FC Switch Entity. As a minimum the FC Entity shall accept the following messages from the = FCIP entity and shall transfer them as an RLIR to the FC Switching = Element by the VE_Port or to the FC Network by the VB_Access: FCIP RFC Section 6.6.2.3: Loss of FC frame synchronization FCIP RFC Section 9.1.2.3: Failure to setup TCP connection FCIP RFC Section 9.1.3: TCP connect request timeout or Duplicate = connect request FCIP RFC Section 9.2: Successful completion of FC Entity request to = close TCP connection FCIP RFC Section 9.4: Loss of TCP connectivity FCIP RFC Section 10.4.3: Excessive number of dropped datagrams or Any = confidentiality violations FCIP RFC Section 10.4.4: SA parameter mis-match Don Fraser Contributor to FCIP -----Original Message----- From: Chong Peng [mailto:ChongPeng@MaXXan.com]=20 Sent: Thursday, April 25, 2002 2:48 PM To: ips@ece.cmu.edu Subject: questions about FCIP connection failure detection Hi, all The Section 9.4 (TCP Connection Considerations) of = draft-ietf-ips-fcovertcpip-09=20 says: =20 In idle mode, a TCP Connection "keep alive" option of TCP is normally used to keep a connection alive. However, this timeout is fairly large and may prevent early detection of loss of connectivity. In order to facilitate faster detection of loss of connectivity, FC Entities SHOULD implement some form of Fibre Channel connection failure detection (see FC-BB-2 [4]). =20 When an FCIP Entity discovers that TCP connectivity has been lost, the FCIP Entity SHALL notify the FC Entity of the failure including information about the reason for the failure. I have a couple of questions regarding this section: 1. The first pragraph states that the FC entity is responsable to = discover the=20 connection failure. But the second paragraph implys the FCIP entity = discovers=20 the connection failure first and then notifies the FC entity. Is = there an=20 editorial error? 2. If we let the application protocol on the top of TCP to discover the=20 connection failure, what scheme are we going to use? Are we planning = to define some "FCIP keep alive" frames in the future? I checked = FC-BB-2, in the section related to discovery (13.2.2.4.2), it says "TBD". Chong Peng This email message is for the sole use of the intended recipient(s) and = may contain confidential information. Any unauthorized use; review, = disclosure or distribution is prohibited. If you are not the intended = recipient, please contact the sender by return email and destroy all = copies of the original message.=20 Copyright =A9 2002 MaXXan Systems, Inc. All rights reserved. This email message is for the sole use of the intended recipient(s) and = may contain confidential information. Any unauthorized use; review, = disclosure or distribution is prohibited. If you are not the intended = recipient, please contact the sender by return email and destroy all = copies of the original message.=20 Copyright =A9 2002 MaXXan Systems, Inc. All rights reserved. This email message is for the sole use of the intended recipient(s) and = may contain confidential information. Any unauthorized use; review, = disclosure or distribution is prohibited. If you are not the intended = recipient, please contact the sender by return email and destroy all = copies of the original message.=20 Copyright =A9 2002 MaXXan Systems, Inc. All rights reserved. From owner-ips@ece.cmu.edu Wed May 1 14:01:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10944 for ; Wed, 1 May 2002 14:01:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41He9K08463 for ips-outgoing; Wed, 1 May 2002 13:40:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41He6w08456 for ; Wed, 1 May 2002 13:40:06 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id 0BE2FC00271 for ; Wed, 1 May 2002 10:40:01 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id KAA07407 for ; Wed, 1 May 2002 10:39:55 -0700 (PDT) Message-ID: <3CD029E8.8B926544@cup.hp.com> Date: Wed, 01 May 2002 10:46:16 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: large keys during login? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Studenmund wrote: > > On Wed, 1 May 2002, Julian Satran wrote: > > > I pointed to that earlier. TTT are needed only for multiple answers to one > > query (like SendTargets). > > Spanning responses over several PDUs can be handled in different ways. > > Here is a simple example: > > > > I->T Key=a > > T-> Key=bbbbb (and does not end here i.e., no null in the PDU) ^^^^^^^^^^^^^^^^^^^^^^^^^ Hello, I don't know how the above would work. Every string (in this case, the key=value string) is assumed to be NULL terminated. If this is not the case, the usage of standard string routines like strlen(), strcpy(), strstr(), etc will have problems in the iscsi login/text parsers. I think the multi-pdu fragmentation and re-assembly mechanisms must be uniform across both the login and text pdu's allowing the same code to be re-used in both the login and text parsers. Hence, it would be better to have the TTT and F bit in the login pdu. The receiving side must not interpret any received keys, but simply store them, send an empty login/login_rsp pdu back with the TTT set and eventually perform re-assembly until the sending side sends a pdu with the F bit set. When the 'F' bit PDU is received, the keys may be interpreted, negotiations performed, and if necessary, another login/login_rsp pdu be sent indicating the appropriate (CSG, NSG, T) setting. Regards, Santosh -- We have enough people who tell it like it is Now we could use a few who tell it like it can be. - Robert Orben From owner-ips@ece.cmu.edu Wed May 1 14:33:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14966 for ; Wed, 1 May 2002 14:33:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41IAB811208 for ips-outgoing; Wed, 1 May 2002 14:10:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41IA8w11199 for ; Wed, 1 May 2002 14:10:08 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g41I9xpY025391; Wed, 1 May 2002 11:09:59 -0700 (PDT) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA01834; Wed, 1 May 2002 11:10:00 -0700 (PDT) Message-ID: <3CD02B5B.677319CE@cisco.com> Date: Wed, 01 May 2002 12:52:27 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Julian Satran CC: ips@ece.cmu.edu Subject: Re: iSCSI 4.1 & 4.2 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian- Text-value is also used for initiator names, target names, and aliases, which are UTF-8 encoded, so they don't fit into the current text-value definition. Here are two more text value types we should add. -- Mark Julian Satran wrote: > > text-value: a string defined by the regular expression > "[][a-zA-Z0-9.-+@_/\[\]=]*" Used by InitiatorName and TargetName: name-value: a UTF-8 string, with its valid character set defined in draft-ietf-ips-iscsi-string-prep-00. Used by InitiatorAlias and TargetAlias: utf8-value: any UTF-8 string, terminated by a null character, Ranges and comma-separated lists are not allowed for keys that use this type. -- Mark From owner-ips@ece.cmu.edu Wed May 1 14:44:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16554 for ; Wed, 1 May 2002 14:44:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41I5Oo10774 for ips-outgoing; Wed, 1 May 2002 14:05:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from athena.demit.net (adsl-64-164-205-50.dsl.snfc21.pacbell.net [64.164.205.50]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41I5Kw10769 for ; Wed, 1 May 2002 14:05:20 -0400 (EDT) Received: from carlos.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by athena.demit.net (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id AD0846F51; Wed, 1 May 2002 11:05:18 -0700 (PDT) Message-Id: <5.1.0.14.0.20020501104954.00acfc78@pop3.silverbacksystems.com> X-Sender: crimola@athena.demit.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 01 May 2002 11:04:02 -0700 To: From: Carlos Rimola Subject: Re: iSCSI: large keys during login? Cc: andy currid , "THALER,PAT (A-Roseville,ex1)" , Bill Studenmund , Julian Satran In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk Hello, I believe the other point was the use of the F bit in Text requests/responses. In Login Text requests/responses, the same bit position is known as the T bit and is defined as the "Transition" to next stage indicator. Does this mean that the T bit in login request/responses should be interpreted in the same way as the F bit in text requests/responses? If this is the case, is this dual meaning of the T bit desirable? At the least, it would be useful for the spec to explicitly state the dual usage to remove any ambiguity. Carlos Rimola Silverback Systems At 09:14 AM 5/1/2002 -0700, Bill Studenmund wrote: >On Wed, 1 May 2002, Julian Satran wrote: > > > Andy, > > > > The data part is the same on both text and login. > > I will make o note to say this again in chapter 9. > >Julian, I think the grit of Andy's question still stands. At least I'm now >puzzled by a question he raised. :-) > >I agree that the section you quote, 9.12.10, describes what keys can be >used when & refers to the correct chapters. > >I think Andy's question, or the question I now have, is how do we do the >equivalent of the multi-part exchange shown in section 9.10.3 (towards the >bottom of page 156) with Login PDU's? We don't have a Target Transfer Tag >field? > >Do we need to add one? > >Take care, > >Bill From owner-ips@ece.cmu.edu Wed May 1 14:46:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16848 for ; Wed, 1 May 2002 14:46:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41IGqo11842 for ips-outgoing; Wed, 1 May 2002 14:16:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41IGjw11823; Wed, 1 May 2002 14:16:45 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id UAA41258; Wed, 1 May 2002 20:16:39 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g41IGc405796; Wed, 1 May 2002 20:16:38 +0200 To: Santosh Rao Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: large keys during login? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 1 May 2002 21:16:35 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/05/2002 21:16:39, Serialize complete at 01/05/2002 21:16:39 Content-Type: multipart/alternative; boundary="=_alternative 0063B6CAC2256BAC_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0063B6CAC2256BAC_= Content-Type: text/plain; charset="us-ascii" The mechanism is uniform. Spanning and multiresponse PDUs are different issues though. Julo Spanning is not happening often at login (not many keys extend above 8k). TTT is now the mechanism for target having more key=value for a single key=value query. Spanning is far simpler> We could colapse them and use TTT for both and if there is a bit needed it can't be F as F is the end of a sequence not a single negotiation. I think however that the simple string delimiter search that we have now is sufficient and the two mechanisms are sufficiently different to be kept separate. Julo Santosh Rao Sent by: owner-ips@ece.cmu.edu 05/01/2002 08:46 PM Please respond to Santosh Rao To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: large keys during login? Bill Studenmund wrote: > > On Wed, 1 May 2002, Julian Satran wrote: > > > I pointed to that earlier. TTT are needed only for multiple answers to one > > query (like SendTargets). > > Spanning responses over several PDUs can be handled in different ways. > > Here is a simple example: > > > > I->T Key=a > > T-> Key=bbbbb (and does not end here i.e., no null in the PDU) ^^^^^^^^^^^^^^^^^^^^^^^^^ Hello, I don't know how the above would work. Every string (in this case, the key=value string) is assumed to be NULL terminated. If this is not the case, the usage of standard string routines like strlen(), strcpy(), strstr(), etc will have problems in the iscsi login/text parsers. I think the multi-pdu fragmentation and re-assembly mechanisms must be uniform across both the login and text pdu's allowing the same code to be re-used in both the login and text parsers. Hence, it would be better to have the TTT and F bit in the login pdu. The receiving side must not interpret any received keys, but simply store them, send an empty login/login_rsp pdu back with the TTT set and eventually perform re-assembly until the sending side sends a pdu with the F bit set. When the 'F' bit PDU is received, the keys may be interpreted, negotiations performed, and if necessary, another login/login_rsp pdu be sent indicating the appropriate (CSG, NSG, T) setting. Regards, Santosh -- We have enough people who tell it like it is Now we could use a few who tell it like it can be. - Robert Orben --=_alternative 0063B6CAC2256BAC_= Content-Type: text/html; charset="us-ascii"
The mechanism is uniform. Spanning and multiresponse PDUs are different issues though. Julo Spanning is not happening often at login (not many keys extend above 8k).
TTT is now the mechanism for target having more key=value for a single key=value query. Spanning is far simpler> We could colapse them and use TTT for both and if there is a bit needed it can't be F as F is the end of a sequence not a single negotiation. I think however that the simple string delimiter search that we have now is sufficient and the two mechanisms are sufficiently different to be kept separate.

Julo


Santosh Rao <santoshr@cup.hp.com>
Sent by: owner-ips@ece.cmu.edu

05/01/2002 08:46 PM
Please respond to Santosh Rao

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        Re: iSCSI: large keys during login?

       


Bill Studenmund wrote:
>
> On Wed, 1 May 2002, Julian Satran wrote:
>
> > I pointed to that earlier. TTT are needed only for multiple answers to one
> > query (like SendTargets).
> > Spanning responses  over several PDUs can be handled in different ways.
> > Here is a simple example:
> >
> > I->T Key=a
> > T-> Key=bbbbb (and does not end here i.e., no null in the PDU)

                                           ^^^^^^^^^^^^^^^^^^^^^^^^^
Hello,

I don't know how the above would work. Every string (in this case, the
key=value string) is assumed to be NULL terminated. If this is not the
case, the usage of standard string routines like strlen(), strcpy(),
strstr(), etc will have problems in the iscsi login/text parsers.

I think the multi-pdu fragmentation and re-assembly mechanisms must be
uniform across both the login and text pdu's allowing the same code to
be re-used in both the login and text parsers.

Hence, it would be better to have the TTT and F bit in the login pdu.
The receiving side must not interpret any received keys, but simply
store them, send an empty login/login_rsp pdu back with the TTT set and
eventually perform re-assembly until the sending side sends a pdu with
the F bit set. When the 'F' bit PDU is received, the keys may be
interpreted, negotiations performed, and if necessary, another
login/login_rsp pdu be sent indicating the appropriate (CSG, NSG, T)
setting.

Regards,
Santosh


--
We have enough people who tell it like it is
Now we could use a few who tell it like it can be.

-  Robert Orben

--=_alternative 0063B6CAC2256BAC_=-- From owner-ips@ece.cmu.edu Wed May 1 14:47:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16942 for ; Wed, 1 May 2002 14:47:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41IZYE13565 for ips-outgoing; Wed, 1 May 2002 14:35:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from fed1mtao02.cox.net (fed1mtao02.cox.net [68.6.19.243]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41IZWw13560 for ; Wed, 1 May 2002 14:35:32 -0400 (EDT) Received: from CX418298C ([68.5.217.92]) by fed1mtao02.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020501183527.PZSI1370.fed1mtao02.cox.net@CX418298C>; Wed, 1 May 2002 14:35:27 -0400 From: "Murali Rajagopal" To: "Chong Peng" , "Fraser, Don" Cc: Subject: RE: questions about FCIP connection failure detection Date: Wed, 1 May 2002 11:36:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Chong: Can you point to a scenario in the FCIP spec where it may break interoperability? -Murali -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Chong Peng Sent: Wednesday, May 01, 2002 9:53 AM To: Fraser, Don Cc: ips@ece.cmu.edu Subject: RE: questions about FCIP connection failure detection Don: My thought is that "there are several other link outage detection techniques" might cause interoperability problem. Are those link outage detection techniques interoperable? Because if they are not, and the FCIP spec does not specify which should be used, we will have interoperability problem. Chong Peng -----Original Message----- From: Fraser, Don [mailto:Don.Fraser@COMPAQ.com] Sent: Tuesday, April 30, 2002 11:17 AM To: Chong Peng; ips@ece.cmu.edu Subject: RE: questions about FCIP connection failure detection Hi; I don't think you missed anything in your understanding of the FCIP keep-alive timer. And yes it is true that for it to work, both sides must use the same messages. Please remember that there are several other link outage detection techniques intended to detect outages much faster than 2 hours. All of these are listed in the table at the very end of the FCIP draft. Then upon detecting an outage of the TCP connect, the FCIP entity is to report those to the FC entity which in turn informs the FC fabric of the FCIP link outage. In addition at the Fibre Channel fabric level, one should also expect the basic Fibre Channel hello protocol to also periodically test the status of the same TCP connection but between FCIP switching elements, not at the TCP stack level. Don -----Original Message----- From: Chong Peng [mailto:ChongPeng@MaXXan.com] Sent: Friday, April 26, 2002 5:25 PM To: Fraser, Don; ips@ece.cmu.edu Subject: RE: questions about FCIP connection failure detection Don: Thanks for the explaination. But I do have another question. Here is my understanding: A TCP connection can fail in two different situations. (1) TCP connection fails when data flows across it. (2) TCP connection fails when there is no data flows across it. For example, the one end of a TCP connection crashes/reboot while no data exchanged across the TCP connection. Failure (1) is relatively easy to detect. For example, after TCP does re-transmit for a few times, it will send a RST. So, eventually, both ends of the TCP connection will notice the failure. Failure (2) is relatively hard to handle. When one end get rebooted, there is a possiblity that the other end never notice the failure. This is especially true when the end get rebooted is the TCP client, because usually, when the TCP clients do not send service requests to the TCP servers, the TCP servers would not send anything to the TCP clients. That is why TCP keep-alive timer, although not defined in RFC 793, come into the place in some of the TCP implementations. I believe the purpose of the TCP keep-alive timer is to guranteer that both ends of the TCP connection eventually detect failure (2), enev though it is after a long time (max two hours). Now look at the TCP failures in the context of FC over TCPIP. The first paragraph of Section 9.4 in FCIP spec basically says that, in order to detect failure (2) in FC over TCPIP, means other than TCP keep-alive timer is needed because two hours is too long. And the spec then suggests that "In order to facilitate faster detection of loss of connectivity, FC Entities SHOULD implement some form of Fibre Channel connection failure detection (see FC-BB-2 [4])". Here, my understanding is that the spec suggests some sort of "keep-alive like" scheme can be implemented in the FC entity. The question is: how can we keep the interoperability among FCIP devices from different vendors if we let vendors to implement their own "keep-alive like" scheme in the FC entity? My understanding is that any "keep-alive like" scheme involves message exchanges between two ends, in other word, for any "keep-alive like" scheme to work properly, both ends of the connection have to talk the same language. Do I understand this wrong or miss something here? chong peng -----Original Message----- From: Fraser, Don [mailto:Don.Fraser@compaq.com] Sent: Friday, April 26, 2002 7:29 AM To: Chong Peng; ips@ece.cmu.edu Subject: RE: questions about FCIP connection failure detection Hi: > In idle mode, a TCP Connection "keep alive" option of TCP is normally used to keep a connection alive. However, this timeout is fairly large and may prevent early detection of loss of connectivity. In order to facilitate faster detection of loss of connectivity, FC Entities SHOULD implement some form of Fibre Channel connection failure detection (see FC-BB-2 [4]). This is a not required to implement to pass interoperability with other FCIP gateways devices and is not in error. A vendor may choose to implement their own keep-alive to be used whenever there is no traffic received for the keep-alive time internal. > When an FCIP Entity discovers that TCP connectivity has been lost, the FCIP Entity SHALL notify the FC Entity of the failure including information about the reason for the failure. On the other hand the FCIP entity being closer to the TCP stack than the FC entity and is therefore able to detect and report the loss of TCP connectivity. The method of reporting this loss to the FC entity is left up to the implementer. In a revision of the FC-BB-2 made at the last T11 meeting in Vancouver it was approved to add the following to a new clause in section 16.3: 16.3.x FCIP Error Reporting The FC entity will receive notifications from the FCIP entity due to a number of errors detected by the FCIP entity. As a result, the E_Port implementation of the FC entity must report those errors to the local FC switch element via the local VE_port (see Fig 23). Similarly the B_Port implementation must report the error to the local VB_access port (see figure 26). In addition the FC entity may pass these error reports to the local PMM for inclusion in a local event log. In both cases, the FC entity shall convert the error message received from the FCIP entity into a Registered Link Incident Report (FC-FS RLIR). It is the RLIR that is forwarded from the FC entity to either the VE_Port (figure 23) or VB_Access (figure 26). On receipt of the message from the FC Entity, the VE_Port or VB_Access shall immediately forward the RLIR to the FC Switch Entity. As a minimum the FC Entity shall accept the following messages from the FCIP entity and shall transfer them as an RLIR to the FC Switching Element by the VE_Port or to the FC Network by the VB_Access: FCIP RFC Section 6.6.2.3: Loss of FC frame synchronization FCIP RFC Section 9.1.2.3: Failure to setup TCP connection FCIP RFC Section 9.1.3: TCP connect request timeout or Duplicate connect request FCIP RFC Section 9.2: Successful completion of FC Entity request to close TCP connection FCIP RFC Section 9.4: Loss of TCP connectivity FCIP RFC Section 10.4.3: Excessive number of dropped datagrams or Any confidentiality violations FCIP RFC Section 10.4.4: SA parameter mis-match Don Fraser Contributor to FCIP -----Original Message----- From: Chong Peng [mailto:ChongPeng@MaXXan.com] Sent: Thursday, April 25, 2002 2:48 PM To: ips@ece.cmu.edu Subject: questions about FCIP connection failure detection Hi, all The Section 9.4 (TCP Connection Considerations) of draft-ietf-ips-fcovertcpip-09 says: In idle mode, a TCP Connection "keep alive" option of TCP is normally used to keep a connection alive. However, this timeout is fairly large and may prevent early detection of loss of connectivity. In order to facilitate faster detection of loss of connectivity, FC Entities SHOULD implement some form of Fibre Channel connection failure detection (see FC-BB-2 [4]). When an FCIP Entity discovers that TCP connectivity has been lost, the FCIP Entity SHALL notify the FC Entity of the failure including information about the reason for the failure. I have a couple of questions regarding this section: 1. The first pragraph states that the FC entity is responsable to discover the connection failure. But the second paragraph implys the FCIP entity discovers the connection failure first and then notifies the FC entity. Is there an editorial error? 2. If we let the application protocol on the top of TCP to discover the connection failure, what scheme are we going to use? Are we planning to define some "FCIP keep alive" frames in the future? I checked FC-BB-2, in the section related to discovery (13.2.2.4.2), it says "TBD". Chong Peng This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized use; review, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by return email and destroy all copies of the original message. Copyright © 2002 MaXXan Systems, Inc. All rights reserved. This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized use; review, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by return email and destroy all copies of the original message. Copyright © 2002 MaXXan Systems, Inc. All rights reserved. This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized use; review, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by return email and destroy all copies of the original message. Copyright © 2002 MaXXan Systems, Inc. All rights reserved. From owner-ips@ece.cmu.edu Wed May 1 14:47:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16984 for ; Wed, 1 May 2002 14:47:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41IS5P12893 for ips-outgoing; Wed, 1 May 2002 14:28:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [195.212.91.196]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41IS2w12876 for ; Wed, 1 May 2002 14:28:02 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id g41IRtgE020718; Wed, 1 May 2002 20:27:55 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g41IRs4110182; Wed, 1 May 2002 20:27:54 +0200 To: Carlos Rimola Cc: andy currid , ips@ece.cmu.edu, "THALER,PAT (A-Roseville,ex1)" , Bill Studenmund MIME-Version: 1.0 Subject: Re: iSCSI: large keys during login? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 1 May 2002 21:27:51 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/05/2002 21:27:54, Serialize complete at 01/05/2002 21:27:54 Content-Type: multipart/alternative; boundary="=_alternative 0064C5C6C2256BAC_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0064C5C6C2256BAC_= Content-Type: text/plain; charset="us-ascii" Both the F bit and the T bit have clear interpretation specified - they are similar but not identical. F bit is the end of the life of text request (and its ITT). T bit does not have this implication for Login. That is also the reason for the name change :-) Julo Carlos Rimola 05/01/2002 09:04 PM Please respond to Carlos Rimola To: cc: andy currid , "THALER,PAT (A-Roseville,ex1)" , Bill Studenmund , Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI: large keys during login? Hello, I believe the other point was the use of the F bit in Text requests/responses. In Login Text requests/responses, the same bit position is known as the T bit and is defined as the "Transition" to next stage indicator. Does this mean that the T bit in login request/responses should be interpreted in the same way as the F bit in text requests/responses? If this is the case, is this dual meaning of the T bit desirable? At the least, it would be useful for the spec to explicitly state the dual usage to remove any ambiguity. Carlos Rimola Silverback Systems At 09:14 AM 5/1/2002 -0700, Bill Studenmund wrote: >On Wed, 1 May 2002, Julian Satran wrote: > > > Andy, > > > > The data part is the same on both text and login. > > I will make o note to say this again in chapter 9. > >Julian, I think the grit of Andy's question still stands. At least I'm now >puzzled by a question he raised. :-) > >I agree that the section you quote, 9.12.10, describes what keys can be >used when & refers to the correct chapters. > >I think Andy's question, or the question I now have, is how do we do the >equivalent of the multi-part exchange shown in section 9.10.3 (towards the >bottom of page 156) with Login PDU's? We don't have a Target Transfer Tag >field? > >Do we need to add one? > >Take care, > >Bill --=_alternative 0064C5C6C2256BAC_= Content-Type: text/html; charset="us-ascii"
Both the F bit and the T bit have clear interpretation specified - they are similar but not identical. F bit is the end of the life of text request (and its ITT).
T bit does not have this implication for Login. That is also the reason for the name change :-)

Julo


Carlos Rimola <crimola@silverbacksystems.com>

05/01/2002 09:04 PM
Please respond to Carlos Rimola

       
        To:        <ips@ece.cmu.edu>
        cc:        andy currid <andy@windriver.com>, "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>, Bill Studenmund <wrstuden@wasabisystems.com>, Julian Satran/Haifa/IBM@IBMIL
        Subject:        Re: iSCSI: large keys during login?

       


Hello,

I believe the other point was the use of the F bit in Text
requests/responses.  In Login Text requests/responses, the same bit
position is known as the T bit and is defined as the "Transition" to next
stage indicator.

Does this mean that the T bit in login request/responses should be
interpreted in the same way as the F bit in text requests/responses?

If this is the case, is this dual meaning of the T bit desirable?  At the
least, it would be useful for the spec to explicitly state the dual usage
to remove any ambiguity.

Carlos Rimola
Silverback Systems

At 09:14 AM 5/1/2002 -0700, Bill Studenmund wrote:
>On Wed, 1 May 2002, Julian Satran wrote:
>
> > Andy,
> >
> > The data part is the same on both text and login.
> > I will make o note to say this again in chapter 9.
>
>Julian, I think the grit of Andy's question still stands. At least I'm now
>puzzled by a question he raised. :-)
>
>I agree that the section you quote, 9.12.10, describes what keys can be
>used when & refers to the correct chapters.
>
>I think Andy's question, or the question I now have, is how do we do the
>equivalent of the multi-part exchange shown in section 9.10.3 (towards the
>bottom of page 156) with Login PDU's? We don't have a Target Transfer Tag
>field?
>
>Do we need to add one?
>
>Take care,
>
>Bill

--=_alternative 0064C5C6C2256BAC_=-- From owner-ips@ece.cmu.edu Wed May 1 14:51:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17445 for ; Wed, 1 May 2002 14:51:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41IPYT12625 for ips-outgoing; Wed, 1 May 2002 14:25:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41IPWw12620 for ; Wed, 1 May 2002 14:25:32 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g41IOstk007176 for ; Wed, 1 May 2002 20:24:55 +0200 (MET DST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F13D.8FDF74FE" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: remove Date: Wed, 1 May 2002 20:25:25 +0200 Message-ID: <3F91B5D35324E64F878D7F282DC83D7314CAB2@XCH-AMS-302.cisco.com> Thread-Topic: remove Thread-Index: AcHxPY+xqUyqCYcdRe2pvTkLQRpFJw== From: "Steve Moon" To: Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1F13D.8FDF74FE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable remove =20 ------_=_NextPart_001_01C1F13D.8FDF74FE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
remove
 
=00 ------_=_NextPart_001_01C1F13D.8FDF74FE-- From owner-ips@ece.cmu.edu Wed May 1 14:52:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17589 for ; Wed, 1 May 2002 14:52:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41IcCB13834 for ips-outgoing; Wed, 1 May 2002 14:38:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41Ic9w13825 for ; Wed, 1 May 2002 14:38:09 -0400 (EDT) Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id g41Ibxp28854 for ; Wed, 1 May 2002 11:37:59 -0700 (PDT) Received: from ussvlexc01.corp.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.12.2/8.12.2/NTAP-1.4) with ESMTP id g41IbxfO027367 for ; Wed, 1 May 2002 11:37:59 -0700 (PDT) Received: by ussvlexc01.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 May 2002 11:37:58 -0700 Message-ID: <02740A3D0809D5118C7C00034707E9F30155490D@ussvlexc10.corp.netapp.com> From: "Pittman, Joseph" To: "'ips@ece.cmu.edu'" Subject: iSCSI: Target increment CmdSN on unretryable rejects Date: Wed, 1 May 2002 11:37:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I am working on an iSCSI target implementation, and I have a a question about whether the target should increment CmdSN under certain Reject conditions. Draft 12 of the iSCSI Specification (draft-ietf-ips-iscsi-12.txt) says the following: 6.2 Usage of Reject PDU in Recovery ... If the task had never been active before the Reject (i.e. the Reject is on the command PDU), targets should not send any further responses since the command itself is being discarded. ... The CmdSN of the rejected command PDU MUST NOT be considered received by the target, (i.e. a command sequence gap must be assumed for the CmdSN) This tells me that whenever I send a Reject as the only response to a command, I should not increment CmdSN. The specification also says the following: 6.1.1 Usage of Retry By resending the same iSCSI command PDU ("retry")... an initiator attempts to "plug"... discontinuities in CmdSN ordering on the target end... When an iSCSI command is retried, the command PDU MUST carry the original Initiator Task Tag and the original operational attributes (e.g. flags, function names, LUN, CDB, etc.) as well as the original CmdSN. This is the only discussion within the specification about the steps the initiator takes to plug a command sequence gap. So, as I understand the combined meaning of these two sections, when an initiator receives a Reject as the only response to a command, it must assume that the command was discarded, and it must 'plug the CmdSN hole' by retrying the rejected request. Now consider these two situations where a target may send a Reject: 1) Initiator issues Text command with a non-0xffffffff value for Target Transfer Tag (TTT). But the target does not recognize or has discarded the state for the TTT value. So the target sends a Reject/0x9(Invalid PDU Field). 2) Initiator issues a SNACK/Data to request retransmission of a DATA_IN. But the ErrorRecoveryLevel=0 target does not support SNACK, so the target sends a Reject/0x3(Data-SNACK Reject), or a Reject/0x5(Cmd not supported) or a Reject/0x9(Invalid PDU Field). In either case, the target is rejecting the command itself, so according to section 6.1.2, the target should not increment CmdSN. Instead, it should delay submission of subsequently received commands with larger within-window CmdSN values, until the initiator 'plugs the hole'. But according to my understanding, the initiator can only plug the hole by retransmitting the same command. The target will only reject this command again, so the hole won't really be 'plugged' after all. What am I missing here? A) Is there a class of 'command rejects' for which CmdSN should be incremented? Namely, those commands for which retrying the same command doesn't make sense? B) Or perhaps the specification must allow an initiator to plug a CmdSN hole by sending a NOP. I hope the answer is something along the lines of choice A. Because, I would like to avoid, for now, the whole issue of hole-plugging and out-of-order processing of incoming commands, by taking advantage of - MaxConnections=1 - guaranteed in-order per-connection delivery - escalating digest errors to session recovery Any guidance would be greatly appreciated. -- Joe Pittman From owner-ips@ece.cmu.edu Wed May 1 14:52:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17683 for ; Wed, 1 May 2002 14:52:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41IVFd13173 for ips-outgoing; Wed, 1 May 2002 14:31:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [195.212.91.196]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41IVDw13162 for ; Wed, 1 May 2002 14:31:13 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id g41IRwgE020720; Wed, 1 May 2002 20:27:58 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g41IRv479170; Wed, 1 May 2002 20:27:57 +0200 To: Mark Bakke Cc: ips@ece.cmu.edu, mbakke@cisco.com MIME-Version: 1.0 Subject: Re: iSCSI 4.1 & 4.2 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 1 May 2002 21:27:52 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/05/2002 21:27:57, Serialize complete at 01/05/2002 21:27:57 Content-Type: multipart/alternative; boundary="=_alternative 00652744C2256BAC_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00652744C2256BAC_= Content-Type: text/plain; charset="us-ascii" Mark, John Hufferd has solicited twice input from NDT about their additional requirement. I did not hear back from you. The attached note does not say anything concrete (are some characters that you need missing?) either. Julo Mark Bakke Sent by: mbakke@cisco.com 05/01/2002 08:52 PM Please respond to Mark Bakke To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI 4.1 & 4.2 Julian- Text-value is also used for initiator names, target names, and aliases, which are UTF-8 encoded, so they don't fit into the current text-value definition. Here are two more text value types we should add. -- Mark Julian Satran wrote: > > text-value: a string defined by the regular expression > "[][a-zA-Z0-9.-+@_/\[\]=]*" Used by InitiatorName and TargetName: name-value: a UTF-8 string, with its valid character set defined in draft-ietf-ips-iscsi-string-prep-00. Used by InitiatorAlias and TargetAlias: utf8-value: any UTF-8 string, terminated by a null character, Ranges and comma-separated lists are not allowed for keys that use this type. -- Mark --=_alternative 00652744C2256BAC_= Content-Type: text/html; charset="us-ascii"
Mark,

John Hufferd has solicited twice input from NDT about their additional requirement.
I did not hear back from you.
The attached note does not say anything concrete (are some characters that you need missing?) either.

Julo


Mark Bakke <mbakke@cisco.com>
Sent by: mbakke@cisco.com

05/01/2002 08:52 PM
Please respond to Mark Bakke

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        Re: iSCSI 4.1 & 4.2

       


Julian-

Text-value is also used for initiator names, target names,
and aliases, which are UTF-8 encoded, so they don't fit into
the current text-value definition.   Here are two more
text value types we should add.

--
Mark

Julian Satran wrote:
>
> text-value: a string defined by the regular expression
> "[][a-zA-Z0-9.-+@_/\[\]=]*"

Used by InitiatorName and TargetName:

name-value: a UTF-8 string, with its valid character set
defined in draft-ietf-ips-iscsi-string-prep-00.

Used by InitiatorAlias and TargetAlias:

utf8-value: any UTF-8 string, terminated by a null character,
Ranges and comma-separated lists are not allowed for keys
that use this type.

--
Mark

--=_alternative 00652744C2256BAC_=-- From owner-ips@ece.cmu.edu Wed May 1 15:33:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22517 for ; Wed, 1 May 2002 15:33:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41Iwbe15520 for ips-outgoing; Wed, 1 May 2002 14:58:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41IwYw15512 for ; Wed, 1 May 2002 14:58:34 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g41IwRp6000650; Wed, 1 May 2002 11:58:27 -0700 (PDT) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA13646; Wed, 1 May 2002 11:58:25 -0700 (PDT) Message-ID: <3CD036AF.66757CB@cisco.com> Date: Wed, 01 May 2002 13:40:47 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Julian Satran CC: ips@ece.cmu.edu Subject: Re: iSCSI 4.1 & 4.2 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian- Sorry, I've been unavailable the last few days. What do you mean about the note not being concrete? The string-prep draft says exactly which additional characters we need for the name-value (all of the international lower-case equivalent characters are valid), and the utf8-value specifies that any UTF-8 character is legal (other than \0). Without adding these, we would have to ditch internationalization completely within iSCSI names, but since the DNS folks are going through the pain of internationalizing host and domain names, we should keep internationalization in iSCSI as well. -- Mark Julian Satran wrote: > > Mark, > > John Hufferd has solicited twice input from NDT about their additional requirement. > I did not hear back from you. > The attached note does not say anything concrete (are some characters that you need missing?) > either. > > Julo > > Mark Bakke > Sent by: mbakke@cisco.com To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > 05/01/2002 08:52 PM Subject: Re: iSCSI 4.1 & 4.2 > Please respond to Mark Bakke > > > Julian- > > Text-value is also used for initiator names, target names, > and aliases, which are UTF-8 encoded, so they don't fit into > the current text-value definition. Here are two more > text value types we should add. > > -- > Mark > > Julian Satran wrote: > > > > text-value: a string defined by the regular expression > > "[][a-zA-Z0-9.-+@_/\[\]=]*" > > Used by InitiatorName and TargetName: > > name-value: a UTF-8 string, with its valid character set > defined in draft-ietf-ips-iscsi-string-prep-00. > > Used by InitiatorAlias and TargetAlias: > > utf8-value: any UTF-8 string, terminated by a null character, > Ranges and comma-separated lists are not allowed for keys > that use this type. > > -- > Mark -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed May 1 15:35:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22836 for ; Wed, 1 May 2002 15:35:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41JCOO16744 for ips-outgoing; Wed, 1 May 2002 15:12:24 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41JCMw16738 for ; Wed, 1 May 2002 15:12:22 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id VAA09580; Wed, 1 May 2002 21:12:16 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g41JCF499268; Wed, 1 May 2002 21:12:15 +0200 To: Mark Bakke Cc: ips@ece.cmu.edu, mbakke@cisco.com MIME-Version: 1.0 Subject: Re: iSCSI 4.1 & 4.2 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 1 May 2002 22:12:12 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/05/2002 22:12:15, Serialize complete at 01/05/2002 22:12:15 Content-Type: multipart/alternative; boundary="=_alternative 0068D379C2256BAC_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0068D379C2256BAC_= Content-Type: text/plain; charset="us-ascii" Please send me a list of the characters to add or a specification for them. Julo Mark Bakke Sent by: mbakke@cisco.com 05/01/2002 09:40 PM Please respond to Mark Bakke To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI 4.1 & 4.2 Julian- Sorry, I've been unavailable the last few days. What do you mean about the note not being concrete? The string-prep draft says exactly which additional characters we need for the name-value (all of the international lower-case equivalent characters are valid), and the utf8-value specifies that any UTF-8 character is legal (other than \0). Without adding these, we would have to ditch internationalization completely within iSCSI names, but since the DNS folks are going through the pain of internationalizing host and domain names, we should keep internationalization in iSCSI as well. -- Mark Julian Satran wrote: > > Mark, > > John Hufferd has solicited twice input from NDT about their additional requirement. > I did not hear back from you. > The attached note does not say anything concrete (are some characters that you need missing?) > either. > > Julo > > Mark Bakke > Sent by: mbakke@cisco.com To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > 05/01/2002 08:52 PM Subject: Re: iSCSI 4.1 & 4.2 > Please respond to Mark Bakke > > > Julian- > > Text-value is also used for initiator names, target names, > and aliases, which are UTF-8 encoded, so they don't fit into > the current text-value definition. Here are two more > text value types we should add. > > -- > Mark > > Julian Satran wrote: > > > > text-value: a string defined by the regular expression > > "[][a-zA-Z0-9.-+@_/\[\]=]*" > > Used by InitiatorName and TargetName: > > name-value: a UTF-8 string, with its valid character set > defined in draft-ietf-ips-iscsi-string-prep-00. > > Used by InitiatorAlias and TargetAlias: > > utf8-value: any UTF-8 string, terminated by a null character, > Ranges and comma-separated lists are not allowed for keys > that use this type. > > -- > Mark -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 --=_alternative 0068D379C2256BAC_= Content-Type: text/html; charset="us-ascii"
Please send me a list of the characters to add or a specification for them. Julo


Mark Bakke <mbakke@cisco.com>
Sent by: mbakke@cisco.com

05/01/2002 09:40 PM
Please respond to Mark Bakke

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        Re: iSCSI 4.1 & 4.2

       


Julian-

Sorry, I've been unavailable the last few days.  What do you mean
about the note not being concrete?  The string-prep draft says
exactly which additional characters we need for the name-value
(all of the international lower-case equivalent characters
are valid), and the utf8-value specifies that any UTF-8
character is legal (other than \0).

Without adding these, we would have to ditch internationalization
completely within iSCSI names, but since the DNS folks are going
through the pain of internationalizing host and domain names, we
should keep internationalization in iSCSI as well.

--
Mark

Julian Satran wrote:
>
> Mark,
>
> John Hufferd has solicited twice input from NDT about their additional requirement.
> I did not hear back from you.
> The attached note does not say anything concrete (are some characters that you need missing?)
> either.
>
> Julo
>
>   Mark Bakke <mbakke@cisco.com>
>   Sent by: mbakke@cisco.com                   To:        Julian Satran/Haifa/IBM@IBMIL
>                                               cc:        ips@ece.cmu.edu
>   05/01/2002 08:52 PM                         Subject:        Re: iSCSI 4.1 & 4.2
>   Please respond to Mark Bakke
>
>
> Julian-
>
> Text-value is also used for initiator names, target names,
> and aliases, which are UTF-8 encoded, so they don't fit into
> the current text-value definition.   Here are two more
> text value types we should add.
>
> --
> Mark
>
> Julian Satran wrote:
> >
> > text-value: a string defined by the regular expression
> > "[][a-zA-Z0-9.-+@_/\[\]=]*"
>
> Used by InitiatorName and TargetName:
>
> name-value: a UTF-8 string, with its valid character set
> defined in draft-ietf-ips-iscsi-string-prep-00.
>
> Used by InitiatorAlias and TargetAlias:
>
> utf8-value: any UTF-8 string, terminated by a null character,
> Ranges and comma-separated lists are not allowed for keys
> that use this type.
>
> --
> Mark

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054

--=_alternative 0068D379C2256BAC_=-- From owner-ips@ece.cmu.edu Wed May 1 15:35:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22852 for ; Wed, 1 May 2002 15:35:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41J15u15754 for ips-outgoing; Wed, 1 May 2002 15:01:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [195.212.91.196]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41J12w15747 for ; Wed, 1 May 2002 15:01:02 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id g41J0tgE038134; Wed, 1 May 2002 21:00:55 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g41J0t479116; Wed, 1 May 2002 21:00:55 +0200 To: "Pittman, Joseph" Cc: "'ips@ece.cmu.edu'" MIME-Version: 1.0 Subject: Re: iSCSI: Target increment CmdSN on unretryable rejects X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 1 May 2002 22:00:52 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/05/2002 22:00:55, Serialize complete at 01/05/2002 22:00:55 Content-Type: multipart/alternative; boundary="=_alternative 00683B6CC2256BAC_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00683B6CC2256BAC_= Content-Type: text/plain; charset="us-ascii" comments in text - julo "Pittman, Joseph" 05/01/2002 08:05 PM Please respond to "Pittman, Joseph" To: Julian Satran/Haifa/IBM@IBMIL cc: "'ips@ece.cmu.edu'" Subject: iSCSI: Target increment CmdSN on unretryable rejects Julian, I am working on an iSCSI target implementation, and I have a a question about whether the target should increment CmdSN under certain Reject conditions. Draft 12 of the iSCSI Specification (draft-ietf-ips-iscsi-12.txt) says the following: 6.2 Usage of Reject PDU in Recovery ... If the task had never been active before the Reject (i.e. the Reject is on the command PDU), targets should not send any further responses since the command itself is being discarded. ... The CmdSN of the rejected command PDU MUST NOT be considered received by the target, (i.e. a command sequence gap must be assumed for the CmdSN) This tells me that whenever I send a Reject as the only response to a command, I should not increment CmdSN. +++ target is not incrementing just "taking note" and sending ExpCmdSN +++ The specification also says the following: 6.1.1 Usage of Retry By resending the same iSCSI command PDU ("retry")... an initiator attempts to "plug"... discontinuities in CmdSN ordering on the target end... When an iSCSI command is retried, the command PDU MUST carry the original Initiator Task Tag and the original operational attributes (e.g. flags, function names, LUN, CDB, etc.) as well as the original CmdSN. This is the only discussion within the specification about the steps the initiator takes to plug a command sequence gap. So, as I understand the combined meaning of these two sections, when an initiator receives a Reject as the only response to a command, it must assume that the command was discarded, and it must 'plug the CmdSN hole' by retrying the rejected request. +++ not if it is an intermediate reject - like that of a data packet after the command got instantiated For a new command that is true. +++ Now consider these two situations where a target may send a Reject: 1) Initiator issues Text command with a non-0xffffffff value for Target Transfer Tag (TTT). But the target does not recognize or has discarded the state for the TTT value. So the target sends a Reject/0x9(Invalid PDU Field). 2) Initiator issues a SNACK/Data to request retransmission of a DATA_IN. But the ErrorRecoveryLevel=0 target does not support SNACK, so the target sends a Reject/0x3(Data-SNACK Reject), or a Reject/0x5(Cmd not supported) or a Reject/0x9(Invalid PDU Field). In either case, the target is rejecting the command itself, so according to section 6.1.2, the target should not increment CmdSN. Instead, it should delay submission of subsequently received commands with larger within-window CmdSN values, until the initiator 'plugs the hole'. But according to my understanding, the initiator can only plug the hole by retransmitting the same command. The target will only reject this command again, so the hole won't really be 'plugged' after all. What am I missing here? A) Is there a class of 'command rejects' for which CmdSN should be incremented? Namely, those commands for which retrying the same command doesn't make sense? B) Or perhaps the specification must allow an initiator to plug a CmdSN hole by sending a NOP. +++ the interdiction on pluging is to insure that the initiator knows what he does and has enough tools to keep the intended order. For the case you describe initiator may abort the "hole" (that is allowed) on the same connection as specified under task management. Enabling NOPs is not needed+++ I hope the answer is something along the lines of choice A. Because, I would like to avoid, for now, the whole issue of hole-plugging and out-of-order processing of incoming commands, by taking advantage of - MaxConnections=1 - guaranteed in-order per-connection delivery - escalating digest errors to session recovery Any guidance would be greatly appreciated. -- Joe Pittman jpittman@netapp.com --=_alternative 00683B6CC2256BAC_= Content-Type: text/html; charset="us-ascii"
comments in text - julo


"Pittman, Joseph" <Joseph.Pittman@netapp.com>

05/01/2002 08:05 PM
Please respond to "Pittman, Joseph"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
        Subject:        iSCSI: Target increment CmdSN on unretryable rejects

       


Julian,

I am working on an iSCSI target implementation, and I have a
a question about whether the target should increment CmdSN
under certain Reject conditions.

Draft 12 of the iSCSI Specification (draft-ietf-ips-iscsi-12.txt)
says the following:

 6.2 Usage of Reject PDU in Recovery

 ...
 If the task had never been active before the Reject (i.e. the
 Reject is on the command PDU), targets should not send any
 further responses since the command itself is being discarded.
 ...
 The CmdSN of the rejected command PDU MUST NOT be considered
 received by the target, (i.e. a command sequence gap must
 be assumed for the CmdSN)


This tells me that whenever I send a Reject as the only response
to a command, I should not increment CmdSN.
+++ target is not incrementing just "taking note" and sending ExpCmdSN +++

The specification also says the following:

 6.1.1 Usage of Retry

 By resending the same iSCSI command PDU ("retry")...
 an initiator attempts to "plug"... discontinuities in CmdSN
 ordering on the target end...

 When an iSCSI command is retried, the command PDU MUST carry
 the original Initiator Task Tag and the original operational
 attributes (e.g. flags, function names, LUN, CDB, etc.) as
 well as the original CmdSN.

This is the only discussion within the specification about the
steps the initiator takes to plug a command sequence gap.

So, as I understand the combined meaning of these two sections,
when an initiator receives a Reject as the only response to a
command, it must assume that the command was discarded, and it
must 'plug the CmdSN hole' by retrying the rejected request.
+++ not if it is an intermediate reject - like that of a data packet after the command got instantiated
For a new command that is true. +++

Now consider these two situations where a target may send a
Reject:

 1) Initiator issues Text command with a non-0xffffffff value
    for Target Transfer Tag (TTT).  But the target does not
    recognize or has discarded the state for the TTT value.
    So the target sends a Reject/0x9(Invalid PDU Field).

 2) Initiator issues a SNACK/Data to request retransmission
    of a DATA_IN.  But the ErrorRecoveryLevel=0 target does
    not support SNACK, so the target sends a
    Reject/0x3(Data-SNACK Reject), or a Reject/0x5(Cmd not supported)
    or a Reject/0x9(Invalid PDU Field).


In either case, the target is rejecting the command itself, so
according to section 6.1.2, the target should not increment CmdSN.
Instead, it should delay submission of subsequently received
commands with larger within-window CmdSN values, until the
initiator 'plugs the hole'.

But according to my understanding, the initiator can only plug the
hole by retransmitting the same command.  The target will only
reject this command again, so the hole won't really be 'plugged'
after all.


What am I missing here?

A) Is there a class of 'command rejects' for which CmdSN should
  be incremented?  Namely, those commands for which retrying the
  same command doesn't make sense?

B) Or perhaps the specification must allow an initiator to plug
  a CmdSN hole by sending a NOP.

+++ the interdiction on pluging is to insure that the initiator knows what he does and has enough tools to keep the intended order. For the case you describe initiator may abort the "hole" (that is allowed) on the same connection as specified under task management. Enabling NOPs is not needed+++


I hope the answer is something along the lines of choice A.
Because, I would like to avoid, for now, the whole issue of
hole-plugging and out-of-order processing of incoming commands,
by taking advantage of

 - MaxConnections=1
 - guaranteed in-order per-connection delivery
 - escalating digest errors to session recovery

Any guidance would be greatly appreciated.
--
Joe Pittman
jpittman@netapp.com

--=_alternative 00683B6CC2256BAC_=-- From owner-ips@ece.cmu.edu Wed May 1 16:42:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29730 for ; Wed, 1 May 2002 16:42:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41KCMk21738 for ips-outgoing; Wed, 1 May 2002 16:12:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41KCJw21729 for ; Wed, 1 May 2002 16:12:19 -0400 (EDT) Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id g41KCDp04511; Wed, 1 May 2002 13:12:13 -0700 (PDT) Received: from tahoe.corp.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.12.2/8.12.2/NTAP-1.4) with ESMTP id g41KCC3r006469; Wed, 1 May 2002 13:12:13 -0700 (PDT) Received: by tahoe.corp.netapp.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 May 2002 13:08:30 -0700 Message-ID: <02740A3D0809D5118C7C00034707E9F30155490E@ussvlexc10.corp.netapp.com> From: "Pittman, Joseph" To: "'Julian Satran'" Cc: "'ips@ece.cmu.edu'" Subject: Re: iSCSI: Target increment CmdSN on unretryable rejects Date: Wed, 1 May 2002 13:12:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Thanks for your quick response. Can you help me by answering the followup question below? > What am I missing here? > > A) Is there a class of 'command rejects' for which CmdSN should > be incremented? Namely, those commands for which retrying the > same command doesn't make sense? > > B) Or perhaps the specification must allow an initiator to plug > a CmdSN hole by sending a NOP. > > +++ the interdiction on pluging is to insure that the initiator > knows what he does and has enough tools to keep the intended > order. For the case you describe initiator may abort the > "hole" (that is allowed) on the same connection as specified > under task management. Enabling NOPs is not needed +++ I see the following text in Draft12, section 9.6.1: For the ABORT TASK function: a) if the ITT identifies a valid task... b) if the ITT does not identify an existing task but if the CmdSN indicated by the RefCmdSN field in the task management function request is within the valid CmdSN window (between MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received and return the "Function complete" response. c) if the ITT does not identify an existing task and ... outside the valid CmdSN window, ... "Task does not exist" Is case b) above the piece of text within the specification that describes 'aborting the hole', or is there some other discussion of this? To make sure I am clear on this, can you tell me whether the following statements are accurate? Consider this situation: - Target's ExpCmdSN=10, MaxCmdSN=19 - Initiator sends 4 commands, numbered 10-13 - Target processes command 10, recognizes a situation which warrants reject, and which will always warrant a reject no matter how many times it is retried (i.e. Text command with invalid TTT; SNACK for data when target does not support; or ANY Invalid PDU field-type error) In this situation, my understanding is that the target must behave as follows: - Delay submission of commands 11-13 until the command window hole at CmdSN=10 is plugged - If the initiator retries command 10, the target will send the same reject message again - If the initiator sends a non-immediate TaskMgmt ABORT_TASK command (CmdSN 14), to abort command 10, the target will NOT process command 14 because the hole has still not been filled - If the initiator sends an immediate TaskMgmt ABORT_TASK command to abort command 10, the target will process this request immediately, consider command 10 to have been sent (9.6.1 case b), close the hole, and respond to the immediate TaskMgmt command with Function Complete. Then, the target will resume submitting the sequenced commands starting with 11 (since the hole at 10 has been closed). Is my understanding correct? Thanks for your continued help. -- Joe Pittman jpittman@netapp.com From owner-ips@ece.cmu.edu Wed May 1 16:43:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29800 for ; Wed, 1 May 2002 16:43:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41KGuP22120 for ips-outgoing; Wed, 1 May 2002 16:16:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41KGsw22115 for ; Wed, 1 May 2002 16:16:54 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g41KGl8M026226; Wed, 1 May 2002 13:16:47 -0700 (PDT) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA15197; Wed, 1 May 2002 13:16:45 -0700 (PDT) Message-ID: <3CD04910.B9CFCF9B@cisco.com> Date: Wed, 01 May 2002 14:59:12 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Julian Satran CC: ips@ece.cmu.edu Subject: Re: iSCSI 4.1 & 4.2 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian- The specification is at http://search.ietf.org/internet-drafts/draft-ietf-ips-iscsi-string-prep-00.txt It would be better to reference the specification rather than attempt to add the individual characters to iSCSI; the point of the separate specification is to leverage the same work that the IDN folks are doing. -- Mark Julian Satran wrote: > > Please send me a list of the characters to add or a specification for them. Julo > > Mark Bakke > Sent by: mbakke@cisco.com To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > 05/01/2002 09:40 PM Subject: Re: iSCSI 4.1 & 4.2 > Please respond to Mark Bakke > > > Julian- > > Sorry, I've been unavailable the last few days. What do you mean > about the note not being concrete? The string-prep draft says > exactly which additional characters we need for the name-value > (all of the international lower-case equivalent characters > are valid), and the utf8-value specifies that any UTF-8 > character is legal (other than \0). > > Without adding these, we would have to ditch internationalization > completely within iSCSI names, but since the DNS folks are going > through the pain of internationalizing host and domain names, we > should keep internationalization in iSCSI as well. > > -- > Mark > > Julian Satran wrote: > > > > Mark, > > > > John Hufferd has solicited twice input from NDT about their additional requirement. > > I did not hear back from you. > > The attached note does not say anything concrete (are some characters that you need missing?) > > either. > > > > Julo > > > > Mark Bakke > > Sent by: mbakke@cisco.com To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > 05/01/2002 08:52 PM Subject: Re: iSCSI 4.1 & 4.2 > > Please respond to Mark Bakke > > > > > > Julian- > > > > Text-value is also used for initiator names, target names, > > and aliases, which are UTF-8 encoded, so they don't fit into > > the current text-value definition. Here are two more > > text value types we should add. > > > > -- > > Mark > > > > Julian Satran wrote: > > > > > > text-value: a string defined by the regular expression > > > "[][a-zA-Z0-9.-+@_/\[\]=]*" > > > > Used by InitiatorName and TargetName: > > > > name-value: a UTF-8 string, with its valid character set > > defined in draft-ietf-ips-iscsi-string-prep-00. > > > > Used by InitiatorAlias and TargetAlias: > > > > utf8-value: any UTF-8 string, terminated by a null character, > > Ranges and comma-separated lists are not allowed for keys > > that use this type. > > > > -- > > Mark > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed May 1 16:44:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29876 for ; Wed, 1 May 2002 16:44:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41K5jZ21134 for ips-outgoing; Wed, 1 May 2002 16:05:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41K5iw21129 for ; Wed, 1 May 2002 16:05:44 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 6F6CA30706; Wed, 1 May 2002 16:05:43 -0400 (EDT) Date: Wed, 1 May 2002 13:05:04 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Santosh Rao Cc: Subject: Re: iSCSI: large keys during login? In-Reply-To: <3CD029E8.8B926544@cup.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 1 May 2002, Santosh Rao wrote: > Hello, > > I don't know how the above would work. Every string (in this case, the > key=value string) is assumed to be NULL terminated. If this is not the > case, the usage of standard string routines like strlen(), strcpy(), > strstr(), etc will have problems in the iscsi login/text parsers. Before you start processing key/value pairs, you look to see if the last byte in the PDU is NUL (note, NUL, not NULL). If it is not, then there's more text comming. You save what you have, ack what you got, and wait for more. When you get more, you append it in the buffer, and then check to see if this blob was terminated by a NUL. If not, you have yet more to do, so loop. If you get more than you can accept, bail. When you get the last bit (NUL terminated), you then parse. > I think the multi-pdu fragmentation and re-assembly mechanisms must be > uniform across both the login and text pdu's allowing the same code to > be re-used in both the login and text parsers. I agree it would be nice to have the same mechanisms, but I think we can live without. We can do either. :-) > Hence, it would be better to have the TTT and F bit in the login pdu. > The receiving side must not interpret any received keys, but simply > store them, send an empty login/login_rsp pdu back with the TTT set and > eventually perform re-assembly until the sending side sends a pdu with > the F bit set. When the 'F' bit PDU is received, the keys may be > interpreted, negotiations performed, and if necessary, another > login/login_rsp pdu be sent indicating the appropriate (CSG, NSG, T) > setting. Why do we need BOTH the TTT field and the F bit? One or the other would suffice, and I'd vote we use TTT (we already have something at the F bit position). Take care, Bill From owner-ips@ece.cmu.edu Wed May 1 17:33:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05505 for ; Wed, 1 May 2002 17:33:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41KoaG24800 for ips-outgoing; Wed, 1 May 2002 16:50:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41KoWw24789 for ; Wed, 1 May 2002 16:50:33 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id WAA91368; Wed, 1 May 2002 22:50:26 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g41KoQT76310; Wed, 1 May 2002 22:50:26 +0200 To: Mark Bakke Cc: ips@ece.cmu.edu, mbakke@cisco.com MIME-Version: 1.0 Subject: Re: iSCSI 4.1 & 4.2 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 1 May 2002 23:50:24 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/05/2002 23:50:26, Serialize complete at 01/05/2002 23:50:26 Content-Type: multipart/alternative; boundary="=_alternative 0071CFE7C2256BAC_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0071CFE7C2256BAC_= Content-Type: text/plain; charset="us-ascii" Mark, I thought that this will be handled within NDT and I will see the end-result. I can't make the reference before looking at the list of characters for conflicts and scan dead-ends. Julo Mark Bakke Sent by: mbakke@cisco.com 05/01/2002 10:59 PM Please respond to Mark Bakke To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI 4.1 & 4.2 Julian- The specification is at http://search.ietf.org/internet-drafts/draft-ietf-ips-iscsi-string-prep-00.txt It would be better to reference the specification rather than attempt to add the individual characters to iSCSI; the point of the separate specification is to leverage the same work that the IDN folks are doing. -- Mark Julian Satran wrote: > > Please send me a list of the characters to add or a specification for them. Julo > > Mark Bakke > Sent by: mbakke@cisco.com To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > 05/01/2002 09:40 PM Subject: Re: iSCSI 4.1 & 4.2 > Please respond to Mark Bakke > > > Julian- > > Sorry, I've been unavailable the last few days. What do you mean > about the note not being concrete? The string-prep draft says > exactly which additional characters we need for the name-value > (all of the international lower-case equivalent characters > are valid), and the utf8-value specifies that any UTF-8 > character is legal (other than \0). > > Without adding these, we would have to ditch internationalization > completely within iSCSI names, but since the DNS folks are going > through the pain of internationalizing host and domain names, we > should keep internationalization in iSCSI as well. > > -- > Mark > > Julian Satran wrote: > > > > Mark, > > > > John Hufferd has solicited twice input from NDT about their additional requirement. > > I did not hear back from you. > > The attached note does not say anything concrete (are some characters that you need missing?) > > either. > > > > Julo > > > > Mark Bakke > > Sent by: mbakke@cisco.com To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > 05/01/2002 08:52 PM Subject: Re: iSCSI 4.1 & 4.2 > > Please respond to Mark Bakke > > > > > > Julian- > > > > Text-value is also used for initiator names, target names, > > and aliases, which are UTF-8 encoded, so they don't fit into > > the current text-value definition. Here are two more > > text value types we should add. > > > > -- > > Mark > > > > Julian Satran wrote: > > > > > > text-value: a string defined by the regular expression > > > "[][a-zA-Z0-9.-+@_/\[\]=]*" > > > > Used by InitiatorName and TargetName: > > > > name-value: a UTF-8 string, with its valid character set > > defined in draft-ietf-ips-iscsi-string-prep-00. > > > > Used by InitiatorAlias and TargetAlias: > > > > utf8-value: any UTF-8 string, terminated by a null character, > > Ranges and comma-separated lists are not allowed for keys > > that use this type. > > > > -- > > Mark > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 --=_alternative 0071CFE7C2256BAC_= Content-Type: text/html; charset="us-ascii"
Mark,

I thought that this will be handled within NDT and I will see the end-result.
I can't make the reference before looking at the list of characters for conflicts and scan dead-ends.

Julo


Mark Bakke <mbakke@cisco.com>
Sent by: mbakke@cisco.com

05/01/2002 10:59 PM
Please respond to Mark Bakke

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        Re: iSCSI 4.1 & 4.2

       


Julian-

The specification is at

http://search.ietf.org/internet-drafts/draft-ietf-ips-iscsi-string-prep-00.txt

It would be better to reference the specification rather than attempt
to add the individual characters to iSCSI; the point
of the separate specification is to leverage the same work that
the IDN folks are doing.

--
Mark


Julian Satran wrote:
>
> Please send me a list of the characters to add or a specification for them. Julo
>
>   Mark Bakke <mbakke@cisco.com>
>   Sent by: mbakke@cisco.com                   To:        Julian Satran/Haifa/IBM@IBMIL
>                                               cc:        ips@ece.cmu.edu
>   05/01/2002 09:40 PM                         Subject:        Re: iSCSI 4.1 & 4.2
>   Please respond to Mark Bakke
>
>
> Julian-
>
> Sorry, I've been unavailable the last few days.  What do you mean
> about the note not being concrete?  The string-prep draft says
> exactly which additional characters we need for the name-value
> (all of the international lower-case equivalent characters
> are valid), and the utf8-value specifies that any UTF-8
> character is legal (other than \0).
>
> Without adding these, we would have to ditch internationalization
> completely within iSCSI names, but since the DNS folks are going
> through the pain of internationalizing host and domain names, we
> should keep internationalization in iSCSI as well.
>
> --
> Mark
>
> Julian Satran wrote:
> >
> > Mark,
> >
> > John Hufferd has solicited twice input from NDT about their additional requirement.
> > I did not hear back from you.
> > The attached note does not say anything concrete (are some characters that you need missing?)
> > either.
> >
> > Julo
> >
> >   Mark Bakke <mbakke@cisco.com>
> >   Sent by: mbakke@cisco.com                   To:        Julian Satran/Haifa/IBM@IBMIL
> >                                               cc:        ips@ece.cmu.edu
> >   05/01/2002 08:52 PM                         Subject:        Re: iSCSI 4.1 & 4.2
> >   Please respond to Mark Bakke
> >
> >
> > Julian-
> >
> > Text-value is also used for initiator names, target names,
> > and aliases, which are UTF-8 encoded, so they don't fit into
> > the current text-value definition.   Here are two more
> > text value types we should add.
> >
> > --
> > Mark
> >
> > Julian Satran wrote:
> > >
> > > text-value: a string defined by the regular expression
> > > "[][a-zA-Z0-9.-+@_/\[\]=]*"
> >
> > Used by InitiatorName and TargetName:
> >
> > name-value: a UTF-8 string, with its valid character set
> > defined in draft-ietf-ips-iscsi-string-prep-00.
> >
> > Used by InitiatorAlias and TargetAlias:
> >
> > utf8-value: any UTF-8 string, terminated by a null character,
> > Ranges and comma-separated lists are not allowed for keys
> > that use this type.
> >
> > --
> > Mark
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054

--=_alternative 0071CFE7C2256BAC_=-- From owner-ips@ece.cmu.edu Wed May 1 17:33:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05521 for ; Wed, 1 May 2002 17:33:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41KrEf25035 for ips-outgoing; Wed, 1 May 2002 16:53:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41KrCw25031 for ; Wed, 1 May 2002 16:53:13 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g41Kr48M015425; Wed, 1 May 2002 13:53:04 -0700 (PDT) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA23356; Wed, 1 May 2002 13:53:02 -0700 (PDT) Message-ID: <3CD05191.9D3B91D5@cisco.com> Date: Wed, 01 May 2002 15:35:29 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Julian Satran CC: ips@ece.cmu.edu Subject: Re: iSCSI 4.1 & 4.2 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian- We originally were going to just deal with this in the NDT spec, but since the NDT spec (and the referenced stringprep spec) affects the character set that is being defined in 4.1 and 4.2, it will be hard to avoid referencing it from 4.1 and 4.2 as well. -- Mark Julian Satran wrote: > > Mark, > > I thought that this will be handled within NDT and I will see the end-result. > I can't make the reference before looking at the list of characters for conflicts and scan > dead-ends. > > Julo > > Mark Bakke > Sent by: mbakke@cisco.com To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > 05/01/2002 10:59 PM Subject: Re: iSCSI 4.1 & 4.2 > Please respond to Mark Bakke > > > Julian- > > The specification is at > > http://search.ietf.org/internet-drafts/draft-ietf-ips-iscsi-string-prep-00.txt > > It would be better to reference the specification rather than attempt > to add the individual characters to iSCSI; the point > of the separate specification is to leverage the same work that > the IDN folks are doing. > > -- > Mark > > Julian Satran wrote: > > > > Please send me a list of the characters to add or a specification for them. Julo > > > > Mark Bakke > > Sent by: mbakke@cisco.com To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > 05/01/2002 09:40 PM Subject: Re: iSCSI 4.1 & 4.2 > > Please respond to Mark Bakke > > > > > > Julian- > > > > Sorry, I've been unavailable the last few days. What do you mean > > about the note not being concrete? The string-prep draft says > > exactly which additional characters we need for the name-value > > (all of the international lower-case equivalent characters > > are valid), and the utf8-value specifies that any UTF-8 > > character is legal (other than \0). > > > > Without adding these, we would have to ditch internationalization > > completely within iSCSI names, but since the DNS folks are going > > through the pain of internationalizing host and domain names, we > > should keep internationalization in iSCSI as well. > > > > -- > > Mark > > > > Julian Satran wrote: > > > > > > Mark, > > > > > > John Hufferd has solicited twice input from NDT about their additional requirement. > > > I did not hear back from you. > > > The attached note does not say anything concrete (are some characters that you need missing?) > > > either. > > > > > > Julo > > > > > > Mark Bakke > > > Sent by: mbakke@cisco.com To: Julian Satran/Haifa/IBM@IBMIL > > > cc: ips@ece.cmu.edu > > > 05/01/2002 08:52 PM Subject: Re: iSCSI 4.1 & 4.2 > > > Please respond to Mark Bakke > > > > > > > > > Julian- > > > > > > Text-value is also used for initiator names, target names, > > > and aliases, which are UTF-8 encoded, so they don't fit into > > > the current text-value definition. Here are two more > > > text value types we should add. > > > > > > -- > > > Mark > > > > > > Julian Satran wrote: > > > > > > > > text-value: a string defined by the regular expression > > > > "[][a-zA-Z0-9.-+@_/\[\]=]*" > > > > > > Used by InitiatorName and TargetName: > > > > > > name-value: a UTF-8 string, with its valid character set > > > defined in draft-ietf-ips-iscsi-string-prep-00. > > > > > > Used by InitiatorAlias and TargetAlias: > > > > > > utf8-value: any UTF-8 string, terminated by a null character, > > > Ranges and comma-separated lists are not allowed for keys > > > that use this type. > > > > > > -- > > > Mark > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed May 1 17:33:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05604 for ; Wed, 1 May 2002 17:33:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g41L0Ug25615 for ips-outgoing; Wed, 1 May 2002 17:00:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g41L0Qw25607 for ; Wed, 1 May 2002 17:00:26 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id XAA85102 for ; Wed, 1 May 2002 23:00:20 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g41L0JT145638 for ; Wed, 1 May 2002 23:00:19 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Target increment CmdSN on unretryable rejects X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 2 May 2002 00:00:18 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 02/05/2002 00:00:19, Serialize complete at 02/05/2002 00:00:19 Content-Type: multipart/alternative; boundary="=_alternative 0072E3A0C2256BAC_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0072E3A0C2256BAC_= Content-Type: text/plain; charset="us-ascii" comments in text - julo "Pittman, Joseph" Sent by: owner-ips@ece.cmu.edu 05/01/2002 11:12 PM Please respond to "Pittman, Joseph" To: Julian Satran/Haifa/IBM@IBMIL cc: "'ips@ece.cmu.edu'" Subject: Re: iSCSI: Target increment CmdSN on unretryable rejects Julian, Thanks for your quick response. Can you help me by answering the followup question below? > What am I missing here? > > A) Is there a class of 'command rejects' for which CmdSN should > be incremented? Namely, those commands for which retrying the > same command doesn't make sense? > > B) Or perhaps the specification must allow an initiator to plug > a CmdSN hole by sending a NOP. > > +++ the interdiction on pluging is to insure that the initiator > knows what he does and has enough tools to keep the intended > order. For the case you describe initiator may abort the > "hole" (that is allowed) on the same connection as specified > under task management. Enabling NOPs is not needed +++ I see the following text in Draft12, section 9.6.1: For the ABORT TASK function: a) if the ITT identifies a valid task... b) if the ITT does not identify an existing task but if the CmdSN indicated by the RefCmdSN field in the task management function request is within the valid CmdSN window (between MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received and return the "Function complete" response. c) if the ITT does not identify an existing task and ... outside the valid CmdSN window, ... "Task does not exist" Is case b) above the piece of text within the specification that describes 'aborting the hole', or is there some other discussion of this? +++ yes +++ To make sure I am clear on this, can you tell me whether the following statements are accurate? Consider this situation: - Target's ExpCmdSN=10, MaxCmdSN=19 - Initiator sends 4 commands, numbered 10-13 - Target processes command 10, recognizes a situation which warrants reject, and which will always warrant a reject no matter how many times it is retried (i.e. Text command with invalid TTT; SNACK for data when target does not support; or ANY Invalid PDU field-type error) In this situation, my understanding is that the target must behave as follows: - Delay submission of commands 11-13 until the command window hole at CmdSN=10 is plugged - If the initiator retries command 10, the target will send the same reject message again - If the initiator sends a non-immediate TaskMgmt ABORT_TASK command (CmdSN 14), to abort command 10, the target will NOT process command 14 because the hole has still not been filled - If the initiator sends an immediate TaskMgmt ABORT_TASK command to abort command 10, the target will process this request immediately, consider command 10 to have been sent (9.6.1 case b), close the hole, and respond to the immediate TaskMgmt command with Function Complete. Then, the target will resume submitting the sequenced commands starting with 11 (since the hole at 10 has been closed). Is my understanding correct? +++ yes +++ Thanks for your continued help. -- Joe Pittman jpittman@netapp.com --=_alternative 0072E3A0C2256BAC_= Content-Type: text/html; charset="us-ascii"

comments in text - julo


"Pittman, Joseph" <Joseph.Pittman@netapp.com>
Sent by: owner-ips@ece.cmu.edu

05/01/2002 11:12 PM
Please respond to "Pittman, Joseph"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
        Subject:        Re: iSCSI: Target increment CmdSN on unretryable rejects

       


Julian,
Thanks for your quick response.  Can you help me by answering
the followup question below?

> What am I missing here?
>
> A) Is there a class of 'command rejects' for which CmdSN should
>    be incremented?  Namely, those commands for which retrying the
>    same command doesn't make sense?
>
> B) Or perhaps the specification must allow an initiator to plug
>    a CmdSN hole by sending a NOP.
>
> +++ the interdiction on pluging is to insure that the initiator
>     knows what he does and has enough tools to keep the intended
>     order.  For the case you describe initiator may abort the
>     "hole" (that is allowed) on the same connection as specified
>     under task management.  Enabling NOPs is not needed +++

I see the following text in Draft12, section 9.6.1:

 For the ABORT TASK function:
   a) if the ITT identifies a valid task...
   b) if the ITT does not identify an existing task but if the
      CmdSN indicated by the RefCmdSN field in the task management
      function request is within the valid CmdSN window (between
      MaxCmdSN and ExpCmdSN), targets must consider the CmdSN
      received and return the "Function complete" response.
   c) if the ITT does not identify an existing task and ...
      outside the valid CmdSN window, ... "Task does not exist"

Is case b) above the piece of text within the specification that
describes 'aborting the hole', or is there some other discussion
of this?
+++ yes +++

To make sure I am clear on this, can you tell me whether the
following statements are accurate?

Consider this situation:

 - Target's ExpCmdSN=10, MaxCmdSN=19
 - Initiator sends 4 commands, numbered 10-13
 - Target processes command 10, recognizes a situation which
   warrants reject, and which will always warrant a reject
   no matter how many times it is retried (i.e. Text command
   with invalid TTT; SNACK for data when target does not support;
   or ANY Invalid PDU field-type error)

In this situation, my understanding is that the target must
behave as follows:

 - Delay submission of commands 11-13 until the command window
   hole at CmdSN=10 is plugged
 - If the initiator retries command 10, the target will send
   the same reject message again
 - If the initiator sends a non-immediate TaskMgmt ABORT_TASK
   command (CmdSN 14), to abort command 10, the target will NOT
   process command 14 because the hole has still not been filled
 - If the initiator sends an immediate TaskMgmt ABORT_TASK command
   to abort command 10, the target will process this request
   immediately, consider command 10 to have been sent (9.6.1 case b),
   close the hole, and respond to the immediate TaskMgmt command with
   Function Complete.  Then, the target will resume submitting
   the sequenced commands starting with 11 (since the hole at 10
   has been closed).

Is my understanding correct?

+++ yes +++

Thanks for your continued help.
--
Joe Pittman
jpittman@netapp.com



--=_alternative 0072E3A0C2256BAC_=-- From owner-ips@ece.cmu.edu Thu May 2 03:52:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29164 for ; Thu, 2 May 2002 03:52:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g427CMU05597 for ips-outgoing; Thu, 2 May 2002 03:12:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msr.hinet.net (msr13.hinet.net [168.95.4.113]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g427CJw05592 for ; Thu, 2 May 2002 03:12:20 -0400 (EDT) Received: from thinkpad (61-222-223-118.HINET-IP.hinet.net [61.222.223.118]) by msr.hinet.net (8.9.3/8.9.3) with ESMTP id PAA12328 for ; Thu, 2 May 2002 15:12:16 +0800 (CST) From: "Chien-Liang Chen" To: Subject: remove Date: Thu, 2 May 2002 15:11:46 +0800 Message-ID: <002101c1f1a8$9f3efe70$2e02a8c0@thinkpad> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C1F1EB.AD63C510" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C1F1EB.AD63C510 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit remove ------=_NextPart_000_0022_01C1F1EB.AD63C510 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

remove

------=_NextPart_000_0022_01C1F1EB.AD63C510-- From owner-ips@ece.cmu.edu Thu May 2 09:30:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23811 for ; Thu, 2 May 2002 09:30:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g42ClTZ04380 for ips-outgoing; Thu, 2 May 2002 08:47:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [195.212.91.196]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g42ClRw04370 for ; Thu, 2 May 2002 08:47:27 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id g42ClKgE044116; Thu, 2 May 2002 14:47:20 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g42ClKD155622; Thu, 2 May 2002 14:47:20 +0200 To: Jarda Beran Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Request to change Logout Request X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 2 May 2002 15:47:18 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 02/05/2002 15:47:20, Serialize complete at 02/05/2002 15:47:20 Content-Type: multipart/alternative; boundary="=_alternative 00460B02C2256BAD_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00460B02C2256BAD_= Content-Type: text/plain; charset="us-ascii" I will look into it - Julo Jarda Beran 05/02/2002 11:21 AM Please respond to Jarda Beran To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: iSCSI: Request to change Logout Request Hello Julian, Can I make a request to change the position of the field "Reason code" in the Logout Request from offset 23 to 3. This change would make the PDU consistent with others and make decoding simpler as most PDUs have fields "Reason" or "Response" at offset 3. As you know offsets 20-23 are usually used for "Target Transfer Tag", except "Expected Data Transfer Length" in the SCSI command (it have no reserved fields) and "CID" for Login/Logout requests. I think that "CID" could be placed e.g. at offset 40 as an "additional" parameter. Regards, Jarda ------- Jarda Beran Software Engineer Silicon & Software Systems Safrankova 1 155 00 Praha 5 Czech Republic --=_alternative 00460B02C2256BAD_= Content-Type: text/html; charset="us-ascii"
I will look into it - Julo


Jarda Beran <jaroslav.beran@s3group.com>

05/02/2002 11:21 AM
Please respond to Jarda Beran

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        iSCSI: Request to change Logout Request

       


Hello Julian,

Can I make a request to change the position of the field "Reason code"
in
the Logout Request from offset 23 to 3.
This change would make the PDU consistent with others and make decoding
simpler as most PDUs have fields "Reason" or "Response" at offset 3.

As you know offsets 20-23 are usually used for "Target Transfer Tag",
except
"Expected Data Transfer Length" in the SCSI command (it have no reserved
fields) and "CID" for Login/Logout requests. I think that "CID" could be
placed e.g. at offset 40 as an "additional" parameter.


Regards,

   Jarda

-------
Jarda Beran
Software Engineer
Silicon & Software Systems
Safrankova 1
155 00  Praha 5
Czech Republic

--=_alternative 00460B02C2256BAD_=-- From owner-ips@ece.cmu.edu Thu May 2 10:46:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02148 for ; Thu, 2 May 2002 10:46:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g42EAvW10432 for ips-outgoing; Thu, 2 May 2002 10:10:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from S3-Prague.fw (s3group.dial-up.cz [193.85.188.82]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g428Law09897 for ; Thu, 2 May 2002 04:21:37 -0400 (EDT) Received: from ([193.85.188.86]) by S3-Prague.fw; Thu, 02 May 2002 10:20:59 +0200 (MET DST) Received: from S3-Prague.fw (s3group-6.dial-up.cz [193.85.188.85]) by lynx.s3group.cz with SMTP id KAA28699; Thu, 2 May 2002 10:21:28 +0200 (MET DST) Received: from ([192.168.60.3]) by S3-Prague.fw; Thu, 02 May 2002 10:20:56 +0200 (MET DST) Message-ID: <3CD0F705.17C9B526@s3group.com> Date: Thu, 02 May 2002 10:21:25 +0200 From: Jarda Beran Organization: Silicon & Software Systems X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Julian_Satran@il.ibm.com CC: ips@ece.cmu.edu Subject: iSCSI: Request to change Logout Request Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello Julian, Can I make a request to change the position of the field "Reason code" in the Logout Request from offset 23 to 3. This change would make the PDU consistent with others and make decoding simpler as most PDUs have fields "Reason" or "Response" at offset 3. As you know offsets 20-23 are usually used for "Target Transfer Tag", except "Expected Data Transfer Length" in the SCSI command (it have no reserved fields) and "CID" for Login/Logout requests. I think that "CID" could be placed e.g. at offset 40 as an "additional" parameter. Regards, Jarda ------- Jarda Beran Software Engineer Silicon & Software Systems Safrankova 1 155 00 Praha 5 Czech Republic From owner-ips@ece.cmu.edu Thu May 2 10:49:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02468 for ; Thu, 2 May 2002 10:49:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g42EBIK10486 for ips-outgoing; Thu, 2 May 2002 10:11:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g42CI0w02451 for ; Thu, 2 May 2002 08:18:00 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17150; Thu, 2 May 2002 08:17:53 -0400 (EDT) Message-Id: <200205021217.IAA17150@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-fcip-wglc-01.txt,.pdf Date: Thu, 02 May 2002 08:17:53 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : FCIP 1st WG Last Call Author(s) : R. Weber Filename : draft-ietf-ips-fcip-wglc-01.txt,.pdf Pages : 69 Date : 01-May-02 This ips (IP Storage) working group draft contains all the working group last call comments received regarding: draft-ietf-ips-fcovertcpip-09.txt The proposed disposition of each comment also is recorded in this draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-fcip-wglc-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-fcip-wglc-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020501141322.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcip-wglc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcip-wglc-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020501141322.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu May 2 11:37:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07115 for ; Thu, 2 May 2002 11:37:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g42Ex6Q14155 for ips-outgoing; Thu, 2 May 2002 10:59:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g42Ex4w14151 for ; Thu, 2 May 2002 10:59:04 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 10:51:24 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E05040983@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: RE: Relation between iSCSI session and IPSec SAs Date: Thu, 2 May 2002 10:57:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > I found a similar statement in the mailing list from February but no > discussion about this issue: > "If an implementor wants to put all their iSCSI sessions on the same IPSec > SA, I think they should have that liberty." > > So the question is, what is the situation? Must we negotiate per multiple > session (and evaluate packets additional for a session identifier) or must > we not? The current situation is that there are no IP Storage requirements in this space; one manage both phase 1 and phase 2 SAs in whatever fashion makes sense. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu May 2 20:01:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19793 for ; Thu, 2 May 2002 20:00:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g42NABT27347 for ips-outgoing; Thu, 2 May 2002 19:10:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g42NA7w27336 for ; Thu, 2 May 2002 19:10:07 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id E1375BBD4; Thu, 2 May 2002 17:10:06 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id A5573305; Thu, 2 May 2002 17:10:06 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 02 May 2002 17:10:06 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <262CQ2Y2>; Thu, 2 May 2002 17:10:06 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00BC00998@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Julian Satran , ips@ece.cmu.edu Subject: RE: iSCSI - re-phrase of 4.1 Date: Thu, 2 May 2002 17:09:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-e5c315b1-5e1c-11d6-ac7c-009027aa5b50" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-e5c315b1-5e1c-11d6-ac7c-009027aa5b50 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F22E.7AF2BB70" ------_=_NextPart_001_01C1F22E.7AF2BB70 Content-Type: text/plain; charset="iso-8859-1" hex-constant: unsigned hexadecimal constant described by regu-lar expression "0[xX][0-9a-zA-Z]+" Hexidecimal only uses the alphabet up to F so the regular expression should be: "0[xX][0-9a-fA-F]+" Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, April 27, 2002 9:15 AM To: ips@ece.cmu.edu Subject: iSCSI - re-phrase of 4.1 Here is an attemp to re-phrase 4.1. Please note that the only substantive change introduced is the limit of 2**64 for the decimal encoding. The fact that key names must start with a letter and that binaries are all unsigned is made explicit. Please comment: The initiator and target send a set of key=value pairs encoded in UTF-8 Unicode. All the text keys and text values specified in this docu-ment are to be presented and interpreted in the case they appear in this document. They are case sensitive. The following character symbols are used in this document for text items: (a-z, A-Z) - letters (0-9) - digits " " (0x20) - space "." (0x2e) - point "-" (0x2d) - minus "+" (0x2b) - plus "@" (0x40) - commercial at "_" (0x5f) - underscore "=" (0x3d) - equal ":" (0x3a) - colon "/" (0x2f) - solidus or slash "[" (0x5b) - left bracket "]" (0x5d) - right bracket null(0x00) - null separator "," (0x2c) - comma "~" (0x7e) - tilde A key is key-name followed by "=". The term key is used frequently in this document with the meaning of key-name. A value is whatever follows the = that follows the key-name up to a null separator - that separates one key value from the next A value is either a simple-value or a list-of-values. The following definitions will be used in the rest of this document: key-name: a string defined by the regular expression "[A-Z][a-zA-Z0-9.-+@_]*" text-value: a string defined by the regular expression "[][a-zA-Z0-9.-+@_/\[\]=]*" boolean-value: a string defined by the regular expression "Yes|No" hex-constant: unsigned hexadecimal constant described by regu-lar expression "0[xX][0-9a-zA-Z]+" base-64-constant: unsigned base-64 constant described by regu-lar expression "0b[A-Za-z0-9+/=]+" regular-binary-value : an unsigned integer less than 2**64 encoded as a decimal constant, hex constant, or base-64 con-stant large-binary-value : an unsigned integer larger than 2**64-1 encoded as a hex constant, or base-64 constant binary-value: a regular-binary-value or a large binary-value numeric-range: two binary-values separated by a tilde simple-value: text-value, boolean-value, binary-value or a numeric range. list-of-values: a sequence of simple-values separated by comma Key names MUST NOT exceed 63 bytes. If not otherwise specified, the maximum length of a simple-value (not its encoded representation) is 255 bytes not including the delimiter (comma or null). Any iSCSI target or initiator MUST support receiving at least 16384 bytes of key=value data in a negotiation sequence except when indicat-ing support for very long authentication items such as public key cer-tificates in which case they MUST support receiving at least 64 kilobytes of key=value data. ------_=_NextPart_001_01C1F22E.7AF2BB70 Content-Type: text/html; charset="iso-8859-1"
hex-constant: unsigned hexadecimal constant described by regu-lar expression "0[xX][0-9a-zA-Z]+"
Hexidecimal only uses the alphabet up to F so the regular expression should be: "0[xX][0-9a-fA-F]+"
 
 
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, April 27, 2002 9:15 AM
To: ips@ece.cmu.edu
Subject: iSCSI - re-phrase of 4.1


Here is an attemp to re-phrase 4.1.
Please note that the only substantive change introduced is the limit of 2**64 for the decimal encoding.
The fact that key names must start with a letter and that binaries are all unsigned is made explicit.

Please comment:

The initiator and target send a set of key=value pairs encoded in UTF-8 Unicode. All the text keys and text values specified in this docu-ment are to be presented and interpreted in the case they appear in this document. They are case sensitive.

The following character symbols are used in this document for text items:

(a-z, A-Z) - letters
(0-9) - digits
" " (0x20) - space
"." (0x2e) - point
"-" (0x2d) - minus
"+" (0x2b) - plus
"@" (0x40) - commercial at
"_" (0x5f) - underscore
"=" (0x3d) - equal
":" (0x3a) - colon
"/" (0x2f) - solidus or slash
"[" (0x5b) - left bracket
"]" (0x5d) - right bracket
null(0x00) - null separator
"," (0x2c) - comma
"~" (0x7e) - tilde

A key is key-name followed by "=". The term key is used frequently in this document with the meaning of key-name.

A value is whatever follows the = that follows the key-name up to a null separator - that separates one key value from the next

A value is either a simple-value or a list-of-values.

The following definitions will be used in the rest of this document:

key-name: a string defined by the regular expression
"[A-Z][a-zA-Z0-9.-+@_]*"

text-value: a string defined by the regular expression
"[][a-zA-Z0-9.-+@_/\[\]=]*"

boolean-value: a string defined by the regular expression
"Yes|No"

hex-constant: unsigned hexadecimal constant described by regu-lar expression "0[xX][0-9a-zA-Z]+"

base-64-constant: unsigned base-64 constant described by regu-lar expression "0b[A-Za-z0-9+/=]+"

regular-binary-value :  an unsigned integer less than 2**64 encoded as a decimal constant, hex constant, or base-64 con-stant

large-binary-value :  an unsigned integer larger than 2**64-1 encoded as a hex constant, or base-64 constant

binary-value: a regular-binary-value or a large binary-value

numeric-range: two binary-values separated by a tilde

simple-value: text-value, boolean-value, binary-value or a numeric range.

list-of-values: a sequence of simple-values separated by comma


Key names MUST NOT exceed 63 bytes.  If not otherwise specified, the maximum length of a simple-value (not its encoded representation) is 255 bytes not including the delimiter (comma or null).

Any iSCSI target or initiator MUST support receiving at least 16384 bytes of key=value data in a negotiation sequence except when indicat-ing support for very long authentication items such as public key cer-tificates in which case they MUST support receiving at least 64 kilobytes of key=value data. ------_=_NextPart_001_01C1F22E.7AF2BB70-- ------=_NextPartTM-000-e5c315b1-5e1c-11d6-ac7c-009027aa5b50-- From owner-ips@ece.cmu.edu Thu May 2 20:05:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19857 for ; Thu, 2 May 2002 20:05:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g42NiNE00303 for ips-outgoing; Thu, 2 May 2002 19:44:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g42NiKw00290 for ; Thu, 2 May 2002 19:44:20 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id BB0BD104D; Thu, 2 May 2002 17:44:19 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 9DE7711B; Thu, 2 May 2002 17:44:19 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 02 May 2002 17:44:17 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 17:44:17 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00BC009A4@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI 4.1 & 4.2 Date: Thu, 2 May 2002 17:44:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Please change "All negotiations are stateless and explicit..." to "All negotiations are explicit..." as has been discussed. Also, since a key-value pair can span request or response boundaries, the null-separator should be used to terminate every value and not just a value that is followed by another key. Otherwise, one won't know if the last key-value in a PDU is complete or has a value that will continue in the next PDU and one won't be able to respond to the key until one gets the next key (or maybe a PDU with no parameters if we assume that sending PDU with an empty parameter field means that the last value is complete). Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, April 27, 2002 12:39 PM To: ips@ece.cmu.edu Subject: iSCSI 4.1 & 4.2 Here are the rephrased 4.1 & 4.2 for better context: Text Format The initiator and target send a set of key=value pairs encoded in UTF-8 Unicode. All the text keys and text values specified in this docu-ment are to be presented and interpreted in the case they appear in this document. They are case sensitive. The following character symbols are used in this document for text items: (a-z, A-Z) - letters (0-9) - digits " " (0x20) - space "." (0x2e) - point "-" (0x2d) - minus "+" (0x2b) - plus "@" (0x40) - commercial at "_" (0x5f) - underscore "=" (0x3d) - equal ":" (0x3a) - colon "/" (0x2f) - solidus or slash "[" (0x5b) - left bracket "]" (0x5d) - right bracket null(0x00) - null separator "," (0x2c) - comma "~" (0x7e) - tilde DLB> It would be good to say at this point that at least space, colon, DLB> comma, tilde, and null are reserved characters that cannot appear DLB> in key names or values. It's also worth saying that any character DLB> not in the above list is reserved for future use and MUST NOT be used. A key is key-name followed by "=". The term key is used frequently in this document with the meaning of key-name. DLB> Really? Including the "=" in the definition of key is counter-intuitive, DLB> and the second sentence is an invitation to serious confusion. DLB> It would be better to introduce this as the separator in a definition DLB> of key-value-expression or key-value-pair. A value is whatever follows the = that follows the key-name up to a null separator - that separates one key value from the next The following definitions will be used in the rest of this document: key-name: a string defined by the regular expression "[A-Z][a-zA-Z0-9.-+@_]*" DLB> Need to explain the regular expression syntax. Also the last DLB> occurrence of minus needs a \ prefix to indicate that it's character DLB> rather than a regular expression syntax element. DLB> Starting here, I'd add a sentence to explain each regular expression. DLB> For example, "A key-name is a string consisting of letters, numbers, DLB> and/or the characters .-+@_ ; it MUST begin with a capital letter. text-value: a string defined by the regular expression "[][a-zA-Z0-9.-+@_/\[\]=]*" DLB> This appears to allow equal to occur in a text-value. I'd DLB> recommend against that, as it has obvious potential for confusion. DLB> It has the same issue with minus as the previous expression. boolean-value: a string defined by the regular expression "Yes|No" DLB> What about "yes" and "no", "YES" and "NO"? Weirder things like DLB> "yEs and "nO" don't seem useful, though. hex-constant: unsigned hexadecimal constant described by regu-lar expression "0[xX][0-9a-zA-Z]+" DLB> That should be "[0-9a-fA-F]" with a note that the letters are case- DLB> insensitive, and a through f (A through F) represent the decimal DLB> values 10 through 16 as hex digits. base-64-constant: unsigned base-64 constant described by regu-lar expression "0b[A-Za-z0-9+/=]+" DLB> Occurrence of "=" in the constants is a potential problem, similar to DLB> allowing it in the text values. Also, similar to hex, describe what DLB> the characters other than digits denote, and in addition DLB> how possible letter "O" vs. number "0" and letter "l" vs. number "1" DLB> confusion is avoided. regular-numerical-value : an unsigned integer less than 2**64 encoded as a decimal constant, hex constant, or base-64 con-stant large-numerical-value : an unsigned integer larger than 2**64-1 encoded as a hex constant, or base-64 constant DLB> Add an explicit statement that decimal representation MUST NOT be used DLB> for numbers >= 2^64. I realize that any mathematician or logician DLB> can figure this out, but we're dealing with implementers who can use DLB> all the help they can get ... numerical-value: a regular-numerical-value or a large numeri-cal-value numeric-range: two numerical-values separated by a tilde simple-value: text-value, boolean-value, numeric-value or a numeric range. list-of-values: a sequence of text-values separated by comma Key names MUST NOT exceed 63 bytes. If not otherwise specified, the maximum length of a simple-value (not its encoded representation) is 255 bytes not including the delimiter (comma or null). Any iSCSI target or initiator MUST support receiving at least 16384 bytes of key=value data in a negotiation sequence except when indicat-ing support for very long authentication items such as public key cer-tificates in which case they MUST support receiving at least 64 kilobytes of key=value data. DLB> Say how that "support for very long authentication items" is indicated. Text Mode Negotiation During login, and thereafter, some session or connection parameters are negotiated through an exchange of textual information. The initiator starts the negotiation through a Text/Login request and indicates when it is ready for completion (by setting to 1 and keeping to 1 the F bit in a Text Request or the T bit in the Login Request). The general format of text negotiation is: Originator-> = Responder-> =|NotUnderstood|Irrelevant|Reject The originator can either be the initiator or the target and the responder can either be the target or initiator, respectively. Target requests are not limited to respond to key=value pairs as offered by the initiator. The target may offer key=value pairs of its own. All negotiations are stateless and explicit (i.e., the result MUST be based only on newly exchanged values). There is no such thing as implicit offers. If an explicit offer is not made then a reply cannot be expected. DLB> Delete "stateless and", as there is state retained (e.g., is the response DLB> the same as what was offered). Is this the place to put in the requirement DLB> that any value that has a significant affect on the correct operation or DLB> performance of an implementation MUST be negotiated? In other words, a DLB> default value MUST NOT be relied upon when use of some other value by the DLB> other party has serious consequences - implementers are free to decide DLB> which consequences are serious, but we need this requirement to prevent DLB> "It's not my fault, that other implementation didn't use the default" DLB> interoperability/finger-pointing problems. The value offered can be an numerical-value, a numerical-range defined by lower and upper value - both integers separated by tilde, a text-value, a boolean-value (Yes or No), or a list of comma sepa-rated text-values. A range MAY ONLY be offered if it is explicitly allowed for a key. A selected value can be an numerical-value, a text-value or a boolean-value. In list negotiation, the originator sends a list of values (which may include "None") for each key in its order of preference. The responding party answers with the first value that it supports and is allowed to use for the specific originator selected from the orig-inator list. DLB> "first" is a potential problem. If this was intended, it needs to DLB> come with a warning that when larger numeric values are preferred, DLB> numeric lists need to be listed in descending order rather than DLB> ascending order ... but this convention does not apply to ranges, DLB> which is peculiar. I'm not sure about this priority order convention. The constant "None" MUST always be used to indicate a missing func-tion. However, None is a valid selection only if it is explicitly offered. If a responder does not understand any particular value in a list it MUST ignore it. If a responder does not support, does not understand or is not allowed to use all of the offered options with a specific originator, it MAY use the constant "Reject". The selection of a value not admissible under the selection rules is considered a negoti-ation failure and is handled accordingly. DLB> That "MAY" is a problem. It should be a MUST, possibly with some DLB> rephrasing. If the "MAY" remains, a sentence explaining the alternative(s) DLB> needs to be added. For simple-value negotiations, the responding party MUST respond with the required key. The value it selects, based on the selection rule specific to the key, becomes the negotiation result. For a numerical range the value selected must be an integer within the offered range or "Reject" (if the range is unacceptable). An offer of a value not admissible MAY be answered with the constant "Reject". The selection of a value not admissible under the selection rules is considered a negotiation failure and is handled accordingly. DLB> Use upper case MUST in "value selected must", Also the MAY for "Reject" DLB> has the same problem as the previous MAY compounded by the need for DLB> an explanation of "value not admissible". For boolean negotiations (keys taking the values Yes or No), the responding party MUST respond with the required key and the result of the negotiation when the received value does not determine that result by itself. The last value transmitted becomes the negotiation result. The rules for selecting the value with which to respond are expressed as Boolean functions of the value received and the value that the responding party would select in the absence of knowledge of the received value. Specifically, the two cases in which responses are OPTIONAL are: - The boolean function is "AND" and the value "No" is received. The outcome of the negotiation is "No". - The boolean function is "OR" and the value "Yes" is received. The outcome of the negotiation is "Yes". DLB> On further reflection, this seems a bit on the clever side and a minor DLB> optimization. Does anyone else care? The alternative would be to DLB> always require explicit responses (even when there is only one DLB> acceptable response) at the possible cost of an extra negotiation DLB> round trip. Responses are REQUIRED in all other cases, and the value chosen and sent by the responder becomes the outcome of the negotiation. An offer of a value not admissible MAY be answered with the constant "Reject". The selection of a value not admissible under the selection rules is considered a negotiation failure and is handled accordingly. DLB> Need to define "offer of a value not admissible". If a specific key is not relevant for the current negotiation, the responder may answer with the constant "Irrelevant" for all types of negotiation. However the negotiation is not considered as failed if the response is Irrelevant. DLB> But, but ... if the Initiator considers the key important, the negotiation DLB> may fail. Implementers should (lower case) be cautious and conservative DLB> in using "Irrelevant", as humoring the other party to the negotiation DLB> when it behaves in a somewhat clue-impaired fashion improves inter- DLB> operability. Any other key not understood by the responder may be ignored by the responder without affecting the basic function. However, the Text Response for a key not understood MUST be key=NotUnderstood. The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and must only be used as described here. DLB> Do we want to reserve any other strings for future use? Some basic key=value pairs are described in Chapter 11. All keys in Chapter 11, except for the X- extension format, MUST be supported by iSCSI initiators and targets and MUST NOT be answered with NotUnder-stood. Manufacturers may introduce new keys by prefixing them with X- fol-lowed by their (reversed) domain name. For example the company owning the domain acme.com can issue: X-com.acme.bar.foo.do_something=3 DLB> Change "Manufacturers" to "Implementers" and "company" to "entity" for DLB> generality. From owner-ips@ece.cmu.edu Thu May 2 22:24:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22320 for ; Thu, 2 May 2002 22:24:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g431flw06843 for ips-outgoing; Thu, 2 May 2002 21:41:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g431fhw06836 for ; Thu, 2 May 2002 21:41:43 -0400 (EDT) Received: (from mailgate@localhost) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id VAA04532 for ips@ece.cmu.edu; Thu, 2 May 2002 21:41:34 -0400 (EDT) Received: from compuserve.com (mid-tgn-neu-vty37.as.wcom.net [216.192.70.37]) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id VAA04499 for ; Thu, 2 May 2002 21:41:27 -0400 (EDT) Message-ID: <3CD1EB45.4D2A1D1C@compuserve.com> Date: Thu, 02 May 2002 20:43:33 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: Revised FCIP Last Call comments resolution posted Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The recently posted: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.txt http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.pdf contains the proposed FCIP last call comments resolutions with revision based on the discussions on this reflector. Please review these comments resolutions to ensure that the desired changes are described. Thanks. .Ralph From owner-ips@ece.cmu.edu Fri May 3 02:16:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05611 for ; Fri, 3 May 2002 02:16:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g435Pnj18838 for ips-outgoing; Fri, 3 May 2002 01:25:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g435Plw18833 for ; Fri, 3 May 2002 01:25:47 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g435PcjI008628; Fri, 3 May 2002 07:25:38 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g435PbA47986; Fri, 3 May 2002 07:25:37 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI 4.1 & 4.2 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 3 May 2002 08:25:34 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 03/05/2002 08:25:37, Serialize complete at 03/05/2002 08:25:37 Content-Type: multipart/alternative; boundary="=_alternative 001D3194C2256BAE_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001D3194C2256BAE_= Content-Type: text/plain; charset="us-ascii" thanks - I did already both - and will publish as soon as I have all the input from the names - Julo pat_thaler@agilent.com 05/03/2002 02:44 AM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI 4.1 & 4.2 Julian, Please change "All negotiations are stateless and explicit..." to "All negotiations are explicit..." as has been discussed. Also, since a key-value pair can span request or response boundaries, the null-separator should be used to terminate every value and not just a value that is followed by another key. Otherwise, one won't know if the last key-value in a PDU is complete or has a value that will continue in the next PDU and one won't be able to respond to the key until one gets the next key (or maybe a PDU with no parameters if we assume that sending PDU with an empty parameter field means that the last value is complete). Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, April 27, 2002 12:39 PM To: ips@ece.cmu.edu Subject: iSCSI 4.1 & 4.2 Here are the rephrased 4.1 & 4.2 for better context: Text Format The initiator and target send a set of key=value pairs encoded in UTF-8 Unicode. All the text keys and text values specified in this docu-ment are to be presented and interpreted in the case they appear in this document. They are case sensitive. The following character symbols are used in this document for text items: (a-z, A-Z) - letters (0-9) - digits " " (0x20) - space "." (0x2e) - point "-" (0x2d) - minus "+" (0x2b) - plus "@" (0x40) - commercial at "_" (0x5f) - underscore "=" (0x3d) - equal ":" (0x3a) - colon "/" (0x2f) - solidus or slash "[" (0x5b) - left bracket "]" (0x5d) - right bracket null(0x00) - null separator "," (0x2c) - comma "~" (0x7e) - tilde DLB> It would be good to say at this point that at least space, colon, DLB> comma, tilde, and null are reserved characters that cannot appear DLB> in key names or values. It's also worth saying that any character DLB> not in the above list is reserved for future use and MUST NOT be used. A key is key-name followed by "=". The term key is used frequently in this document with the meaning of key-name. DLB> Really? Including the "=" in the definition of key is counter-intuitive, DLB> and the second sentence is an invitation to serious confusion. DLB> It would be better to introduce this as the separator in a definition DLB> of key-value-expression or key-value-pair. A value is whatever follows the = that follows the key-name up to a null separator - that separates one key value from the next The following definitions will be used in the rest of this document: key-name: a string defined by the regular expression "[A-Z][a-zA-Z0-9.-+@_]*" DLB> Need to explain the regular expression syntax. Also the last DLB> occurrence of minus needs a \ prefix to indicate that it's character DLB> rather than a regular expression syntax element. DLB> Starting here, I'd add a sentence to explain each regular expression. DLB> For example, "A key-name is a string consisting of letters, numbers, DLB> and/or the characters .-+@_ ; it MUST begin with a capital letter. text-value: a string defined by the regular expression "[][a-zA-Z0-9.-+@_/\[\]=]*" DLB> This appears to allow equal to occur in a text-value. I'd DLB> recommend against that, as it has obvious potential for confusion. DLB> It has the same issue with minus as the previous expression. boolean-value: a string defined by the regular expression "Yes|No" DLB> What about "yes" and "no", "YES" and "NO"? Weirder things like DLB> "yEs and "nO" don't seem useful, though. hex-constant: unsigned hexadecimal constant described by regu-lar expression "0[xX][0-9a-zA-Z]+" DLB> That should be "[0-9a-fA-F]" with a note that the letters are case- DLB> insensitive, and a through f (A through F) represent the decimal DLB> values 10 through 16 as hex digits. base-64-constant: unsigned base-64 constant described by regu-lar expression "0b[A-Za-z0-9+/=]+" DLB> Occurrence of "=" in the constants is a potential problem, similar to DLB> allowing it in the text values. Also, similar to hex, describe what DLB> the characters other than digits denote, and in addition DLB> how possible letter "O" vs. number "0" and letter "l" vs. number "1" DLB> confusion is avoided. regular-numerical-value : an unsigned integer less than 2**64 encoded as a decimal constant, hex constant, or base-64 con-stant large-numerical-value : an unsigned integer larger than 2**64-1 encoded as a hex constant, or base-64 constant DLB> Add an explicit statement that decimal representation MUST NOT be used DLB> for numbers >= 2^64. I realize that any mathematician or logician DLB> can figure this out, but we're dealing with implementers who can use DLB> all the help they can get ... numerical-value: a regular-numerical-value or a large numeri-cal-value numeric-range: two numerical-values separated by a tilde simple-value: text-value, boolean-value, numeric-value or a numeric range. list-of-values: a sequence of text-values separated by comma Key names MUST NOT exceed 63 bytes. If not otherwise specified, the maximum length of a simple-value (not its encoded representation) is 255 bytes not including the delimiter (comma or null). Any iSCSI target or initiator MUST support receiving at least 16384 bytes of key=value data in a negotiation sequence except when indicat-ing support for very long authentication items such as public key cer-tificates in which case they MUST support receiving at least 64 kilobytes of key=value data. DLB> Say how that "support for very long authentication items" is indicated. Text Mode Negotiation During login, and thereafter, some session or connection parameters are negotiated through an exchange of textual information. The initiator starts the negotiation through a Text/Login request and indicates when it is ready for completion (by setting to 1 and keeping to 1 the F bit in a Text Request or the T bit in the Login Request). The general format of text negotiation is: Originator-> = Responder-> =|NotUnderstood|Irrelevant|Reject The originator can either be the initiator or the target and the responder can either be the target or initiator, respectively. Target requests are not limited to respond to key=value pairs as offered by the initiator. The target may offer key=value pairs of its own. All negotiations are stateless and explicit (i.e., the result MUST be based only on newly exchanged values). There is no such thing as implicit offers. If an explicit offer is not made then a reply cannot be expected. DLB> Delete "stateless and", as there is state retained (e.g., is the response DLB> the same as what was offered). Is this the place to put in the requirement DLB> that any value that has a significant affect on the correct operation or DLB> performance of an implementation MUST be negotiated? In other words, a DLB> default value MUST NOT be relied upon when use of some other value by the DLB> other party has serious consequences - implementers are free to decide DLB> which consequences are serious, but we need this requirement to prevent DLB> "It's not my fault, that other implementation didn't use the default" DLB> interoperability/finger-pointing problems. The value offered can be an numerical-value, a numerical-range defined by lower and upper value - both integers separated by tilde, a text-value, a boolean-value (Yes or No), or a list of comma sepa-rated text-values. A range MAY ONLY be offered if it is explicitly allowed for a key. A selected value can be an numerical-value, a text-value or a boolean-value. In list negotiation, the originator sends a list of values (which may include "None") for each key in its order of preference. The responding party answers with the first value that it supports and is allowed to use for the specific originator selected from the orig-inator list. DLB> "first" is a potential problem. If this was intended, it needs to DLB> come with a warning that when larger numeric values are preferred, DLB> numeric lists need to be listed in descending order rather than DLB> ascending order ... but this convention does not apply to ranges, DLB> which is peculiar. I'm not sure about this priority order convention. The constant "None" MUST always be used to indicate a missing func-tion. However, None is a valid selection only if it is explicitly offered. If a responder does not understand any particular value in a list it MUST ignore it. If a responder does not support, does not understand or is not allowed to use all of the offered options with a specific originator, it MAY use the constant "Reject". The selection of a value not admissible under the selection rules is considered a negoti-ation failure and is handled accordingly. DLB> That "MAY" is a problem. It should be a MUST, possibly with some DLB> rephrasing. If the "MAY" remains, a sentence explaining the alternative(s) DLB> needs to be added. For simple-value negotiations, the responding party MUST respond with the required key. The value it selects, based on the selection rule specific to the key, becomes the negotiation result. For a numerical range the value selected must be an integer within the offered range or "Reject" (if the range is unacceptable). An offer of a value not admissible MAY be answered with the constant "Reject". The selection of a value not admissible under the selection rules is considered a negotiation failure and is handled accordingly. DLB> Use upper case MUST in "value selected must", Also the MAY for "Reject" DLB> has the same problem as the previous MAY compounded by the need for DLB> an explanation of "value not admissible". For boolean negotiations (keys taking the values Yes or No), the responding party MUST respond with the required key and the result of the negotiation when the received value does not determine that result by itself. The last value transmitted becomes the negotiation result. The rules for selecting the value with which to respond are expressed as Boolean functions of the value received and the value that the responding party would select in the absence of knowledge of the received value. Specifically, the two cases in which responses are OPTIONAL are: - The boolean function is "AND" and the value "No" is received. The outcome of the negotiation is "No". - The boolean function is "OR" and the value "Yes" is received. The outcome of the negotiation is "Yes". DLB> On further reflection, this seems a bit on the clever side and a minor DLB> optimization. Does anyone else care? The alternative would be to DLB> always require explicit responses (even when there is only one DLB> acceptable response) at the possible cost of an extra negotiation DLB> round trip. Responses are REQUIRED in all other cases, and the value chosen and sent by the responder becomes the outcome of the negotiation. An offer of a value not admissible MAY be answered with the constant "Reject". The selection of a value not admissible under the selection rules is considered a negotiation failure and is handled accordingly. DLB> Need to define "offer of a value not admissible". If a specific key is not relevant for the current negotiation, the responder may answer with the constant "Irrelevant" for all types of negotiation. However the negotiation is not considered as failed if the response is Irrelevant. DLB> But, but ... if the Initiator considers the key important, the negotiation DLB> may fail. Implementers should (lower case) be cautious and conservative DLB> in using "Irrelevant", as humoring the other party to the negotiation DLB> when it behaves in a somewhat clue-impaired fashion improves inter- DLB> operability. Any other key not understood by the responder may be ignored by the responder without affecting the basic function. However, the Text Response for a key not understood MUST be key=NotUnderstood. The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and must only be used as described here. DLB> Do we want to reserve any other strings for future use? Some basic key=value pairs are described in Chapter 11. All keys in Chapter 11, except for the X- extension format, MUST be supported by iSCSI initiators and targets and MUST NOT be answered with NotUnder-stood. Manufacturers may introduce new keys by prefixing them with X- fol-lowed by their (reversed) domain name. For example the company owning the domain acme.com can issue: X-com.acme.bar.foo.do_something=3 DLB> Change "Manufacturers" to "Implementers" and "company" to "entity" for DLB> generality. --=_alternative 001D3194C2256BAE_= Content-Type: text/html; charset="us-ascii"
thanks - I did already both - and will publish as soon as I have all the input from the names - Julo


pat_thaler@agilent.com

05/03/2002 02:44 AM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI 4.1 & 4.2

       


Julian,

Please change "All negotiations are stateless and explicit..." to "All
negotiations are explicit..." as has been discussed.

Also, since a key-value pair can span request or response boundaries,
the null-separator should be used to terminate every value and not just a
value that is followed by another key. Otherwise, one won't know if the last
key-value in a PDU is complete or has a value that will continue in the next
PDU and one won't be able to respond to the key until one gets the next key
(or maybe a PDU with no parameters if we assume that sending PDU with an
empty parameter field means that the last value is complete).

Pat

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, April 27, 2002 12:39 PM
To: ips@ece.cmu.edu
Subject: iSCSI 4.1 & 4.2

Here are the rephrased 4.1 & 4.2 for better context:

Text Format
The initiator and target send a set of key=value pairs encoded in UTF-8
Unicode. All the text keys and text values specified in this docu-ment are
to be presented and interpreted in the case they appear in this document.
They are case sensitive.

The following character symbols are used in this document for text items:

(a-z, A-Z) - letters
(0-9) - digits
" " (0x20) - space
"." (0x2e) - point
"-" (0x2d) - minus
"+" (0x2b) - plus
"@" (0x40) - commercial at
"_" (0x5f) - underscore
"=" (0x3d) - equal
":" (0x3a) - colon
"/" (0x2f) - solidus or slash
"[" (0x5b) - left bracket
"]" (0x5d) - right bracket
null(0x00) - null separator
"," (0x2c) - comma
"~" (0x7e) - tilde

DLB> It would be good to say at this point that at least space, colon,
DLB> comma, tilde, and null are reserved characters that cannot appear
DLB> in key names or values.  It's also worth saying that any character
DLB> not in the above list is reserved for future use and MUST NOT be used.

A key is key-name followed by "=". The term key is used frequently in this
document with the meaning of key-name.

DLB> Really?  Including the "=" in the definition of key is
counter-intuitive,
DLB> and the second sentence is an invitation to serious confusion.
DLB> It would be better to introduce this as the separator in a definition
DLB> of key-value-expression or key-value-pair.

A value is whatever follows the = that follows the key-name up to a null
separator - that separates one key value from the next

The following definitions will be used in the rest of this document:

key-name: a string defined by the regular expression
"[A-Z][a-zA-Z0-9.-+@_]*"

DLB> Need to explain the regular expression syntax.  Also the last
DLB> occurrence of minus needs a \ prefix to indicate that it's character
DLB> rather than a regular expression syntax element.

DLB> Starting here, I'd add a sentence to explain each regular expression.
DLB> For example, "A key-name is a string consisting of letters, numbers,
DLB> and/or the characters .-+@_  ; it MUST begin with a capital letter.

text-value: a string defined by the regular expression
"[][a-zA-Z0-9.-+@_/\[\]=]*"

DLB> This appears to allow equal to occur in a text-value.  I'd
DLB> recommend against that, as it has obvious potential for confusion.
DLB> It has the same issue with minus as the previous expression.

boolean-value: a string defined by the regular expression
"Yes|No"

DLB> What about "yes" and "no", "YES" and "NO"?  Weirder things like
DLB> "yEs and "nO" don't seem useful, though.

hex-constant: unsigned hexadecimal constant described by regu-lar expression
"0[xX][0-9a-zA-Z]+"

DLB> That should be "[0-9a-fA-F]" with a note that the letters are case-
DLB> insensitive, and a through f (A through F) represent the decimal
DLB> values 10 through 16 as hex digits.

base-64-constant: unsigned base-64 constant described by regu-lar expression
"0b[A-Za-z0-9+/=]+"

DLB> Occurrence of "=" in the constants is a potential problem, similar to
DLB> allowing it in the text values.  Also, similar to hex, describe what
DLB> the characters other than digits denote, and in addition
DLB> how possible letter "O" vs. number "0" and letter "l" vs. number "1"
DLB> confusion is avoided.

regular-numerical-value :  an unsigned integer less than 2**64 encoded as a
decimal constant, hex constant, or base-64 con-stant

large-numerical-value :  an unsigned integer larger than 2**64-1 encoded as
a hex constant, or base-64 constant

DLB> Add an explicit statement that decimal representation MUST NOT be used
DLB> for numbers >= 2^64.  I realize that any mathematician or logician
DLB> can figure this out, but we're dealing with implementers who can use
DLB> all the help they can get ...

numerical-value: a regular-numerical-value or a large numeri-cal-value

numeric-range: two numerical-values separated by a tilde

simple-value: text-value, boolean-value, numeric-value or a numeric range.

list-of-values: a sequence of text-values separated by comma


Key names MUST NOT exceed 63 bytes.  If not otherwise specified, the maximum
length of a simple-value (not its encoded representation) is 255 bytes not
including the delimiter (comma or null).

Any iSCSI target or initiator MUST support receiving at least 16384 bytes of
key=value data in a negotiation sequence except when indicat-ing support for
very long authentication items such as public key cer-tificates in which
case they MUST support receiving at least 64 kilobytes of key=value data.

DLB> Say how that "support for very long authentication items" is indicated.


Text Mode Negotiation
During login, and thereafter, some session or connection parameters are
negotiated through an exchange of textual information.

The initiator starts the negotiation through a Text/Login request and
indicates when it is ready for completion (by setting to 1 and keeping to 1
the F bit in a Text Request or the T bit in the Login Request).

The general format of text negotiation is:

Originator-> <key>=<valuex>
Responder-> <key>=<valuey>|NotUnderstood|Irrelevant|Reject

The originator can either be the initiator or the target and the responder
can either be the target or initiator, respectively. Target requests are not
limited to respond to key=value pairs as offered by the initiator. The
target may offer key=value pairs of its own.

All negotiations are stateless and explicit (i.e., the result MUST be based
only on newly exchanged values). There is no such thing as implicit offers.
If an explicit offer is not made then a reply cannot be expected.

DLB> Delete "stateless and", as there is state retained (e.g., is the
response
DLB> the same as what was offered).  Is this the place to put in the
requirement
DLB> that any value that has a significant affect on the correct operation
or
DLB> performance of an implementation MUST be negotiated?  In other words, a
DLB> default value MUST NOT be relied upon when use of some other value by
the
DLB> other party has serious consequences - implementers are free to decide
DLB> which consequences are serious, but we need this requirement to prevent
DLB> "It's not my fault, that other implementation didn't use the default"
DLB> interoperability/finger-pointing problems.

The value offered can be an numerical-value, a numerical-range defined by
lower and upper value - both integers separated by tilde, a text-value, a
boolean-value (Yes or No), or a list of comma sepa-rated text-values. A
range MAY ONLY be offered if it is explicitly allowed for a key. A selected
value can be an numerical-value, a text-value or a boolean-value.

In list negotiation, the originator sends a list of values (which may
include "None") for each key in its order of preference.

The responding party answers with the first value that it supports and is
allowed to use for the specific originator selected from the orig-inator
list.

DLB> "first" is a potential problem.  If this was intended, it needs to
DLB> come with a warning that when larger numeric values are preferred,
DLB> numeric lists need to be listed in descending order rather than
DLB> ascending order ... but this convention does not apply to ranges,
DLB> which is peculiar.  I'm not sure about this priority order convention.

The constant "None" MUST always be used to indicate a missing func-tion.
However, None is a valid selection only if it is explicitly offered.

If a responder does not understand any particular value in a list it MUST
ignore it. If a responder does not support, does not understand or is not
allowed to use all of the offered options with a specific originator, it MAY
use the constant "Reject".  The selection of a value not admissible under
the selection rules is considered a negoti-ation failure and is handled
accordingly.

DLB> That "MAY" is a problem.  It should be a MUST, possibly with some
DLB> rephrasing.  If the "MAY" remains, a sentence explaining the
alternative(s)
DLB> needs to be added.

For simple-value negotiations, the responding party MUST respond with the
required key. The value it selects, based on the selection rule specific to
the key, becomes the negotiation result. For a numerical range the value
selected must be an integer within the offered range or "Reject" (if the
range is unacceptable).  An offer of a value not admissible MAY be answered
with the constant "Reject". The selection of a value not admissible under
the selection rules is considered a negotiation failure and is handled
accordingly.

DLB> Use upper case MUST in "value selected must", Also the MAY for "Reject"
DLB> has the same problem as the previous MAY compounded by the need for
DLB> an explanation of "value not admissible".

For boolean negotiations (keys taking the values Yes or No), the responding
party MUST respond with the required key and the result of the negotiation
when the received value does not determine that result by itself. The last
value transmitted becomes the negotiation result. The rules for selecting
the value with which to respond are expressed as Boolean functions of the
value received and the value that the responding party would select in the
absence of knowledge of the received value.
 
Specifically, the two cases in which responses are OPTIONAL are:

- The boolean function is "AND" and the value "No" is received. The outcome
of the negotiation is "No".
- The boolean function is "OR" and the value "Yes" is received. The outcome
of the negotiation is "Yes".

DLB> On further reflection, this seems a bit on the clever side and a minor
DLB> optimization.  Does anyone else care?  The alternative would be to
DLB> always require explicit responses (even when there is only one
DLB> acceptable response) at the possible cost of an extra negotiation
DLB> round trip.

Responses are REQUIRED in all other cases, and the value chosen and sent by
the responder becomes the outcome of the negotiation.

An offer of a value not admissible MAY be answered with the constant
"Reject". The selection of a value not admissible under the selection rules
is considered a negotiation failure and is handled accordingly.

DLB> Need to define "offer of a value not admissible".

If a specific key is not relevant for the current negotiation, the responder
may answer with the constant "Irrelevant" for all types of negotiation.
However the negotiation is not considered as failed if the response is
Irrelevant.

DLB> But, but ... if the Initiator considers the key important, the
negotiation
DLB> may fail.  Implementers should (lower case) be cautious and
conservative
DLB> in using "Irrelevant", as humoring the other party to the negotiation
DLB> when it behaves in a somewhat clue-impaired fashion improves inter-
DLB> operability.

Any other key not understood by the responder may be ignored by the
responder without affecting the basic function. However, the Text Response
for a key not understood MUST be key=NotUnderstood.

The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are
reserved and must only be used as described here.

DLB> Do we want to reserve any other strings for future use?

Some basic key=value pairs are described in Chapter 11. All keys in Chapter
11, except for the X- extension format, MUST be supported by iSCSI
initiators and targets and MUST NOT be answered with NotUnder-stood.

Manufacturers may introduce new keys by prefixing them with X- fol-lowed by
their (reversed) domain name. For example the company owning the domain
acme.com can issue:

X-com.acme.bar.foo.do_something=3

DLB> Change "Manufacturers" to "Implementers" and "company" to "entity" for
DLB> generality.

--=_alternative 001D3194C2256BAE_=-- From owner-ips@ece.cmu.edu Fri May 3 06:45:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08788 for ; Fri, 3 May 2002 06:45:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43A4kW12575 for ips-outgoing; Fri, 3 May 2002 06:04:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2aa.compuserve.com (siaar2aa.compuserve.com [149.174.40.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43A4iw12570 for ; Fri, 3 May 2002 06:04:44 -0400 (EDT) Received: (from mailgate@localhost) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id GAA19475 for ips@ece.cmu.edu; Fri, 3 May 2002 06:04:38 -0400 (EDT) Received: from compuserve.com (mid-tgn-neu-vty14.as.wcom.net [216.192.70.14]) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id GAA19452 for ; Fri, 3 May 2002 06:04:32 -0400 (EDT) Message-ID: <3CD25FFF.454A9EF7@compuserve.com> Date: Fri, 03 May 2002 05:01:35 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: FC Encapsulation 2nd Last Call Complete Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit As far as I can tell, the 2nd Last Call on the FC Encapsulation draft draft-ietf-ips-fcencapsulation-07.txt completed yesterday with only one comment received: o Update the contact address for Murali Rajagopal If I have missed a change you requested, please notify me directly via e-mail to roweber@acm.org ASAP. -08 addressing the 2nd Last Call comments will be sent to the Internet Drafts office sometime after noon on Sunday, 5 May. Requests for changes after that time will be referred to the ips co-chairs for consideration. Thanks. .Ralph From owner-ips@ece.cmu.edu Fri May 3 10:54:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16139 for ; Fri, 3 May 2002 10:54:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43EJHk26848 for ips-outgoing; Fri, 3 May 2002 10:19:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43EJFw26844 for ; Fri, 3 May 2002 10:19:15 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g43EHuk17707; Fri, 3 May 2002 10:17:56 -0400 Message-ID: <3CD29C4D.735FB8ED@splentec.com> Date: Fri, 03 May 2002 10:18:53 -0400 From: Luben Tuikov Reply-To: iSCSI , Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "THALER,PAT (A-Roseville,ex1)" CC: Julian Satran , ips@ece.cmu.edu Subject: Re: iSCSI - re-phrase of 4.1 References: <1BEBA5E8600DD4119A50009027AF54A00BC00998@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > "THALER,PAT (A-Roseville,ex1)" wrote: > > hex-constant: unsigned hexadecimal constant described by regu-lar expression "0[xX][0-9a-zA-Z]+" > Hexidecimal only uses the alphabet up to F so the regular expression should be: > "0[xX][0-9a-fA-F]+" Wasn't there some consenus that there will be no extra leading 0, unless part of the base identifier (and thus at most one)? Else I can put 1e9 zeros like this: 0x0000...03 to be a valid hex const. Also why do we need to _restrict_ as to the sign of a hex constant. I'm sure that sooner or later it will have its applications. If a value cannot be negative and a node sent it as negative then the peer will reply with Reject or appropriately. Isn't all this the whole point of interoperability and the use of Reject, et al? Thus, hex const: 0[xX][1-9A-Fa-f]+[0-9A-Fa-f]* And similarly for the others. -- Luben From owner-ips@ece.cmu.edu Fri May 3 13:00:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19546 for ; Fri, 3 May 2002 13:00:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43GH0I06169 for ips-outgoing; Fri, 3 May 2002 12:17:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from snjspop2.snjs.qwest.net (snjspop2.snjs.qwest.net [168.103.24.2]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g43GGrw06151 for ; Fri, 3 May 2002 12:16:53 -0400 (EDT) Received: (qmail 52092 invoked from network); 3 May 2002 16:16:50 -0000 Received: from 168-103-214-43.dslgw2.snva.qwest.net (HELO theglowmonster) (168.103.214.43) by snjspop2.snjs.qwest.net with SMTP; 3 May 2002 16:16:50 -0000 Date: Thu, 2 May 2002 19:57:42 -0700 Message-ID: From: "Randy Jennings" To: "iSCSI" , "Luben Tuikov" Subject: RE: iSCSI - re-phrase of 4.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3CD29C4D.735FB8ED@splentec.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Comments in text > Also why do we need to _restrict_ as to the sign of > a hex constant. I'm sure that sooner or later it will > have its applications. If a value cannot be negative > and a node sent it as negative then the peer will > reply with Reject or appropriately. Granted, I am a young engineer, but I have never seen a signed hex constant. I've always seen decimal when signed. In my (vast :-> ) experience, hex is always used to represent straight bits. Period. You have enough zeros for place holders for the bits and that is all you ever have. If it happens to translate into a numeric value, that is ducky, but not necessary. > Thus, > hex const: 0[xX][1-9A-Fa-f]+[0-9A-Fa-f]* In any case, with this regex, 0x0 is no longer valid. If you persist in not wanting leading zeros, try: hex const: 0[xX](([1-9A-Fa-f][0-9A-Fa-f]*)|0) ^ ^ I do not know if these are needed, but they should not hurt I also removed the + because the * after the second term takes care of it. Sincerely, Randy Data Transit From owner-ips@ece.cmu.edu Fri May 3 13:02:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19627 for ; Fri, 3 May 2002 13:02:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43GnbQ08659 for ips-outgoing; Fri, 3 May 2002 12:49:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43GnZw08655 for ; Fri, 3 May 2002 12:49:35 -0400 (EDT) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.43 2002/05/02 20:18:48 root Exp $) with ESMTP id g43GoRi01112 for ; Fri, 3 May 2002 16:50:27 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.18 2002/05/02 20:17:19 root Exp $) with SMTP id g43Glq825177 for ; Fri, 3 May 2002 16:47:52 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002050309495222530 for ; Fri, 03 May 2002 09:49:52 -0700 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 May 2002 09:49:33 -0700 Message-ID: <10C8636AE359D4119118009027AE998706C85AC2@fmsmsx34.fm.intel.com> From: "Godavarthi, Vinupama" To: ips@ece.cmu.edu Subject: remove Date: Fri, 3 May 2002 09:49:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F2C2.7FC3F350" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F2C2.7FC3F350 Content-Type: text/plain; charset="ISO-8859-1" remove Vinu Godavarthi Intel Corporation (512)732-3936 (512)732-3912 (fax) ------_=_NextPart_001_01C1F2C2.7FC3F350 Content-Type: text/html; charset="ISO-8859-1" Message
remove
 

Vinu Godavarthi
Intel Corporation
(512)732-3936
(512)732-3912 (fax)

------_=_NextPart_001_01C1F2C2.7FC3F350-- From owner-ips@ece.cmu.edu Fri May 3 13:02:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19641 for ; Fri, 3 May 2002 13:02:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43GkkQ08429 for ips-outgoing; Fri, 3 May 2002 12:46:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43Gkiw08425 for ; Fri, 3 May 2002 12:46:44 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g43GkYp6002861; Fri, 3 May 2002 09:46:34 -0700 (PDT) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA29865; Fri, 3 May 2002 09:46:27 -0700 (PDT) Message-ID: <3CD2BAC1.CD13FE23@cisco.com> Date: Fri, 03 May 2002 11:28:49 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: iSCSI , Luben Tuikov CC: "THALER,PAT (A-Roseville,ex1)" , Julian Satran Subject: Re: iSCSI - re-phrase of 4.1 References: <1BEBA5E8600DD4119A50009027AF54A00BC00998@axcs04.cos.agilent.com> <3CD29C4D.735FB8ED@splentec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The problem with not allowing leading zeroes in binary (hex) encodings is that some keys, such as CHAP_C, are not guaranteed to always be the same length. Currently, we get the length from counting the number of hex digits for the key. If leading zeroes are not allowed, this won't work. Since leading zeroes don't hurt a hex constant anyway (e.g. these would come after the 0x, so we won't confuse them with octal), we should allow them so we don't have to introduce length fields. -- Mark Luben Tuikov wrote: > > > "THALER,PAT (A-Roseville,ex1)" wrote: > > > > hex-constant: unsigned hexadecimal constant described by regu-lar expression "0[xX][0-9a-zA-Z]+" > > Hexidecimal only uses the alphabet up to F so the regular expression should be: > > "0[xX][0-9a-fA-F]+" > > Wasn't there some consenus that there will be no extra leading 0, unless > part of the base identifier (and thus at most one)? Else I can > put 1e9 zeros like this: 0x0000...03 to be a valid hex const. > > Also why do we need to _restrict_ as to the sign of > a hex constant. I'm sure that sooner or later it will > have its applications. If a value cannot be negative > and a node sent it as negative then the peer will > reply with Reject or appropriately. > > Isn't all this the whole point of interoperability and > the use of Reject, et al? > > Thus, > hex const: 0[xX][1-9A-Fa-f]+[0-9A-Fa-f]* > > And similarly for the others. > > -- > Luben -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri May 3 13:42:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20943 for ; Fri, 3 May 2002 13:42:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43H6bF09943 for ips-outgoing; Fri, 3 May 2002 13:06:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f63.pav2.hotmail.com [64.4.37.63]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43H6aw09939 for ; Fri, 3 May 2002 13:06:36 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 3 May 2002 10:06:30 -0700 Received: from 207.46.137.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 03 May 2002 17:06:30 GMT X-Originating-IP: [207.46.137.253] From: "Bernard Aboba" To: bill@strahm.net, philmac@research.bell-labs.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: PAK: an alternative to SRP and DH-CHAP Date: Fri, 03 May 2002 10:06:30 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 May 2002 17:06:30.0391 (UTC) FILETIME=[DE85D870:01C1F2C4] Sender: owner-ips@ece.cmu.edu Precedence: bulk >From my understaning of PAK, I don't see a way of plugging this into >a legacy RADIUS environment (I don't have the password avail at the >iSCSI endpoint, only the ability to say please authenticate this for >me) The RADIUS argument is a red herring. RFC 2869 defines the use of extensible authentication within RADIUS, and most RADIUS servers (including versions of FreeRADIUS) now support this. So the bottom line is the iSCSI should choose the authentication algorithms most appropriate to its needs and not worry about RADIUS compatibility. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-ips@ece.cmu.edu Fri May 3 13:43:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20976 for ; Fri, 3 May 2002 13:43:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43HLbG11128 for ips-outgoing; Fri, 3 May 2002 13:21:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from strahm.net (adsl-67-115-29-109.dsl.sndg02.pacbell.net [67.115.29.109]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43HLZw11124 for ; Fri, 3 May 2002 13:21:36 -0400 (EDT) Received: (from bill@localhost) by strahm.net (8.11.6/8.11.6) id g43Hdqk76170; Fri, 3 May 2002 10:39:52 -0700 (PDT) (envelope-from bill) Date: Fri, 3 May 2002 10:39:47 -0700 From: Bill Strahm To: Bernard Aboba Cc: bill@strahm.net, philmac@research.bell-labs.com, ips@ece.cmu.edu Subject: Re: iSCSI: PAK: an alternative to SRP and DH-CHAP Message-ID: <20020503103947.A76147@homegate.strahm.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from bernard_aboba@hotmail.com on Fri, May 03, 2002 at 10:06:30AM -0700 Sender: owner-ips@ece.cmu.edu Precedence: bulk I'd almost buy this argument, except that means that my custommers will have to upgrade their environments to an updated Radius server. Putting deployment requirements like this on custommers is not an easy thing... I have been told that many Radius environments in organizations are rather old and not prone to upgrading (to do it you have to shut down authentication for a period of time). That is why I refer to a legacy environment, it is really easy if I can just say, Please use our Radius server in place of the one that you are all ready running... Now would you want to base sales on that ? Bill On Fri, May 03, 2002 at 10:06:30AM -0700, Bernard Aboba wrote: > >From my understaning of PAK, I don't see a way of plugging this into > >a legacy RADIUS environment (I don't have the password avail at the > >iSCSI endpoint, only the ability to say please authenticate this for >me) > > The RADIUS argument is a red herring. RFC 2869 defines the use of > extensible authentication within RADIUS, and most RADIUS servers (including > versions of FreeRADIUS) now support this. So the bottom line is the iSCSI > should choose the authentication algorithms most appropriate to its needs > and not worry about RADIUS compatibility. > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > From owner-ips@ece.cmu.edu Fri May 3 13:45:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21062 for ; Fri, 3 May 2002 13:45:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43HFWB10632 for ips-outgoing; Fri, 3 May 2002 13:15:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43HFUw10627 for ; Fri, 3 May 2002 13:15:30 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g43HFHPR011888; Fri, 3 May 2002 19:15:21 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g43HFGA68340; Fri, 3 May 2002 19:15:16 +0200 To: iSCSI , Luben Tuikov MIME-Version: 1.0 Subject: Re: iSCSI - re-phrase of 4.1 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 3 May 2002 20:15:13 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 03/05/2002 20:15:15, Serialize complete at 03/05/2002 20:15:15 Content-Type: multipart/alternative; boundary="=_alternative 005DF79CC2256BAE_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005DF79CC2256BAE_= Content-Type: text/plain; charset="us-ascii" The issue of leading 0s was brought up in the context of decimal numbers. In the context of hex or base 64 encoding for binaries (not numbers) the leading 0 has value - it implies length - 0x0015 is different from 0x15. Julo Luben Tuikov Sent by: owner-ips@ece.cmu.edu 05/03/2002 05:18 PM Please respond to iSCSI; Please respond to Luben Tuikov To: "THALER,PAT (A-Roseville,ex1)" cc: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu Subject: Re: iSCSI - re-phrase of 4.1 > "THALER,PAT (A-Roseville,ex1)" wrote: > > hex-constant: unsigned hexadecimal constant described by regu-lar expression "0[xX][0-9a-zA-Z]+" > Hexidecimal only uses the alphabet up to F so the regular expression should be: > "0[xX][0-9a-fA-F]+" Wasn't there some consenus that there will be no extra leading 0, unless part of the base identifier (and thus at most one)? Else I can put 1e9 zeros like this: 0x0000...03 to be a valid hex const. Also why do we need to _restrict_ as to the sign of a hex constant. I'm sure that sooner or later it will have its applications. If a value cannot be negative and a node sent it as negative then the peer will reply with Reject or appropriately. Isn't all this the whole point of interoperability and the use of Reject, et al? Thus, hex const: 0[xX][1-9A-Fa-f]+[0-9A-Fa-f]* And similarly for the others. -- Luben --=_alternative 005DF79CC2256BAE_= Content-Type: text/html; charset="us-ascii"
The issue of leading 0s was brought up in the context of decimal numbers.
In the context of hex or base 64 encoding for binaries (not numbers) the leading 0 has value - it implies length -
0x0015 is different from 0x15.

Julo



Luben Tuikov <luben@splentec.com>
Sent by: owner-ips@ece.cmu.edu

05/03/2002 05:18 PM
Please respond to iSCSI; Please respond to Luben Tuikov

       
        To:        "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
        cc:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        Subject:        Re: iSCSI - re-phrase of 4.1

       


> "THALER,PAT (A-Roseville,ex1)" wrote:
>
> hex-constant: unsigned hexadecimal constant described by regu-lar expression "0[xX][0-9a-zA-Z]+"
> Hexidecimal only uses the alphabet up to F so the regular expression should be:
> "0[xX][0-9a-fA-F]+"

Wasn't there some consenus that there will be no extra leading 0, unless
part of the base identifier (and thus at most one)? Else I can
put 1e9 zeros like this: 0x0000...03 to be a valid hex const.

Also why do we need to _restrict_ as to the sign of
a hex constant. I'm sure that sooner or later it will
have its applications. If a value cannot be negative
and a node sent it as negative then the peer will
reply with Reject or appropriately.

Isn't all this the whole point of interoperability and
the use of Reject, et al?

Thus,
hex const: 0[xX][1-9A-Fa-f]+[0-9A-Fa-f]*

And similarly for the others.

--
Luben

--=_alternative 005DF79CC2256BAE_=-- From owner-ips@ece.cmu.edu Fri May 3 13:53:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21580 for ; Fri, 3 May 2002 13:53:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43HeBs12652 for ips-outgoing; Fri, 3 May 2002 13:40:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f94.pav2.hotmail.com [64.4.37.94]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43He8w12645 for ; Fri, 3 May 2002 13:40:08 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 3 May 2002 10:40:02 -0700 Received: from 131.107.3.75 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 03 May 2002 17:40:02 GMT X-Originating-IP: [131.107.3.75] From: "Bernard Aboba" To: bill@strahm.net Cc: philmac@research.bell-labs.com, ips@ece.cmu.edu Subject: Re: iSCSI: PAK: an alternative to SRP and DH-CHAP Date: Fri, 03 May 2002 10:40:02 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 May 2002 17:40:02.0593 (UTC) FILETIME=[8DE38110:01C1F2C9] Sender: owner-ips@ece.cmu.edu Precedence: bulk >I'd almost buy this argument, except that means that my custommers will >have to upgrade their environments to an updated Radius server. >Putting >deployment requirements like this on custommers is not an easy >thing... This used to be a reasonable argument when most RADIUS servers didn't support extensible authentication, but that isn't true anymore. Today customers who don't want to upgrade legacy servers often go out and buy a new set of servers supporting extensible authentication and deploy it for the new application only. That way they don't have to worry about the upgrades breaking legacy applications, yet they can still support new applications. Also, if we were to restrict IETF authentication methods to those supported in RFC 2865, that would mean that that the only acceptable algorithm would be CHAP. Given that CHAP doesn't support mutual authentication and has a dictionary attack vulnerability, that seems like too tight a straightjacket to put ourselves in. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-ips@ece.cmu.edu Fri May 3 13:59:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22209 for ; Fri, 3 May 2002 13:59:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43HWC312041 for ips-outgoing; Fri, 3 May 2002 13:32:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43H3pw09728 for ; Fri, 3 May 2002 13:03:51 -0400 (EDT) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel10.hp.com (Postfix) with ESMTP id 3B5AAC00433 for ; Fri, 3 May 2002 10:03:45 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 31A4B16C for ; Fri, 3 May 2002 10:03:45 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 May 2002 10:03:44 -0700 Message-ID: <499DC368E25AD411B3F100902740AD650DB50224@xrose03.rose.hp.com> From: "BARRY,BOB (HP-Roseville,ex1)" To: "'ips@ece.cmu.edu'" Subject: Comments on v12 of iSCSI Specification Date: Fri, 3 May 2002 10:03:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The following comments are submitted against the April 17, 2002, draft-ietf-ips-iSCSI-12.txt. Bob Barry ==================================================== General Comments 1) An acronym section would make it easier to read this document. Acronyms such as SW for session wide, IO for initialize-only, and others are not immediately obvious. 2) A copyright notice be part of this document. 3) In chapter 9, each PDU should have a complete description provided. Yes, this means a duplication of the field descriptions, but having to search back in the document to find field meanings does not make sense. 4) Each table should be numbered and titled. Currently, there is no way to reference an individual table, accept a page number which may change over revisions. 5) Either "data is" or "data are" are considered correct for technical documentation, however, only one should be used in a document for consistency. Examples: p 35: last paragraph, first line "data is" p 36: third paragraph, first line "data are" p 36: third paragraph, third line "data are" p 36: seventh paragraph, fourth line "data is" 6) Word "since" used instead of "because". "Since" implies a temporal relationship, "because" implies a cause-effect" relationship. Some examples p 31: third paragraph from bottom, first line; p 37: last paragraph, second line; p 44: second paragraph, seventh line; p 47: last paragraph, third line p 108: second paragraph, second line p 111: first paragraph after bullet item, first line p 141: bullet item c) in upper list 6) The word "null" is used throughout this document to mean "zero", or "zero valued". This needs to be clearly stated. Comments regarding draft contents 1) p 22: "iSCSI Initiator Node" and "iSCSI Target Node" are circular and provide no insight into what is being defined. 2) p 31: second paragraph, third line: "from ExpCmdSN to MaxCmdSN" should be "from ExpCmdSN to MaxCmdSN inclusive"; or "in the closed interval [ ExpCmdSN . . MaxCmdSN ]" 3) p 31: second paragraph, sixth line, how the parathesized example applies to the preceding sentence is not immediately obvous. 4) p 31: last paragraph, last 2 lines: use of the words "and" and "or" could be ambiguously interpreted. 5) p 34: second paragraph, line 3: "the TSIH is null". The word "null" should be replaced with "equal to zero". 6) p 36: third paragraph, third line: the sentence ends right in the middle; need to complete the thought. 7) p 37: second paragraph: "Unsolicited data MUST be sent on every connection in the same order in which commands are sent." This sentence needs better wording to get the intended point. 8) p 39: item c) in list: where are "displayable" and and "whitespace" characters defined? 9) p 50: item e), some of the references to "Node" should be references to "Entity". 10) p 52: last paragraph, fifth bullet item: "3 null bytes". The word "null" should be replaced with "zero". 11) p 63: third paragraph of 4.1, last line: "(comma or null)" should be "(comma or zero byte)" 12) p 72: fourth paragraph, second line: does the phrase "MUST be sent after the parameters" mean later in the current request, or could they be sent in a later request. The same comment can be applied on p 75, paragaph 4. 13) p 72: fifth paragraph, second line: "a null TSIH" should be "a zero-valued TSIH" 14) p 78: in the state table, it appears that exit from S8 is impossible. Actually, this is explained on p 84. An explanation of what is going on on p 78 would be helpful. The same can be said of the state table on p 80. 15) p 118: section 9 - why are some bits marked as reserved and some marked as '0' or '1' in the PDU definitions. If the bits marked as '0' or '1' in the PDUs will never change, then this needs to be stated. In other words, there are not treated the same as reserved bits. 16) p 122 and 123: why doesn't AHS-Specific data begin on a 4-byte boundary? Doesn't this lead to an extra operation when using the AHSLength? 17) p 147: it should be explicitly stated that the O and U bits are valid only of the S bit is 1. 18) p 150: first paragraph, last line: the requirement should be a MUST, not a SHOULD; it is not obvious what an initiator should do if a transfer length of 0 is received. If the SHOULD requirement is maintained, then explain what is an initiator to do with an R2T containing a zero transfer length. 19) p 152: for code 1 -- "Close the connection" (if not the only connection) OR "Close the session" to close all connections -- What must be sent for a single connection session? 20) p 155: second paragraph: the requirement of MUST with the current wording requires that one text request must be outstanding at any given time. This requirement should be MAY, or the wording changed to "An initiator MUST have at most one outstanding Text Request on a connection at any given time." 21) p 156 (and other areas): next to last paragraph beginning with "A target MAY reset its internal state". What should it be reset to, the original or default settings, the previous state prior to this sequence of text requests, or ... A similar reference is made on p 159 in each of the last 2 paragraphs. Doesn't it say somewhere in the spec something about a stateless exchange? If so, what state are you talking about? 22) p 162: section 9.12.4: in this section, the version of the current draft is defined. Shouldn't this info be in a more obvious location in the draft? How would someone reading this spec know to come to this section to find out this info? Formatting and wording issues 1) p 26: second paragraph, last line: is the phase 'an individual I/O device is called a "logical unit" LU' consistent with the definition of "CSSI device" earlier in the document. 2) p 27: first paragraph of 2.2, fourth line, "the request response mechanism" should be "the request-response mechanism". 3) p 28: paragraph preceding section 2.2.2, last sentence, "For error recovery purposes, targets ... during recovery" contains some redundancy. Remove the words "during recovery" from the end of the sentence. 4) p 34: third paragraph, third line: the phrase "later in this part" is used. What is the "part" that is being referenced? 5) p 35: second paragraph, third line: the use of the phrase "by default" implies a non-default behavior. This phrase should be deleted. 6) p 36: last paragraph, third line, does the phrase "these tags" refer to initiator tags or target tags? The current wording could be ambiguous. 7) p 39: item c) in list, fourth line: "would be identical except for their case" could be "are case sensitive". 8) p 39: third paragraph from bottom, fourth line: "NIC or HBA card". The word "card" is redundant. 9) p 53: first paragraph after section 2.4.3, last line: "with a given session" should be "with the same session". 10) p 54: last paragraph, first line: "via one iSCSI node" should be "via one iSCSI target node" 11) p 66: last paragraph, fifth line: "key=value pair TargetName" What does this mean? 12) p 82: for -T6 and -T7: the individual cases should be maintained in a table-like list, or at least separated by semi-colons. -T15, T16 on page 83 has a nice table- like list. Why not use this format for consistency. 13) p 97: after last paragraph: formatting (indentation) would assist in understanding. - item a) additional blanks near end of first line - between item a) and i), there is an extra '-' - at end of ii), the "[OR]" should refer to a) or b), however, the placement could indicate ii) or b). This could lead to an ambiguous interpretation. 14) p 104: bullet item near top beginning with "- N.B. The logout". Should this bullet item be here? 15) p 108: first and third paragraphs, first line in each: paragraph begins with "With this mechanism". What do you mean? Yes, I know, but you need to say it. :-) 16) p 108: third paragraph, line 4: the sentence ends in the middle: "received in clear" 17) p 118: section 9.2, first paragraph "may" should be capitalized, similarly in second paragraph, second line. 18) p 119: first paragraph, last line "SHOULD be sent as 0" should be "SHOULD be set to zero". Also, why is SHOULD used here instead of MUST? 19) p 125: in SCSI Command PDU, very last field: "(DataSegment - Command Data + Data Digest (if any))" should be "(DataSegment or Command Data, Data Digest) (if any)" 20) p 126: paragraph preceding 9.3.2: "Expected Data Transfer Lengths are" should be "Expected Data Transfer Length and Bidirectional Read Expected Data Transfer Length are" 21) p 144: last paragraph on page, line 5: "in this later case" should be "in this latter case". 22) p 153: last paragraph: "Data Segment" should be "DataSegment". 23) p 155: last paragraph: the word "commands" should be replaced by "Text Requests" 24) p 162: the list in the middle of the page: why was the number 2 skipped in numbering the items in this list? 25) p 164: next to last line: "All login requests within the login phase" should be "All login requests within a login phase". 26) p 182: third paragraph, second line: should the "must" be capitalized? 27) p 184: last line: "Data Segment Length" should be "DataSegmentLength" 28) p 188: the info below the table at the top of the page should be incorporated into the table. 29) p 188: last paragraph, first line: "the target MUST answer" could be "the target MUST respond" (keeping with the language of the spec. 30) p 193: section 11, this info would be nice in a table, and also in an acronym table. 31) p 198, 199, 200, 203, 203: what do Result function is OR and Result function is AND mean? 32) p 200: third paragraph, last line "MUST reject them with". What does "them" refer to? 33) p 201: Third paragraph "This is a connection specific parameter". This statement is redundant because the scope is CO. 34) p 201: last paragraph of section 11.14: what "two numbers" are being referenced? Same question can be asked on p 202, second paragraph from top, and also in section 11.16, second last paragraph. Simple issues 1) p 24: last paragraph, second line, "session ID that is tuple" should be session ID that is a tuple". 2) p 25: definition of "SCSI Port Name", get rid of the word "basically". Use of this adverb implies there are additional items that make up the name. 3) p 25: definition of "TSIH", third line, change "the target is generating" to "the target generates". 4) p 32: section 2.2.2.2, first paragraph, line 5: "32bit" should be "32-bit" (the '-' could be a blank). 5) p 35: third paragraph, second line: "the status for a command" should be "the status for the command" 6) p 55: last paragraph, need a blank line between paragraphs. 7) p 56: third paragraph, last 2 lines (occurs twice): "at target" should be "at the target". 8) p 56: third paragraph, second line: "Data-In PDU" should be "Data-In PDUs". 9) p 57: last paragraph, third line: "status indicated termination" should be "statue indicates termination". 10) p 60: first paagraph after 2.5.3.4, fourth line: "the type is indicate in" should be "the type is indicated in" 11) p 63: second paragraph, next to last line: "range is a a set" should be "range is a set". 12) P 64: fifth paragraph, second line: "a single literal constant a Boolean value" should be "a single literal constand, a Boolean value". 13) p 65: after first paragraph there is an extra blank line. 14) p 68: paragraph preceding 4.3.1, second line: period '.' missing after "once during login". 15) p 73: fourth paragraph, first line: "implicit logout connection reinstatement is" should be "implicit logout connection, reinstatement is" 16) p 74: first paragraph before 4.3.6, last line: there is some garbage at the end of the paragraph. 17) p 82: for transition -T8, second line: "on a another connection" should be "on another connection" 18) p 93: First paragraph, fifth line: "assumed that at target" should be "assumed that at the targer" 19) p 95: throughout the text, words like "Reject" is used in referring to a PDU type. The problem is the use of the plural "Rejects"; this would be better written as "Reject's". 20) p 96: first paragraph after 6.3.2, third line: "(section 9.15)in" should be "section 9.15) in". 21) page 100: second paragraph after 6.9, second line: "errors can be only be" should be "errors can only be" 22) p 104: third line on page: "not received for a response" should be "not received a response". 23) p 105: bullet item b) near top of page, last line: "in resource requirement" should be "in resource requirements". 24) p 107: first paragraph, fourth line: "via a subnet distinctly" could be "via a SAN distinctly". 25) p 107: first paragraph, line line 6: "such as SCSI, over IP networks requires" should be "such as SCSI over IP, requires" 26) p 108: after paragraph 4, there is an extra blank line 27) p 108: sixth paragraph, fourth line: it looks like an extra was added at the end of this line. 28) p 113: first paragraph after 8.1.2, first line: it looks like an extra was added at the end of this line. 29) p 114: third paragraph, second line: it looks like an extra was added at the end of this line. 30) p 115: first paragraph after 8.3, fourth line: "acknowledgements etc.)" should be "acknowledgements, etc.)" 31) p 122: section 9.2.1.7, first paragraph, second line: "identify it" should be "identify the task". 32) p 128: last line of page: "the b Bidirectional" should be "the Bidirectional". 33) p 129: for bit 5 at the top, third line: "Transfer length" should be "Transfer Length". 34) p 129: for bit 6 at the top, third line: "bytes that expected to be" should be "bytes that were expected to be". 35) p 130: third line from top of page, "sequence, before" should be "sequence before" 36) p 130: third line from bottom of page: use "greater than" rather than "higher than". "Higher" could imply some level of positioning 37) p 134: the fields in the number list at the bottom of the page should be lined up. 38) p 138: why is this page blank? 39) p 145: second paragraph of 9.7.3, third line: "SNACK of, type " should be "SNACK of type". 40) p 147: last paragraph: "and they values are as define in" should be "and the values are as defined in" 41) p 151: PDU diagram, align the right side 42) p 154: PDU diagram, align the right side 43) p 156: first paragraph, first line: it looks like an extra was added at the end of this line. 44) p 159: section 9.11.2, first line: "initial Text request" should be "initial Text Request". Similarly, in last paragraph, second line, "Text request" should be "Text Request". 45) p 162: section 9.12.2, first paragraph, next to last line, it looks like an extra was added at the end of this line. 46) p 164: section 9.12.6, first paragraph, fifth line: "to the target, the associated" should be "to the target the associated" 47) p 165: last paragraph: missing a blank line after line 3. 48) p 165:last paragraph: "Keys in Chapter 10, only need" should be "Keys in Chapter 10 only need" 49) p 167: section 9.13.3, fifth line: "andd" should be "and". 50) p 169: for codes 0101 and 0201, remove the in the description fields. 51) p 178: first 2 paragraphs: what do "its" refer to -- "its flags" 52) p 179: section 9.16.3, second paragraph, second line: "or greater to BegRun" should be "or greater than BegRun" 53) p 181: code 0x04 in table, the explanation for this code is missing a right paren at the end. 54) p 186: second paragraph, first line: "When a target send a NOP-In" should be When a target sends a NOP-In". 55) p 193: bottom: position entire table on one page. 56) p 196: missing blank line between paragraphs at top of page. 57) p 199: first paragraph on top of page, it looks like an extra was added in the middle. 58) p 201: section 11.14, second to last paragraph, second line: "bytes in an Data-In" should be "bytes in a Data-In". Also, the last phrase in this paragraph is not a sentence. 59) p 201: last line of page: "to the target, during the" should be "to the target during the From owner-ips@ece.cmu.edu Fri May 3 14:02:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22404 for ; Fri, 3 May 2002 14:02:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43HfBf12751 for ips-outgoing; Fri, 3 May 2002 13:41:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43Hf9w12745 for ; Fri, 3 May 2002 13:41:09 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g43Hew8M024430; Fri, 3 May 2002 10:40:58 -0700 (PDT) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA06347; Fri, 3 May 2002 10:40:51 -0700 (PDT) Message-ID: <3CD2C781.A885A5E7@cisco.com> Date: Fri, 03 May 2002 12:23:13 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Julian Satran CC: iSCSI , Luben Tuikov Subject: Re: iSCSI - re-phrase of 4.1 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian- That works great! Thanks, Mark Julian Satran wrote: > > The issue of leading 0s was brought up in the context of decimal numbers. > In the context of hex or base 64 encoding for binaries (not numbers) the leading 0 has value - it > implies length - > 0x0015 is different from 0x15. > > Julo > > Luben Tuikov > Sent by: owner-ips@ece.cmu.edu To: "THALER,PAT (A-Roseville,ex1)" > > 05/03/2002 05:18 PM cc: Julian Satran/Haifa/IBM@IBMIL, > Please respond to iSCSI; Please respond to ips@ece.cmu.edu > Luben Tuikov Subject: Re: iSCSI - re-phrase of 4.1 > > > > > "THALER,PAT (A-Roseville,ex1)" wrote: > > > > hex-constant: unsigned hexadecimal constant described by regu-lar expression "0[xX][0-9a-zA-Z]+" > > Hexidecimal only uses the alphabet up to F so the regular expression should be: > > "0[xX][0-9a-fA-F]+" > > Wasn't there some consenus that there will be no extra leading 0, unless > part of the base identifier (and thus at most one)? Else I can > put 1e9 zeros like this: 0x0000...03 to be a valid hex const. > > Also why do we need to _restrict_ as to the sign of > a hex constant. I'm sure that sooner or later it will > have its applications. If a value cannot be negative > and a node sent it as negative then the peer will > reply with Reject or appropriately. > > Isn't all this the whole point of interoperability and > the use of Reject, et al? > > Thus, > hex const: 0[xX][1-9A-Fa-f]+[0-9A-Fa-f]* > > And similarly for the others. > > -- > Luben -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri May 3 14:03:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22453 for ; Fri, 3 May 2002 14:03:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43HhMn12947 for ips-outgoing; Fri, 3 May 2002 13:43:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43HhJw12938 for ; Fri, 3 May 2002 13:43:19 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g43HhD8M025399; Fri, 3 May 2002 10:43:13 -0700 (PDT) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA08802; Fri, 3 May 2002 10:43:11 -0700 (PDT) Message-ID: <3CD2C80D.FC488297@cisco.com> Date: Fri, 03 May 2002 12:25:33 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Bill Strahm CC: Bernard Aboba , philmac@research.bell-labs.com, ips@ece.cmu.edu Subject: Re: iSCSI: PAK: an alternative to SRP and DH-CHAP References: <20020503103947.A76147@homegate.strahm.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill- I agree with you on this one; my sales people tell me the same thing. It's very important that iSCSI works with existing infrastructure that's deployed, which is rarely the same thing as existing technology that could be deployed. -- Mark Bill Strahm wrote: > > I'd almost buy this argument, except that means that my custommers will > have to upgrade their environments to an updated Radius server. Putting > deployment requirements like this on custommers is not an easy thing... > > I have been told that many Radius environments in organizations are rather > old and not prone to upgrading (to do it you have to shut down authentication > for a period of time). That is why I refer to a legacy environment, it > is really easy if I can just say, Please use our Radius server in place > of the one that you are all ready running... Now would you want to base > sales on that ? > > Bill > On Fri, May 03, 2002 at 10:06:30AM -0700, Bernard Aboba wrote: > > >From my understaning of PAK, I don't see a way of plugging this into > > >a legacy RADIUS environment (I don't have the password avail at the > > >iSCSI endpoint, only the ability to say please authenticate this for >me) > > > > The RADIUS argument is a red herring. RFC 2869 defines the use of > > extensible authentication within RADIUS, and most RADIUS servers (including > > versions of FreeRADIUS) now support this. So the bottom line is the iSCSI > > should choose the authentication algorithms most appropriate to its needs > > and not worry about RADIUS compatibility. > > > > > > _________________________________________________________________ > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri May 3 14:19:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23276 for ; Fri, 3 May 2002 14:19:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43HuiW13990 for ips-outgoing; Fri, 3 May 2002 13:56:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43Hugw13982 for ; Fri, 3 May 2002 13:56:42 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 898C6B830; Fri, 3 May 2002 11:56:41 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 292854D4; Fri, 3 May 2002 11:56:41 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 03 May 2002 11:56:39 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <262CRNSK>; Fri, 3 May 2002 11:56:39 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00BC00BA2@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Randy Jennings , iSCSI , Luben Tuikov Subject: RE: iSCSI - re-phrase of 4.1 Date: Fri, 3 May 2002 11:56:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Randy, I'm not young and I have never seen a signed hex constant either. I don't see any need to use signed hex constants. I also agree with Julian on leading zeros for hex (and base 64). They should be allowed. Pat -----Original Message----- From: Randy Jennings [mailto:randyj@data-transit.com] Sent: Thursday, May 02, 2002 7:58 PM To: iSCSI; Luben Tuikov Subject: RE: iSCSI - re-phrase of 4.1 Comments in text > Also why do we need to _restrict_ as to the sign of > a hex constant. I'm sure that sooner or later it will > have its applications. If a value cannot be negative > and a node sent it as negative then the peer will > reply with Reject or appropriately. Granted, I am a young engineer, but I have never seen a signed hex constant. I've always seen decimal when signed. In my (vast :-> ) experience, hex is always used to represent straight bits. Period. You have enough zeros for place holders for the bits and that is all you ever have. If it happens to translate into a numeric value, that is ducky, but not necessary. > Thus, > hex const: 0[xX][1-9A-Fa-f]+[0-9A-Fa-f]* In any case, with this regex, 0x0 is no longer valid. If you persist in not wanting leading zeros, try: hex const: 0[xX](([1-9A-Fa-f][0-9A-Fa-f]*)|0) ^ ^ I do not know if these are needed, but they should not hurt I also removed the + because the * after the second term takes care of it. Sincerely, Randy Data Transit From owner-ips@ece.cmu.edu Fri May 3 14:19:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23291 for ; Fri, 3 May 2002 14:19:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43Hljh13313 for ips-outgoing; Fri, 3 May 2002 13:47:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f17.pav2.hotmail.com [64.4.37.17]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43Hlgw13307 for ; Fri, 3 May 2002 13:47:43 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 3 May 2002 10:47:36 -0700 Received: from 131.107.3.92 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 03 May 2002 17:47:36 GMT X-Originating-IP: [131.107.3.92] From: "Bernard Aboba" To: cbh@zyfer.com, ips@ece.cmu.edu Subject: Re: Relation between iSCSI session and IPSec SAs Date: Fri, 03 May 2002 10:47:36 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 May 2002 17:47:36.0982 (UTC) FILETIME=[9CB9C360:01C1F2CA] Sender: owner-ips@ece.cmu.edu Precedence: bulk >From the minutes of Minneapolis: >"...a single IPSec Phase 2 SA per TCP connection ...had no security > >value." >I agree and like to extend this: >"...a single IKE negotiation per multiple iSCSI session (between the >same >IP addresses of initiator and target) ...had no security value." If you are saying that it it doesn't matter how many IKE phase 2 SAs correspond to a given IKE Phase 1 SA, then I would agree. Is this what you meant? >Must we negotiate per multiple session (and evaluate packets >additional >for a session identifier) or must we not? I think that the bottom line is that an iSCSI session needs to be protected by an IKE phase 2 SA. You can have multiple iSCSI sessions per phase 2 SA. You can have multiple phase 2 SAs per phase 1 SA. Those are implementation decisions that generally don't influence the security properties, except in a few exceptional conditions (e.g. QoS marking, desire to protect iSCSI sessions with different transforms). _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-ips@ece.cmu.edu Fri May 3 14:20:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23309 for ; Fri, 3 May 2002 14:20:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43HmEI13356 for ips-outgoing; Fri, 3 May 2002 13:48:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43HmBw13347; Fri, 3 May 2002 13:48:11 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g43Hm5PR009252; Fri, 3 May 2002 19:48:05 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g43Hm3N143364; Fri, 3 May 2002 19:48:04 +0200 To: Bill Strahm Cc: Bernard Aboba , bill@strahm.net, ips@ece.cmu.edu, owner-ips@ece.cmu.edu, philmac@research.bell-labs.com MIME-Version: 1.0 Subject: Re: iSCSI: PAK: an alternative to SRP and DH-CHAP X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 3 May 2002 20:48:02 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 03/05/2002 20:48:04, Serialize complete at 03/05/2002 20:48:04 Content-Type: multipart/alternative; boundary="=_alternative 006104AAC2256BAE_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006104AAC2256BAE_= Content-Type: text/plain; charset="us-ascii" It will also not work on the (mostly) legacy IP-over-pigeon networks. Julo Bill Strahm Sent by: owner-ips@ece.cmu.edu 05/03/2002 08:39 PM Please respond to Bill Strahm To: Bernard Aboba cc: bill@strahm.net, philmac@research.bell-labs.com, ips@ece.cmu.edu Subject: Re: iSCSI: PAK: an alternative to SRP and DH-CHAP I'd almost buy this argument, except that means that my custommers will have to upgrade their environments to an updated Radius server. Putting deployment requirements like this on custommers is not an easy thing... I have been told that many Radius environments in organizations are rather old and not prone to upgrading (to do it you have to shut down authentication for a period of time). That is why I refer to a legacy environment, it is really easy if I can just say, Please use our Radius server in place of the one that you are all ready running... Now would you want to base sales on that ? Bill On Fri, May 03, 2002 at 10:06:30AM -0700, Bernard Aboba wrote: > >From my understaning of PAK, I don't see a way of plugging this into > >a legacy RADIUS environment (I don't have the password avail at the > >iSCSI endpoint, only the ability to say please authenticate this for >me) > > The RADIUS argument is a red herring. RFC 2869 defines the use of > extensible authentication within RADIUS, and most RADIUS servers (including > versions of FreeRADIUS) now support this. So the bottom line is the iSCSI > should choose the authentication algorithms most appropriate to its needs > and not worry about RADIUS compatibility. > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > --=_alternative 006104AAC2256BAE_= Content-Type: text/html; charset="us-ascii"
It will also not work on the (mostly) legacy IP-over-pigeon networks.

Julo


Bill Strahm <bill@strahm.net>
Sent by: owner-ips@ece.cmu.edu

05/03/2002 08:39 PM
Please respond to Bill Strahm

       
        To:        Bernard Aboba <bernard_aboba@hotmail.com>
        cc:        bill@strahm.net, philmac@research.bell-labs.com, ips@ece.cmu.edu
        Subject:        Re: iSCSI: PAK: an alternative to SRP and DH-CHAP

       


I'd almost buy this argument, except that means that my custommers will
have to upgrade their environments to an updated Radius server.  Putting
deployment requirements like this on custommers is not an easy thing...

I have been told that many Radius environments in organizations are rather
old and not prone to upgrading (to do it you have to shut down authentication
for a period of time).  That is why I refer to a legacy environment, it
is really easy if I can just say, Please use our Radius server in place
of the one that you are all ready running...  Now would you want to base
sales on that ?  

Bill
On Fri, May 03, 2002 at 10:06:30AM -0700, Bernard Aboba wrote:
> >From my understaning of PAK, I don't see a way of plugging this into
> >a legacy RADIUS environment (I don't have the password avail at the
> >iSCSI endpoint, only the ability to say please authenticate this for >me)
>
> The  RADIUS argument is a red herring. RFC 2869 defines the use of
> extensible authentication within RADIUS, and most RADIUS servers (including
> versions of FreeRADIUS) now support this. So the bottom line is the iSCSI
> should choose the authentication algorithms most appropriate to its needs
> and not worry about RADIUS compatibility.
>
>
> _________________________________________________________________
> Chat with friends online, try MSN Messenger: http://messenger.msn.com
>


--=_alternative 006104AAC2256BAE_=-- From owner-ips@ece.cmu.edu Fri May 3 14:20:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23327 for ; Fri, 3 May 2002 14:20:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43Hqgs13708 for ips-outgoing; Fri, 3 May 2002 13:52:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f52.pav2.hotmail.com [64.4.37.52]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43Hqew13704 for ; Fri, 3 May 2002 13:52:40 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 3 May 2002 10:52:34 -0700 Received: from 131.107.3.83 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 03 May 2002 17:52:34 GMT X-Originating-IP: [131.107.3.83] From: "Bernard Aboba" To: kukkonen@ssh.com, ips@ece.cmu.edu Cc: cbh@zyfer.com Subject: Re: Relation between iSCSI session and IPSec SAs Date: Fri, 03 May 2002 10:52:34 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 May 2002 17:52:34.0593 (UTC) FILETIME=[4E1D9910:01C1F2CB] Sender: owner-ips@ece.cmu.edu Precedence: bulk >I would like to understand what is the usual justification >for separating individual TCP sessions to different SAs. >(and also whether people are doing this or not in iSCSI) The most likely reasons seemed to have to do with the desire to provide different QoS for the sessions, or to use different transforms to protect the sessions. Personally, I don't think either of those reasons is compelling, but your _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-ips@ece.cmu.edu Fri May 3 14:29:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23709 for ; Fri, 3 May 2002 14:29:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43HmFa13361 for ips-outgoing; Fri, 3 May 2002 13:48:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43HmCw13348 for ; Fri, 3 May 2002 13:48:12 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g43Hm6PR005320 for ; Fri, 3 May 2002 19:48:06 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g43Hm5N143366 for ; Fri, 3 May 2002 19:48:05 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - an improved text for 4.1 & 4.2 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 3 May 2002 20:48:02 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 03/05/2002 20:48:05, Serialize complete at 03/05/2002 20:48:05 Content-Type: multipart/alternative; boundary="=_alternative 0061AE60C2256BAE_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0061AE60C2256BAE_= Content-Type: text/plain; charset="us-ascii" Here is another attempt. Julo Text Format The initiator and target send a set of key=value pairs encoded in UTF-8 Unicode. All the text keys and text values specified in this document are to be presented and interpreted in the case they appear in this document. They are case sensitive. The following character symbols are used in this document for text items: (a-z, A-Z) - letters (0-9) - digits " " (0x20) - space "." (0x2e) - dot "-" (0x2d) - minus "+" (0x2b) - plus "@" (0x40) - commercial at "_" (0x5f) - underscore "=" (0x3d) - equal ":" (0x3a) - colon "/" (0x2f) - solidus or slash "[" (0x5b) - left bracket "]" (0x5d) - right bracket null(0x00) - null separator "," (0x2c) - comma "~" (0x7e) - tilde A key-name is whatever precedes the first = in the key=value pair. The term key is used frequently in this document with the meaning of key-name. A value is whatever follows the = that follows the key-name up to a null delimiter that marks the end of any key=value pair (including the last in a PDU). The following definitions will be used in the rest of this document: key-name: a string of one or more characters consisting of letters, digits, point, minus, plus, commercial at, and underscore, A key-name MUST begin with a capital letter an must not exceed 63 characters. text-value: a string of 0 or more characters consisting of let-ters, digits, dot, minus, plus, commercial at, underscore, slash, left bracket, right bracket and colon. iSCSI-name-value: a string of one or more characters consist-ing of minus, dot, colon and any character allowed by the output of the iSCSI string-prep template as specified in [STPREP-iSCSI] (see also Section 2.2.6.2 iSCSI Name Encoding). iSCSI-local-name-value: an UTF-8 string terminated by the null character that terminates the key=value pair; no null charac-ters are allowed in the string. This encoding is to be used for localized (internationalized) aliases. boolean-value: the strings "Yes" or "No". hex-constant: hexadecimal constant encoded as a string start-ing with "0x" or "0X" followed by 1 or more digits or the letters a, b, c, d, e, f, A, B, C, D, E and F. decimal-constant: an unsigned decimal number - a string of 1 or more digits starting with a non-zero digit. This encoding is not used for numerical values equal or greater than 2**64. base-64-constant: unsigned base-64 constant encoded as a string starting with "0b" or "0B" followed by 1 or more digits or letters or plus or slash or equal. regular-numerical-value : an unsigned integer less than 2**64 encoded as a decimal-constant, hex constant, or base-64 con-stant. For base-64 encoding the encoding is done according to [RFC2045]. large-numerical-value : an unsigned integer larger than or equal to 2**64 encoded as a hex constant, or base-64 con-stant. numerical-value: a regular-numerical-value or a large numeri-cal-value. Unsigned integer arithmetic applies to numeric-values. numeric-range: two numerical-values separated by a tilde. regular-binary-value : a binary string less than 64 bits encoded as a decimal constant, hex constant or base-64 con-stant. For base-64 encoding the encoding is done according to [RFC2045]. The length of the string is either specified by the key definition or is implied by the encoding as the mini-mum number of bytes that can hold the encoded string. large-binary-value : a binary string encoded as a hex con-stant or base-64 constant. For base-64 encoding the encoding is done according to [RFC2045]. The length of the string is either specified by the key definition or is implied by the encoding as the minimum number of bytes that can hold the encoded string. binary-value: a regular-binary-value or a large-binary-value. Operations on binary values are key specific. simple-value: text-value, iSCSI-name-value, boolean-value, numeric-value, a numeric-range or a binary-value. list-of-values: a sequence of text-values separated by comma If not otherwise specified, the maximum length of a simple-value (not its encoded representation) is 255 bytes not including the delimiter (comma or null). Any iSCSI target or initiator MUST support receiving at least 16384 bytes of key=value data in a negotiation sequence except when indi-cating support for very long authentication items by offering or selecting authentication methods such as public key certificates in which case they MUST support receiving at least 64 kilobytes of key=value data. Text Mode Negotiation During login, and thereafter, some session or connection parameters are either declared or negotiated through an exchange of textual information. The initiator starts the negotiation and/or declaration through a Text/Login request and indicates when it is ready for completion (by setting to 1 and keeping to 1 the F bit in a Text Request or the T bit in the Login Request). The format of a declaration is: Declarer-> = The general format of text negotiation is: Originator-> = Responder-> =|NotUnderstood|Irrelevant|Reject The originator or declarer can either be the initiator or the target and the responder can either be the target or initiator, respec-tively. Target requests are not limited to respond to key=value pairs as offered by the initiator. The target may offer key=value pairs of its own. All negotiations are explicit (i.e., the result MUST be based only on newly exchanged or declared values). There are no implicit offers. If an explicit offer is not made then a reply cannot be expected. Con-servative design requires also that default values should not be relied upon when use of some other value has serious consequences. The value offered or declared can be an numerical-value, a numerical-range defined by lower and upper value - both integers separated by tilde, a binary value, a text-value, a iSCSI-name-value, an iSCSI-local-name-value, a boolean-value (Yes or No), or a list of comma separated text-values. A range MAY ONLY be offered if it is explic-itly allowed for a key. An iSCSI-name-value and an iSCSI-local-name-value can be used only where explicitly allowed. A selected value can be an numerical-value, a text-value or a boolean-value. If a specific key is not relevant for the current negotiation, the responder may answer with the constant "Irrelevant" for all types of negotiation. However the negotiation is not considered as failed if the response is Irrelevant. Any key not understood by the responder may be ignored by the responder without affecting the basic function. However, the Text Response for a key not understood MUST be key=NotUnderstood. The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and must only be used as described here. None, Reject or Irrelevant are legitimate negotiation options where allowed but their excessive use is discouraged. Some basic key=value pairs are described in Chapter 11. All keys in Chapter 11, except for the X- extension format, MUST be supported by iSCSI initiators and targets and MUST NOT be answered with NotUnder-stood. Implementers may introduce new keys by prefixing them with X- fol-lowed by their (reversed) domain name. For example the entity owning the domain acme.com can issue: X-com.acme.bar.foo.do_something=3 List negotiations In list negotiation, the originator sends a list of values (which may include "None") in its order of preference. The responding party MUST answer with the first value that it sup-ports (and is allowed to use for the specific originator) selected from the originator list. The constant "None" MUST always be used to indicate a missing func-tion. However, None is a valid selection only if it is explicitly offered. If a responder does not understand any particular value in a list it MUST ignore it. If a responder does not support, does not understand or is not allowed to use all of the offered options with a specific originator, it MAY use the constant "Reject". The selection of a value not admissible under the selection rules is considered a nego-tiation failure and is handled as a protocol error. The selection rules are key-specific. Simple-value negotiations For simple-value negotiations, the responding party MUST respond with the same key. The value it selects, based on the selection rule spe-cific to the key, becomes the negotiation result. For a numerical range the value selected must be an integer within the offered range or "Reject" (if the range is unacceptable). An offer of a value not admissible MAY be answered with the constant "Reject" or the responder MAY select an admissible value. The selection, by the responder, of a value not admissible under the selection rules is considered a negotiation failure and is handled accordingly. The selection rules are key-specific. For boolean negotiations (keys taking the values Yes or No), the responding party MUST respond with the same key and the result of the negotiation when the received value does not determine that result by itself. The last value transmitted becomes the negotiation result. The rules for selecting the value with which to respond are expressed as Boolean functions of the value received and the value that the responding party would select in the absence of knowledge of the received value. Specifically, the two cases in which responses are OPTIONAL are: - The boolean function is "AND" and the value "No" is received. The outcome of the negotiation is "No". - The boolean function is "OR" and the value "Yes" is received. The outcome of the negotiation is "Yes". Responses are REQUIRED in all other cases, and the value chosen and sent by the responder becomes the outcome of the negotiation. --=_alternative 0061AE60C2256BAE_= Content-Type: text/html; charset="us-ascii"
Here is another attempt.

Julo

Text Format

The initiator and target send a set of key=value pairs encoded in UTF-8 Unicode. All the text keys and text values specified in this document are to be presented and interpreted in the case they appear in this document. They are case sensitive.

The following character symbols are used in this document for text items:

(a-z, A-Z) - letters
(0-9) - digits
" " (0x20) - space
"." (0x2e) - dot
"-" (0x2d) - minus
"+" (0x2b) - plus
"@" (0x40) - commercial at
"_" (0x5f) - underscore
"=" (0x3d) - equal
":" (0x3a) - colon
"/" (0x2f) - solidus or slash
"[" (0x5b) - left bracket
"]" (0x5d) - right bracket
null(0x00) - null separator
"," (0x2c) - comma
"~" (0x7e) - tilde

A key-name is whatever precedes the first = in the key=value pair. The term key is used frequently in this document with the meaning of key-name.

A value is whatever follows the = that follows the key-name up to a null delimiter that marks the end of any key=value pair (including the last in a PDU).

The following definitions will be used in the rest of this document:

key-name:  a string of one or more characters consisting of letters, digits, point, minus, plus, commercial at, and underscore, A key-name MUST begin with a capital letter an must not exceed 63 characters.

text-value: a string of 0 or more characters consisting of let-ters, digits, dot, minus, plus, commercial at, underscore, slash, left bracket, right bracket and colon.

iSCSI-name-value: a string of one or more characters consist-ing of minus, dot, colon and any character allowed by the output of the iSCSI string-prep template as specified in [STPREP-iSCSI] (see also Section 2.2.6.2 iSCSI Name Encoding).

iSCSI-local-name-value: an UTF-8 string terminated by the null character that terminates the key=value pair; no null charac-ters are allowed in the string. This encoding is to be used for localized (internationalized) aliases.

boolean-value: the strings "Yes" or "No".

hex-constant: hexadecimal constant encoded as a string start-ing with "0x" or "0X" followed by 1 or more digits or the letters a, b, c, d, e, f, A, B, C, D, E and F.

decimal-constant: an unsigned decimal number - a string of 1 or more digits starting with a non-zero digit. This encoding is not used for numerical values equal or greater than 2**64.

base-64-constant: unsigned base-64 constant encoded as a string starting with "0b" or "0B" followed by 1 or more digits or letters or plus or slash or equal.

regular-numerical-value :  an unsigned integer less than 2**64 encoded as a decimal-constant, hex constant, or base-64 con-stant. For base-64 encoding the encoding is done according to [RFC2045].

large-numerical-value :  an unsigned integer larger than or equal to 2**64 encoded as a hex constant, or base-64 con-stant.

numerical-value: a regular-numerical-value or a large numeri-cal-value. Unsigned integer arithmetic applies to numeric-values.

numeric-range: two numerical-values separated by a tilde.

regular-binary-value :  a binary string less than 64 bits encoded as a decimal constant, hex constant or base-64 con-stant. For base-64 encoding the encoding is done according to [RFC2045]. The length of the string is either specified by the key definition or is implied by the encoding as the mini-mum number of bytes that can hold the encoded string.

large-binary-value :  a binary string encoded as a hex con-stant or base-64 constant. For base-64 encoding the encoding is done according to [RFC2045]. The length of the string is either specified by the key definition or is implied by the encoding as the minimum number of bytes that can hold the encoded string.

binary-value: a regular-binary-value or a large-binary-value. Operations on binary values are key specific.

simple-value: text-value, iSCSI-name-value, boolean-value, numeric-value, a numeric-range or a binary-value.

list-of-values: a sequence of text-values separated by comma


If not otherwise specified, the maximum length of a simple-value (not its encoded representation) is 255 bytes not including the delimiter (comma or null).

Any iSCSI target or initiator MUST support receiving at least 16384 bytes of key=value data in a negotiation sequence except when indi-cating support for very long authentication items by offering or selecting authentication methods such as public key certificates in which case they MUST support receiving at least 64 kilobytes of key=value data.

Text Mode Negotiation

During login, and thereafter, some session or connection parameters are either declared or negotiated through an exchange of textual information.

The initiator starts the negotiation and/or declaration through a Text/Login request and indicates when it is ready for completion (by setting to 1 and keeping to 1 the F bit in a Text Request or the T bit in the Login Request).

The format of a declaration is:

Declarer-> <key>=<valuex>

The general format of text negotiation is:

Originator-> <key>=<valuex>
Responder-> <key>=<valuey>|NotUnderstood|Irrelevant|Reject

The originator or declarer can either be the initiator or the target and the responder can either be the target or initiator, respec-tively. Target requests are not limited to respond to key=value pairs as offered by the initiator. The target may offer key=value pairs of its own.

All negotiations are explicit (i.e., the result MUST be based only on newly exchanged or declared values). There are no implicit offers. If an explicit offer is not made then a reply cannot be expected. Con-servative design requires also that default values should not be relied upon when use of some other value has serious consequences.

The value offered or declared can be an numerical-value, a numerical-range defined by lower and upper value - both integers separated by tilde, a binary value, a text-value, a iSCSI-name-value, an iSCSI-local-name-value, a boolean-value (Yes or No), or a list of comma separated text-values. A range MAY ONLY be offered if it is explic-itly allowed for a key.  An iSCSI-name-value and an iSCSI-local-name-value can be used only where explicitly allowed. A selected value can be an numerical-value, a text-value or a boolean-value.

If a specific key is not relevant for the current negotiation, the responder may answer with the constant "Irrelevant" for all types of negotiation.  However the negotiation is not considered as failed if the response is Irrelevant.

Any key not understood by the responder may be ignored by the responder without affecting the basic function. However, the Text Response for a key not understood MUST be key=NotUnderstood.

The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and must only be used as described here.

None, Reject or Irrelevant are legitimate negotiation options where allowed but their excessive use is discouraged.
 
Some basic key=value pairs are described in Chapter 11. All keys in Chapter 11, except for the X- extension format, MUST be supported by iSCSI initiators and targets and MUST NOT be answered with NotUnder-stood.

Implementers may introduce new keys by prefixing them with X- fol-lowed by their (reversed) domain name. For example the entity owning the domain acme.com can issue:

X-com.acme.bar.foo.do_something=3

List negotiations

In list negotiation, the originator sends a list of values (which may include "None") in its order of preference.

The responding party MUST answer with the first value that it sup-ports (and is allowed to use for the specific originator) selected from the originator list.

The constant "None" MUST always be used to indicate a missing func-tion. However, None is a valid selection only if it is explicitly offered.

If a responder does not understand any particular value in a list it MUST ignore it. If a responder does not support, does not understand or is not allowed to use all of the offered options with a specific originator, it MAY use the constant "Reject".  The selection of a value not admissible under the selection rules is considered a nego-tiation failure and is handled as a protocol error. The selection rules are key-specific.

Simple-value negotiations

For simple-value negotiations, the responding party MUST respond with the same key. The value it selects, based on the selection rule spe-cific to the key, becomes the negotiation result. For a numerical range the value selected must be an integer within the offered range or "Reject" (if the range is unacceptable).  An offer of a value not admissible MAY be answered with the constant "Reject" or the responder MAY select an admissible value. The selection, by the responder, of a value not admissible under the selection rules is considered a negotiation failure and is handled accordingly. The selection rules are key-specific.

For boolean negotiations (keys taking the values Yes or No), the responding party MUST respond with the same key and the result of the negotiation when the received value does not determine that result by itself. The last value transmitted becomes the negotiation result. The rules for selecting the value with which to respond are expressed as Boolean functions of the value received and the value that the responding party would select in the absence of knowledge of the received value.
 
Specifically, the two cases in which responses are OPTIONAL are:

- The boolean function is "AND" and the value "No" is received. The outcome of the negotiation is "No".
- The boolean function is "OR" and the value "Yes" is received. The outcome of the negotiation is "Yes".

Responses are REQUIRED in all other cases, and the value chosen and sent by the responder becomes the outcome of the negotiation.
--=_alternative 0061AE60C2256BAE_=-- From owner-ips@ece.cmu.edu Fri May 3 16:35:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29895 for ; Fri, 3 May 2002 16:35:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43JsTZ24511 for ips-outgoing; Fri, 3 May 2002 15:54:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from intotoinc.com (sdsl-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43JsRw24504 for ; Fri, 3 May 2002 15:54:27 -0400 (EDT) Received: from localhost (srao@localhost) by intotoinc.com (8.11.0/8.11.0) with ESMTP id g43K49r09153; Fri, 3 May 2002 13:04:10 -0700 Date: Fri, 3 May 2002 13:04:09 -0700 (PDT) From: Srinivasa Addepalli To: Bernard Aboba cc: cbh@zyfer.com, ips@ece.cmu.edu Subject: Re: Relation between iSCSI session and IPSec SAs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8BIT Security Policy Database, as defined by RFC2401 (Section 4.4.1) is flexibile enough to create security associations for individual TCP connections and for set of TCP/IP connections. For clarity, I am listing down the portion of the RFC here: " For each selector, the policy entry specifies how to derive the corresponding values for a new Security Association Database (SAD, see Section 4.4.3) entry from those in the SPD and the packet (Note that at present, ranges are only supported for IP addresses; but wildcarding can be expressed for all selectors): a. use the value in the packet itself -- This will limit use of the SA to those packets which have this packet's value for the selector even if the selector for the policy entry has a range of allowed values or a wildcard for this selector. b. use the value associated with the policy entry -- If this were to be just a single value, then there would be no difference between (b) and (a). However, if the allowed values for the selector are a range (for IP addresses) or wildcard, then in the case of a range,(b) would enable use of the SA by any packet with a selector value within the range not just by packets with the selector value of the packet that triggered the creation of the SA. In the case of a wildcard, (b) would allow use of the SA by packets with any value for this selector. " If security association is required for each TCP connection between iSCSI initiator and target, then Security policy can be configured to create security associations based on packet values for sourceIP, destination IP, protocol, SP and DP. If Security association is required for all connections between a iSCSI initiator and target, then security policy can be configured to depend on packet values for Source IP and destination IP and policy values for others. Since, SPD itself provides this granularity, I think, there is no need for any communication/relation between iSCSI layer and IPSEC layer. Srini On Fri, 3 May 2002, Bernard Aboba wrote: > >From the minutes of Minneapolis: > >"...a single IPSec Phase 2 SA per TCP connection ...had no security > > >value." > >I agree and like to extend this: > > >"...a single IKE negotiation per multiple iSCSI session (between the >same > >IP addresses of initiator and target) ...had no security value." > > If you are saying that it it doesn't matter how many IKE phase 2 SAs > correspond to a given IKE Phase 1 SA, then I would agree. Is this what you > meant? > > >Must we negotiate per multiple session (and evaluate packets >additional > >for a session identifier) or must we not? > > I think that the bottom line is that an iSCSI session needs to be protected > by an IKE phase 2 SA. You can have multiple iSCSI sessions per phase 2 SA. > You can have multiple phase 2 SAs per phase 1 SA. Those are implementation > decisions that generally don't influence the security properties, except in > a few exceptional conditions (e.g. QoS marking, desire to protect iSCSI > sessions with different transforms). > > _________________________________________________________________ > Join the world’s largest e-mail service with MSN Hotmail. > http://www.hotmail.com > -- Srinivasa Rao Addepalli Intoto Inc. 3160, De La Cruz Blvd #100 Santa Clara, CA USA Ph: 408-844-0480 x317 From owner-ips@ece.cmu.edu Fri May 3 17:21:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01303 for ; Fri, 3 May 2002 17:21:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43KdpS29119 for ips-outgoing; Fri, 3 May 2002 16:39:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43Kdlw29108; Fri, 3 May 2002 16:39:47 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id B921D30706; Fri, 3 May 2002 16:39:46 -0400 (EDT) Date: Fri, 3 May 2002 13:38:39 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Eddy Quicksall Cc: "'Julian Satran'" , "THALER,PAT (A-Roseville,ex1)" , andy currid , , Subject: RE: iSCSI: large keys during login? In-Reply-To: <25369470B6F0D41194820002B328BDD23A6EDE@ATLOPS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 3 May 2002, Eddy Quicksall wrote: > Regarding the following sentence in 9.10.4, can we say the key and equal > sign most not be spanned? The reason I ask for this is because it makes the > parsing of the key much easier if you don't have it cut into two PDUs. Wouldn't it just be easier to just read the whole extended text and then parse? i.e. do { Read_packet(&empty part of buffer) if (packet doesn't end with a NUL) { send response asking for more make sure there's more space in buffer } } while (packet doesn't end with a NUL) parse while buffer Why would you be parsing the text before it has all arrived? Or is it more you were going to keep things in different buffers, and don't want to fumble with the key spanning buffers? Take care, Bill From owner-ips@ece.cmu.edu Fri May 3 17:25:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01406 for ; Fri, 3 May 2002 17:25:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43L96001592 for ips-outgoing; Fri, 3 May 2002 17:09:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43L93w01586 for ; Fri, 3 May 2002 17:09:04 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 82D233070A; Fri, 3 May 2002 17:09:03 -0400 (EDT) Date: Fri, 3 May 2002 14:07:56 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "BARRY,BOB (HP-Roseville,ex1)" Cc: "'ips@ece.cmu.edu'" Subject: Re: Comments on v12 of iSCSI Specification In-Reply-To: <499DC368E25AD411B3F100902740AD650DB50224@xrose03.rose.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 3 May 2002, BARRY,BOB (HP-Roseville,ex1) wrote: > The following comments are submitted against the April 17, 2002, > draft-ietf-ips-iSCSI-12.txt. Wow. That's a lot of input. :-) Commenting on the ones I have input on. > Bob Barry > ==================================================== > > General Comments > 1) An acronym section would make it easier to read > this document. Acronyms such as SW for session > wide, IO for initialize-only, and others are not > immediately obvious. Agreed. > 2) A copyright notice be part of this document. There is one, on page 260. > 3) In chapter 9, each PDU should have a complete > description provided. Yes, this means a duplication > of the field descriptions, but having to search back > in the document to find field meanings does not > make sense. Also, I think some PDUs (R2T for example) list DataSegmentLengths when the PDU won't have a data segment. Other PDUs that lack data segments list bytes 5 through 7 as reserved. Additionally, some PDU examples helpfully show the data coming after the PDU. Others show the digests (if any), then the data. Both of these usages are not consistent with the usage shown on page 119 at the top of the page (tail end of section 9.2); they don't show the AHS, nor the data digests. I realize that AHSs don't always make sense, but if we're going to have an AHSlength in a PDU, and we show more than just the PDU, shouldn't we show the optional AHS? > 5) Either "data is" or "data are" are considered correct > for technical documentation, however, only one should > be used in a document for consistency. Examples: > p 35: last paragraph, first line "data is" > p 36: third paragraph, first line "data are" > p 36: third paragraph, third line "data are" > p 36: seventh paragraph, fourth line "data is" Agreed. I also vote for using "data are" since data originated as the plural of datum. :-) > 6) The word "null" is used throughout this document to > mean "zero", or "zero valued". This needs to be > clearly stated. Also, when we are talking about the zero-character at the end of login/text messages, could we please refer to it as NUL, which is the correct ASCII name for it. Yes, I realize they are UTF-8, not ASCII, but "null" is sloppy in this regard. > Comments regarding draft contents > 11) p 63: third paragraph of 4.1, last line: "(comma or > null)" should be "(comma or zero byte)" zero byte would work too. Take care, Bill From owner-ips@ece.cmu.edu Fri May 3 17:28:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01520 for ; Fri, 3 May 2002 17:28:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43LHbE02232 for ips-outgoing; Fri, 3 May 2002 17:17:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail2.hd.intel.com (hdfdns02.hd.intel.com [192.52.58.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43LHZw02226 for ; Fri, 3 May 2002 17:17:35 -0400 (EDT) Received: from mkrikis-laptop (mkrikis-laptop.hd.intel.com [10.127.144.113]) by mail2.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.36 2002/05/02 20:19:58 root Exp $) with ESMTP id g43LHTe13618 for ; Fri, 3 May 2002 21:17:29 GMT Received: from martinsk by mkrikis-laptop with local (Exim 3.35 #1 (Debian)) id 173lMg-0000Po-00 for ; Fri, 03 May 2002 17:17:22 -0500 To: ips@ece.cmu.edu Subject: Re: iSCSI - an improved text for 4.1 & 4.2 Message-Id: From: Martins Krikis Date: Fri, 03 May 2002 17:17:22 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk Adding regular expressions, where possible, would have benefited the draft, IMHO. More comments follow. > key-name: a string of one or more characters consisting of letters, digits, > point, minus, plus, commercial at, and underscore, A key-name MUST begin with > a capital letter an must not exceed 63 characters. I believe it should be "dot" instead of "point". > iSCSI-local-name-value: an UTF-8 string terminated by the null character that > terminates the key=value pair; no null charac-ters are allowed in the > string. This encoding is to be used for localized (internationalized) aliases. Very strangely this definition starts mentioning the terminator when others didn't. And null characters aren't allowed in any other kind of values either, are they? If so, how do we know where the value really ends? > boolean-value: the strings "Yes" or "No". "string". > decimal-constant: an unsigned decimal number - a string of 1 or more digits > starting with a non-zero digit. This encoding is not used for numerical values > equal or greater than 2**64. We just disallowed the 0 itself. > base-64-constant: unsigned base-64 constant encoded as a string starting with > "0b" or "0B" followed by 1 or more digits or letters or plus or slash or > equal. > regular-numerical-value : an unsigned integer less than 2**64 encoded as a > decimal-constant, hex constant, or base-64 con-stant. For base-64 encoding the > encoding is done according to [RFC2045]. How the encoding is done would be better put higher up with the base-64-constant definition, then it would not need to be repeated again and again. > numeric-range: two numerical-values separated by a tilde. Why not mention here that the values must come in non-decreasing order? > regular-binary-value : a binary string less than 64 bits encoded as a decimal > constant, hex constant or base-64 con-stant. For base-64 encoding the encoding > is done according to [RFC2045]. The length of the string is either specified > by the key definition or is implied by the encoding as the mini-mum number of > bytes that can hold the encoded string. The last sentence is ambiguous, IMHO, and incorrect no matter how understood. If, encoded as as a hex constant, the value is 0x000f, what is its length when decoded? 6 bytes ("0x000f" w/o '\0') or 1 byte (containing bits 00001111)? The answer that I think we want is 2 bytes... The problem is that not knowing what the string is, we can't tell how many bytes are required to hold it. Some other description will be necessary, I'm afraid. > simple-value: text-value, iSCSI-name-value, boolean-value, numeric-value, a > numeric-range or a binary-value. iSCSI-local-name-value seems to be missing. > All negotiations are explicit (i.e., the result MUST be based only on newly > exchanged or declared values). There are no implicit offers. If an explicit > offer is not made then a reply cannot be expected. Con-servative design > requires also that default values should not be relied upon when use of some > other value has serious consequences. Negotiations are not explicit due to the boolean omission "feature". Offers are explicit, negotiations aren't. > None, Reject or Irrelevant are legitimate negotiation options where allowed > but their excessive use is discouraged. Why is the use of "None" discouraged? In fact, "None" is not very special after all---it is only allowed in a response, if offered... > ... If a responder does not support, does not understand or is not > allowed to use all of the offered options with a specific originator, it MAY > use the constant "Reject". If I don't support "all", but support at least one of the offered values, I should answer with something I support and not with Reject. "Options" have not been defined or used before. Alright, I'm not a native English speaker myself, but I'll volunteer: If each of the offered values is not understood or not supported, or the responder is not allowed to use it with the specific originator, it MAY use the constant "Reject". And I would prefer a MUST instead of MAY. > The selection of a value not admissible under the > selection rules is considered a nego-tiation failure and is handled as a > protocol error. The selection rules are key-specific. It was just said above (I didn't quote it) that the selection rule is to pick the first value supported. Thus, I'm not sure why here the rule is key-specific. > For simple-value negotiations, the responding party MUST respond with the same > key. We forgot to mention the same for list negotiations. > The value it selects, based on the selection rule spe-cific to the key, > becomes the negotiation result. For a numerical range the value selected must > be an integer within the offered range or "Reject" (if the range is > unacceptable).  An offer of a value not admissible MAY be answered with the > constant "Reject" or the responder MAY select an admissible value. What was meant here by "value not admissible"? Outside the legal range of values or simply outside the range that the responder supports? > The > selection, by the responder, of a value not admissible under the selection > rules is considered a negotiation failure and is handled accordingly. The > selection rules are key-specific. Rules again are key-specific, when it was just said that the rule is to pick a value from the range (or Reject, or, well, that part was not clear), but they don't seem to be key-specific again... > The rules for selecting the value > with which to respond are expressed as Boolean functions of the value received > and the value that the responding party would select in the absence of > knowledge of the received value. I've mentioned this numerous times, nobody seems to care. IMO, there is a logic flay here: InitialR2T: function OR, default Yes. I -> T: No Target wants "No", too. However, in the "absence of the knowledge of the received value", it would have been forced to stick with the default "Yes". According to the quoted sentence above, the target must reply with OR(No, Yes) = Yes. Thus: T -> I: Yes Congratulations. Both parties wanted "No", but due to logic errors in the specification were forced to settle with "Yes". Am I right or wrong? Besides, this sentence is in the context of value omissions, so it should not be talking about the value to respond anyway. I'll volunteer for a fix-up (for the whole boolean negotiation part, until the word "Specifically"): For boolean negotiations (keys taking the values Yes or No), the negotiation result is determined by applying the key-specific boolean function to the value received and the value that the responding party would have offered, had it been the first to do so. The respoponding party MUST respond with the same key and the result of the negotiation when the received value does not determine that result by itself. The last value transmitted becomes the negotiation result. Thanks for your attention to these issues, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. From owner-ips@ece.cmu.edu Fri May 3 18:05:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01965 for ; Fri, 3 May 2002 18:05:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43LSOP03145 for ips-outgoing; Fri, 3 May 2002 17:28:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43KMhw26912; Fri, 3 May 2002 16:23:18 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 3 May 2002 16:22:43 -0400 Message-ID: <25369470B6F0D41194820002B328BDD23A6EDE@ATLOPS> From: Eddy Quicksall To: "'Julian Satran'" , "THALER,PAT (A-Roseville,ex1)" Cc: andy currid , ips@ece.cmu.edu, owner-ips@ece.cmu.edu, Bill Studenmund Subject: RE: iSCSI: large keys during login? Date: Fri, 3 May 2002 16:22:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F2E0.4745D700" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F2E0.4745D700 Content-Type: text/plain; charset="iso-8859-1" Regarding the following sentence in 9.10.4, can we say the key and equal sign most not be spanned? The reason I ask for this is because it makes the parsing of the key much easier if you don't have it cut into two PDUs. A key=value pair can span Text request or response boundaries (i.e., a key=value pair can start in one PDU and continue on the next). Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, April 29, 2002 8:35 PM To: THALER,PAT (A-Roseville,ex1) Cc: andy currid; ips@ece.cmu.edu; owner-ips@ece.cmu.edu; Bill Studenmund Subject: RE: iSCSI: large keys during login? Pat, For spanning look at 9.10.4 and 9.11.4. I assume that the text covers whatever does not fit. Regards, Julo "THALER,PAT (A-Roseville,ex1)" 04/30/2002 02:24 AM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL, Bill Studenmund cc: andy currid , ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: large keys during login? Julian, I assume you mean that keys can span requests as well. I can't find anything in the draft that says that they can though there also isn't anything that says they can't. Does this only apply to key-value pairs too long to fit in a single response or can a short key-value pair span a request/response when multiple key-value pairs are packed into a PDU? The draft should clarify. -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, April 29, 2002 3:54 PM To: Bill Studenmund Cc: andy currid; ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: large keys during login? Key can span responses. Bookmarking is for things that have multiple answers - like the SendTargets - Julo Bill Studenmund Sent by: owner-ips@ece.cmu.edu 04/30/2002 01:15 AM Please respond to Bill Studenmund To: andy currid cc: Subject: Re: iSCSI: large keys during login? On Mon, 29 Apr 2002, andy currid wrote: > > Hi > > In iSCSI draft 12, chapter 10, the Kerberos and SPKM authentication > mechanisms specify a limit of 64k on their unencoded key values. > > Given that these keys are only used during login and, during login, > the PDU size in use is 8k and, unlike text commands, there is no > bookmarking, how can you send a key value of this size during login? I thought that was covered. If you say you can do kerberos or SPKM, you are saying you can do 64k. Take care, Bill ------_=_NextPart_001_01C1F2E0.4745D700 Content-Type: text/html; charset="iso-8859-1"

Regarding the following sentence in 9.10.4, can we say the key and equal sign most not be spanned? The reason I ask for this is because it makes the parsing of the key much easier if you don't have it cut into two PDUs.
 

A key=value pair can span Text request or response boundaries (i.e., a

key=value pair can start in one PDU and continue on the next).

 

Eddy

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, April 29, 2002 8:35 PM
To: THALER,PAT (A-Roseville,ex1)
Cc: andy currid; ips@ece.cmu.edu; owner-ips@ece.cmu.edu; Bill Studenmund
Subject: RE: iSCSI: large keys during login?


Pat,

For spanning look at 9.10.4 and 9.11.4.

I assume that the text covers whatever does not fit.


Regards,
Julo


"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>

04/30/2002 02:24 AM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL, Bill Studenmund <wrstuden@wasabisystems.com>
        cc:        andy currid <andy@windriver.com>, ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iSCSI: large keys during login?

       


Julian,
 
I assume you mean that keys can span requests as well. I can't find anything in the draft that says that they can though there also isn't anything that says they can't. Does this only apply to key-value pairs too long to fit in a single response or can a short key-value pair span a request/response when multiple key-value pairs are packed into a PDU?
 
The draft should clarify.
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, April 29, 2002 3:54 PM
To: Bill Studenmund
Cc: andy currid; ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: large keys during login?


Key can span responses. Bookmarking is for things that have multiple answers - like the SendTargets - Julo

Bill Studenmund <wrstuden@wasabisystems.com>
Sent by: owner-ips@ece.cmu.edu

04/30/2002 01:15 AM
Please respond to Bill Studenmund

       
       To:        andy currid <andy@windriver.com>
       cc:        <ips@ece.cmu.edu>
       Subject:        Re: iSCSI: large keys during login?

     



On Mon, 29 Apr 2002, andy currid wrote:

>
> Hi
>
> In iSCSI draft 12, chapter 10, the Kerberos and SPKM authentication
> mechanisms specify a limit of 64k on their unencoded key values.
>
> Given that these keys are only used during login and, during login,
> the PDU size in use is 8k and, unlike text commands, there is no
> bookmarking, how can you send a key value of this size during login?

I thought that was covered. If you say you can do kerberos or SPKM, you
are saying you can do 64k.

Take care,

Bill




------_=_NextPart_001_01C1F2E0.4745D700-- From owner-ips@ece.cmu.edu Fri May 3 18:12:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02059 for ; Fri, 3 May 2002 18:12:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g43LaIf03810 for ips-outgoing; Fri, 3 May 2002 17:36:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g43LaGw03797 for ; Fri, 3 May 2002 17:36:16 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id EBD3AC5B4; Fri, 3 May 2002 15:36:14 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id BF971187; Fri, 3 May 2002 15:36:14 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 03 May 2002 15:36:11 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 May 2002 15:36:10 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00BC00C65@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: mkrikis@yahoo.com, ips@ece.cmu.edu Subject: RE: iSCSI - an improved text for 4.1 & 4.2 Date: Fri, 3 May 2002 15:36:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Martins, RE: why iSCSI-local-name-value mentions that null characters aren't allowed in the string while other value definitions do not. Most of the others name a specific set of characters that is allowed so they don't have to call out a particular character as not allowed. iSCSI-local-name-value seems to be the only one that is described as a "UTF-8 string" rather than a string "consisting of ". That is why it has to meantion the exclusion of null specifically. "terminated by the null charater" is probably unnecessary the text above says that all values are terminated by the null character. Pat -----Original Message----- From: Martins Krikis [mailto:mkrikis@yahoo.com] Sent: Friday, May 03, 2002 3:17 PM To: ips@ece.cmu.edu Subject: Re: iSCSI - an improved text for 4.1 & 4.2 Adding regular expressions, where possible, would have benefited the draft, IMHO. More comments follow. > key-name: a string of one or more characters consisting of letters, digits, > point, minus, plus, commercial at, and underscore, A key-name MUST begin with > a capital letter an must not exceed 63 characters. I believe it should be "dot" instead of "point". > iSCSI-local-name-value: an UTF-8 string terminated by the null character that > terminates the key=value pair; no null charac-ters are allowed in the > string. This encoding is to be used for localized (internationalized) aliases. Very strangely this definition starts mentioning the terminator when others didn't. And null characters aren't allowed in any other kind of values either, are they? If so, how do we know where the value really ends? > boolean-value: the strings "Yes" or "No". "string". > decimal-constant: an unsigned decimal number - a string of 1 or more digits > starting with a non-zero digit. This encoding is not used for numerical values > equal or greater than 2**64. We just disallowed the 0 itself. > base-64-constant: unsigned base-64 constant encoded as a string starting with > "0b" or "0B" followed by 1 or more digits or letters or plus or slash or > equal. > regular-numerical-value : an unsigned integer less than 2**64 encoded as a > decimal-constant, hex constant, or base-64 con-stant. For base-64 encoding the > encoding is done according to [RFC2045]. How the encoding is done would be better put higher up with the base-64-constant definition, then it would not need to be repeated again and again. > numeric-range: two numerical-values separated by a tilde. Why not mention here that the values must come in non-decreasing order? > regular-binary-value : a binary string less than 64 bits encoded as a decimal > constant, hex constant or base-64 con-stant. For base-64 encoding the encoding > is done according to [RFC2045]. The length of the string is either specified > by the key definition or is implied by the encoding as the mini-mum number of > bytes that can hold the encoded string. The last sentence is ambiguous, IMHO, and incorrect no matter how understood. If, encoded as as a hex constant, the value is 0x000f, what is its length when decoded? 6 bytes ("0x000f" w/o '\0') or 1 byte (containing bits 00001111)? The answer that I think we want is 2 bytes... The problem is that not knowing what the string is, we can't tell how many bytes are required to hold it. Some other description will be necessary, I'm afraid. > simple-value: text-value, iSCSI-name-value, boolean-value, numeric-value, a > numeric-range or a binary-value. iSCSI-local-name-value seems to be missing. > All negotiations are explicit (i.e., the result MUST be based only on newly > exchanged or declared values). There are no implicit offers. If an explicit > offer is not made then a reply cannot be expected. Con-servative design > requires also that default values should not be relied upon when use of some > other value has serious consequences. Negotiations are not explicit due to the boolean omission "feature". Offers are explicit, negotiations aren't. > None, Reject or Irrelevant are legitimate negotiation options where allowed > but their excessive use is discouraged. Why is the use of "None" discouraged? In fact, "None" is not very special after all---it is only allowed in a response, if offered... > ... If a responder does not support, does not understand or is not > allowed to use all of the offered options with a specific originator, it MAY > use the constant "Reject". If I don't support "all", but support at least one of the offered values, I should answer with something I support and not with Reject. "Options" have not been defined or used before. Alright, I'm not a native English speaker myself, but I'll volunteer: If each of the offered values is not understood or not supported, or the responder is not allowed to use it with the specific originator, it MAY use the constant "Reject". And I would prefer a MUST instead of MAY. > The selection of a value not admissible under the > selection rules is considered a nego-tiation failure and is handled as a > protocol error. The selection rules are key-specific. It was just said above (I didn't quote it) that the selection rule is to pick the first value supported. Thus, I'm not sure why here the rule is key-specific. > For simple-value negotiations, the responding party MUST respond with the same > key. We forgot to mention the same for list negotiations. > The value it selects, based on the selection rule spe-cific to the key, > becomes the negotiation result. For a numerical range the value selected must > be an integer within the offered range or "Reject" (if the range is > unacceptable).  An offer of a value not admissible MAY be answered with the > constant "Reject" or the responder MAY select an admissible value. What was meant here by "value not admissible"? Outside the legal range of values or simply outside the range that the responder supports? > The > selection, by the responder, of a value not admissible under the selection > rules is considered a negotiation failure and is handled accordingly. The > selection rules are key-specific. Rules again are key-specific, when it was just said that the rule is to pick a value from the range (or Reject, or, well, that part was not clear), but they don't seem to be key-specific again... > The rules for selecting the value > with which to respond are expressed as Boolean functions of the value received > and the value that the responding party would select in the absence of > knowledge of the received value. I've mentioned this numerous times, nobody seems to care. IMO, there is a logic flay here: InitialR2T: function OR, default Yes. I -> T: No Target wants "No", too. However, in the "absence of the knowledge of the received value", it would have been forced to stick with the default "Yes". According to the quoted sentence above, the target must reply with OR(No, Yes) = Yes. Thus: T -> I: Yes Congratulations. Both parties wanted "No", but due to logic errors in the specification were forced to settle with "Yes". Am I right or wrong? Besides, this sentence is in the context of value omissions, so it should not be talking about the value to respond anyway. I'll volunteer for a fix-up (for the whole boolean negotiation part, until the word "Specifically"): For boolean negotiations (keys taking the values Yes or No), the negotiation result is determined by applying the key-specific boolean function to the value received and the value that the responding party would have offered, had it been the first to do so. The respoponding party MUST respond with the same key and the result of the negotiation when the received value does not determine that result by itself. The last value transmitted becomes the negotiation result. Thanks for your attention to these issues, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. From owner-ips@ece.cmu.edu Fri May 3 22:57:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08313 for ; Fri, 3 May 2002 22:57:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g442RYM19932 for ips-outgoing; Fri, 3 May 2002 22:27:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g442RWw19926 for ; Fri, 3 May 2002 22:27:32 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id 211B5C00DC8 for ; Fri, 3 May 2002 19:27:26 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id TAA16497 for ; Fri, 3 May 2002 19:29:10 -0700 (PDT) Message-ID: <00d001c1f313$39de4240$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: Subject: FCIP: Comment 125 Date: Fri, 3 May 2002 19:27:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.pdf .... > Please review these comments resolutions to ensure that > the desired changes are described. Sorry for the delayed review, I have additional comments on wglc-01 for Comment 125. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com >Comment 125 >> 9.1.2.3 Connection Setup After a Successful TCP Connect Request >...... >> If the echoed FCIP Special Frame bytes do not exactly match the >> FCIP Special Frame bytes sent (words 7 through 17 inclusive), the >> FCIP Entity SHALL close the TCP Connection and notify the FC >> Entity with the reason for the closure. >Seems like all the 11 words are required to be compared. If so, what >is the Ch bit being used for? IOW, why SHALL it be set by the >responder? >Inquiry >The Ch bit serves to identify the difference between changes >made intentionally by the echoing FCIP Entity and changes that >result from transmission errors. OK, but I don't see how is this distinction may be made use of by the receiver. IIRC, any comparison failure (Ch bit or not) leads to a connection drop. Is Ch bit then intended only for diagnostics? From owner-ips@ece.cmu.edu Fri May 3 23:00:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08351 for ; Fri, 3 May 2002 23:00:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g442Q6q19829 for ips-outgoing; Fri, 3 May 2002 22:26:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g442Pxw19819 for ; Fri, 3 May 2002 22:26:05 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id 9E4596008D1; Fri, 3 May 2002 19:25:53 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id TAA15944; Fri, 3 May 2002 19:27:37 -0700 (PDT) Message-ID: <00ca01c1f313$0296ccd0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Ralph Weber" Cc: Subject: FCIP: Comment 120 Date: Fri, 3 May 2002 19:25:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.pdf .... > Please review these comments resolutions to ensure that > the desired changes are described. Sorry for the delayed review, I have additional comments on wglc-01 for Comment 120. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com >Comment 120 >> 8. The FCIP Special Frame >...... >> Note: The combination of the Source FC Entity World Wide Name and >> Source FCIP Entity Identifier fields uniquely identifies every FC >> Entity FCIP Entity pair in the IP Network. >.... >- Also I take it that the "FC/FCIP Entity Identifier" is unique only >within the scope of the given FC Entity's WWN. So, does the model >allow multiple FCIP Entities to be associated with the FC Fabric >Entity WWN? >.... >Response to the second bullet: Yes, the "FC/FCIP Entity Identifier" >is unique only within the scope of the given FC Entity's WWN. Yes, >the model allows multiple FCIP Entities to be associated with the FC >Fabric Entity WWN. > If that is so, please add an architectural model diagram (similar to Figure 3, or perhaps convert Figure 3 into) which clearly shows this 1-to-n association. This is the only hint in the document (at least that I found) which suggests the stated possibility. Figure 3 with 1-to-1 association almost seemed like the architectural model, but on careful reading, is only an example. From owner-ips@ece.cmu.edu Fri May 3 23:02:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08377 for ; Fri, 3 May 2002 23:02:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g442SVX19984 for ips-outgoing; Fri, 3 May 2002 22:28:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g442STw19980 for ; Fri, 3 May 2002 22:28:29 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id EFBD3C0051B for ; Fri, 3 May 2002 19:28:23 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id TAA16835 for ; Fri, 3 May 2002 19:30:08 -0700 (PDT) Message-ID: <00d601c1f313$5c64c280$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: Subject: FCIP: Comment 109 Date: Fri, 3 May 2002 19:28:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.pdf .... > Please review these comments resolutions to ensure that > the desired changes are described. Sorry for the delayed review, I have additional comments on wglc-01 for Comment 109. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com >>Comment 109 Technical >> 6.6.1 FCIP Encapsulation of FC Frames >.... >> The CRCV (CRC Valid) Flag SHALL be set to 0. >> >> The CRC field SHALL be set to 0. >I am surprised that the FCIP encapsulated header is never protected >by a CRC. The error detection section clearly acknowledges the >possibility that TCP checksum could be inadequate for certain >deployments - and even suggests checking the FC frame CRC (sort >of like a data digest) on reception at the Encapsulated Frame >Receiver Portal. >My recommendation is to require an FCIP Entity to employ the header >CRC if the SF that it receives asks for CRC - IOW, similar to iSCSI's >approach. So, I guess I am also advocating a new bit in the pFlags >field to announce this. When this CRC expectation is announced, the >FC CRC checking test in 6.6.2.2 should also be a mandatory test -from >the "semi-optional" list it is currently in. >Accepted with the following result >Add the following to the new section created in response to comment >44: "Note: Owing to the limited manner in which the FSF is used and >the requirement that the FSF be echoed without changes before a TCP >connection is allowed to carry user data, no error checking beyond >that provided by TCP is deemed necessary." Sorry, I missed the earlier discussion on this comment. My comment was for __all__ FCIP encapsulated headers on all FCIP Frames - not just for FSF. The reference to FSF in my comment was to suggest how an "I want CRC" demand be communicated at the FCIP Link establishment time - i.e. the reference was a solution strawman. I probably missed something critical - could you please comment on whether or not CRC protection is available on FCIP headers and help me with a reference if so? From owner-ips@ece.cmu.edu Sat May 4 15:34:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28463 for ; Sat, 4 May 2002 15:34:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g44IpiR18209 for ips-outgoing; Sat, 4 May 2002 14:51:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g44Ipfw18200 for ; Sat, 4 May 2002 14:51:42 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g44Hp2l07843; Sat, 4 May 2002 13:51:03 -0400 Message-ID: <3CD42DB3.4F39BAAD@splentec.com> Date: Sat, 04 May 2002 14:51:31 -0400 From: Luben Tuikov Reply-To: iSCSI , Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "THALER,PAT (A-Roseville,ex1)" CC: Randy Jennings , iSCSI Subject: Re: iSCSI - re-phrase of 4.1 References: <1BEBA5E8600DD4119A50009027AF54A00BC00BA2@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit "THALER,PAT (A-Roseville,ex1)" wrote: > > Randy, > > I'm not young and I have never seen a signed hex constant either. I don't > see any need to use signed hex constants. I also agree with Julian on > leading zeros for hex (and base 64). They should be allowed. I got it; for some reason I was still thinking about integers (Z), rather than bits (string of {0,1}). You could've just mentioned that: bits, not integers... Nevertheless, ``signed hex constants'' do exist, as do floating point hex representations, granted in a different context. -- Luben From owner-ips@ece.cmu.edu Sun May 5 11:14:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19832 for ; Sun, 5 May 2002 11:14:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g45EUao23799 for ips-outgoing; Sun, 5 May 2002 10:30:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g45A3dw12112 for ; Sun, 5 May 2002 06:03:39 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Sun, 5 May 2002 06:03:23 -0400 Message-ID: <25369470B6F0D41194820002B328BDD23A6EF5@ATLOPS> From: Eddy Quicksall To: "'Bill Studenmund'" Cc: ips@ece.cmu.edu Subject: RE: iSCSI: large keys during login? Date: Sun, 5 May 2002 06:03:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Yes, you are correct. I was trying to get away with small buffers and I didn't notice a change in 4.1. Eddy -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Friday, May 03, 2002 4:39 PM To: Eddy Quicksall Cc: 'Julian Satran'; THALER,PAT (A-Roseville,ex1); andy currid; ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI: large keys during login? On Fri, 3 May 2002, Eddy Quicksall wrote: > Regarding the following sentence in 9.10.4, can we say the key and equal > sign most not be spanned? The reason I ask for this is because it makes the > parsing of the key much easier if you don't have it cut into two PDUs. Wouldn't it just be easier to just read the whole extended text and then parse? i.e. do { Read_packet(&empty part of buffer) if (packet doesn't end with a NUL) { send response asking for more make sure there's more space in buffer } } while (packet doesn't end with a NUL) parse while buffer Why would you be parsing the text before it has all arrived? Or is it more you were going to keep things in different buffers, and don't want to fumble with the key spanning buffers? Take care, Bill From owner-ips@ece.cmu.edu Sun May 5 17:21:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23738 for ; Sun, 5 May 2002 17:21:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g45KexE12211 for ips-outgoing; Sun, 5 May 2002 16:40:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g45Ketw12200; Sun, 5 May 2002 16:40:55 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g45KemPt008916; Sun, 5 May 2002 22:40:48 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g45Kejg170848; Sun, 5 May 2002 22:40:45 +0200 To: Eddy Quicksall Cc: andy currid , ips@ece.cmu.edu, owner-ips@ece.cmu.edu, "THALER,PAT (A-Roseville,ex1)" , Bill Studenmund MIME-Version: 1.0 Subject: RE: iSCSI: large keys during login? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 5 May 2002 23:40:35 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/05/2002 23:40:46, Serialize complete at 05/05/2002 23:40:46 Content-Type: multipart/alternative; boundary="=_alternative 00505D30C2256BAF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00505D30C2256BAF_= Content-Type: text/plain; charset="us-ascii" Eddy, There are many ways to do it. Recall that we had no spanning at all and that was best. But it was not good enough for all values with small PDU's. The alternative would be to allow at least the sender to lay out data and the send-it out by cutting it in pieces of PDU length without it having to parse. What you are suggesting requires the sender to build the stream considering the boundaries. We could go either way but IMHO it is better as we have it now - only the receiver gets more complicated not both receiver and sender. Julo Eddy Quicksall 05/03/2002 11:22 PM Please respond to Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL, "THALER,PAT (A-Roseville,ex1)" cc: andy currid , ips@ece.cmu.edu, owner-ips@ece.cmu.edu, Bill Studenmund Subject: RE: iSCSI: large keys during login? Regarding the following sentence in 9.10.4, can we say the key and equal sign most not be spanned? The reason I ask for this is because it makes the parsing of the key much easier if you don't have it cut into two PDUs. A key=value pair can span Text request or response boundaries (i.e., a key=value pair can start in one PDU and continue on the next). Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, April 29, 2002 8:35 PM To: THALER,PAT (A-Roseville,ex1) Cc: andy currid; ips@ece.cmu.edu; owner-ips@ece.cmu.edu; Bill Studenmund Subject: RE: iSCSI: large keys during login? Pat, For spanning look at 9.10.4 and 9.11.4. I assume that the text covers whatever does not fit. Regards, Julo "THALER,PAT (A-Roseville,ex1)" 04/30/2002 02:24 AM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL, Bill Studenmund cc: andy currid , ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: large keys during login? Julian, I assume you mean that keys can span requests as well. I can't find anything in the draft that says that they can though there also isn't anything that says they can't. Does this only apply to key-value pairs too long to fit in a single response or can a short key-value pair span a request/response when multiple key-value pairs are packed into a PDU? The draft should clarify. -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, April 29, 2002 3:54 PM To: Bill Studenmund Cc: andy currid; ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: large keys during login? Key can span responses. Bookmarking is for things that have multiple answers - like the SendTargets - Julo Bill Studenmund Sent by: owner-ips@ece.cmu.edu 04/30/2002 01:15 AM Please respond to Bill Studenmund To: andy currid cc: Subject: Re: iSCSI: large keys during login? On Mon, 29 Apr 2002, andy currid wrote: > > Hi > > In iSCSI draft 12, chapter 10, the Kerberos and SPKM authentication > mechanisms specify a limit of 64k on their unencoded key values. > > Given that these keys are only used during login and, during login, > the PDU size in use is 8k and, unlike text commands, there is no > bookmarking, how can you send a key value of this size during login? I thought that was covered. If you say you can do kerberos or SPKM, you are saying you can do 64k. Take care, Bill --=_alternative 00505D30C2256BAF_= Content-Type: text/html; charset="us-ascii"
Eddy,

There are many ways to do it. Recall that we had no spanning at all and that was best. But it was not good enough for all values with small PDU's.
The alternative would be to allow at least the sender to lay out data and the send-it out by cutting it in pieces of PDU length without it having to parse.

What you are suggesting requires the sender to build the stream considering the boundaries.

We could go either way but IMHO it is better as we have it now - only the receiver gets more complicated not both receiver and sender.

Julo


Eddy Quicksall <eddyq@ivivity.com>

05/03/2002 11:22 PM
Please respond to Eddy Quicksall

       
        To:        Julian Satran/Haifa/IBM@IBMIL, "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
        cc:        andy currid <andy@windriver.com>, ips@ece.cmu.edu, owner-ips@ece.cmu.edu, Bill Studenmund <wrstuden@wasabisystems.com>
        Subject:        RE: iSCSI: large keys during login?

       


Regarding the following sentence in 9.10.4, can we say the key and equal sign most not be spanned? The reason I ask for this is because it makes the parsing of the key much easier if you don't have it cut into two PDUs.
 

A key=value pair can span Text request or response boundaries (i.e., a

key=value pair can start in one PDU and continue on the next).

 

Eddy

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, April 29, 2002 8:35 PM
To: THALER,PAT (A-Roseville,ex1)
Cc: andy currid; ips@ece.cmu.edu; owner-ips@ece.cmu.edu; Bill Studenmund
Subject: RE: iSCSI: large keys during login?

Pat,

For spanning look at 9.10.4 and 9.11.4.

I assume that the text covers whatever does not fit.


Regards,
Julo

"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>

04/30/2002 02:24 AM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
       To:        Julian Satran/Haifa/IBM@IBMIL, Bill Studenmund <wrstuden@wasabisystems.com>
       cc:        andy currid <andy@windriver.com>, ips@ece.cmu.edu, owner-ips@ece.cmu.edu
       Subject:        RE: iSCSI: large keys during login?

     



Julian,
 
I assume you mean that keys can span requests as well. I can't find anything in the draft that says that they can though there also isn't anything that says they can't. Does this only apply to key-value pairs too long to fit in a single response or can a short key-value pair span a request/response when multiple key-value pairs are packed into a PDU?
 
The draft should clarify.
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, April 29, 2002 3:54 PM
To: Bill Studenmund
Cc: andy currid; ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: large keys during login?


Key can span responses. Bookmarking is for things that have multiple answers - like the SendTargets - Julo
Bill Studenmund <wrstuden@wasabisystems.com>
Sent by: owner-ips@ece.cmu.edu

04/30/2002 01:15 AM
Please respond to Bill Studenmund

       
      To:        andy currid <andy@windriver.com>
      cc:        <ips@ece.cmu.edu>
      Subject:        Re: iSCSI: large keys during login?

     




On Mon, 29 Apr 2002, andy currid wrote:

>
> Hi
>
> In iSCSI draft 12, chapter 10, the Kerberos and SPKM authentication
> mechanisms specify a limit of 64k on their unencoded key values.
>
> Given that these keys are only used during login and, during login,
> the PDU size in use is 8k and, unlike text commands, there is no
> bookmarking, how can you send a key value of this size during login?

I thought that was covered. If you say you can do kerberos or SPKM, you
are saying you can do 64k.

Take care,

Bill

--=_alternative 00505D30C2256BAF_=-- From owner-ips@ece.cmu.edu Sun May 5 17:22:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23751 for ; Sun, 5 May 2002 17:22:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g45KgUW12318 for ips-outgoing; Sun, 5 May 2002 16:42:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g45KgSw12312 for ; Sun, 5 May 2002 16:42:28 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g45KgMPt006374 for ; Sun, 5 May 2002 22:42:22 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g45KgLg100384 for ; Sun, 5 May 2002 22:42:21 +0200 Importance: High Subject: Re: iSCSI: Request to change Logout Request To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sun, 5 May 2002 22:52:10 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/05/2002 23:42:21 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I have looked into it and unfortunately we can't keep everything everywhere in place. CID is bytes 20-21 in Login and Logout (so that the TTT place can't be kept everywhere). We could move the reason (function) in byte 1 (as it is in most requests). If nobody shouts loudly against this we might do move reason (function) into byte 1 Julo ----- Forwarded by Julian Satran/Haifa/IBM on 05/05/2002 10:46 PM ----- Julian Satran To: Jarda Beran 05/02/2002 03:45 cc: ips@ece.cmu.edu PM From: Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI: Request to change Logout Request(Document link: Julian Satran - Mail) I will look into it - Julo Jarda Beran cc: ips@ece.cmu.edu Subject: iSCSI: Request to change Logout Request 05/02/2002 11:21 AM Please respond to Jarda Beran Hello Julian, Can I make a request to change the position of the field "Reason code" in the Logout Request from offset 23 to 3. This change would make the PDU consistent with others and make decoding simpler as most PDUs have fields "Reason" or "Response" at offset 3. As you know offsets 20-23 are usually used for "Target Transfer Tag", except "Expected Data Transfer Length" in the SCSI command (it have no reserved fields) and "CID" for Login/Logout requests. I think that "CID" could be placed e.g. at offset 40 as an "additional" parameter. Regards, Jarda ------- Jarda Beran Software Engineer Silicon & Software Systems Safrankova 1 155 00 Praha 5 Czech Republic From owner-ips@ece.cmu.edu Sun May 5 17:27:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23791 for ; Sun, 5 May 2002 17:27:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g45KgO812303 for ips-outgoing; Sun, 5 May 2002 16:42:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g45KgMw12294; Sun, 5 May 2002 16:42:22 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g45KgFPR011536; Sun, 5 May 2002 22:42:15 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g45KgEg32876; Sun, 5 May 2002 22:42:14 +0200 Subject: Re: Comments on v12 of iSCSI Specification To: "BARRY,BOB (HP-Roseville,ex1)" Cc: "'ips@ece.cmu.edu'" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sun, 5 May 2002 22:32:48 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/05/2002 23:42:14 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Thanks for tanking your time to do such a thorough review. my comments in text -Thanks again - Julo "BARRY,BOB (HP-Roseville,ex1 To: "'ips@ece.cmu.edu'" )" cc: Sent by: owner-ips@ece.cmu .edu 05/03/2002 08:03 PM Please respond to "BARRY,BOB (HP-Roseville,ex1 )" The following comments are submitted against the April 17, 2002, draft-ietf-ips-iSCSI-12.txt. Bob Barry ==================================================== General Comments 1) An acronym section would make it easier to read this document. Acronyms such as SW for session wide, IO for initialize-only, and others are not immediately obvious. +++ If you volunteer to do it, I will volunteer to review it and add it with proper acknowledgements +++ 2) A copyright notice be part of this document. +++ There is one on the last page as customary for RFCs +++ 3) In chapter 9, each PDU should have a complete description provided. Yes, this means a duplication of the field descriptions, but having to search back in the document to find field meanings does not make sense. +++ NO - it will add too much volume and no additional meaning +++ 4) Each table should be numbered and titled. Currently, there is no way to reference an individual table, accept a page number which may change over revisions. +++ All references - are made with a tool that takes care of it. 5) Either "data is" or "data are" are considered correct for technical documentation, however, only one should be used in a document for consistency. Examples: p 35: last paragraph, first line "data is" p 36: third paragraph, first line "data are" p 36: third paragraph, third line "data are" p 36: seventh paragraph, fourth line "data is" +++ fixed +++ 6) Word "since" used instead of "because". "Since" implies a temporal relationship, "because" implies a cause-effect" relationship. Some examples p 31: third paragraph from bottom, first line; p 37: last paragraph, second line; p 44: second paragraph, seventh line; p 47: last paragraph, third line p 108: second paragraph, second line p 111: first paragraph after bullet item, first line +++ fixed +++ p 141: bullet item c) in upper list 6) The word "null" is used throughout this document to mean "zero", or "zero valued". This needs to be clearly stated. +++ I think that this is common in computing but I will see where I can add something +++ Comments regarding draft contents 1) p 22: "iSCSI Initiator Node" and "iSCSI Target Node" are circular and provide no insight into what is being defined. +++ what do you suggest? The notions hep us map iSCSI architecurally to SCSI +++ 2) p 31: second paragraph, third line: "from ExpCmdSN to MaxCmdSN" should be "from ExpCmdSN to MaxCmdSN inclusive"; or "in the closed interval [ ExpCmdSN . . MaxCmdSN ]" +++ fixed +++ 3) p 31: second paragraph, sixth line, how the parathesized example applies to the preceding sentence is not immediately obvous. +++ wht do you suggest? +++ 4) p 31: last paragraph, last 2 lines: use of the words "and" and "or" could be ambiguously interpreted. +++ I reread it twice - and the parsing is obvious +++ 5) p 34: second paragraph, line 3: "the TSIH is null". The word "null" should be replaced with "equal to zero". +++ null is commonly used and its meaning is clear in the context. However, I will replace it in this instance+++ 6) p 36: third paragraph, third line: the sentence ends right in the middle; need to complete the thought. +++ I can't locate it - context would help ++ 7) p 37: second paragraph: "Unsolicited data MUST be sent on every connection in the same order in which commands are sent." This sentence needs better wording to get the intended point. +++ It is clear to me and my friends. If you have a suggestion please make it explicit Better is unbounded :-). +++ 8) p 39: item c) in list: where are "displayable" and and "whitespace" characters defined? +++ The common meanings are well understood that is why they appear in requirements (i have removed the MUST from this part of the text the normative text follows in the encoding part. Precise references are stringprep, and mime. +++ 9) p 50: item e), some of the references to "Node" should be references to "Entity". +++ which ones ? +++ 10) p 52: last paragraph, fifth bullet item: "3 null bytes". The word "null" should be replaced with "zero". +++ that is the log of changes part +++ 11) p 63: third paragraph of 4.1, last line: "(comma or null)" should be "(comma or zero byte)" +++ OK +++ 12) p 72: fourth paragraph, second line: does the phrase "MUST be sent after the parameters" mean later in the current request, or could they be sent in a later request. The same comment can be applied on p 75, paragaph 4. +++ either - by omission +++ 13) p 72: fifth paragraph, second line: "a null TSIH" should be "a zero-valued TSIH" +++ OK +++ 14) p 78: in the state table, it appears that exit from S8 is impossible. Actually, this is explained on p 84. An explanation of what is going on on p 78 would be helpful. The same can be said of the state table on p 80. +++ It is just the internal activity and/or time that makess the transition out of S8 not an even of interest to iSCSI. Hard to show any of those in a crowded ASCII table or figure and the text is clear. +++ 15) p 118: section 9 - why are some bits marked as reserved and some marked as '0' or '1' in the PDU definitions. If the bits marked as '0' or '1' in the PDUs will never change, then this needs to be stated. In other words, there are not treated the same as reserved bits. +++ ??? +++ 16) p 122 and 123: why doesn't AHS-Specific data begin on a 4-byte boundary? Doesn't this lead to an extra operation when using the AHSLength? +++ 4 byte boundaries are somewhat artificial - no boundary is needed on the wire. We introduced it when frame markers where introduced marker and we use it only when strictly necessary +++ 17) p 147: it should be explicitly stated that the O and U bits are valid only of the S bit is 1. +++ added it - although the statement about usage indicates affinity to SCSI response +++ 18) p 150: first paragraph, last line: the requirement should be a MUST, not a SHOULD; it is not obvious what an initiator should do if a transfer length of 0 is received. If the SHOULD requirement is maintained, then explain what is an initiator to do with an R2T containing a zero transfer length. +++ fixed +++ 19) p 152: for code 1 -- "Close the connection" (if not the only connection) OR "Close the session" to close all connections -- What must be sent for a single connection session? +++ if you do not intend to close the session send "close connection" and then you are free (within the llowed time) to login on a new connection. If you close the session the session is gone. +++ 20) p 155: second paragraph: the requirement of MUST with the current wording requires that one text request must be outstanding at any given time. This requirement should be MAY, or the wording changed to "An initiator MUST have at most one outstanding Text Request on a connection at any given time." +++ fixed +++ 21) p 156 (and other areas): next to last paragraph beginning with "A target MAY reset its internal state". What should it be reset to, the original or default settings, the previous state prior to this sequence of text requests, or ... A similar reference is made on p 159 in each of the last 2 paragraphs. Doesn't it say somewhere in the spec something about a stateless exchange? If so, what state are you talking about? +++ the current negotiation state - (related to the current ITT) I will state that ++ 22) p 162: section 9.12.4: in this section, the version of the current draft is defined. Shouldn't this info be in a more obvious location in the draft? How would someone reading this spec know to come to this section to find out this info? +++ It is only for the login to state the version. I will add this to the front matter +++ Formatting and wording issues 1) p 26: second paragraph, last line: is the phase 'an individual I/O device is called a "logical unit" LU' consistent with the definition of "CSSI device" earlier in the document. +++ NO - for details see SAM This paragraph is meant as an level setting for an overvie the SCSI Device is a formal element in SCSI lingo+++ 2) p 27: first paragraph of 2.2, fourth line, "the request response mechanism" should be "the request-response mechanism". +++ fixed +++ 3) p 28: paragraph preceding section 2.2.2, last sentence, "For error recovery purposes, targets ... during recovery" contains some redundancy. Remove the words "during recovery" from the end of the sentence. +++ the statement stresses tha 2 connection may have to be supported ONLY during recovery +++ 4) p 34: third paragraph, third line: the phrase "later in this part" is used. What is the "part" that is being referenced? +++ section - fixed +++ 5) p 35: second paragraph, third line: the use of the phrase "by default" implies a non-default behavior. This phrase should be deleted. +++ fixed +++ 6) p 36: last paragraph, third line, does the phrase "these tags" refer to initiator tags or target tags? The current wording could be ambiguous. +++ fixed - target tags +++ 7) p 39: item c) in list, fourth line: "would be identical except for their case" could be "are case sensitive". +++ fixed removed also MUSTs as this part is a requirement description part not an encoding norm +++ 8) p 39: third paragraph from bottom, fourth line: "NIC or HBA card". The word "card" is redundant. +++ fixed +++ 9) p 53: first paragraph after section 2.4.3, last line: "with a given session" should be "with the same session". +++ fixed +++ 10) p 54: last paragraph, first line: "via one iSCSI node" should be "via one iSCSI target node" +++ fixed +++ 11) p 66: last paragraph, fifth line: "key=value pair TargetName" What does this mean? +++ I've made it TargetName key=value pair. Is this better? +++ 12) p 82: for -T6 and -T7: the individual cases should be maintained in a table-like list, or at least separated by semi-colons. -T15, T16 on page 83 has a nice table- like list. Why not use this format for consistency. +++ did i prompted by an earlier mail +++ 13) p 97: after last paragraph: formatting (indentation) would assist in understanding. - item a) additional blanks near end of first line - between item a) and i), there is an extra '-' - at end of ii), the "[OR]" should refer to a) or b), however, the placement could indicate ii) or b). This could lead to an ambiguous interpretation. +++ fixed (I think :-) +++ 14) p 104: bullet item near top beginning with "- N.B. The logout". Should this bullet item be here? +++ fixed +++ 15) p 108: first and third paragraphs, first line in each: paragraph begins with "With this mechanism". What do you mean? Yes, I know, but you need to say it. :-) +++ fixed +++ 16) p 108: third paragraph, line 4: the sentence ends in the middle: "received in clear" +++ does not look this way to me - it says that without IPsec .... +++ 17) p 118: section 9.2, first paragraph "may" should be capitalized, similarly in second paragraph, second line. +++ fixed +++ 18) p 119: first paragraph, last line "SHOULD be sent as 0" should be "SHOULD be set to zero". Also, why is SHOULD used here instead of MUST? +++ sent means on the wire and as the receiver must not check them we felt SHOULD is enough +++ 19) p 125: in SCSI Command PDU, very last field: "(DataSegment - Command Data + Data Digest (if any))" should be "(DataSegment or Command Data, Data Digest) (if any)" +++ fixed ++ 20) p 126: paragraph preceding 9.3.2: "Expected Data Transfer Lengths are" should be "Expected Data Transfer Length and Bidirectional Read Expected Data Transfer Length are" +++ it said Lenths - but I made it explicit as you suggested ++++ 21) p 144: last paragraph on page, line 5: "in this later case" should be "in this latter case". +++ fixed - I will suggest we write the next RFC in Hebrew - at list spelling is simpler :-) +++ 22) p 153: last paragraph: "Data Segment" should be "DataSegment". +++ fixed +++ 23) p 155: last paragraph: the word "commands" should be replaced by "Text Requests" +++ fixed +++ 24) p 162: the list in the middle of the page: why was the number 2 skipped in numbering the items in this list? +++ just a coding choice - it is not a bullet number - but a code ++ 25) p 164: next to last line: "All login requests within the login phase" should be "All login requests within a login phase". +++ fixed +++ 26) p 182: third paragraph, second line: should the "must" be capitalized? +++ more of a SCSI requirement but I have capitalized it +++ 27) p 184: last line: "Data Segment Length" should be "DataSegmentLength" +++ fixed +++ 28) p 188: the info below the table at the top of the page should be incorporated into the table. +++ fixed +++ 29) p 188: last paragraph, first line: "the target MUST answer" could be "the target MUST respond" (keeping with the language of the spec. +++ fixed +++ 30) p 193: section 11, this info would be nice in a table, and also in an acronym table. +++ are you volunteering ? +++ 31) p 198, 199, 200, 203, 203: what do Result function is OR and Result function is AND mean? +++ means that the result an AND or OR boolean function of the offer and what the responder would have to say +++ 32) p 200: third paragraph, last line "MUST reject them with". What does "them" refer to? +++ I've replaced them with unsolicited data +++ 33) p 201: Third paragraph "This is a connection specific parameter". This statement is redundant because the scope is CO. +++ removed +++ 34) p 201: last paragraph of section 11.14: what "two numbers" are being referenced? Same question can be asked on p 202, second paragraph from top, and also in section 11.16, second last paragraph. +++ Great - this was from the time when selection was done by "observer" not responder. I have changed it to: The responder MUST select a value that does not exceed the offered value. ++++ Simple issues 1) p 24: last paragraph, second line, "session ID that is tuple" should be session ID that is a tuple". +++ fixed +++ 2) p 25: definition of "SCSI Port Name", get rid of the word "basically". Use of this adverb implies there are additional items that make up the name. +++ fixed +++ 3) p 25: definition of "TSIH", third line, change "the target is generating" to "the target generates". +++ fixed +++ 4) p 32: section 2.2.2.2, first paragraph, line 5: "32bit" should be "32-bit" (the '-' could be a blank). +++ fixed +++ 5) p 35: third paragraph, second line: "the status for a command" should be "the status for the command" +++ fixed +++ 6) p 55: last paragraph, need a blank line between paragraphs. +++ fixed +++ 7) p 56: third paragraph, last 2 lines (occurs twice): "at target" should be "at the target". +++ fixed +++ 8) p 56: third paragraph, second line: "Data-In PDU" should be "Data-In PDUs". +++ fixed +++ 9) p 57: last paragraph, third line: "status indicated termination" should be "statue indicates termination". +++ fixed +++ 10) p 60: first paagraph after 2.5.3.4, fourth line: "the type is indicate in" should be "the type is indicated in" +++ fixed +++ 11) p 63: second paragraph, next to last line: "range is a a set" should be "range is a set". +++ text changed +++ 12) P 64: fifth paragraph, second line: "a single literal constant a Boolean value" should be "a single literal constand, a Boolean value". +++ text changed +++ 13) p 65: after first paragraph there is an extra blank line. +++ text changed +++ 14) p 68: paragraph preceding 4.3.1, second line: period '.' missing after "once during login". +++ fixed +++ 15) p 73: fourth paragraph, first line: "implicit logout connection reinstatement is" should be "implicit logout connection, reinstatement is" +++ fixed +++ 16) p 74: first paragraph before 4.3.6, last line: there is some garbage at the end of the paragraph. +++ fixed +++ 17) p 82: for transition -T8, second line: "on a another connection" should be "on another connection" +++ fixed +++ 18) p 93: First paragraph, fifth line: "assumed that at target" should be "assumed that at the targer" +++ fixed +++ 19) p 95: throughout the text, words like "Reject" is used in referring to a PDU type. The problem is the use of the plural "Rejects"; this would be better written as "Reject's". +++ fixed only 2 occurences! +++ 20) p 96: first paragraph after 6.3.2, third line: "(section 9.15)in" should be "section 9.15) in". +++ fixed +++ 21) page 100: second paragraph after 6.9, second line: "errors can be only be" should be "errors can only be" +++ fixed +++ 22) p 104: third line on page: "not received for a response" should be "not received a response". +++ fixed +++ 23) p 105: bullet item b) near top of page, last line: "in resource requirement" should be "in resource requirements". +++ fixed +++ 24) p 107: first paragraph, fourth line: "via a subnet distinctly" could be "via a SAN distinctly". +++ fixed +++ 25) p 107: first paragraph, line line 6: "such as SCSI, over IP networks requires" should be "such as SCSI over IP, requires" +++ I've made it IP-networks to disambiguate +++ 26) p 108: after paragraph 4, there is an extra blank line +++ removed +++ 27) p 108: sixth paragraph, fourth line: it looks like an extra was added at the end of this line. +++ removed +++ 28) p 113: first paragraph after 8.1.2, first line: it looks like an extra was added at the end of this line. +++ fixed +++ 29) p 114: third paragraph, second line: it looks like an extra was added at the end of this line. +++ fixed +++ 30) p 115: first paragraph after 8.3, fourth line: "acknowledgements etc.)" should be "acknowledgements, etc.)" +++ fixed +++ 31) p 122: section 9.2.1.7, first paragraph, second line: "identify it" should be "identify the task". +++ fixed +++ 32) p 128: last line of page: "the b Bidirectional" should be "the Bidirectional". +++ fixed +++ 33) p 129: for bit 5 at the top, third line: "Transfer length" should be "Transfer Length". +++ fixed +++ 34) p 129: for bit 6 at the top, third line: "bytes that expected to be" should be "bytes that were expected to be". +++ fixed +++ 35) p 130: third line from top of page, "sequence, before" should be "sequence before" +++ fixed +++ 36) p 130: third line from bottom of page: use "greater than" rather than "higher than". "Higher" could imply some level of positioning +++ fixed +++ 37) p 134: the fields in the number list at the bottom of the page should be lined up. +++ I will try to make clear that it is a list of codes and not a table with fields +++ 38) p 138: why is this page blank? +++ fixed +++ 39) p 145: second paragraph of 9.7.3, third line: "SNACK of, type " should be "SNACK of type". +++ fixed +++ 40) p 147: last paragraph: "and they values are as define in" should +++ fixed +++ be "and the values are as defined in" 41) p 151: PDU diagram, align the right side +++ tool problem +++ 42) p 154: PDU diagram, align the right side +++ tool problem +++ 43) p 156: first paragraph, first line: it looks like an extra was added at the end of this line. +++ fixed +++ 44) p 159: section 9.11.2, first line: "initial Text request" should be "initial Text Request". Similarly, in last paragraph, second line, "Text request" should be "Text Request". +++ fixed +++ 45) p 162: section 9.12.2, first paragraph, next to last line, it looks like an extra was added at the end of this line. +++ fixed +++ 46) p 164: section 9.12.6, first paragraph, fifth line: "to the target, the associated" should be "to the target the associated" +++ fixed +++ 47) p 165: last paragraph: missing a blank line after line 3. +++ fixed +++ 48) p 165:last paragraph: "Keys in Chapter 10, only need" should be "Keys in Chapter 10 only need" +++ fixed +++ 49) p 167: section 9.13.3, fifth line: "andd" should be "and". +++ fixed +++ 50) p 169: for codes 0101 and 0201, remove the in the description fields. +++ ???? +++ 51) p 178: first 2 paragraphs: what do "its" refer to -- "its flags" +++ the two paragraphs read now: The numbered-response(s) or R2T(s), requested by a SNACK, MUST be delivered as exact replicas of the ones the initiator missed except for the fields ExpCmdSN, MaxCmdSN and ExpDataSN which MUST carry the current values. The numbered Data-In PDUs, requested by a SNACK with a RunLength dif-ferent from 0, MUST be delivered as exact replicas of the ones the initiator missed except the fields ExpCmdSN and MaxCmdSN which MUST carry the current values. Data-In PDUs requested with RunLength 0 (meaning all PDUs after this number) may be different from the ones originally sent, in order to reflect changes in MaxRecvPDULength. ++++ 52) p 179: section 9.16.3, second paragraph, second line: "or greater to BegRun" should be "or greater than BegRun" +++ fixed +++ 53) p 181: code 0x04 in table, the explanation for this code is missing a right paren at the end. +++ fixed +++ 54) p 186: second paragraph, first line: "When a target send a NOP-In" should be When a target sends a NOP-In". +++ fixed +++ 55) p 193: bottom: position entire table on one page. +++ done +++ 56) p 196: missing blank line between paragraphs at top of page. +++ fixed +++ 57) p 199: first paragraph on top of page, it looks like an extra was added in the middle. +++ fixed +++ 58) p 201: section 11.14, second to last paragraph, second line: "bytes in an Data-In" should be "bytes in a Data-In". Also, the last phrase in this paragraph is not a sentence. +++ fixed +++ 59) p 201: last line of page: "to the target, during the" should be "to the target during the +++ fixed +++ From owner-ips@ece.cmu.edu Mon May 6 10:24:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20824 for ; Mon, 6 May 2002 10:24:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g46DiLV14962 for ips-outgoing; Mon, 6 May 2002 09:44:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g46DiJw14956 for ; Mon, 6 May 2002 09:44:19 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g46DiDM17288 for ; Mon, 6 May 2002 09:44:13 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g46DiDX17279; Mon, 6 May 2002 09:44:13 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g46DiCO27526; Mon, 6 May 2002 09:44:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15574.34989.880000.685139@gargle.gargle.HOWL> Date: Mon, 6 May 2002 09:44:13 -0400 From: Paul Koning To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Request to change Logout Request References: X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 5 May 2002) by Julian Satran: > I have looked into it and unfortunately we can't keep everything everywhere > in place. > > CID is bytes 20-21 in Login and Logout (so that the TTT place can't be kept > everywhere). > > We could move the reason (function) in byte 1 (as it is in most requests). > > If nobody shouts loudly against this we might do move reason (function) > into byte 1 I don't like that at all. "Function" is not anything like "Reason". "Last call" is the time to fix BUGS in the spec. This isn't a bug. Let's stop changing things for the sake of esthetics, or other similar non-bug reasons. paul From owner-ips@ece.cmu.edu Mon May 6 10:25:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20878 for ; Mon, 6 May 2002 10:25:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g46E6wQ16687 for ips-outgoing; Mon, 6 May 2002 10:06:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g46E6sw16679 for ; Mon, 6 May 2002 10:06:54 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g46E6sXt057585 for ; Mon, 6 May 2002 10:06:54 -0400 (EDT) Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g46E6lo56779 for ; Mon, 6 May 2002 10:06:48 -0400 (EDT) Received: from research.bell-labs.com (philmac-pcmh1.research.bell-labs.com [135.104.54.81]) by aura.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g46E6lx6012337 for ; Mon, 6 May 2002 10:06:47 -0400 (EDT) Message-ID: <3CD691B3.60804@research.bell-labs.com> Date: Mon, 06 May 2002 10:22:43 -0400 From: Philip MacKenzie Organization: Bell Labs, Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 CC: ips@ece.cmu.edu Subject: PAK: New Internet Draft available References: <200205021217.IAA17150@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The internet draft on PAK is now available: http://www.ietf.org/internet-drafts/draft-mackenzie-ips-iscsi-pak-00.txt -Phil From owner-ips@ece.cmu.edu Mon May 6 11:10:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22968 for ; Mon, 6 May 2002 11:10:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g46ETt718484 for ips-outgoing; Mon, 6 May 2002 10:29:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2aa.compuserve.com (siaar2aa.compuserve.com [149.174.40.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g46ETqw18478 for ; Mon, 6 May 2002 10:29:52 -0400 (EDT) Received: (from mailgate@localhost) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id KAA11258 for ips@ece.cmu.edu; Mon, 6 May 2002 10:29:46 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkd-vty32.as.wcom.net [206.175.233.32]) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id KAA11187; Mon, 6 May 2002 10:29:43 -0400 (EDT) Message-ID: <3CD691B0.52486D27@compuserve.com> Date: Mon, 06 May 2002 09:22:40 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu CC: "Mallikarjun C." Subject: Re: FCIP: Comment 109 References: <00d601c1f313$5c64c280$edd52b0f@rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallikarjun, > ... - could you please comment on whether or not CRC protection > is available on FCIP headers and help me with a reference if so? CRC protection is prohibited for FCIP headers as per following two statements in 6.6.1: "The CRCV (CRC Valid) Flag SHALL be set to 0." "The CRC field SHALL be set to 0." It is further worth noting that the error detection algorithms described in 6.6.2.2 include no provisions for the use of CRCs but do describe a through FCIP header validation mechanism based on redundancy. The recommendation that CRC be used for FCIP headers has been considered and rejected in the past. The preference for redundancy validation of FCIP headers is partially described in the FC Encapsulation draft section 3.2.1. "Header validation based on redundancy is a stepwise process in that the first word is validated, then the second, then the third and so on. A decision that a candidate header is not valid may be reached before the complete header is available." It should be noted that the Fibre Channel requirements for usage of its CRC are such that the usage of CRC by FCIP would constitute the only requirement for CRC hardware in an FCIP device. Interoperability concerns dictate that FCIP must either mandate or prohibit use of CRC, so CRC usage is prohibited. Thanks. .Ralph "Mallikarjun C." wrote: > > Ralph, > > > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.pdf > .... > > Please review these comments resolutions to ensure that > > the desired changes are described. > > Sorry for the delayed review, I have additional comments on wglc-01 > for Comment 109. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > >>Comment 109 Technical > >> 6.6.1 FCIP Encapsulation of FC Frames > >.... > >> The CRCV (CRC Valid) Flag SHALL be set to 0. > >> > >> The CRC field SHALL be set to 0. > >I am surprised that the FCIP encapsulated header is never protected > >by a CRC. The error detection section clearly acknowledges the > >possibility that TCP checksum could be inadequate for certain > >deployments - and even suggests checking the FC frame CRC (sort > >of like a data digest) on reception at the Encapsulated Frame > >Receiver Portal. > >My recommendation is to require an FCIP Entity to employ the header > >CRC if the SF that it receives asks for CRC - IOW, similar to iSCSI's > >approach. So, I guess I am also advocating a new bit in the pFlags > >field to announce this. When this CRC expectation is announced, the > >FC CRC checking test in 6.6.2.2 should also be a mandatory test -from > >the "semi-optional" list it is currently in. > >Accepted with the following result > >Add the following to the new section created in response to comment > >44: "Note: Owing to the limited manner in which the FSF is used and > >the requirement that the FSF be echoed without changes before a TCP > >connection is allowed to carry user data, no error checking beyond > >that provided by TCP is deemed necessary." > > Sorry, I missed the earlier discussion on this comment. > > My comment was for __all__ FCIP encapsulated headers on all FCIP > Frames - not just for FSF. The reference to FSF in my comment was > to suggest how an "I want CRC" demand be communicated at the FCIP > Link establishment time - i.e. the reference was a solution strawman. > > I probably missed something critical - could you please comment on > whether or not CRC protection is available on FCIP headers and > help me with a reference if so? From owner-ips@ece.cmu.edu Mon May 6 11:13:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23093 for ; Mon, 6 May 2002 11:13:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g46EU1u18499 for ips-outgoing; Mon, 6 May 2002 10:30:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2aa.compuserve.com (siaar2aa.compuserve.com [149.174.40.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g46ETuw18488 for ; Mon, 6 May 2002 10:29:57 -0400 (EDT) Received: (from mailgate@localhost) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id KAA11292 for ips@ece.cmu.edu; Mon, 6 May 2002 10:29:51 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkd-vty32.as.wcom.net [206.175.233.32]) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id KAA11264; Mon, 6 May 2002 10:29:46 -0400 (EDT) Message-ID: <3CD694BC.E01A5A32@compuserve.com> Date: Mon, 06 May 2002 09:35:40 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu CC: "Mallikarjun C." Subject: Re: FCIP: Comment 120 References: <00ca01c1f313$0296ccd0$edd52b0f@rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallikarjun, > >... the "FC/FCIP Entity Identifier" is unique only within the scope > >of the given FC Entity's WWN. ... the model allows multiple FCIP > >Entities to be associated with the FC Fabric Entity WWN. > > If that is so, please add an architectural model diagram (similar to > Figure 3, or perhaps convert Figure 3 into) which clearly shows this > 1-to-n association. > > This is the only hint in the document (at least that I found) which > suggests the stated possibility. Figure 3 with 1-to-1 association almost > seemed like the architectural model, but on careful reading, is only > an example. The fact that the "FC/FCIP Entity Identifier" is unique only within the scope of a given FC Entity's WWN seems to be clearly stated in the definition of the field: "The Source FC/FCIP Entity Identifier field SHALL contain a unique identifier for the FC Entity FCIP Entity pair that generates (as opposed to echoes) the Special Frame. The value is assigned by the FC Fabric entity whose world wide name appears in the Source FC Fabric Entity World Wide Name field. "Note: The combination of the Source FC Entity World Wide Name and Source FCIP Entity Identifier fields uniquely identifies every FC Entity FCIP Entity pair in the IP Network." The requested figure relies on Fibre Channel concepts and thus appears in a T11 document, FC-BB-2, ftp://ftp.t11.org/t11/pub/fc/bb-2/02-030v1.pdf. See Figure 23 on PDF page 87, or Figure 26 on PDF page 94. Thanks. .Ralph "Mallikarjun C." wrote: > > Ralph, > > > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.pdf > .... > > Please review these comments resolutions to ensure that > > the desired changes are described. > > Sorry for the delayed review, I have additional comments on wglc-01 > for Comment 120. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > >Comment 120 > >> 8. The FCIP Special Frame > >...... > >> Note: The combination of the Source FC Entity World Wide Name and > >> Source FCIP Entity Identifier fields uniquely identifies every FC > >> Entity FCIP Entity pair in the IP Network. > >.... > >- Also I take it that the "FC/FCIP Entity Identifier" is unique only > >within the scope of the given FC Entity's WWN. So, does the model > >allow multiple FCIP Entities to be associated with the FC Fabric > >Entity WWN? > >.... > >Response to the second bullet: Yes, the "FC/FCIP Entity Identifier" > >is unique only within the scope of the given FC Entity's WWN. Yes, > >the model allows multiple FCIP Entities to be associated with the FC > >Fabric Entity WWN. > > > > If that is so, please add an architectural model diagram (similar to > Figure 3, or perhaps convert Figure 3 into) which clearly shows this > 1-to-n association. > > This is the only hint in the document (at least that I found) which > suggests the stated possibility. Figure 3 with 1-to-1 association almost > seemed like the architectural model, but on careful reading, is only > an example. From owner-ips@ece.cmu.edu Mon May 6 11:13:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23080 for ; Mon, 6 May 2002 11:12:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g46EZaw18955 for ips-outgoing; Mon, 6 May 2002 10:35:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2aa.compuserve.com (siaar2aa.compuserve.com [149.174.40.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g46EZVw18945 for ; Mon, 6 May 2002 10:35:31 -0400 (EDT) Received: (from mailgate@localhost) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id KAA16094 for ips@ece.cmu.edu; Mon, 6 May 2002 10:35:26 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkd-vty32.as.wcom.net [206.175.233.32]) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id KAA15816; Mon, 6 May 2002 10:35:14 -0400 (EDT) Message-ID: <3CD69618.2BC1ADF2@compuserve.com> Date: Mon, 06 May 2002 09:41:28 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu CC: "Mallikarjun C." Subject: Re: FCIP: Comment 125 References: <00d001c1f313$39de4240$edd52b0f@rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallikarjun, > OK, but I don't see how is this distinction may be made use of by the > receiver. IIRC, any comparison failure (Ch bit or not) leads to a > connection drop. Is Ch bit then intended only for diagnostics? If the Ch bit is zero, the poor-man's SLP receiver cannot inspect the contents of the Destination FC Fabric Entity World Wide Name field to determine the correct Destination FC Fabric Entity World Wide Name value. If the Ch bit is one, the poor-man's SLP receiver can inspect the contents of the Destination FC Fabric Entity World Wide Name field to determine the correct Destination FC Fabric Entity World Wide Name value. As David has pointed out, the FC Fabric Entity World Wide Name value determined in this was is itself subject to potential corruption. However, the only result of that corruption is that the subsequent connection setup will fail because the FC Fabric Entity World Wide Name will be wrong. Thanks. .Ralph "Mallikarjun C." wrote: > > Ralph, > > > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.pdf > .... > > Please review these comments resolutions to ensure that > > the desired changes are described. > > Sorry for the delayed review, I have additional comments on wglc-01 > for Comment 125. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > >Comment 125 > >> 9.1.2.3 Connection Setup After a Successful TCP Connect Request > >...... > >> If the echoed FCIP Special Frame bytes do not exactly match the > >> FCIP Special Frame bytes sent (words 7 through 17 inclusive), the > >> FCIP Entity SHALL close the TCP Connection and notify the FC > >> Entity with the reason for the closure. > >Seems like all the 11 words are required to be compared. If so, what > >is the Ch bit being used for? IOW, why SHALL it be set by the > >responder? > >Inquiry > >The Ch bit serves to identify the difference between changes > >made intentionally by the echoing FCIP Entity and changes that > >result from transmission errors. > > OK, but I don't see how is this distinction may be made use of by the > receiver. IIRC, any comparison failure (Ch bit or not) leads to a > connection drop. Is Ch bit then intended only for diagnostics? From owner-ips@ece.cmu.edu Mon May 6 14:27:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01476 for ; Mon, 6 May 2002 14:27:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g46I91A05894 for ips-outgoing; Mon, 6 May 2002 14:09:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g46I8ww05886 for ; Mon, 6 May 2002 14:08:58 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel9.hp.com (Postfix) with ESMTP id EFB978050ED; Mon, 6 May 2002 14:08:52 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id LAA21844; Mon, 6 May 2002 11:10:37 -0700 (PDT) Message-ID: <005b01c1f529$1427c720$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , References: <00d601c1f313$5c64c280$edd52b0f@rose.hp.com> <3CD691B0.52486D27@compuserve.com> Subject: Re: FCIP: Comment 109 Date: Mon, 6 May 2002 11:08:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, > Interoperability concerns dictate that FCIP must either mandate > or prohibit use of CRC, Or adopt a must-implement-may-use policy with the FSF indicating the choice - which was my strawman. I was about to be completely satisfied about the redundancy, but I see that with the exception of Timestamp - all other fields are redundant. If the corruption probability of timestamp (with attendant side effects) is considered insignificant by everyone else, I wouldn't press this. Perhaps it is worth noting the lack of redundancy for timestamp and leaving it there. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Ralph Weber" To: Cc: "Mallikarjun C." Sent: Monday, May 06, 2002 7:22 AM Subject: Re: FCIP: Comment 109 > Mallikarjun, > > > ... - could you please comment on whether or not CRC protection > > is available on FCIP headers and help me with a reference if so? > > CRC protection is prohibited for FCIP headers as per following > two statements in 6.6.1: > > "The CRCV (CRC Valid) Flag SHALL be set to 0." > "The CRC field SHALL be set to 0." > > It is further worth noting that the error detection algorithms > described in 6.6.2.2 include no provisions for the use of CRCs > but do describe a through FCIP header validation mechanism > based on redundancy. > > The recommendation that CRC be used for FCIP headers has been > considered and rejected in the past. The preference for > redundancy validation of FCIP headers is partially described > in the FC Encapsulation draft section 3.2.1. > > "Header validation based on redundancy is a stepwise process > in that the first word is validated, then the second, then > the third and so on. A decision that a candidate header is > not valid may be reached before the complete header is > available." > > It should be noted that the Fibre Channel requirements for usage > of its CRC are such that the usage of CRC by FCIP would constitute > the only requirement for CRC hardware in an FCIP device. > > Interoperability concerns dictate that FCIP must either mandate > or prohibit use of CRC, so CRC usage is prohibited. > > Thanks. > > .Ralph > > "Mallikarjun C." wrote: > > > > > Ralph, > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.pdf > > .... > > > Please review these comments resolutions to ensure that > > > the desired changes are described. > > > > Sorry for the delayed review, I have additional comments on wglc-01 > > for Comment 109. > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > >>Comment 109 Technical > > >> 6.6.1 FCIP Encapsulation of FC Frames > > >.... > > >> The CRCV (CRC Valid) Flag SHALL be set to 0. > > >> > > >> The CRC field SHALL be set to 0. > > >I am surprised that the FCIP encapsulated header is never protected > > >by a CRC. The error detection section clearly acknowledges the > > >possibility that TCP checksum could be inadequate for certain > > >deployments - and even suggests checking the FC frame CRC (sort > > >of like a data digest) on reception at the Encapsulated Frame > > >Receiver Portal. > > >My recommendation is to require an FCIP Entity to employ the header > > >CRC if the SF that it receives asks for CRC - IOW, similar to iSCSI's > > >approach. So, I guess I am also advocating a new bit in the pFlags > > >field to announce this. When this CRC expectation is announced, the > > >FC CRC checking test in 6.6.2.2 should also be a mandatory test -from > > >the "semi-optional" list it is currently in. > > >Accepted with the following result > > >Add the following to the new section created in response to comment > > >44: "Note: Owing to the limited manner in which the FSF is used and > > >the requirement that the FSF be echoed without changes before a TCP > > >connection is allowed to carry user data, no error checking beyond > > >that provided by TCP is deemed necessary." > > > > Sorry, I missed the earlier discussion on this comment. > > > > My comment was for __all__ FCIP encapsulated headers on all FCIP > > Frames - not just for FSF. The reference to FSF in my comment was > > to suggest how an "I want CRC" demand be communicated at the FCIP > > Link establishment time - i.e. the reference was a solution strawman. > > > > I probably missed something critical - could you please comment on > > whether or not CRC protection is available on FCIP headers and > > help me with a reference if so? > > > From owner-ips@ece.cmu.edu Mon May 6 14:29:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01598 for ; Mon, 6 May 2002 14:29:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g46I2ND05328 for ips-outgoing; Mon, 6 May 2002 14:02:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g46I2Kw05318; Mon, 6 May 2002 14:02:20 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id E4D2530706; Mon, 6 May 2002 14:02:19 -0400 (EDT) Date: Mon, 6 May 2002 11:01:08 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Eddy Quicksall , andy currid , , , "THALER,PAT (A-Roseville,ex1)" Subject: RE: iSCSI: large keys during login? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Sun, 5 May 2002, Julian Satran wrote: > Eddy, > > There are many ways to do it. Recall that we had no spanning at all and > that was best. But it was not good enough for all values with small PDU's. > The alternative would be to allow at least the sender to lay out data and > the send-it out by cutting it in pieces of PDU length without it having to > parse. > > What you are suggesting requires the sender to build the stream > considering the boundaries. > > We could go either way but IMHO it is better as we have it now - only the > receiver gets more complicated not both receiver and sender. Sounds good & simple. From owner-ips@ece.cmu.edu Mon May 6 14:30:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01665 for ; Mon, 6 May 2002 14:30:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g46HkCV04068 for ips-outgoing; Mon, 6 May 2002 13:46:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g46Hk4w04053 for ; Mon, 6 May 2002 13:46:09 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel9.hp.com (Postfix) with ESMTP id 354298052B2; Mon, 6 May 2002 13:45:59 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id KAA12836; Mon, 6 May 2002 10:47:43 -0700 (PDT) Message-ID: <005301c1f525$e162fb00$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , References: <00ca01c1f313$0296ccd0$edd52b0f@rose.hp.com> <3CD694BC.E01A5A32@compuserve.com> Subject: Re: FCIP: Comment 120 Date: Mon, 6 May 2002 10:45:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, > The requested figure relies on Fibre Channel concepts and thus appears > in a T11 document, FC-BB-2, ftp://ftp.t11.org/t11/pub/fc/bb-2/02-030v1.pdf. > See Figure 23 on PDF page 87, or Figure 26 on PDF page 94. Thanks for the reference, but unfortunately it doesn't help make the point that there is 1-to-n association between FC Entity and FCIP Entity. Given that FCIP is an RFC that defines these Entities and their relationships in its own right, my suggestion would continue to be that the association be depicted in an architectural model diagram. It could be as simple as showing a shadow ASCII box to the FCIP Entity box. I will leave it here up to you and Co-Chairs to make the call. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Ralph Weber" To: Cc: "Mallikarjun C." Sent: Monday, May 06, 2002 7:35 AM Subject: Re: FCIP: Comment 120 > Mallikarjun, > > > >... the "FC/FCIP Entity Identifier" is unique only within the scope > > >of the given FC Entity's WWN. ... the model allows multiple FCIP > > >Entities to be associated with the FC Fabric Entity WWN. > > > > If that is so, please add an architectural model diagram (similar to > > Figure 3, or perhaps convert Figure 3 into) which clearly shows this > > 1-to-n association. > > > > This is the only hint in the document (at least that I found) which > > suggests the stated possibility. Figure 3 with 1-to-1 association almost > > seemed like the architectural model, but on careful reading, is only > > an example. > > The fact that the "FC/FCIP Entity Identifier" is unique only within > the scope of a given FC Entity's WWN seems to be clearly stated in the > definition of the field: > > "The Source FC/FCIP Entity Identifier field SHALL contain a unique > identifier for the FC Entity FCIP Entity pair that generates (as opposed > to echoes) the Special Frame. The value is assigned by the FC Fabric > entity whose world wide name appears in the Source FC Fabric Entity World > Wide Name field. > > "Note: The combination of the Source FC Entity World Wide Name and Source > FCIP Entity Identifier fields uniquely identifies every FC Entity FCIP > Entity pair in the IP Network." > > The requested figure relies on Fibre Channel concepts and thus appears > in a T11 document, FC-BB-2, ftp://ftp.t11.org/t11/pub/fc/bb-2/02-030v1.pdf. > See Figure 23 on PDF page 87, or Figure 26 on PDF page 94. > > Thanks. > > .Ralph > > "Mallikarjun C." wrote: > > > > > Ralph, > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.pdf > > .... > > > Please review these comments resolutions to ensure that > > > the desired changes are described. > > > > Sorry for the delayed review, I have additional comments on wglc-01 > > for Comment 120. > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > >Comment 120 > > >> 8. The FCIP Special Frame > > >...... > > >> Note: The combination of the Source FC Entity World Wide Name and > > >> Source FCIP Entity Identifier fields uniquely identifies every FC > > >> Entity FCIP Entity pair in the IP Network. > > >.... > > >- Also I take it that the "FC/FCIP Entity Identifier" is unique only > > >within the scope of the given FC Entity's WWN. So, does the model > > >allow multiple FCIP Entities to be associated with the FC Fabric > > >Entity WWN? > > >.... > > >Response to the second bullet: Yes, the "FC/FCIP Entity Identifier" > > >is unique only within the scope of the given FC Entity's WWN. Yes, > > >the model allows multiple FCIP Entities to be associated with the FC > > >Fabric Entity WWN. > > > > > > > If that is so, please add an architectural model diagram (similar to > > Figure 3, or perhaps convert Figure 3 into) which clearly shows this > > 1-to-n association. > > > > This is the only hint in the document (at least that I found) which > > suggests the stated possibility. Figure 3 with 1-to-1 association almost > > seemed like the architectural model, but on careful reading, is only > > an example. > > From owner-ips@ece.cmu.edu Mon May 6 14:32:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01776 for ; Mon, 6 May 2002 14:32:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g46IAH906003 for ips-outgoing; Mon, 6 May 2002 14:10:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g46IAEw05992 for ; Mon, 6 May 2002 14:10:15 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel9.hp.com (Postfix) with ESMTP id 3E23C804FE3; Mon, 6 May 2002 14:10:09 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id LAA22440; Mon, 6 May 2002 11:11:54 -0700 (PDT) Message-ID: <006501c1f529$41a6a8b0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , References: <00d001c1f313$39de4240$edd52b0f@rose.hp.com> <3CD69618.2BC1ADF2@compuserve.com> Subject: Re: FCIP: Comment 125 Date: Mon, 6 May 2002 11:10:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, Thanks for the explanation. I see the value of Ch bit. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Ralph Weber" To: Cc: "Mallikarjun C." Sent: Monday, May 06, 2002 7:41 AM Subject: Re: FCIP: Comment 125 > Mallikarjun, > > > OK, but I don't see how is this distinction may be made use of by the > > receiver. IIRC, any comparison failure (Ch bit or not) leads to a > > connection drop. Is Ch bit then intended only for diagnostics? > > If the Ch bit is zero, the poor-man's SLP receiver cannot inspect the > contents of the Destination FC Fabric Entity World Wide Name field to > determine the correct Destination FC Fabric Entity World Wide Name > value. > > If the Ch bit is one, the poor-man's SLP receiver can inspect the > contents of the Destination FC Fabric Entity World Wide Name field > to determine the correct Destination FC Fabric Entity World Wide Name > value. As David has pointed out, the FC Fabric Entity World Wide > Name value determined in this was is itself subject to potential > corruption. However, the only result of that corruption is that > the subsequent connection setup will fail because the FC Fabric > Entity World Wide Name will be wrong. > > Thanks. > > .Ralph > > "Mallikarjun C." wrote: > > > > > Ralph, > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.pdf > > .... > > > Please review these comments resolutions to ensure that > > > the desired changes are described. > > > > Sorry for the delayed review, I have additional comments on wglc-01 > > for Comment 125. > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > >Comment 125 > > >> 9.1.2.3 Connection Setup After a Successful TCP Connect Request > > >...... > > >> If the echoed FCIP Special Frame bytes do not exactly match the > > >> FCIP Special Frame bytes sent (words 7 through 17 inclusive), the > > >> FCIP Entity SHALL close the TCP Connection and notify the FC > > >> Entity with the reason for the closure. > > >Seems like all the 11 words are required to be compared. If so, what > > >is the Ch bit being used for? IOW, why SHALL it be set by the > > >responder? > > >Inquiry > > >The Ch bit serves to identify the difference between changes > > >made intentionally by the echoing FCIP Entity and changes that > > >result from transmission errors. > > > > OK, but I don't see how is this distinction may be made use of by the > > receiver. IIRC, any comparison failure (Ch bit or not) leads to a > > connection drop. Is Ch bit then intended only for diagnostics? > From owner-ips@ece.cmu.edu Mon May 6 17:00:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06512 for ; Mon, 6 May 2002 17:00:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g46KGeP16296 for ips-outgoing; Mon, 6 May 2002 16:16:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g46KGLw16244 for ; Mon, 6 May 2002 16:16:21 -0400 (EDT) Received: (from mailgate@localhost) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id QAA27986 for ips@ece.cmu.edu; Mon, 6 May 2002 16:16:15 -0400 (EDT) Received: from compuserve.com (dal-tgn-tka-vty37.as.wcom.net [206.175.230.37]) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id QAA27848; Mon, 6 May 2002 16:15:58 -0400 (EDT) Message-ID: <3CD6E5F5.A417E048@compuserve.com> Date: Mon, 06 May 2002 15:22:13 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu CC: "Mallikarjun C." Subject: Re: FCIP: Comment 109 References: <00d601c1f313$5c64c280$edd52b0f@rose.hp.com> <3CD691B0.52486D27@compuserve.com> <005b01c1f529$1427c720$edd52b0f@rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallikarjun, The reasons for not worrying about the timestamp are based on the fact that the range of valid timestamp values is very small when compared to the total value range (something like 20 in 4 billion) with results as follows: 1) Changing a valid timestamp into an invalid one is not an issue because it is only one of several ways in which a potentially good frame can get dropped; and 2) The chances of changing an invalid timestamp are considered very remote because two events are required to cause the condition: a) the frame transit has to be delayed too long; and b) the timestamp has to be altered in just the right way without any other alterations occurring. Thanks. .Ralph "Mallikarjun C." wrote: > > Ralph, > > > Interoperability concerns dictate that FCIP must either mandate > > or prohibit use of CRC, > > Or adopt a must-implement-may-use policy with the FSF indicating > the choice - which was my strawman. > > I was about to be completely satisfied about the redundancy, but I see that with > the exception of Timestamp - all other fields are redundant. If the corruption > probability of timestamp (with attendant side effects) is considered insignificant > by everyone else, I wouldn't press this. Perhaps it is worth noting the lack of > redundancy for timestamp and leaving it there. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > ----- Original Message ----- > From: "Ralph Weber" > To: > Cc: "Mallikarjun C." > Sent: Monday, May 06, 2002 7:22 AM > Subject: Re: FCIP: Comment 109 > > > Mallikarjun, > > > > > ... - could you please comment on whether or not CRC protection > > > is available on FCIP headers and help me with a reference if so? > > > > CRC protection is prohibited for FCIP headers as per following > > two statements in 6.6.1: > > > > "The CRCV (CRC Valid) Flag SHALL be set to 0." > > "The CRC field SHALL be set to 0." > > > > It is further worth noting that the error detection algorithms > > described in 6.6.2.2 include no provisions for the use of CRCs > > but do describe a through FCIP header validation mechanism > > based on redundancy. > > > > The recommendation that CRC be used for FCIP headers has been > > considered and rejected in the past. The preference for > > redundancy validation of FCIP headers is partially described > > in the FC Encapsulation draft section 3.2.1. > > > > "Header validation based on redundancy is a stepwise process > > in that the first word is validated, then the second, then > > the third and so on. A decision that a candidate header is > > not valid may be reached before the complete header is > > available." > > > > It should be noted that the Fibre Channel requirements for usage > > of its CRC are such that the usage of CRC by FCIP would constitute > > the only requirement for CRC hardware in an FCIP device. > > > > Interoperability concerns dictate that FCIP must either mandate > > or prohibit use of CRC, so CRC usage is prohibited. > > > > Thanks. > > > > .Ralph > > > > "Mallikarjun C." wrote: > > > > > > > > Ralph, > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.pdf > > > .... > > > > Please review these comments resolutions to ensure that > > > > the desired changes are described. > > > > > > Sorry for the delayed review, I have additional comments on wglc-01 > > > for Comment 109. > > > > > > Regards. > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions Organization > > > Hewlett-Packard MS 5668 > > > Roseville CA 95747 > > > cbm@rose.hp.com > > > > > > >>Comment 109 Technical > > > >> 6.6.1 FCIP Encapsulation of FC Frames > > > >.... > > > >> The CRCV (CRC Valid) Flag SHALL be set to 0. > > > >> > > > >> The CRC field SHALL be set to 0. > > > >I am surprised that the FCIP encapsulated header is never protected > > > >by a CRC. The error detection section clearly acknowledges the > > > >possibility that TCP checksum could be inadequate for certain > > > >deployments - and even suggests checking the FC frame CRC (sort > > > >of like a data digest) on reception at the Encapsulated Frame > > > >Receiver Portal. > > > >My recommendation is to require an FCIP Entity to employ the header > > > >CRC if the SF that it receives asks for CRC - IOW, similar to iSCSI's > > > >approach. So, I guess I am also advocating a new bit in the pFlags > > > >field to announce this. When this CRC expectation is announced, the > > > >FC CRC checking test in 6.6.2.2 should also be a mandatory test -from > > > >the "semi-optional" list it is currently in. > > > >Accepted with the following result > > > >Add the following to the new section created in response to comment > > > >44: "Note: Owing to the limited manner in which the FSF is used and > > > >the requirement that the FSF be echoed without changes before a TCP > > > >connection is allowed to carry user data, no error checking beyond > > > >that provided by TCP is deemed necessary." > > > > > > Sorry, I missed the earlier discussion on this comment. > > > > > > My comment was for __all__ FCIP encapsulated headers on all FCIP > > > Frames - not just for FSF. The reference to FSF in my comment was > > > to suggest how an "I want CRC" demand be communicated at the FCIP > > > Link establishment time - i.e. the reference was a solution strawman. > > > > > > I probably missed something critical - could you please comment on > > > whether or not CRC protection is available on FCIP headers and > > > help me with a reference if so? > > > > > > From owner-ips@ece.cmu.edu Mon May 6 17:00:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06530 for ; Mon, 6 May 2002 17:00:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g46KOWv16984 for ips-outgoing; Mon, 6 May 2002 16:24:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2aa.compuserve.com (siaar2aa.compuserve.com [149.174.40.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g46KOTw16974 for ; Mon, 6 May 2002 16:24:29 -0400 (EDT) Received: (from mailgate@localhost) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id QAA04256 for ips@ece.cmu.edu; Mon, 6 May 2002 16:24:23 -0400 (EDT) Received: from compuserve.com (dal-tgn-tka-vty37.as.wcom.net [206.175.230.37]) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id QAA04132; Mon, 6 May 2002 16:24:14 -0400 (EDT) Message-ID: <3CD6E797.845F0095@compuserve.com> Date: Mon, 06 May 2002 15:29:11 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu CC: "Mallikarjun C." Subject: Re: FCIP: Comment 120 References: <00ca01c1f313$0296ccd0$edd52b0f@rose.hp.com> <3CD694BC.E01A5A32@compuserve.com> <005301c1f525$e162fb00$edd52b0f@rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallikarjun, Oops! This mistake is on me. The Source FC Fabric Entity World Wide Name field DOES NOT contain the WWN of the FC Entity. Rather, it contains the "Fibre Channel Name_Identifier [FC-FS] for the FC Fabric entity associated with the FC Entity FCIP Entity pair." Two corrections are needed in the picture that I led you to believe in: 1) The "FC Fabric entity" IS NOT the FC Entity, it is the FC product (switch or whatever) that contains one or more FC Entities; and 2) There is no 1-to-n relationship between FC Entities and FCIP Entities, in fact, they come in 1-to-1 one matched pairs. Note that these corrections further strengthen the argument that the 1-to-n discussion belongs in FC-BB-2, since the multiplicity relationship really is farther inside FC constructs than I first suggested. Hope this helps. .Ralph "Mallikarjun C." wrote: > > Ralph, > > > The requested figure relies on Fibre Channel concepts and thus appears > > in a T11 document, FC-BB-2, ftp://ftp.t11.org/t11/pub/fc/bb-2/02-030v1.pdf. > > See Figure 23 on PDF page 87, or Figure 26 on PDF page 94. > > Thanks for the reference, but unfortunately it doesn't help make the point > that there is 1-to-n association between FC Entity and FCIP Entity. > > Given that FCIP is an RFC that defines these Entities and their relationships > in its own right, my suggestion would continue to be that the association be depicted > in an architectural model diagram. It could be as simple as showing a shadow ASCII > box to the FCIP Entity box. I will leave it here up to you and Co-Chairs to make > the call. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > ----- Original Message ----- > From: "Ralph Weber" > To: > Cc: "Mallikarjun C." > Sent: Monday, May 06, 2002 7:35 AM > Subject: Re: FCIP: Comment 120 > > > Mallikarjun, > > > > > >... the "FC/FCIP Entity Identifier" is unique only within the scope > > > >of the given FC Entity's WWN. ... the model allows multiple FCIP > > > >Entities to be associated with the FC Fabric Entity WWN. > > > > > > If that is so, please add an architectural model diagram (similar to > > > Figure 3, or perhaps convert Figure 3 into) which clearly shows this > > > 1-to-n association. > > > > > > This is the only hint in the document (at least that I found) which > > > suggests the stated possibility. Figure 3 with 1-to-1 association almost > > > seemed like the architectural model, but on careful reading, is only > > > an example. > > > > The fact that the "FC/FCIP Entity Identifier" is unique only within > > the scope of a given FC Entity's WWN seems to be clearly stated in the > > definition of the field: > > > > "The Source FC/FCIP Entity Identifier field SHALL contain a unique > > identifier for the FC Entity FCIP Entity pair that generates (as opposed > > to echoes) the Special Frame. The value is assigned by the FC Fabric > > entity whose world wide name appears in the Source FC Fabric Entity World > > Wide Name field. > > > > "Note: The combination of the Source FC Entity World Wide Name and Source > > FCIP Entity Identifier fields uniquely identifies every FC Entity FCIP > > Entity pair in the IP Network." > > > > The requested figure relies on Fibre Channel concepts and thus appears > > in a T11 document, FC-BB-2, ftp://ftp.t11.org/t11/pub/fc/bb-2/02-030v1.pdf. > > See Figure 23 on PDF page 87, or Figure 26 on PDF page 94. > > > > Thanks. > > > > .Ralph > > > > "Mallikarjun C." wrote: > > > > > > > > Ralph, > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.pdf > > > .... > > > > Please review these comments resolutions to ensure that > > > > the desired changes are described. > > > > > > Sorry for the delayed review, I have additional comments on wglc-01 > > > for Comment 120. > > > > > > Regards. > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions Organization > > > Hewlett-Packard MS 5668 > > > Roseville CA 95747 > > > cbm@rose.hp.com > > > > > > >Comment 120 > > > >> 8. The FCIP Special Frame > > > >...... > > > >> Note: The combination of the Source FC Entity World Wide Name and > > > >> Source FCIP Entity Identifier fields uniquely identifies every FC > > > >> Entity FCIP Entity pair in the IP Network. > > > >.... > > > >- Also I take it that the "FC/FCIP Entity Identifier" is unique only > > > >within the scope of the given FC Entity's WWN. So, does the model > > > >allow multiple FCIP Entities to be associated with the FC Fabric > > > >Entity WWN? > > > >.... > > > >Response to the second bullet: Yes, the "FC/FCIP Entity Identifier" > > > >is unique only within the scope of the given FC Entity's WWN. Yes, > > > >the model allows multiple FCIP Entities to be associated with the FC > > > >Fabric Entity WWN. > > > > > > > > > > If that is so, please add an architectural model diagram (similar to > > > Figure 3, or perhaps convert Figure 3 into) which clearly shows this > > > 1-to-n association. > > > > > > This is the only hint in the document (at least that I found) which > > > suggests the stated possibility. Figure 3 with 1-to-1 association almost > > > seemed like the architectural model, but on careful reading, is only > > > an example. > > > > From owner-ips@ece.cmu.edu Mon May 6 17:01:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06547 for ; Mon, 6 May 2002 17:00:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g46Kav318025 for ips-outgoing; Mon, 6 May 2002 16:36:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from snake012.odetics.com (snake012.odetics.com [198.58.66.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g46Kapw18013 for ; Mon, 6 May 2002 16:36:51 -0400 (EDT) Received: by snake012.odetics.com with Internet Mail Service (5.5.2653.19) id <25H5YXDW>; Mon, 6 May 2002 13:36:43 -0700 Message-ID: <6F0AA176DA68704884B7507AE6907E180817D0@snake012.odetics.com> From: Christina Helbig To: "'Srinivasa Addepalli'" , Bernard Aboba , "'kukkonen@ssh.com'" , "'black_david@emc.com'" Cc: ips@ece.cmu.edu Subject: RE: Relation between iSCSI session and IPSec SAs Date: Mon, 6 May 2002 13:36:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, thank you for your answers! May be I have mixed something before I came out with my question. I understand that it is possible and reasonable to secure all tcp connections with the same IKE phase 2 SA if the tcp connections have following properties: - belong to the same iSCSI session - are between the same IP address pair. If this is the security policy then the tcp ports could be eliminated as selectors for the out-bound traffic to reduce the complexity of realization. The consequence of this reduction would be that you can't separate out-bound packets from multiple iSCSI sessions between the same IP address pair and there is also currently no requirement to do this (David). In this case it makes no sense to fulfill following demand of draft-ips-security-11 for a new multiple iSCSI session if there is already an IKE phase 1 SA for an existing multiple iSCSI session between the same IP address pair: "In order to create a new iSCSI Session, an Initiator implementing iSCSI security first establishes an IKE Phase 1 SA. Subsequent iSCSI connections established within the iSCSI session will typically be protected by IKE Phase 2 SAs derived from that IKE Phase 1 SA, although additional IKE Phase 1 SAs can also be brought up." It is possible to change this formulation for multiple iSCSI sessions between a given IP address pair? Greetings Christina > -----Original Message----- > From: Srinivasa Addepalli [mailto:srao@intotoinc.com] > Sent: Friday, May 03, 2002 1:04 PM > To: Bernard Aboba > Cc: Christina Helbig; ips@ece.cmu.edu > Subject: Re: Relation between iSCSI session and IPSec SAs > > > > Security Policy Database, as defined by RFC2401 (Section 4.4.1) is > flexibile enough to create security associations for individual > TCP connections and for set of TCP/IP connections. For clarity, I am > listing down the portion of the RFC here: > " For each selector, the policy entry specifies how > to derive the corresponding values for a new Security Association > Database (SAD, see Section 4.4.3) entry from those in the > SPD and the > packet (Note that at present, ranges are only supported for IP > addresses; but wildcarding can be expressed for all selectors): > > a. use the value in the packet itself -- This will > limit use > of the SA to those packets which have this > packet's value > for the selector even if the selector for the > policy entry > has a range of allowed values or a wildcard for this > selector. > b. use the value associated with the policy entry > -- If this > were to be just a single value, then there would be no > difference between (b) and (a). However, if the allowed > values for the selector are a range (for IP > addresses) or > > wildcard, then in the case of a range,(b) would > enable use > of the SA by any packet with a selector value within the > range not just by packets with the selector value of the > packet that triggered the creation of the SA. > In the case > of a wildcard, (b) would allow use of the SA by packets > with any value for this selector. " > > If security association is required for each TCP connection between > iSCSI initiator and target, then Security policy can be configured > to create security associations based on packet values for sourceIP, > destination IP, protocol, SP and DP. > > If Security association is required for all connections between a > iSCSI initiator and target, then security policy can be configured > to depend on packet values for Source IP and destination IP and policy > values for others. > > Since, SPD itself provides this granularity, I think, there > is no need for > any communication/relation between iSCSI layer and IPSEC layer. > > > Srini > On Fri, 3 May 2002, Bernard Aboba wrote: > > > >From the minutes of Minneapolis: > > >"...a single IPSec Phase 2 SA per TCP connection ...had no > security > > > >value." > > >I agree and like to extend this: > > > > >"...a single IKE negotiation per multiple iSCSI session > (between the >same > > >IP addresses of initiator and target) ...had no security value." > > > > If you are saying that it it doesn't matter how many IKE > phase 2 SAs > > correspond to a given IKE Phase 1 SA, then I would agree. > Is this what you > > meant? > > > > >Must we negotiate per multiple session (and evaluate > packets >additional > > >for a session identifier) or must we not? > > > > I think that the bottom line is that an iSCSI session needs > to be protected > > by an IKE phase 2 SA. You can have multiple iSCSI sessions > per phase 2 SA. > > You can have multiple phase 2 SAs per phase 1 SA. Those are > implementation > > decisions that generally don't influence the security > properties, except in > > a few exceptional conditions (e.g. QoS marking, desire to > protect iSCSI > > sessions with different transforms). > > > > _________________________________________________________________ > > Join the world's largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > -- > Srinivasa Rao Addepalli > Intoto Inc. > 3160, De La Cruz Blvd #100 > Santa Clara, CA > USA > Ph: 408-844-0480 x317 > From owner-ips@ece.cmu.edu Mon May 6 18:25:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09639 for ; Mon, 6 May 2002 18:25:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g46M9XQ25046 for ips-outgoing; Mon, 6 May 2002 18:09:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g46M9Vw25042 for ; Mon, 6 May 2002 18:09:31 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id 82446600AAC for ; Mon, 6 May 2002 15:09:25 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id PAA21595 for ; Mon, 6 May 2002 15:11:10 -0700 (PDT) Message-ID: <012201c1f54a$ae898e40$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: Subject: iSCSI-boot: comments Date: Mon, 6 May 2002 15:09:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Attached are some comments on the iSCSI boot draft, rev05. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com >1. Requirements > > 1. There must be no restriction of network topology between the iSCSI > boot client and the boot server. Need to add "other than those in effect for establishing the iSCSI session." .... > 2. The following represents the minimum information required for an > iSCSI boot client to contact an iSCSI boot server: (a) the client's > IP address (IPv6 or IPv4); (b) the server's iSCSI Service Delivery > Port Name; Suggest an "iSCSI Target Port Name" in place of "Service Delivery Port Name" - same comment for all places in this document wher SDP is used. SAM-2 no longer uses the term.... Also, I'd think the iSCSI target portal address is required, unless discovery is being presumed before boot... ..... > > Additional information may be required at each stage of the boot > process. > > 3. It is possible for the iSCSI boot client to have none of the above > information or capability on starting. > > 4. The client should be able to complete boot without user > intervention (for boots that occur during an unattended power-up). > However, there should be a mechanism for the user to input values so > as to bypass stages of the boot protocol. > > 5. Additional protocol software (for example, DHCP) may be necessary > if the minimum information required for an iSCSI session is not > provided. #3 and #5 above don't sound like requirements to me - particularly #3. ..... >4. DHCP stage > > In order to use an iSCSI boot server, the following pieces of > information are required. for an iSCSI boot client? [ if this is true, the following bullet may be reworded as "its own IP address"....] > > - The IP address of the iSCSI boot client (IPv4 or IPv6) > > - The IP transport endpoint for the iSCSI service delivery port for > the iSCSI boot server. If the transport is TCP, for example, this > has to resolve to an IP address and a TCP port number. It is useful to note that iSCSI currently is defined only for TCP. > > - The eight-byte LUN structure identifying the device within the I wouldn't use "device" at all here - it is a "Logical Unit" per SAM-2. > iSCSI boot server. It appears to me that all the above information is realized *after* using the "DHCP stage". It would be useful to state this, particularly when presented at the beginning of the section as the "required information". ..... > Unless otherwise specified here, DHCP fields such as the client ID > and gateway information are used identically with applications other > than iSCSI. S/b "identically with applications other than iSCSI." W/ "in an identical way as applications other than iSCSI do." > .... > The fields "servername", "port", "protocol" and "LUN" are optional > and should be left blank if there are no corresponding values. The > "targetname" field is not optional and must be provided. > > Thv "servername" is the name of iSCSI server and contains either a Typo above - "Thv". ..... > The "LUN" field is a 16 byte hexadecimal representation of the 8-byte 16-nibble? I'd actually prefer "8 byte". > LU number in hex. Digits above 9 may be either lower or upper case, > and all 16 nibbles must be present. If the LUN field is blank, then > LUN 0 is assumed. > > Note that SCSI targets are allowed to present different LU numberings > for different SCSI initiators, so that to our knowledge nothing > precludes a SCSI target from exporting several different devices to S/b "device" W/ "LU" > several different SCSI initiators as their respective LU 0s. S/b "LU" W/ "LUN". > > The "targetname" field is an iSCSI Name that is defined by the naming > and discovery in Section 2.1 iSCSI Naming and Discovery draft[9] to > uniquely identify an iSCSI target. The use of the targetname > component is also defined by the iSCSI standard[4] and is to be used > accordingly. Given that iSCSI now assumed all normative N&D text, I would suggest getting rid of the reference to N&D for normative definitions here. ..... > >5. Discovery Service stage: Remove ":" A general comment on this Stage - the LBA offset within the LUN (where the boot image starts) could also be discovered by a boot client via the service attributes in the SLP Service Advertisement. This is perhaps one more reason for employing Discovery Service stage. BTW, all stages should either be titled "Stage" or "stage". I see both now. > > This stage is required if the DHCP server (v4 or v6) is unaware of > the Service Delivery Port Name of the iSCSI boot server. The > implemention of the discovery service is to based on the SLP Remove "to". > protocol[1,24]. > > The iSCSI boot client may have obtained the targetname of the iSCSI > boot server in the DHCP stage (Section 4). In that case, the iSCSI > boot client queries the Discovery Service using query string 1 as Need to define "Discovery Service" before using it ( = "discovery service" = "an instantiation of SLP DA"?). > specified in the iSCSI SLP interaction document[24] to resolve the > targetname to an IP address and port number. One this is obtained, S/b "One" W/ "Once" A reading of the iscsi-slp draft doesn't lead me to believe that this translation is necessarily maintained by the DA. I am not sure why can't the regular DNS be used here. Also, a search of the iscsi-slp draft doesn't yield any pointers to what "query string 1" (or 4) is.... ...... > > client may contact any iSCSI boot server in the list. Moreover, the > the order in which iSCSI boot servers are contacted is also left to S/b "the order" W/ "order". > the discretion of the implementor. > >6. Boot Stage > .... > > However, the use of a discovery session is not recommended because at The iSCSI discovery session *cannot* be used if any read commands are to be performed. > this stage (i) a boot server has probably been found and (ii) the "probably" ? I presume a boot client would not proceed to Boot Stage unles a boot server had been found. ..... >References ..... > > > [17] http://developer.intel.com/ial/WfM/wfm20/design/pxedt/index.htm This URL is broken. Also, Intel now calls the enhanced PXE as Boot Integrity Services (BIS). From owner-ips@ece.cmu.edu Mon May 6 18:26:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09676 for ; Mon, 6 May 2002 18:26:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g46Lup324157 for ips-outgoing; Mon, 6 May 2002 17:56:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g46Luow24153 for ; Mon, 6 May 2002 17:56:50 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 May 2002 17:55:44 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293784C@CORPMX14> From: Black_David@emc.com To: cbh@zyfer.com Cc: ips@ece.cmu.edu Subject: RE: Relation between iSCSI session and IPSec SAs Date: Mon, 6 May 2002 17:55:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Yes, the wording that implies a new IKE phase 1 for each iSCSI session needs to be changed. I believe that to be an oversight. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Christina Helbig [mailto:cbh@zyfer.com] > Sent: Monday, May 06, 2002 4:37 PM > To: 'Srinivasa Addepalli'; Bernard Aboba; 'kukkonen@ssh.com'; > 'black_david@emc.com' > Cc: ips@ece.cmu.edu > Subject: RE: Relation between iSCSI session and IPSec SAs > > > Hi, thank you for your answers! > May be I have mixed something before I came out with my question. I > understand that it is possible and reasonable to secure all > tcp connections > with the same IKE phase 2 SA if the tcp connections have following > properties: > - belong to the same iSCSI session > - are between the same IP address pair. > If this is the security policy then the tcp ports could be > eliminated as > selectors for the out-bound traffic to reduce the complexity > of realization. > The consequence of this reduction would be that you can't > separate out-bound > packets from multiple iSCSI sessions between the same IP > address pair and > there is also currently no requirement to do this (David). In > this case it > makes no sense to fulfill following demand of > draft-ips-security-11 for a > new multiple iSCSI session if there is already an IKE phase 1 > SA for an > existing multiple iSCSI session between the same IP address pair: > "In order to create a new iSCSI Session, an Initiator > implementing iSCSI > security first establishes an IKE Phase 1 SA. Subsequent > iSCSI connections > established within the iSCSI session will typically be > protected by IKE > Phase 2 SAs derived from that IKE Phase 1 SA, although > additional IKE Phase > 1 SAs can also be brought up." > It is possible to change this formulation for multiple iSCSI sessions > between a given IP address pair? > Greetings > Christina > > > > -----Original Message----- > > From: Srinivasa Addepalli [mailto:srao@intotoinc.com] > > Sent: Friday, May 03, 2002 1:04 PM > > To: Bernard Aboba > > Cc: Christina Helbig; ips@ece.cmu.edu > > Subject: Re: Relation between iSCSI session and IPSec SAs > > > > > > > > Security Policy Database, as defined by RFC2401 (Section 4.4.1) is > > flexibile enough to create security associations for individual > > TCP connections and for set of TCP/IP connections. For clarity, I am > > listing down the portion of the RFC here: > > " For each selector, the policy entry specifies how > > to derive the corresponding values for a new Security Association > > Database (SAD, see Section 4.4.3) entry from those in the > > SPD and the > > packet (Note that at present, ranges are only supported for IP > > addresses; but wildcarding can be expressed for all selectors): > > > > a. use the value in the packet itself -- This will > > limit use > > of the SA to those packets which have this > > packet's value > > for the selector even if the selector for the > > policy entry > > has a range of allowed values or a wildcard for this > > selector. > > b. use the value associated with the policy entry > > -- If this > > were to be just a single value, then there would be no > > difference between (b) and (a). However, if > the allowed > > values for the selector are a range (for IP > > addresses) or > > > > wildcard, then in the case of a range,(b) would > > enable use > > of the SA by any packet with a selector value > within the > > range not just by packets with the selector > value of the > > packet that triggered the creation of the SA. > > In the case > > of a wildcard, (b) would allow use of the SA > by packets > > with any value for this selector. " > > > > If security association is required for each TCP connection between > > iSCSI initiator and target, then Security policy can be configured > > to create security associations based on packet values for sourceIP, > > destination IP, protocol, SP and DP. > > > > If Security association is required for all connections between a > > iSCSI initiator and target, then security policy can be configured > > to depend on packet values for Source IP and destination IP > and policy > > values for others. > > > > Since, SPD itself provides this granularity, I think, there > > is no need for > > any communication/relation between iSCSI layer and IPSEC layer. > > > > > > Srini > > On Fri, 3 May 2002, Bernard Aboba wrote: > > > > > >From the minutes of Minneapolis: > > > >"...a single IPSec Phase 2 SA per TCP connection ...had no > > security > > > > >value." > > > >I agree and like to extend this: > > > > > > >"...a single IKE negotiation per multiple iSCSI session > > (between the >same > > > >IP addresses of initiator and target) ...had no security value." > > > > > > If you are saying that it it doesn't matter how many IKE > > phase 2 SAs > > > correspond to a given IKE Phase 1 SA, then I would agree. > > Is this what you > > > meant? > > > > > > >Must we negotiate per multiple session (and evaluate > > packets >additional > > > >for a session identifier) or must we not? > > > > > > I think that the bottom line is that an iSCSI session needs > > to be protected > > > by an IKE phase 2 SA. You can have multiple iSCSI sessions > > per phase 2 SA. > > > You can have multiple phase 2 SAs per phase 1 SA. Those are > > implementation > > > decisions that generally don't influence the security > > properties, except in > > > a few exceptional conditions (e.g. QoS marking, desire to > > protect iSCSI > > > sessions with different transforms). > > > > > > _________________________________________________________________ > > > Join the world's largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > -- > > Srinivasa Rao Addepalli > > Intoto Inc. > > 3160, De La Cruz Blvd #100 > > Santa Clara, CA > > USA > > Ph: 408-844-0480 x317 > > > From owner-ips@ece.cmu.edu Mon May 6 18:27:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09698 for ; Mon, 6 May 2002 18:27:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g46Lmfa23512 for ips-outgoing; Mon, 6 May 2002 17:48:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g46Lmcw23506 for ; Mon, 6 May 2002 17:48:39 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel9.hp.com (Postfix) with ESMTP id 2BCC2805284; Mon, 6 May 2002 17:48:33 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id OAA12883; Mon, 6 May 2002 14:50:16 -0700 (PDT) Message-ID: <011001c1f547$c3229070$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , References: <00ca01c1f313$0296ccd0$edd52b0f@rose.hp.com> <3CD694BC.E01A5A32@compuserve.com> <005301c1f525$e162fb00$edd52b0f@rose.hp.com> <3CD6E797.845F0095@compuserve.com> Subject: Re: FCIP: Comment 120 Date: Mon, 6 May 2002 14:48:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, > Two corrections are needed in the picture that I led you to believe in: Ah, thank you. It's much easier to visualize the model now. May I make a couple of recommendations based on this - - Please add a definition of the "FC Fabric Entity" to the Terminology section (section 4). - All the pictures (starting with Figure 3) show the FC Entity directly talking to FC Fabric directly - the containment relationship wrt FC Fabric Entity is not illustrated anywhere. I'd recommend that at least one picture show FC Fabric Entity, and perhaps state that the same applies to all pictures even while not explicitly shown. A reasonable alternative would be to refer to the T11 document's picture illustrating the containment relationship. In either case, I suggest the FCIP text state this. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Ralph Weber" To: Cc: "Mallikarjun C." Sent: Monday, May 06, 2002 1:29 PM Subject: Re: FCIP: Comment 120 > Mallikarjun, > > Oops! This mistake is on me. > > The Source FC Fabric Entity World Wide Name field DOES NOT contain the > WWN of the FC Entity. Rather, it contains the "Fibre Channel Name_Identifier > [FC-FS] for the FC Fabric entity associated with the FC Entity FCIP Entity > pair." > > Two corrections are needed in the picture that I led you to believe in: > > 1) The "FC Fabric entity" IS NOT the FC Entity, it is the FC product > (switch or whatever) that contains one or more FC Entities; and > 2) There is no 1-to-n relationship between FC Entities and FCIP Entities, > in fact, they come in 1-to-1 one matched pairs. > > Note that these corrections further strengthen the argument that the > 1-to-n discussion belongs in FC-BB-2, since the multiplicity relationship > really is farther inside FC constructs than I first suggested. > > Hope this helps. > > .Ralph > > "Mallikarjun C." wrote: > > > > > Ralph, > > > > > The requested figure relies on Fibre Channel concepts and thus appears > > > in a T11 document, FC-BB-2, ftp://ftp.t11.org/t11/pub/fc/bb-2/02-030v1.pdf. > > > See Figure 23 on PDF page 87, or Figure 26 on PDF page 94. > > > > Thanks for the reference, but unfortunately it doesn't help make the point > > that there is 1-to-n association between FC Entity and FCIP Entity. > > > > Given that FCIP is an RFC that defines these Entities and their relationships > > in its own right, my suggestion would continue to be that the association be depicted > > in an architectural model diagram. It could be as simple as showing a shadow ASCII > > box to the FCIP Entity box. I will leave it here up to you and Co-Chairs to make > > the call. > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > ----- Original Message ----- > > From: "Ralph Weber" > > To: > > Cc: "Mallikarjun C." > > Sent: Monday, May 06, 2002 7:35 AM > > Subject: Re: FCIP: Comment 120 > > > > > Mallikarjun, > > > > > > > >... the "FC/FCIP Entity Identifier" is unique only within the scope > > > > >of the given FC Entity's WWN. ... the model allows multiple FCIP > > > > >Entities to be associated with the FC Fabric Entity WWN. > > > > > > > > If that is so, please add an architectural model diagram (similar to > > > > Figure 3, or perhaps convert Figure 3 into) which clearly shows this > > > > 1-to-n association. > > > > > > > > This is the only hint in the document (at least that I found) which > > > > suggests the stated possibility. Figure 3 with 1-to-1 association almost > > > > seemed like the architectural model, but on careful reading, is only > > > > an example. > > > > > > The fact that the "FC/FCIP Entity Identifier" is unique only within > > > the scope of a given FC Entity's WWN seems to be clearly stated in the > > > definition of the field: > > > > > > "The Source FC/FCIP Entity Identifier field SHALL contain a unique > > > identifier for the FC Entity FCIP Entity pair that generates (as opposed > > > to echoes) the Special Frame. The value is assigned by the FC Fabric > > > entity whose world wide name appears in the Source FC Fabric Entity World > > > Wide Name field. > > > > > > "Note: The combination of the Source FC Entity World Wide Name and Source > > > FCIP Entity Identifier fields uniquely identifies every FC Entity FCIP > > > Entity pair in the IP Network." > > > > > > The requested figure relies on Fibre Channel concepts and thus appears > > > in a T11 document, FC-BB-2, ftp://ftp.t11.org/t11/pub/fc/bb-2/02-030v1.pdf. > > > See Figure 23 on PDF page 87, or Figure 26 on PDF page 94. > > > > > > Thanks. > > > > > > .Ralph > > > > > > "Mallikarjun C." wrote: > > > > > > > > > > > Ralph, > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.pdf > > > > .... > > > > > Please review these comments resolutions to ensure that > > > > > the desired changes are described. > > > > > > > > Sorry for the delayed review, I have additional comments on wglc-01 > > > > for Comment 120. > > > > > > > > Regards. > > > > -- > > > > Mallikarjun > > > > > > > > Mallikarjun Chadalapaka > > > > Networked Storage Architecture > > > > Network Storage Solutions Organization > > > > Hewlett-Packard MS 5668 > > > > Roseville CA 95747 > > > > cbm@rose.hp.com > > > > > > > > >Comment 120 > > > > >> 8. The FCIP Special Frame > > > > >...... > > > > >> Note: The combination of the Source FC Entity World Wide Name and > > > > >> Source FCIP Entity Identifier fields uniquely identifies every FC > > > > >> Entity FCIP Entity pair in the IP Network. > > > > >.... > > > > >- Also I take it that the "FC/FCIP Entity Identifier" is unique only > > > > >within the scope of the given FC Entity's WWN. So, does the model > > > > >allow multiple FCIP Entities to be associated with the FC Fabric > > > > >Entity WWN? > > > > >.... > > > > >Response to the second bullet: Yes, the "FC/FCIP Entity Identifier" > > > > >is unique only within the scope of the given FC Entity's WWN. Yes, > > > > >the model allows multiple FCIP Entities to be associated with the FC > > > > >Fabric Entity WWN. > > > > > > > > > > > > > If that is so, please add an architectural model diagram (similar to > > > > Figure 3, or perhaps convert Figure 3 into) which clearly shows this > > > > 1-to-n association. > > > > > > > > This is the only hint in the document (at least that I found) which > > > > suggests the stated possibility. Figure 3 with 1-to-1 association almost > > > > seemed like the architectural model, but on careful reading, is only > > > > an example. > > > > > > > From owner-ips@ece.cmu.edu Mon May 6 20:42:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12256 for ; Mon, 6 May 2002 20:42:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g46NwoA02040 for ips-outgoing; Mon, 6 May 2002 19:58:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g46Nwmw02035 for ; Mon, 6 May 2002 19:58:48 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id B9EB430706; Mon, 6 May 2002 19:58:47 -0400 (EDT) Date: Mon, 6 May 2002 16:57:33 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Christina Helbig Cc: "'Srinivasa Addepalli'" , Bernard Aboba , "'kukkonen@ssh.com'" , "'black_david@emc.com'" , Subject: RE: Relation between iSCSI session and IPSec SAs In-Reply-To: <6F0AA176DA68704884B7507AE6907E180817D0@snake012.odetics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 6 May 2002, Christina Helbig wrote: > Hi, thank you for your answers! > May be I have mixed something before I came out with my question. I > understand that it is possible and reasonable to secure all tcp connections > with the same IKE phase 2 SA if the tcp connections have following > properties: > - belong to the same iSCSI session > - are between the same IP address pair. I don't think so. I don't think that iSCSI session is a reasonable selector for negotiating IPsec SAs. Mainly as you have to negotiate IPsec SAs before the iSCSI login starts, and it is only during iSCSI login that the target determines what session the initiator wants to talk to. The IPsec standards list IP address, protocol, and (for ones where it makes sense) port number as valid selectors for negotiating SAs. So how would we negotiate session (but not tcp port) specific SAs? The initiator doesn't know what tcp port a given session involves until it sets up the tcp connection. The target doesn't know the tcp ports involved in a connection _for_a_session_ until after its negotiated login (which as above is way too late). > If this is the security policy then the tcp ports could be eliminated as > selectors for the out-bound traffic to reduce the complexity of realization. While you can do whatever you want internally, it has to look to the outside world like you are using port numbers for selecting. > The consequence of this reduction would be that you can't separate out-bound > packets from multiple iSCSI sessions between the same IP address pair and > there is also currently no requirement to do this (David). In this case it > makes no sense to fulfill following demand of draft-ips-security-11 for a > new multiple iSCSI session if there is already an IKE phase 1 SA for an > existing multiple iSCSI session between the same IP address pair: > "In order to create a new iSCSI Session, an Initiator implementing iSCSI > security first establishes an IKE Phase 1 SA. Subsequent iSCSI connections > established within the iSCSI session will typically be protected by IKE > Phase 2 SAs derived from that IKE Phase 1 SA, although additional IKE Phase > 1 SAs can also be brought up." I agree that it makes no sense to satisfy that requirement if you already have a valid IKE Phase 1 SA. That text should be modified. When I quoted the text to a number of IPsec implementors (different IPsec stacks), they said, "that's just so wrong." :-) I expect (from the quote) that that text is trying to describe what you need to do when setting up the very first session between an initiator and a target; you have to do the IPsec negotiation first, which starts with a phase 1 SA. > It is possible to change this formulation for multiple iSCSI sessions > between a given IP address pair? I think we need more than that. :-) Consider the case where we are using IPsec between the initiator and the target. The initiator sets up a discovery session, and as part of that, we negotiate both a phase 1 and phase 2 SA. Then the initiator logs into one of the targets it just found. It's more than likely that those SA negotiations are still valid. :-) For iSCSI to require renegotiation would be, "less than desirable." :-) Take care, Bill From owner-ips@ece.cmu.edu Mon May 6 21:46:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14478 for ; Mon, 6 May 2002 21:45:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4713Mj05712 for ips-outgoing; Mon, 6 May 2002 21:03:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from intotoinc.com (sdsl-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4713Kw05707 for ; Mon, 6 May 2002 21:03:20 -0400 (EDT) Received: from localhost (srao@localhost) by intotoinc.com (8.11.0/8.11.0) with ESMTP id g471CYV08735; Mon, 6 May 2002 18:12:35 -0700 Date: Mon, 6 May 2002 18:12:34 -0700 (PDT) From: Srinivasa Addepalli To: Bill Studenmund cc: Christina Helbig , Bernard Aboba , "'kukkonen@ssh.com'" , "'black_david@emc.com'" , ips@ece.cmu.edu Subject: RE: Relation between iSCSI session and IPSec SAs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, Securing iSCSI using IPSEC is now can be treated as two independent entities. iSCSI is just one more application on top of IPSEC. I see only one relation ( which is optional), that is, iSCSI layer can omit iSCSI CRC, if IPSEC is employed. Ofcourse, this is possible if both layers exist in the same machine. Are there any more dependencies? Srini On Mon, 6 May 2002, Bill Studenmund wrote: > On Mon, 6 May 2002, Christina Helbig wrote: > > > Hi, thank you for your answers! > > May be I have mixed something before I came out with my question. I > > understand that it is possible and reasonable to secure all tcp connections > > with the same IKE phase 2 SA if the tcp connections have following > > properties: > > - belong to the same iSCSI session > > - are between the same IP address pair. > > I don't think so. I don't think that iSCSI session is a reasonable > selector for negotiating IPsec SAs. Mainly as you have to negotiate IPsec > SAs before the iSCSI login starts, and it is only during iSCSI login that > the target determines what session the initiator wants to talk to. > > The IPsec standards list IP address, protocol, and (for ones where it > makes sense) port number as valid selectors for negotiating SAs. So how > would we negotiate session (but not tcp port) specific SAs? The initiator > doesn't know what tcp port a given session involves until it sets up the > tcp connection. The target doesn't know the tcp ports involved in a > connection _for_a_session_ until after its negotiated login (which as > above is way too late). > > > If this is the security policy then the tcp ports could be eliminated as > > selectors for the out-bound traffic to reduce the complexity of realization. > > While you can do whatever you want internally, it has to look to the > outside world like you are using port numbers for selecting. > > > The consequence of this reduction would be that you can't separate out-bound > > packets from multiple iSCSI sessions between the same IP address pair and > > there is also currently no requirement to do this (David). In this case it > > makes no sense to fulfill following demand of draft-ips-security-11 for a > > new multiple iSCSI session if there is already an IKE phase 1 SA for an > > existing multiple iSCSI session between the same IP address pair: > > "In order to create a new iSCSI Session, an Initiator implementing iSCSI > > security first establishes an IKE Phase 1 SA. Subsequent iSCSI connections > > established within the iSCSI session will typically be protected by IKE > > Phase 2 SAs derived from that IKE Phase 1 SA, although additional IKE Phase > > 1 SAs can also be brought up." > > I agree that it makes no sense to satisfy that requirement if you already > have a valid IKE Phase 1 SA. That text should be modified. When I quoted > the text to a number of IPsec implementors (different IPsec stacks), they > said, "that's just so wrong." :-) > > I expect (from the quote) that that text is trying to describe what you > need to do when setting up the very first session between an initiator and > a target; you have to do the IPsec negotiation first, which starts with a > phase 1 SA. > > > It is possible to change this formulation for multiple iSCSI sessions > > between a given IP address pair? > > I think we need more than that. :-) Consider the case where we are using > IPsec between the initiator and the target. The initiator sets up a > discovery session, and as part of that, we negotiate both a phase 1 and > phase 2 SA. Then the initiator logs into one of the targets it just found. > It's more than likely that those SA negotiations are still valid. :-) For > iSCSI to require renegotiation would be, "less than desirable." :-) > > Take care, > > Bill > -- Srinivasa Rao Addepalli Intoto Inc. (Enabling Security Infrastructure) 3160, De La Cruz Blvd #100 Santa Clara, CA USA From owner-ips@ece.cmu.edu Mon May 6 23:36:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17563 for ; Mon, 6 May 2002 23:36:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g472nro11668 for ips-outgoing; Mon, 6 May 2002 22:49:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g472nnw11656; Mon, 6 May 2002 22:49:49 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g472nlvA014270; Mon, 6 May 2002 22:49:48 -0400 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.17.194.41]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g472nlj73248; Mon, 6 May 2002 20:49:47 -0600 Subject: Re: iSCSI-boot: comments To: "Mallikarjun C." Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Prasenjit Sarkar" Date: Mon, 6 May 2002 19:49:43 -0700 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/06/2002 07:49:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Thanks for your comments. Reponses embedded in +++ Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose "Mallikarjun C." To: Sent by: cc: owner-ips@ece.cmu Subject: iSCSI-boot: comments .edu 05/06/2002 03:09 PM Attached are some comments on the iSCSI boot draft, rev05. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com >1. Requirements > > 1. There must be no restriction of network topology between the iSCSI > boot client and the boot server. Need to add "other than those in effect for establishing the iSCSI session." +++ didnt follow - what topology restrictions are required to establish an iSCSI session +++ .... > 2. The following represents the minimum information required for an > iSCSI boot client to contact an iSCSI boot server: (a) the client's > IP address (IPv6 or IPv4); (b) the server's iSCSI Service Delivery > Port Name; Suggest an "iSCSI Target Port Name" in place of "Service Delivery Port Name" - same comment for all places in this document wher SDP is used. SAM-2 no longer uses the term.... Also, I'd think the iSCSI target portal address is required, unless discovery is being presumed before boot... ++agreed, target portal address has been added to the dhcp string+++ ..... > > Additional information may be required at each stage of the boot > process. > > 3. It is possible for the iSCSI boot client to have none of the above > information or capability on starting. > > 4. The client should be able to complete boot without user > intervention (for boots that occur during an unattended power-up). > However, there should be a mechanism for the user to input values so > as to bypass stages of the boot protocol. > > 5. Additional protocol software (for example, DHCP) may be necessary > if the minimum information required for an iSCSI session is not > provided. #3 and #5 above don't sound like requirements to me - particularly #3. +++ they are requirements found in related boot protocols - while appearing obvious, they need to be stated ++++ ..... >4. DHCP stage > > In order to use an iSCSI boot server, the following pieces of > information are required. for an iSCSI boot client? [ if this is true, the following bullet may be reworded as "its own IP address"....] ++ yes +++ > > - The IP address of the iSCSI boot client (IPv4 or IPv6) > > - The IP transport endpoint for the iSCSI service delivery port for > the iSCSI boot server. If the transport is TCP, for example, this > has to resolve to an IP address and a TCP port number. It is useful to note that iSCSI currently is defined only for TCP. ++noted++ > > - The eight-byte LUN structure identifying the device within the I wouldn't use "device" at all here - it is a "Logical Unit" per SAM-2. ++ ok ++ > iSCSI boot server. It appears to me that all the above information is realized *after* using the "DHCP stage". It would be useful to state this, particularly when presented at the beginning of the section as the "required information". ++ ok +++ ..... > Unless otherwise specified here, DHCP fields such as the client ID > and gateway information are used identically with applications other > than iSCSI. S/b "identically with applications other than iSCSI." W/ "in an identical way as applications other than iSCSI do." ++ yes that is definitely better grammar +++ > .... > The fields "servername", "port", "protocol" and "LUN" are optional > and should be left blank if there are no corresponding values. The > "targetname" field is not optional and must be provided. > > Thv "servername" is the name of iSCSI server and contains either a Typo above - "Thv". ++ ok +++ ..... > The "LUN" field is a 16 byte hexadecimal representation of the 8-byte 16-nibble? I'd actually prefer "8 byte". ++ yes +++ > LU number in hex. Digits above 9 may be either lower or upper case, > and all 16 nibbles must be present. If the LUN field is blank, then > LUN 0 is assumed. > > Note that SCSI targets are allowed to present different LU numberings > for different SCSI initiators, so that to our knowledge nothing > precludes a SCSI target from exporting several different devices to S/b "device" W/ "LU" +++ correct +++ > several different SCSI initiators as their respective LU 0s. S/b "LU" W/ "LUN". ++ yes+++ > > The "targetname" field is an iSCSI Name that is defined by the naming > and discovery in Section 2.1 iSCSI Naming and Discovery draft[9] to > uniquely identify an iSCSI target. The use of the targetname > component is also defined by the iSCSI standard[4] and is to be used > accordingly. Given that iSCSI now assumed all normative N&D text, I would suggest getting rid of the reference to N&D for normative definitions here. +++ will do +++ ..... > >5. Discovery Service stage: Remove ":" A general comment on this Stage - the LBA offset within the LUN (where the boot image starts) could also be discovered by a boot client via the service attributes in the SLP Service Advertisement. This is perhaps one more reason for employing Discovery Service stage. BTW, all stages should either be titled "Stage" or "stage". I see both now. +++ LBA offset discovery is not the concern of iSCSI boot -- this is the job of the boot protocol above iSCSI boot +++ ++ okay wrt Stage/stage +++ > > This stage is required if the DHCP server (v4 or v6) is unaware of > the Service Delivery Port Name of the iSCSI boot server. The > implemention of the discovery service is to based on the SLP Remove "to". ++ok++ > protocol[1,24]. > > The iSCSI boot client may have obtained the targetname of the iSCSI > boot server in the DHCP stage (Section 4). In that case, the iSCSI > boot client queries the Discovery Service using query string 1 as Need to define "Discovery Service" before using it ( = "discovery service" "an instantiation of SLP DA"?). +++ okay +++ > specified in the iSCSI SLP interaction document[24] to resolve the > targetname to an IP address and port number. One this is obtained, S/b "One" W/ "Once" A reading of the iscsi-slp draft doesn't lead me to believe that this translation is necessarily maintained by the DA. I am not sure why can't the regular DNS be used here. Also, a search of the iscsi-slp draft doesn't yield any pointers to what "query string 1" (or 4) is.... ...... +++ will investigate, havent seen the slp draft in some time +++ > > client may contact any iSCSI boot server in the list. Moreover, the > the order in which iSCSI boot servers are contacted is also left to S/b "the order" W/ "order". +++ okay +++ > the discretion of the implementor. > >6. Boot Stage > .... > > However, the use of a discovery session is not recommended because at The iSCSI discovery session *cannot* be used if any read commands are to be performed. ++ will fix, applies to the following comments too +++ > this stage (i) a boot server has probably been found and (ii) the "probably" ? I presume a boot client would not proceed to Boot Stage unles a boot server had been found. ..... >References ..... > > > [17] http://developer.intel.com/ial/WfM/wfm20/design/pxedt/index.htm This URL is broken. Also, Intel now calls the enhanced PXE as Boot Integrity Services (BIS). From owner-ips@ece.cmu.edu Tue May 7 10:53:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10753 for ; Tue, 7 May 2002 10:53:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g47EAoM29280 for ips-outgoing; Tue, 7 May 2002 10:10:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from S3-Prague.fw (s3group.dial-up.cz [193.85.188.82]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g477cBw26689 for ; Tue, 7 May 2002 03:38:11 -0400 (EDT) Received: from ([193.85.188.86]) by S3-Prague.fw; Tue, 07 May 2002 09:38:04 +0200 (MET DST) Received: from S3-Prague.fw (s3group-6.dial-up.cz [193.85.188.85]) by lynx.s3group.cz with SMTP id JAA07182; Tue, 7 May 2002 09:37:58 +0200 (MET DST) Received: from ([192.168.60.3]) by S3-Prague.fw; Mon, 06 May 2002 13:30:33 +0200 (MET DST) Message-ID: <3CD6697B.23DF2528@s3group.cz> Date: Mon, 06 May 2002 13:31:07 +0200 From: Ivan Pavelka X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Julian_Satran@il.ibm.com CC: ips@ece.cmu.edu Subject: iSCSI: Distinguishing between Data SNACK and R2T SNACK Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Julian, Please could you explain how a target can distinguish between the Data SNACK and the R2T SNACK during a bi-directional data command if the Data-In and R2T are transmitted simultaneously. Appendix B. Examples states: Send data and Receive Data may be transferred simultaneously as in an atomic Read-Old-Write-New or sequential as in an atomic Read-Update-Write (in the alter case the R2T may follow the received data). Is it then possible for the Data-In and R2T PDUs to be interleaved? In the chapter 9.16.1 is stated: For Status SNACK and DataACK, the Initiator Task Tag MUST be set to the reserved value 0xffffffff. In all other cases, the Initiator Task Tag field MUST be set to the Initiator Task Tag of the referenced command. For DataACK, the Target Transfer Tag has to contain a copy of the Target Transfer Tag and LUN provided with the SCSI Data-In PDU with the A bit set to 1. In all other cases, the Target Transfer Tag field MUST be set to the reserved value of 0xffffffff. Field: Data SNACK PDU: R2T SNACK PDU: Type = 0 0 Initiator Task Tag = Command Task Tag Command Task Tag Target Transfer Tag= 0xffffffff 0xffffffff If this is the case, I can't see how the initiator can request for Data or for R2T. Regards, Ivan Pavelka S3 From owner-ips@ece.cmu.edu Tue May 7 10:53:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10767 for ; Tue, 7 May 2002 10:53:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g47EAal29257 for ips-outgoing; Tue, 7 May 2002 10:10:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g47BYPw19033 for ; Tue, 7 May 2002 07:34:25 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02612; Tue, 7 May 2002 07:34:17 -0400 (EDT) Message-Id: <200205071134.HAA02612@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-fcencapsulation-08.txt,.pdf Date: Tue, 07 May 2002 07:34:15 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : FC Frame Encapsulation Author(s) : R. Weber, M. Rajagopal, F. Travostino, M. O'Donnell, C. Monia, M. Merhar Filename : draft-ietf-ips-fcencapsulation-08.txt,.pdf Pages : 17 Date : 06-May-02 This is the ips (IP Storage) working group draft describing the common Fibre Channel frame encapsulation format and a procedure for the measurement and calculation of frame transit time through the IP network. This specification is intended for use by any IETF protocol that encapsulates Fibre Channel (FC) frames. This draft describes a frame header containing information mandated for encapsulating, transmitting, de-encapsulating, and calculating the transit times of FC frames. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcencapsulation-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-fcencapsulation-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-fcencapsulation-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020506144056.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcencapsulation-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcencapsulation-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020506144056.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue May 7 12:50:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15386 for ; Tue, 7 May 2002 12:50:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g47GC5x09294 for ips-outgoing; Tue, 7 May 2002 12:12:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail1irv.inside.istor.com (host28.istor.com [66.134.214.28]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g47GC3w09290 for ; Tue, 7 May 2002 12:12:03 -0400 (EDT) content-class: urn:content-classes:message Subject: Associating initiator names with SCSI commands Date: Tue, 7 May 2002 09:11:47 -0700 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF290055519@mail1irv.inside.istor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Associating initiator names with SCSI commands Thread-Index: AcH14eNBPjho29rYT5Csnu6lDG9pSA== From: "Ken Craig" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g47GC3w09291 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I have a question concerning associating incoming SCSI commands with an initiator. I come from a parallel SCSI background and now find myself implementing a SCSI Target port in an iSCSI world. I have searched the mailing list archives for discussions on this subject but have been unable to find anything that succinctly answers my question so please bear with me. In the parallel SCSI world association of an initiator with a new command is very straight-forward as the initiator's ID is encapsulated in the Identify message that occurs with the SCSI Selection phase that precedes receiving the new command. When I read the latest version of the iSCSI draft (rev. 12) the only statement I seem to find that correlates to this association is in Section 2.2.3 on page 34 in the 2nd sentence of the 3rd paragraph. "Any persistent state (e.g., persistent reservations) on the target that is associated with a SCSI initiator port is identified based on the value pair (InitiatorName, ISID)." When I searched the mailing list archives I came across statements that said this association was done using ISID and TSID (now TSIH?) but I do not see these statements in the latest draft so I'm assuming that there was some reason this association method was dropped. My question is: In order to associate initiators with incoming commands to a SCSI Target do I have to compare the Initiator Name and ISID (up to ~268 bytes?) for every command I receive against a list of logged in initiators or is there another method using a lot fewer number of bytes? I had thought about using the IP address in the IP header but the draft seems to say that is not allowed because IP addresses can change. It seems like I must perform this potentially rather long comparison if I support multiple initiators because I can not be guaranteed that different initiators would not use the same ISID during their login. Am I wrong? Thanks in advance, Kenneth Ray Craig, Jr. From owner-ips@ece.cmu.edu Tue May 7 13:36:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17546 for ; Tue, 7 May 2002 13:36:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g47H1Mq13266 for ips-outgoing; Tue, 7 May 2002 13:01:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g47H1Kw13256 for ; Tue, 7 May 2002 13:01:20 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 1E42130706; Tue, 7 May 2002 13:01:19 -0400 (EDT) Date: Tue, 7 May 2002 10:00:03 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "Mallikarjun C." Cc: Subject: Re: iSCSI-boot: comments In-Reply-To: <012201c1f54a$ae898e40$edd52b0f@rose.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 6 May 2002, Mallikarjun C. wrote: > > > > - The IP address of the iSCSI boot client (IPv4 or IPv6) > > > > - The IP transport endpoint for the iSCSI service delivery port for > > the iSCSI boot server. If the transport is TCP, for example, this > > has to resolve to an IP address and a TCP port number. > > It is useful to note that iSCSI currently is defined only for TCP. While it is true now, I understand there has been some interested in adding support for iSCSI over sctp at some point in the future (obviously after we have iSCSI/tcp :-) . So it would be nice to at least have an idea for how to specify another transport in the future. Also, if the spec lists a way to specify transport now, whenever a new transport comes out, iscsi booting devices can make sure they aren't configured to use a transport they don't understand. :-) Take care, Bill From owner-ips@ece.cmu.edu Tue May 7 13:41:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17661 for ; Tue, 7 May 2002 13:41:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g47HVjR15643 for ips-outgoing; Tue, 7 May 2002 13:31:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp3.electric.net (smtp3.electric.net [216.129.90.16]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g47HVgw15638 for ; Tue, 7 May 2002 13:31:42 -0400 (EDT) Received: (qmail 66503 invoked from network); 7 May 2002 17:31:41 -0000 Received: from hm1.electric.net (216.129.90.33) by virusqueue.electric.net with SMTP; 7 May 2002 17:31:41 -0000 Received: from osmtp1.electric.net ([216.129.90.30]) by hm1.electric.net (NAVGW 2.5.2.9) with SMTP id M2002050710314129478 for ; Tue, 07 May 2002 10:31:41 -0700 Received: from [216.192.239.29] (helo=EGRodriguez) by osmtp1.electric.net with esmtp (Exim 3.22 #1) id 1758oO-000N84-04 for ips@ece.cmu.edu; Tue, 07 May 2002 10:31:40 -0700 From: "Elizabeth G. Rodriguez" To: Subject: iSCSI: DH-CHAP resolution Date: Tue, 7 May 2002 12:30:28 -0600 Message-ID: <009001c1f5f5$44a289e0$1defc0d8@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0091_01C1F5C2.FA0819E0" X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: High Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0091_01C1F5C2.FA0819E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, As mentioned previously, the consensus call for DH-CHAP was very close. As a result, Allision Mankin requested security expertise be consulted further prior to declaring consensus on the issue. The result is that security experts believe that DH-CHAP, while from the reading, DH-CHAP seems to be a worthy solution but, as many have stated both to me and the ADs privately as well as on the mailing list, it is unproven. As such, the decision has been made to NOT include DH-CHAP as an authentication mechanism for iSCSI. Now, the next question will be how will this effect the mandatory to implement authentication mechanism decision. The Transport ADs still have significant concerns about IPR issues as they relate to SRP as the mandatory to implement mechanism. They also feel that (as has been expressed on the mailing list) we do not have concrete requirements listed for the authentication mechanism. As such, Allison is in the process of calling a meeting between the Security and Transport ADs. This will likely occur some time late this week. I realize that everyone is anxious to close on this issue. I assure you it is being worked, and that the delay is related to making sure that iSCSI has the best chance of success, both in the IETF review process as well as the corporate environment. Thanks, Elizabeth Rodriguez IPS co-chair ------=_NextPart_000_0091_01C1F5C2.FA0819E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

As mentioned previously, the consensus call for = DH-CHAP was very close.  As a result, Allision Mankin requested security = expertise be consulted further prior to declaring consensus on the = issue.

The result is that security experts believe that = DH-CHAP, while from the reading, DH-CHAP seems to be a worthy solution but, as many have stated both to me = and the ADs privately as well as on the mailing list,

it is unproven.  As = such, the decision has been made to NOT include DH-CHAP as an authentication = mechanism for iSCSI.

 

Now, the next question will be how will this effect = the mandatory to implement authentication mechanism decision.  The = Transport ADs still have significant concerns about IPR issues as they relate to = SRP as the mandatory to implement mechanism.  They also feel that (as has = been expressed on the mailing list) we do not have concrete requirements = listed for the authentication mechanism.  As such, Allison is in the process = of calling a meeting between the Security and Transport ADs. This will likely occur = some time late = this week.

 

I realize that everyone is anxious to close on this issue.  I assure you it is being worked, and that the delay is = related to making sure that iSCSI has the best chance of success, both in the IETF = review process as well as the corporate environment.

 

Thanks,

 

Elizabeth Rodriguez

IPS co-chair

 

 

------=_NextPart_000_0091_01C1F5C2.FA0819E0-- From owner-ips@ece.cmu.edu Tue May 7 14:28:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19321 for ; Tue, 7 May 2002 14:28:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g47I3QU18617 for ips-outgoing; Tue, 7 May 2002 14:03:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g47I3Jw18608 for ; Tue, 7 May 2002 14:03:19 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel12.hp.com (Postfix) with ESMTP id 0C039E002D5; Tue, 7 May 2002 11:03:14 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id LAA03588; Tue, 7 May 2002 11:04:58 -0700 (PDT) Message-ID: <004a01c1f5f1$74a6daa0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Prasenjit Sarkar" Cc: References: Subject: Re: iSCSI-boot: comments Date: Tue, 7 May 2002 11:03:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > >1. Requirements > > > > 1. There must be no restriction of network topology between the iSCSI > > boot client and the boot server. > > Need to add "other than those in effect for establishing the iSCSI > session." > > +++ didnt follow - what topology restrictions are required to establish an > iSCSI session +++ None by iSCSI protocol design, but there may be installation constraints such as firewall traversal. The point of the comment was that the quoted sentence is too broad in scope, and (at least to me) meant that iSCSI boot must be allowed across firewalls/NATs etc. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com From owner-ips@ece.cmu.edu Tue May 7 14:29:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19341 for ; Tue, 7 May 2002 14:29:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g47I3UW18629 for ips-outgoing; Tue, 7 May 2002 14:03:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g47I3Rw18621 for ; Tue, 7 May 2002 14:03:27 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g47I3MvA063980; Tue, 7 May 2002 14:03:22 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g47I2ZZ80600; Tue, 7 May 2002 12:02:35 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: DH-CHAP resolution To: "Elizabeth G. Rodriguez" Cc: X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Tue, 7 May 2002 10:58:51 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/07/2002 12:02:35 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g47I3Rw18623 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Does this mean that DH-CHAP, is not to be even a MAY implement? Or was your statement only about it being a MUST? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Elizabeth G. Rodriguez" @ece.cmu.edu on 05/07/2002 11:30:28 AM Sent by: owner-ips@ece.cmu.edu To: cc: Subject: iSCSI: DH-CHAP resolution All, As mentioned previously, the consensus call for DH-CHAP was very close.  As a result, Allision Mankin requested security expertise be consulted further prior to declaring consensus on the issue. The result is that security experts believe that DH-CHAP, while from the reading, DH-CHAP seems to be a worthy solutionbut, as many have stated both to me and the ADs privately as well as on the mailing list, it is unproven.  As such, the decision has been made to NOT include DH-CHAP as an authentication mechanism for iSCSI. Now, the next question will be how will this effect the mandatory to implement authentication mechanism decision.  The Transport ADs still have significant concerns about IPR issues as they relate to SRP as the mandatory to implement mechanism.  They also feel that (as has been expressed on the mailing list) we do not have concrete requirements listed for the authentication mechanism.  As such, Allison is in the process of calling a meeting between the Security and Transport ADs. This will likely occur some time late this week. I realize that everyone is anxious to close on this issue.  I assure you it is being worked, and that the delay is related to making sure that iSCSI has the best chance of success, both in the IETF review process as well as the corporate environment. Thanks, Elizabeth Rodriguez IPS co-chair From owner-ips@ece.cmu.edu Tue May 7 14:31:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19533 for ; Tue, 7 May 2002 14:31:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g47Hu2l17992 for ips-outgoing; Tue, 7 May 2002 13:56:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g47Htxw17985 for ; Tue, 7 May 2002 13:55:59 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel6.hp.com (Postfix) with ESMTP id 9BF4D698; Tue, 7 May 2002 13:55:53 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id KAA00835; Tue, 7 May 2002 10:57:38 -0700 (PDT) Message-ID: <004201c1f5f0$6dd423a0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , References: <00ca01c1f313$0296ccd0$edd52b0f@rose.hp.com> <3CD694BC.E01A5A32@compuserve.com> <005301c1f525$e162fb00$edd52b0f@rose.hp.com> <3CD6E797.845F0095@compuserve.com> Subject: Re: FCIP: Comment 120 Date: Tue, 7 May 2002 10:55:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, Upon further thought, it appears to me that the "Destination FC/FCIP Entity Identifier" should be sent and received in the FSF. I can not think of a way currently to build an FCIP_LEP with multiple FCIP_DEs - for ex., how would a sender indicate his intention to add a TCP connection to an FC/FCIP Entity Pair that it's already communicating with? Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Ralph Weber" To: Cc: "Mallikarjun C." Sent: Monday, May 06, 2002 1:29 PM Subject: Re: FCIP: Comment 120 > Mallikarjun, > > Oops! This mistake is on me. > > The Source FC Fabric Entity World Wide Name field DOES NOT contain the > WWN of the FC Entity. Rather, it contains the "Fibre Channel Name_Identifier > [FC-FS] for the FC Fabric entity associated with the FC Entity FCIP Entity > pair." > > Two corrections are needed in the picture that I led you to believe in: > > 1) The "FC Fabric entity" IS NOT the FC Entity, it is the FC product > (switch or whatever) that contains one or more FC Entities; and > 2) There is no 1-to-n relationship between FC Entities and FCIP Entities, > in fact, they come in 1-to-1 one matched pairs. > > Note that these corrections further strengthen the argument that the > 1-to-n discussion belongs in FC-BB-2, since the multiplicity relationship > really is farther inside FC constructs than I first suggested. > > Hope this helps. > > .Ralph > > "Mallikarjun C." wrote: > > > > > Ralph, > > > > > The requested figure relies on Fibre Channel concepts and thus appears > > > in a T11 document, FC-BB-2, ftp://ftp.t11.org/t11/pub/fc/bb-2/02-030v1.pdf. > > > See Figure 23 on PDF page 87, or Figure 26 on PDF page 94. > > > > Thanks for the reference, but unfortunately it doesn't help make the point > > that there is 1-to-n association between FC Entity and FCIP Entity. > > > > Given that FCIP is an RFC that defines these Entities and their relationships > > in its own right, my suggestion would continue to be that the association be depicted > > in an architectural model diagram. It could be as simple as showing a shadow ASCII > > box to the FCIP Entity box. I will leave it here up to you and Co-Chairs to make > > the call. > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > ----- Original Message ----- > > From: "Ralph Weber" > > To: > > Cc: "Mallikarjun C." > > Sent: Monday, May 06, 2002 7:35 AM > > Subject: Re: FCIP: Comment 120 > > > > > Mallikarjun, > > > > > > > >... the "FC/FCIP Entity Identifier" is unique only within the scope > > > > >of the given FC Entity's WWN. ... the model allows multiple FCIP > > > > >Entities to be associated with the FC Fabric Entity WWN. > > > > > > > > If that is so, please add an architectural model diagram (similar to > > > > Figure 3, or perhaps convert Figure 3 into) which clearly shows this > > > > 1-to-n association. > > > > > > > > This is the only hint in the document (at least that I found) which > > > > suggests the stated possibility. Figure 3 with 1-to-1 association almost > > > > seemed like the architectural model, but on careful reading, is only > > > > an example. > > > > > > The fact that the "FC/FCIP Entity Identifier" is unique only within > > > the scope of a given FC Entity's WWN seems to be clearly stated in the > > > definition of the field: > > > > > > "The Source FC/FCIP Entity Identifier field SHALL contain a unique > > > identifier for the FC Entity FCIP Entity pair that generates (as opposed > > > to echoes) the Special Frame. The value is assigned by the FC Fabric > > > entity whose world wide name appears in the Source FC Fabric Entity World > > > Wide Name field. > > > > > > "Note: The combination of the Source FC Entity World Wide Name and Source > > > FCIP Entity Identifier fields uniquely identifies every FC Entity FCIP > > > Entity pair in the IP Network." > > > > > > The requested figure relies on Fibre Channel concepts and thus appears > > > in a T11 document, FC-BB-2, ftp://ftp.t11.org/t11/pub/fc/bb-2/02-030v1.pdf. > > > See Figure 23 on PDF page 87, or Figure 26 on PDF page 94. > > > > > > Thanks. > > > > > > .Ralph > > > > > > "Mallikarjun C." wrote: > > > > > > > > > > > Ralph, > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.pdf > > > > .... > > > > > Please review these comments resolutions to ensure that > > > > > the desired changes are described. > > > > > > > > Sorry for the delayed review, I have additional comments on wglc-01 > > > > for Comment 120. > > > > > > > > Regards. > > > > -- > > > > Mallikarjun > > > > > > > > Mallikarjun Chadalapaka > > > > Networked Storage Architecture > > > > Network Storage Solutions Organization > > > > Hewlett-Packard MS 5668 > > > > Roseville CA 95747 > > > > cbm@rose.hp.com > > > > > > > > >Comment 120 > > > > >> 8. The FCIP Special Frame > > > > >...... > > > > >> Note: The combination of the Source FC Entity World Wide Name and > > > > >> Source FCIP Entity Identifier fields uniquely identifies every FC > > > > >> Entity FCIP Entity pair in the IP Network. > > > > >.... > > > > >- Also I take it that the "FC/FCIP Entity Identifier" is unique only > > > > >within the scope of the given FC Entity's WWN. So, does the model > > > > >allow multiple FCIP Entities to be associated with the FC Fabric > > > > >Entity WWN? > > > > >.... > > > > >Response to the second bullet: Yes, the "FC/FCIP Entity Identifier" > > > > >is unique only within the scope of the given FC Entity's WWN. Yes, > > > > >the model allows multiple FCIP Entities to be associated with the FC > > > > >Fabric Entity WWN. > > > > > > > > > > > > > If that is so, please add an architectural model diagram (similar to > > > > Figure 3, or perhaps convert Figure 3 into) which clearly shows this > > > > 1-to-n association. > > > > > > > > This is the only hint in the document (at least that I found) which > > > > suggests the stated possibility. Figure 3 with 1-to-1 association almost > > > > seemed like the architectural model, but on careful reading, is only > > > > an example. > > > > > > > From owner-ips@ece.cmu.edu Tue May 7 15:31:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21557 for ; Tue, 7 May 2002 15:31:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g47J2UN23820 for ips-outgoing; Tue, 7 May 2002 15:02:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g47J2Sw23814 for ; Tue, 7 May 2002 15:02:28 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g47J2D912136; Tue, 7 May 2002 15:02:13 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g47J2C709481; Tue, 7 May 2002 15:02:12 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Tue, 7 May 2002 15:01:11 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293784E@CORPMX14> From: Black_David@emc.com To: cmonia@NishanSystems.com, ips@ece.cmu.edu Cc: travos@nortelnetworks.com Subject: RE: iFCP: Responses to David Black iFCP Technical review comment s Date: Tue, 7 May 2002 12:19:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-PerlMx-Spam: Gauge=XXIIIIIII, Probability=27%, Report="NO_REAL_NAME, SUBJ_HAS_SPACES" Sender: owner-ips@ece.cmu.edu Precedence: bulk Sorry this took so long; I have two issues regarding the proposed resolutions of my comments. -- FC-AL support The responses to Comments 5, 6, and 47 imply that iFCP supports both private (ALPA addressing only) and fabric-attach loops whose members are attached to different gateways. I don't understand how this can work because it requires forwarding FC-AL loop initialization ELSs (LINIT) among gateways, but those ELSs do not have a usable destination port (they're passed directly among neighbors), and the ports involved in the loop have not performed either FLOGI or PLOGI when the loop is initializing. So how does a gateway figure out whether and where to forward a LINIT that it receives? I can figure out how to make this work if only fabric-attached loops are supported and loops never span gateways, but even that will need some explanation. --- Multiple Gateways The proposed new text is: For either iFCP fabric type, an N_PORT may be behind more than one gateway provided: a) One gateway becomes the 'principal switch' and b) All gateways attached to a given gateway region coordinate the assignment of N_PORT IDs and N_PORT aliases such that each N_PORT has one and only one assigned address. The above will be added to the specification. The implications of multiple gateways for the same N_Port on iSNS servers and other gateways needs to be discussed. This may be short, because if the Port's Network Address is registered with iSNS as a consequence of FLOGI, only one address will be registered because FLOGI only occurs once, and hence all traffic to the N_Port will flow through one gateway. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue May 7 15:33:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21653 for ; Tue, 7 May 2002 15:33:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g47ItrR23268 for ips-outgoing; Tue, 7 May 2002 14:55:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([65.68.235.61]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g47Itmw23258 for ; Tue, 7 May 2002 14:55:48 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F5F8.CC6A3D61" Subject: RE: iSCSI: DH-CHAP resolution Disposition-Notification-To: "Lee Xing" Date: Tue, 7 May 2002 13:55:47 -0500 Message-ID: Thread-Topic: iSCSI: DH-CHAP resolution Thread-Index: AcH17z1F+52kEBh0S66wetfkr6/hUwACGrEw From: "Lee Xing" To: "Elizabeth G. Rodriguez" Cc: Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1F5F8.CC6A3D61 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Compare with CHAP, is DH-CHAP any better? If it is, why we don't want = to include DH-CHAP but CHAP as an authentication mechanism for iSCSI? =20 Thanks. =20 =20 Lee -----Original Message----- From: Elizabeth G. Rodriguez [mailto:Elizabeth.G.Rodriguez@123mail.net] Sent: Tuesday, May 07, 2002 1:30 PM To: ips@ece.cmu.edu Subject: iSCSI: DH-CHAP resolution Importance: High All, =20 As mentioned previously, the consensus call for DH-CHAP was very close. = As a result, Allision Mankin requested security expertise be consulted = further prior to declaring consensus on the issue. The result is that security experts believe that DH-CHAP, while from the = reading, DH-CHAP seems to be a worthy solution but, as many have stated = both to me and the ADs privately as well as on the mailing list, it is unproven. As such, the decision has been made to NOT include = DH-CHAP as an authentication mechanism for iSCSI. =20 Now, the next question will be how will this effect the mandatory to = implement authentication mechanism decision. The Transport ADs still = have significant concerns about IPR issues as they relate to SRP as the = mandatory to implement mechanism. They also feel that (as has been = expressed on the mailing list) we do not have concrete requirements = listed for the authentication mechanism. As such, Allison is in the = process of calling a meeting between the Security and Transport ADs. = This will likely occur some time late this week. =20 I realize that everyone is anxious to close on this issue. I assure you = it is being worked, and that the delay is related to making sure that = iSCSI has the best chance of success, both in the IETF review process as = well as the corporate environment. =20 Thanks, =20 Elizabeth Rodriguez IPS co-chair =20 =20 ------_=_NextPart_001_01C1F5F8.CC6A3D61 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Compare with CHAP, is DH-CHAP any better?  If it is, = why we=20 don't want to include DH-CHAP but CHAP as an authentication mechanism = for=20 iSCSI?
 
Thanks.
 
 
Lee
-----Original Message-----
From: Elizabeth G. = Rodriguez=20 [mailto:Elizabeth.G.Rodriguez@123mail.net]
Sent: Tuesday, = May 07,=20 2002 1:30 PM
To: ips@ece.cmu.edu
Subject: iSCSI: = DH-CHAP=20 resolution
Importance: High

All,

 

As mentioned previously, = the=20 consensus call for DH-CHAP was very close.  As a result, Allision = Mankin=20 requested security expertise be consulted further prior to declaring = consensus=20 on the issue.

The result is that = security=20 experts believe that DH-CHAP, while from the reading, DH-CHAP seems to = be a=20 worthy solution but,=20 as many have stated both to me and the ADs privately as = well as=20 on the mailing list,

it is=20 unproven.  As such, the decision has been made to NOT include = DH-CHAP as=20 an authentication mechanism for iSCSI.

 

Now, the next question = will be how=20 will this effect the mandatory to implement authentication mechanism=20 decision.  The Transport ADs still have significant concerns = about IPR=20 issues as they relate to SRP as the mandatory to implement = mechanism. =20 They also feel that (as has been expressed on the mailing list) we do = not have=20 concrete requirements listed for the authentication mechanism.  = As such,=20 Allison is in the process of calling a meeting between the Security = and=20 Transport ADs. This will likely occur some time late this week.

 

I realize that everyone = is anxious=20 to close on this issue.  I assure you it is being worked, and = that the=20 delay is related to making sure that iSCSI has the best chance of = success,=20 both in the IETF review process as well as the corporate=20 environment.

 

Thanks,

 

Elizabeth=20 Rodriguez

IPS = co-chair

 

 

------_=_NextPart_001_01C1F5F8.CC6A3D61-- From owner-ips@ece.cmu.edu Tue May 7 16:05:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22795 for ; Tue, 7 May 2002 16:05:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g47JVgL26224 for ips-outgoing; Tue, 7 May 2002 15:31:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c003.snv.cp.net (h023.c003.snv.cp.net [209.228.32.237]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g47JVfw26220 for ; Tue, 7 May 2002 15:31:41 -0400 (EDT) Received: (cpmta 4134 invoked from network); 7 May 2002 12:31:34 -0700 Received: from 64.130.130.105 (HELO littlejoy) by smtp.telocity.com (209.228.32.237) with SMTP; 7 May 2002 12:31:34 -0700 X-Sent: 7 May 2002 19:31:34 GMT From: "Douglas Otis" To: Cc: "Rdma" Subject: RE: iSCSI-boot: comments Date: Tue, 7 May 2002 12:31:28 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill, I agree. For SCTP-DDP there should be a generalized protocol negotiation similar to an RPC port mapper to identify the PPI and Stream. If so, then there is just a need to identify the transport perhaps using an IANA registration. SCTP-X, SCTP-DDP, DDCP, etc... -Doug On May 7, 2002 10:00 AM Bill StudenMund (wrstuden@wasabisystems.com) wrote: > > On Mon, 6 May 2002, Mallikarjun C. wrote: > > > > > > > - The IP address of the iSCSI boot client (IPv4 or IPv6) > > > > > > - The IP transport endpoint for the iSCSI service delivery port for > > > the iSCSI boot server. If the transport is TCP, for example, this > > > has to resolve to an IP address and a TCP port number. > > > > It is useful to note that iSCSI currently is defined only for TCP. > > While it is true now, I understand there has been some interested in > adding support for iSCSI over sctp at some point in the future (obviously > after we have iSCSI/tcp :-) . So it would be nice to at least have an idea > for how to specify another transport in the future. Also, if the spec > lists a way to specify transport now, whenever a new transport comes out, > iscsi booting devices can make sure they aren't configured to use a > transport they don't understand. :-) > > Take care, > > Bill > From owner-ips@ece.cmu.edu Tue May 7 17:41:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24900 for ; Tue, 7 May 2002 17:41:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g47L3MB03735 for ips-outgoing; Tue, 7 May 2002 17:03:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g47L3Kw03731 for ; Tue, 7 May 2002 17:03:20 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 57DF630706; Tue, 7 May 2002 17:03:20 -0400 (EDT) Date: Tue, 7 May 2002 14:02:04 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Ken Craig Cc: Subject: Re: Associating initiator names with SCSI commands In-Reply-To: <7D036BD3216A084DB1BD9D62BCEAF290055519@mail1irv.inside.istor.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 7 May 2002, Ken Craig wrote: > In the parallel SCSI world association of an > initiator with a new command is very > straight-forward as the initiator's ID is > encapsulated in the Identify message that > occurs with the SCSI Selection phase that > precedes receiving the new command. It's straight-forward here too. See paragraph 2 of section 2.2.3 (the one you mention). Each connection can be part of at most one session, and each session forms an I_T nexus. Thus only one initiator can send commands down a given connection. > When I read the latest version of the iSCSI > draft (rev. 12) the only statement I seem to > find that correlates to this association is > in Section 2.2.3 on page 34 in the 2nd > sentence of the 3rd paragraph. > > "Any persistent state (e.g., persistent reservations) > on the target that is associated with a SCSI > initiator port is identified based on the > value pair (InitiatorName, ISID)." > > When I searched the mailing list archives I > came across statements that said this > association was done using ISID and TSID (now > TSIH?) but I do not see these statements in the > latest draft so I'm assuming that there was some > reason this association method was dropped. Take a look at the table in the middle of page 69, section 4.3.1 Login start, to see what is going on. Both ISID and TSIH only make sense in terms of a given initiator or target; they are not world-unique numbers. > My question is: > In order to associate initiators with incoming > commands to a SCSI Target do I have to compare > the Initiator Name and ISID (up to ~268 bytes?) > for every command I receive against a list of > logged in initiators or is there another method > using a lot fewer number of bytes? No. As above, only one initiator will be sending commands over a connection. Since you know what connection the command came over, you implicitly know the initiator (and the session too). Take care, Bill From owner-ips@ece.cmu.edu Wed May 8 06:38:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00138 for ; Wed, 8 May 2002 06:38:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g489wSq21936 for ips-outgoing; Wed, 8 May 2002 05:58:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g489wPw21931; Wed, 8 May 2002 05:58:25 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g489wDIB020790; Wed, 8 May 2002 11:58:13 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g489w6g38924; Wed, 8 May 2002 11:58:11 +0200 Subject: Re: Associating initiator names with SCSI commands To: "Ken Craig" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Tue, 7 May 2002 22:12:19 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 08/05/2002 12:58:12 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk No - the session is associated with the initiator - if you record the session on which you received the command you have the association. How you represent internally the session is an implementation issue - but I assume you will not uses the names for that! Julo |---------+----------------------------> | | "Ken Craig" | | | | | | Sent by: | | | owner-ips@ece.cmu| | | .edu | | | | | | | | | 05/07/2002 07:11 | | | PM | | | Please respond to| | | "Ken Craig" | | | | |---------+----------------------------> >---------------------------------------------------------------------------------------------------------------| | | | To: | | cc: | | Subject: Associating initiator names with SCSI commands | | | | | >---------------------------------------------------------------------------------------------------------------| I have a question concerning associating incoming SCSI commands with an initiator. I come from a parallel SCSI background and now find myself implementing a SCSI Target port in an iSCSI world. I have searched the mailing list archives for discussions on this subject but have been unable to find anything that succinctly answers my question so please bear with me. In the parallel SCSI world association of an initiator with a new command is very straight-forward as the initiator's ID is encapsulated in the Identify message that occurs with the SCSI Selection phase that precedes receiving the new command. When I read the latest version of the iSCSI draft (rev. 12) the only statement I seem to find that correlates to this association is in Section 2.2.3 on page 34 in the 2nd sentence of the 3rd paragraph. "Any persistent state (e.g., persistent reservations) on the target that is associated with a SCSI initiator port is identified based on the value pair (InitiatorName, ISID)." When I searched the mailing list archives I came across statements that said this association was done using ISID and TSID (now TSIH?) but I do not see these statements in the latest draft so I'm assuming that there was some reason this association method was dropped. My question is: In order to associate initiators with incoming commands to a SCSI Target do I have to compare the Initiator Name and ISID (up to ~268 bytes?) for every command I receive against a list of logged in initiators or is there another method using a lot fewer number of bytes? I had thought about using the IP address in the IP header but the draft seems to say that is not allowed because IP addresses can change. It seems like I must perform this potentially rather long comparison if I support multiple initiators because I can not be guaranteed that different initiators would not use the same ISID during their login. Am I wrong? Thanks in advance, Kenneth Ray Craig, Jr. From owner-ips@ece.cmu.edu Wed May 8 10:51:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10104 for ; Wed, 8 May 2002 10:51:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g48DLmm01776 for ips-outgoing; Wed, 8 May 2002 09:21:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g48DLiw01763 for ; Wed, 8 May 2002 09:21:44 -0400 (EDT) Received: (from mailgate@localhost) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id JAA29475 for ips@ece.cmu.edu; Wed, 8 May 2002 09:21:38 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkk-vty28.as.wcom.net [206.175.239.28]) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id JAA29380; Wed, 8 May 2002 09:21:27 -0400 (EDT) Message-ID: <3CD92786.40BD4B3@compuserve.com> Date: Wed, 08 May 2002 08:26:30 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu CC: "Mallikarjun C." Subject: Re: FCIP: Comment 120 References: <00ca01c1f313$0296ccd0$edd52b0f@rose.hp.com> <3CD694BC.E01A5A32@compuserve.com> <005301c1f525$e162fb00$edd52b0f@rose.hp.com> <3CD6E797.845F0095@compuserve.com> <004201c1f5f0$6dd423a0$edd52b0f@rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit "Mallikarjun C." wrote: > Upon further thought, it appears to me that the "Destination FC/FCIP > Entity Identifier" should be sent and received in the FSF. I can not > think of a way currently to build an FCIP_LEP with multiple FCIP_DEs > - for ex., how would a sender indicate his intention to add a TCP > connection to an FC/FCIP Entity Pair that it's already communicating > with? I would think that sending a TCP connect request to the same IP Address and Port as was used in the previous TCP connect request would achieve the intended result. The only alternative would be to REQUIRE SLP interrogation before every TCP connect request, and even then there would be zero assurance that the IP universe would not shape shift between the SLP activities and the TCP connect request. Surely, there is some stability in IP addressing. Thanks. .Ralph From owner-ips@ece.cmu.edu Wed May 8 14:00:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18941 for ; Wed, 8 May 2002 14:00:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g48HFgV18273 for ips-outgoing; Wed, 8 May 2002 13:15:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g48HFew18266 for ; Wed, 8 May 2002 13:15:40 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel8.hp.com (Postfix) with ESMTP id 42976A00805; Wed, 8 May 2002 13:15:34 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id KAA22926; Wed, 8 May 2002 10:17:16 -0700 (PDT) Message-ID: <002301c1f6b3$f4d4a500$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , References: <00ca01c1f313$0296ccd0$edd52b0f@rose.hp.com> <3CD694BC.E01A5A32@compuserve.com> <005301c1f525$e162fb00$edd52b0f@rose.hp.com> <3CD6E797.845F0095@compuserve.com> <004201c1f5f0$6dd423a0$edd52b0f@rose.hp.com> <3CD92786.40BD4B3@compuserve.com> Subject: Re: FCIP: Comment 120 Date: Wed, 8 May 2002 10:15:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I would think that sending a TCP connect request to the same IP Address > and Port as was used in the previous TCP connect request would achieve > the intended result. Not a correct assumption. You are using names (FC Fabric Entity WWN is a name. The FC/FCIP Entity Identifier is a name unique within the scope of the FC Fabric Entity.) in FSF only because IP addresses/TCP port associations cannot provide the FCIP-end2end assurance that the right entities are talking. Besides, I don't see anything in the current document that prohibits multiple FC/FCIP Entity Pairs from sharing the same IP/TCP address/port - and I believe that is the right architectural approach. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Ralph Weber" To: Cc: "Mallikarjun C." Sent: Wednesday, May 08, 2002 6:26 AM Subject: Re: FCIP: Comment 120 > "Mallikarjun C." wrote: > > > Upon further thought, it appears to me that the "Destination FC/FCIP > > Entity Identifier" should be sent and received in the FSF. I can not > > think of a way currently to build an FCIP_LEP with multiple FCIP_DEs > > - for ex., how would a sender indicate his intention to add a TCP > > connection to an FC/FCIP Entity Pair that it's already communicating > > with? > > I would think that sending a TCP connect request to the same IP Address > and Port as was used in the previous TCP connect request would achieve > the intended result. > > The only alternative would be to REQUIRE SLP interrogation before every > TCP connect request, and even then there would be zero assurance that > the IP universe would not shape shift between the SLP activities and > the TCP connect request. > > Surely, there is some stability in IP addressing. > > Thanks. > > .Ralph > > From owner-ips@ece.cmu.edu Wed May 8 14:43:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20025 for ; Wed, 8 May 2002 14:43:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g48I2cH21480 for ips-outgoing; Wed, 8 May 2002 14:02:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g48I2Zw21470 for ; Wed, 8 May 2002 14:02:35 -0400 (EDT) Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 11:02:29 -0700 Message-ID: <45BEF1D68145D51186C100B0D0AABE659E00C6@med.corp.rhapsodynetworks.com> From: Dennis Young To: ips@ece.cmu.edu Subject: iSCSI: ImmediateData negotiation Date: Wed, 8 May 2002 11:02:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I have a question on how a target should respond to "ImmediateData=Yes" from an initiator if the target doesn't support ImmediateData. Here are two scenarios: Scenario 1: /* The target here only considers the value offered by the * initiator, if the value is not acceptable, it simply * rejects it rather than suggesting another value. */ I->T: ImmediateData=Yes T->I: ImmediateData=Reject I->T: ImmediateData=No /* Should initiator offer No? */ T->I: ImmediateData=No Scenario 2: /* The target here simply returns a value it supports * without rejecting the value offered by the initiator. */ I->T: ImmediateData=Yes T->I: ImmediateData=No I->T: ImmediateData=No /* Should initiator reply No? */ T->I: ImmediateData=No Based on section 4.2 of draft 12, I believe scenario 1 is correct, right? In addition, does the Result function of a text parameter (AND or OR) make a difference here? Thanks, Dennis From owner-ips@ece.cmu.edu Wed May 8 14:44:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20061 for ; Wed, 8 May 2002 14:44:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g48I8Yh21906 for ips-outgoing; Wed, 8 May 2002 14:08:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g48I8Ww21900 for ; Wed, 8 May 2002 14:08:32 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 527DA2A; Wed, 8 May 2002 12:08:31 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 7C240410; Wed, 8 May 2002 12:08:29 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 08 May 2002 12:08:22 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 12:08:21 -0600 Message-ID: <9F8400020EC5D311AF62009027C396160902C36A@axcs09.cos.agilent.com> From: kevin_lemay@agilent.com To: dyoung@rhapsodynetworks.com, ips@ece.cmu.edu Subject: RE: iSCSI: ImmediateData negotiation Date: Wed, 8 May 2002 12:08:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Actually, both are incorrect. It is illegal to negotiate a parameter more than once during a login. The correct sequence is: I->T: ImmediateData=Yes T->I: ImmediateData=No Both initiator and target must send ImmediateData=Yes for immediate data to be used. Kevin Lemay -----Original Message----- From: Dennis Young [mailto:dyoung@rhapsodynetworks.com] Sent: Wednesday, May 08, 2002 11:02 AM To: ips@ece.cmu.edu Subject: iSCSI: ImmediateData negotiation I have a question on how a target should respond to "ImmediateData=Yes" from an initiator if the target doesn't support ImmediateData. Here are two scenarios: Scenario 1: /* The target here only considers the value offered by the * initiator, if the value is not acceptable, it simply * rejects it rather than suggesting another value. */ I->T: ImmediateData=Yes T->I: ImmediateData=Reject I->T: ImmediateData=No /* Should initiator offer No? */ T->I: ImmediateData=No Scenario 2: /* The target here simply returns a value it supports * without rejecting the value offered by the initiator. */ I->T: ImmediateData=Yes T->I: ImmediateData=No I->T: ImmediateData=No /* Should initiator reply No? */ T->I: ImmediateData=No Based on section 4.2 of draft 12, I believe scenario 1 is correct, right? In addition, does the Result function of a text parameter (AND or OR) make a difference here? Thanks, Dennis From owner-ips@ece.cmu.edu Wed May 8 15:25:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21344 for ; Wed, 8 May 2002 15:25:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g48IjRH24690 for ips-outgoing; Wed, 8 May 2002 14:45:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g48IjPw24684 for ; Wed, 8 May 2002 14:45:25 -0400 (EDT) Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 11:45:19 -0700 Message-ID: <45BEF1D68145D51186C100B0D0AABE659E00C8@med.corp.rhapsodynetworks.com> From: Dennis Young To: "'kevin_lemay@agilent.com'" , ips@ece.cmu.edu Subject: RE: iSCSI: ImmediateData negotiation Date: Wed, 8 May 2002 11:45:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The following paragraphs in section 4.2 of draft 12 lead me to believe otherwise: ... The responding party answers with the first value that it supports and is allowed to use for the specfic originator selected from the originator list. ... An offer of a value not admissible MAY be answered with the constant "Reject". My interpretation of the two paragraphs is that the responding party can only respond with value offered in the originator list, and since "Yes" is not admissible, responding with "Reject" seems correct. Dennis >-----Original Message----- >From: kevin_lemay@agilent.com [mailto:kevin_lemay@agilent.com] >Sent: Wednesday, May 08, 2002 11:08 AM >To: dyoung@rhapsodynetworks.com; ips@ece.cmu.edu >Subject: RE: iSCSI: ImmediateData negotiation > > >Actually, both are incorrect. It is illegal to negotiate a >parameter more >than once during a login. The correct sequence is: > >I->T: ImmediateData=Yes >T->I: ImmediateData=No > >Both initiator and target must send ImmediateData=Yes for >immediate data to >be used. > >Kevin Lemay > >-----Original Message----- >From: Dennis Young [mailto:dyoung@rhapsodynetworks.com] >Sent: Wednesday, May 08, 2002 11:02 AM >To: ips@ece.cmu.edu >Subject: iSCSI: ImmediateData negotiation > > >I have a question on how a target should respond to >"ImmediateData=Yes" from an initiator if the target >doesn't support ImmediateData. Here are two scenarios: > >Scenario 1: >/* The target here only considers the value offered by the > * initiator, if the value is not acceptable, it simply > * rejects it rather than suggesting another value. > */ >I->T: ImmediateData=Yes >T->I: ImmediateData=Reject >I->T: ImmediateData=No /* Should initiator offer No? */ >T->I: ImmediateData=No > >Scenario 2: >/* The target here simply returns a value it supports > * without rejecting the value offered by the initiator. > */ >I->T: ImmediateData=Yes >T->I: ImmediateData=No >I->T: ImmediateData=No /* Should initiator reply No? */ >T->I: ImmediateData=No > >Based on section 4.2 of draft 12, I believe scenario 1 is >correct, right? > >In addition, does the Result function of a text parameter (AND >or OR) make a >difference here? > >Thanks, >Dennis > From owner-ips@ece.cmu.edu Wed May 8 15:25:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21359 for ; Wed, 8 May 2002 15:25:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g48IurM25706 for ips-outgoing; Wed, 8 May 2002 14:56:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g48Iuow25700 for ; Wed, 8 May 2002 14:56:50 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id E8A2CC896; Wed, 8 May 2002 12:56:49 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id BF1CD290; Wed, 8 May 2002 12:56:49 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 08 May 2002 12:56:49 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 12:56:49 -0600 Message-ID: <9F8400020EC5D311AF62009027C396160902C36C@axcs09.cos.agilent.com> From: kevin_lemay@agilent.com To: dyoung@rhapsodynetworks.com, ips@ece.cmu.edu Subject: RE: iSCSI: ImmediateData negotiation Date: Wed, 8 May 2002 12:56:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Dennis, That paragraph refers to "List" parameters and not boolean operators. Look over to the next page.... "For Boolean negotiations (keys taking the values Yes or No), the responding party MUST respond with the required key and the result of the negotiation when the received value does not determine that result by itself. The last value transmitted becomes the negotiation result. The rules for selecting the value with which to respond are expressed as Boolean functions of the value received and the value that the responding party would select in the absence of knowledge of the received value." Kevin Lemay -----Original Message----- From: Dennis Young [mailto:dyoung@rhapsodynetworks.com] Sent: Wednesday, May 08, 2002 11:45 AM To: 'kevin_lemay@agilent.com'; ips@ece.cmu.edu Subject: RE: iSCSI: ImmediateData negotiation The following paragraphs in section 4.2 of draft 12 lead me to believe otherwise: ... The responding party answers with the first value that it supports and is allowed to use for the specfic originator selected from the originator list. ... An offer of a value not admissible MAY be answered with the constant "Reject". My interpretation of the two paragraphs is that the responding party can only respond with value offered in the originator list, and since "Yes" is not admissible, responding with "Reject" seems correct. Dennis >-----Original Message----- >From: kevin_lemay@agilent.com [mailto:kevin_lemay@agilent.com] >Sent: Wednesday, May 08, 2002 11:08 AM >To: dyoung@rhapsodynetworks.com; ips@ece.cmu.edu >Subject: RE: iSCSI: ImmediateData negotiation > > >Actually, both are incorrect. It is illegal to negotiate a >parameter more >than once during a login. The correct sequence is: > >I->T: ImmediateData=Yes >T->I: ImmediateData=No > >Both initiator and target must send ImmediateData=Yes for >immediate data to >be used. > >Kevin Lemay > >-----Original Message----- >From: Dennis Young [mailto:dyoung@rhapsodynetworks.com] >Sent: Wednesday, May 08, 2002 11:02 AM >To: ips@ece.cmu.edu >Subject: iSCSI: ImmediateData negotiation > > >I have a question on how a target should respond to >"ImmediateData=Yes" from an initiator if the target >doesn't support ImmediateData. Here are two scenarios: > >Scenario 1: >/* The target here only considers the value offered by the > * initiator, if the value is not acceptable, it simply > * rejects it rather than suggesting another value. > */ >I->T: ImmediateData=Yes >T->I: ImmediateData=Reject >I->T: ImmediateData=No /* Should initiator offer No? */ >T->I: ImmediateData=No > >Scenario 2: >/* The target here simply returns a value it supports > * without rejecting the value offered by the initiator. > */ >I->T: ImmediateData=Yes >T->I: ImmediateData=No >I->T: ImmediateData=No /* Should initiator reply No? */ >T->I: ImmediateData=No > >Based on section 4.2 of draft 12, I believe scenario 1 is >correct, right? > >In addition, does the Result function of a text parameter (AND >or OR) make a >difference here? > >Thanks, >Dennis > From owner-ips@ece.cmu.edu Wed May 8 16:45:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23408 for ; Wed, 8 May 2002 16:45:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g48JxYs01372 for ips-outgoing; Wed, 8 May 2002 15:59:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g48JxWw01365 for ; Wed, 8 May 2002 15:59:32 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48JxSc3021976; Wed, 8 May 2002 15:59:28 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48JxRf90172; Wed, 8 May 2002 13:59:27 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: ImmediateData negotiation To: kevin_lemay@agilent.com Cc: dyoung@rhapsodynetworks.com, ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Wed, 8 May 2002 12:58:01 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/08/2002 01:59:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I think in the case mentioned, the Target will probably be the first sender of the ImmediateData keyword and it will send No, because Yes is the default. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com kevin_lemay@agilent.com@ece.cmu.edu on 05/08/2002 11:56:47 AM Sent by: owner-ips@ece.cmu.edu To: dyoung@rhapsodynetworks.com, ips@ece.cmu.edu cc: Subject: RE: iSCSI: ImmediateData negotiation Dennis, That paragraph refers to "List" parameters and not boolean operators. Look over to the next page.... "For Boolean negotiations (keys taking the values Yes or No), the responding party MUST respond with the required key and the result of the negotiation when the received value does not determine that result by itself. The last value transmitted becomes the negotiation result. The rules for selecting the value with which to respond are expressed as Boolean functions of the value received and the value that the responding party would select in the absence of knowledge of the received value." Kevin Lemay -----Original Message----- From: Dennis Young [mailto:dyoung@rhapsodynetworks.com] Sent: Wednesday, May 08, 2002 11:45 AM To: 'kevin_lemay@agilent.com'; ips@ece.cmu.edu Subject: RE: iSCSI: ImmediateData negotiation The following paragraphs in section 4.2 of draft 12 lead me to believe otherwise: ... The responding party answers with the first value that it supports and is allowed to use for the specfic originator selected from the originator list. ... An offer of a value not admissible MAY be answered with the constant "Reject". My interpretation of the two paragraphs is that the responding party can only respond with value offered in the originator list, and since "Yes" is not admissible, responding with "Reject" seems correct. Dennis >-----Original Message----- >From: kevin_lemay@agilent.com [mailto:kevin_lemay@agilent.com] >Sent: Wednesday, May 08, 2002 11:08 AM >To: dyoung@rhapsodynetworks.com; ips@ece.cmu.edu >Subject: RE: iSCSI: ImmediateData negotiation > > >Actually, both are incorrect. It is illegal to negotiate a >parameter more >than once during a login. The correct sequence is: > >I->T: ImmediateData=Yes >T->I: ImmediateData=No > >Both initiator and target must send ImmediateData=Yes for >immediate data to >be used. > >Kevin Lemay > >-----Original Message----- >From: Dennis Young [mailto:dyoung@rhapsodynetworks.com] >Sent: Wednesday, May 08, 2002 11:02 AM >To: ips@ece.cmu.edu >Subject: iSCSI: ImmediateData negotiation > > >I have a question on how a target should respond to >"ImmediateData=Yes" from an initiator if the target >doesn't support ImmediateData. Here are two scenarios: > >Scenario 1: >/* The target here only considers the value offered by the > * initiator, if the value is not acceptable, it simply > * rejects it rather than suggesting another value. > */ >I->T: ImmediateData=Yes >T->I: ImmediateData=Reject >I->T: ImmediateData=No /* Should initiator offer No? */ >T->I: ImmediateData=No > >Scenario 2: >/* The target here simply returns a value it supports > * without rejecting the value offered by the initiator. > */ >I->T: ImmediateData=Yes >T->I: ImmediateData=No >I->T: ImmediateData=No /* Should initiator reply No? */ >T->I: ImmediateData=No > >Based on section 4.2 of draft 12, I believe scenario 1 is >correct, right? > >In addition, does the Result function of a text parameter (AND >or OR) make a >difference here? > >Thanks, >Dennis > From owner-ips@ece.cmu.edu Wed May 8 19:50:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26364 for ; Wed, 8 May 2002 19:50:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g48MrZR14523 for ips-outgoing; Wed, 8 May 2002 18:53:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g48MrXw14518 for ; Wed, 8 May 2002 18:53:33 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g48MrRe5006302 for ; Wed, 8 May 2002 18:53:27 -0400 Received: from localhost (djwoolf@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g48MrRRu006299 for ; Wed, 8 May 2002 18:53:27 -0400 Date: Wed, 8 May 2002 18:53:27 -0400 (EDT) From: David Woolf To: ips@ece.cmu.edu Subject: RE: iSCSI: ImmediateData negotiation In-Reply-To: <45BEF1D68145D51186C100B0D0AABE659E00C8@med.corp.rhapsodynetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Hello, I've included comments below: On Wed, 8 May 2002, Dennis Young wrote: > The following paragraphs in section 4.2 of draft 12 > lead me to believe otherwise: > ... > The responding party answers with the first value that > it supports and is allowed to use for the specfic originator > selected from the originator list. > ... I would agree with Kevin here, FirstBurstSize and ImmediateData are numerical and boolean keys respectively, and the above paragraph does not apply. > An offer of a value not admissible MAY be answered with > the constant "Reject". It looks like theres some confusion about the meaning of the phrase 'not admissible'. I interpreted it to be refering to any value that is illegal for that type of negotiation. For example, if negotiating ImmediateData, a key value of ImmediateData=5 would be 'not admissible'. The phrase 'not admissible' would not apply if the offered value for the given key was something the device did not support or did not have the resources for. > > My interpretation of the two paragraphs is that the responding > party can only respond with value offered in the originator list, > and since "Yes" is not admissible, responding with "Reject" > seems correct. thank you, David Woolf ************************************************ University of New Hampshire Interoperability Lab iSCSI and Fibre Channel Consortiums Durham, NH 03824 (603) 862 0701 ************************************************ From owner-ips@ece.cmu.edu Wed May 8 19:51:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26382 for ; Wed, 8 May 2002 19:51:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g48MkDD14059 for ips-outgoing; Wed, 8 May 2002 18:46:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g48MkAw14053; Wed, 8 May 2002 18:46:10 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g48Mk2IB033090; Thu, 9 May 2002 00:46:02 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48Mk0g122508; Thu, 9 May 2002 00:46:01 +0200 To: "John Hufferd" Cc: "Elizabeth G. Rodriguez" , ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: DH-CHAP resolution X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 9 May 2002 01:45:55 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 09/05/2002 01:46:00, Serialize complete at 09/05/2002 01:46:00 Content-Type: multipart/alternative; boundary="=_alternative 003DB7E7C2256BB3_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003DB7E7C2256BB3_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John, I read it as being about the MAY - unproven means it's time has not come=20 yet. I hope we can close sometime next week. I plan to start the "countdown" to = 13 during the weekend. Julo John Hufferd/San Jose/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 05/07/2002 08:58 PM Please respond to John Hufferd =20 To: "Elizabeth G. Rodriguez" cc: Subject: Re: iSCSI: DH-CHAP resolution =20 Does this mean that DH-CHAP, is not to be even a MAY implement? Or was your statement only about it being a MUST? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Elizabeth G. Rodriguez" @ece.cmu.edu=20 on 05/07/2002 11:30:28 AM Sent by: owner-ips@ece.cmu.edu To: cc: Subject: iSCSI: DH-CHAP resolution All, As mentioned previously, the consensus call for DH-CHAP was very close.=A0 = As a result, Allision Mankin requested security expertise be consulted=20 further prior to declaring consensus on the issue. The result is that security experts believe that DH-CHAP, while from the reading, DH-CHAP seems to be a worthy solutionbut, as many have stated=20 both to me and the ADs privately as well as on the mailing list, it is unproven.=A0 As such, the decision has been made to NOT include=20 DH-CHAP as an authentication mechanism for iSCSI. Now, the next question will be how will this effect the mandatory to implement authentication mechanism decision.=A0 The Transport ADs still have significant concerns about IPR issues as they relate to SRP as the mandatory to implement mechanism.=A0 They also feel that (as has been expressed on the mailing list) we do not have concrete requirements listed for the authentication mechanism.=A0 As such, Allison is in the process of calling a meeting between the Security and Transport ADs. This will likely occur some time late this week. I realize that everyone is anxious to close on this issue.=A0 I assure you = it is being worked, and that the delay is related to making sure that iSCSI has the best chance of success, both in the IETF review process as well as the corporate environment. Thanks, Elizabeth Rodriguez IPS co-chair --=_alternative 003DB7E7C2256BB3_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
John,

I read it as being about the MAY - u= nproven means it's time has not come yet.
I hope we can close sometime next we= ek. I plan to start the "countdown" to 13 during the weekend.

Julo


John Hufferd/San Jose/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu

05/07/2002 08:58 PM
Please respond to John Hufferd

       
        To: &nbs= p;      "Elizabeth G. Rodriguez" <Elizabeth.G.R= odriguez@123mail.net>
        cc: &nbs= p;      <ips@ece.cmu.edu>
        Subject:=        Re: iSCSI: DH-CHAP resolution

       



Does this mean that DH-CHAP, is not to be even a MAY implement?  Or wa= s
your statement only about it being a MUST?

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


"Elizabeth G. Rodriguez" <Elizabeth.G.Rodriguez@123mail.net>= ;@ece.cmu.edu on
05/07/2002 11:30:28 AM

Sent by:    owner-ips@ece.cmu.edu


To:    <ips@ece.cmu.edu>
cc:
Subject:    iSCSI: DH-CHAP resolution





All,



As mentioned previously, the consensus call for DH-CHAP was very close.=A0 = As
a result, Allision Mankin requested security expertise be consulted further=
prior to declaring consensus on the issue.

The result is that security experts believe that DH-CHAP, while from the
reading, DH-CHAP seems to be a worthy solutionbut, as many have stated both=
to me and the ADs privately as well as on the mailing list,

it is unproven.=A0 As such, the decision has been made to NOT include DH-CH= AP
as an authentication mechanism for iSCSI.



Now, the next question will be how will this effect the mandatory to
implement authentication mechanism decision.=A0 The Transport ADs still hav= e
significant concerns about IPR issues as they relate to SRP as the
mandatory to implement mechanism.=A0 They also feel that (as has been
expressed on the mailing list) we do not have concrete requirements listed<= br> for the authentication mechanism.=A0 As such, Allison is in the process of<= br> calling a meeting between the Security and Transport ADs. This will likely<= br> occur some time late this week.



I realize that everyone is anxious to close on this issue.=A0 I assure you = it
is being worked, and that the delay is related to making sure that iSCSI
has the best chance of success, both in the IETF review process as well as<= br> the corporate environment.



Thanks,



Elizabeth Rodriguez

IPS co-chair

--=_alternative 003DB7E7C2256BB3_=-- From owner-ips@ece.cmu.edu Wed May 8 19:51:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26398 for ; Wed, 8 May 2002 19:51:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g48MkU314079 for ips-outgoing; Wed, 8 May 2002 18:46:30 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g48MkTw14075 for ; Wed, 8 May 2002 18:46:29 -0400 (EDT) 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 g48MkDMe013320; Thu, 9 May 2002 00:46:13 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48Mk9g109414; Thu, 9 May 2002 00:46:09 +0200 Subject: Re: iSCSI 4.1 & 4.2 To: Paul Koning Cc: cbm@rose.hp.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Wed, 8 May 2002 22:49:41 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 09/05/2002 01:46:13 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Your messages have a certain level of inconsistency. On one of them you state the last call is meant to get us rid of bugs (you must have a experienced a large set of last calls state this with such confidence) and here you ask for a change for something that is certainly not a bug. Julo |---------+----------------------------> | | Paul Koning | | | | | | Sent by: | | | owner-ips@ece.cmu| | | .edu | | | | | | | | | 04/29/2002 09:08 | | | PM | | | Please respond to| | | Paul Koning | | | | |---------+----------------------------> >---------------------------------------------------------------------------------------------------------------| | | | To: cbm@rose.hp.com | | cc: ips@ece.cmu.edu | | Subject: Re: iSCSI 4.1 & 4.2 | | | | | >---------------------------------------------------------------------------------------------------------------| Excerpt of message (sent 29 April 2002) by Mallikarjun C.: > > Specifically, the two cases in which responses are OPTIONAL are: > > I would strongly recommend getting rid of this special case. Yes, that would be good riddance for unnecessary confusion and special case extra work in implementations. We've discussed this before; nothing changed then, even though, as far as I remember, not a single person spoke up in favor of the current special cases. paul From owner-ips@ece.cmu.edu Wed May 8 23:19:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01670 for ; Wed, 8 May 2002 23:19:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g492efa28070 for ips-outgoing; Wed, 8 May 2002 22:40:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2ab.compuserve.com (siaar2ab.compuserve.com [149.174.40.138]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g492ebw28061 for ; Wed, 8 May 2002 22:40:38 -0400 (EDT) Received: (from mailgate@localhost) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id WAA11729 for ips@ece.cmu.edu; Wed, 8 May 2002 22:40:31 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkj-vty52.as.wcom.net [206.175.238.52]) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id WAA11708; Wed, 8 May 2002 22:40:17 -0400 (EDT) Message-ID: <3CD9E2F8.5A882A87@compuserve.com> Date: Wed, 08 May 2002 21:46:16 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu CC: "Mallikarjun C." Subject: Re: FCIP: Comment 120 References: <00ca01c1f313$0296ccd0$edd52b0f@rose.hp.com> <3CD694BC.E01A5A32@compuserve.com> <005301c1f525$e162fb00$edd52b0f@rose.hp.com> <3CD6E797.845F0095@compuserve.com> <004201c1f5f0$6dd423a0$edd52b0f@rose.hp.com> <3CD92786.40BD4B3@compuserve.com> <002301c1f6b3$f4d4a500$edd52b0f@rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallikarjun, > Besides, I don't see anything in the current document that prohibits multiple > FC/FCIP Entity Pairs from sharing the same IP/TCP address/port - and I believe > that is the right architectural approach. In the Orange County meeting, the FCIP contributors were told that we had to stop relying on knowing the exact IP Address and Port to decide the end points of the FCIP Links. We were NOT told that we had to allow multiple FC/FCIP Entity Pairs to share a single IP Address/Port. In fact, I believe we were told that we could proceed using such an assumption. We have followed what we were told to do. If you are authorized to change the rules on us again, so be it. But for sure, I will need need to hear that FCIP is getting jerked around again by the IETF from a higher authority. Furthermore, I repeat what I said originally and you conveniently ignored: > > The only alternative would be to REQUIRE SLP interrogation before every > > TCP connect request, and even then there would be zero assurance that > > the IP universe would not shape shift between the SLP activities and > > the TCP connect request. As far as I can tell, the basis for your argument yields the unmistakable conclusion that nothing is stable in an IP Network and SLP doesn't work. Frankly, that is beyond belief. .Ralph "Mallikarjun C." wrote: > > > I would think that sending a TCP connect request to the same IP Address > > and Port as was used in the previous TCP connect request would achieve > > the intended result. > > Not a correct assumption. You are using names (FC Fabric Entity WWN is > a name. The FC/FCIP Entity Identifier is a name unique within the scope of > the FC Fabric Entity.) in FSF only because IP addresses/TCP port associations > cannot provide the FCIP-end2end assurance that the right entities are talking. > > Besides, I don't see anything in the current document that prohibits multiple > FC/FCIP Entity Pairs from sharing the same IP/TCP address/port - and I believe > that is the right architectural approach. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > ----- Original Message ----- > From: "Ralph Weber" > To: > Cc: "Mallikarjun C." > Sent: Wednesday, May 08, 2002 6:26 AM > Subject: Re: FCIP: Comment 120 > > > "Mallikarjun C." wrote: > > > > > Upon further thought, it appears to me that the "Destination FC/FCIP > > > Entity Identifier" should be sent and received in the FSF. I can not > > > think of a way currently to build an FCIP_LEP with multiple FCIP_DEs > > > - for ex., how would a sender indicate his intention to add a TCP > > > connection to an FC/FCIP Entity Pair that it's already communicating > > > with? > > > > I would think that sending a TCP connect request to the same IP Address > > and Port as was used in the previous TCP connect request would achieve > > the intended result. > > > > The only alternative would be to REQUIRE SLP interrogation before every > > TCP connect request, and even then there would be zero assurance that > > the IP universe would not shape shift between the SLP activities and > > the TCP connect request. > > > > Surely, there is some stability in IP addressing. > > > > Thanks. > > > > .Ralph > > > > From owner-ips@ece.cmu.edu Thu May 9 00:23:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02716 for ; Thu, 9 May 2002 00:23:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g493ejZ01597 for ips-outgoing; Wed, 8 May 2002 23:40:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1ab.compuserve.com (siaar1ab.compuserve.com [149.174.40.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g493egw01593 for ; Wed, 8 May 2002 23:40:42 -0400 (EDT) Received: (from mailgate@localhost) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id XAA00948 for ips@ece.cmu.edu; Wed, 8 May 2002 23:40:36 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkk-vty14.as.wcom.net [206.175.239.14]) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id XAA00844; Wed, 8 May 2002 23:40:27 -0400 (EDT) Message-ID: <3CD9F0F8.46590285@compuserve.com> Date: Wed, 08 May 2002 22:46:00 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu CC: "Mallikarjun C." Subject: Re: FCIP: Comment 120 References: <00ca01c1f313$0296ccd0$edd52b0f@rose.hp.com> <3CD694BC.E01A5A32@compuserve.com> <005301c1f525$e162fb00$edd52b0f@rose.hp.com> <3CD6E797.845F0095@compuserve.com> <004201c1f5f0$6dd423a0$edd52b0f@rose.hp.com> <3CD92786.40BD4B3@compuserve.com> <002301c1f6b3$f4d4a500$edd52b0f@rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallikarjun, The more I think about this: > Besides, I don't see anything in the current document that prohibits multiple > FC/FCIP Entity Pairs from sharing the same IP/TCP address/port - and I believe > that is the right architectural approach. the less I like it. This seems like a poorly disguised attempt to force FCIP off its design center, which is a collection of statically (or near statically) configured FCIP Link endpoints. Call FCIP hardware-centric if you like, but the idea that an FCIP Entity controls its connection points through the IP Addresses and Ports it announces (via SLP or otherwise) is fundamental to the design and currently specified algorithms. The idea that one first connects to a IP Address/Port and then decides which FCIP Entity within it really wants to talk to flies in the face of SLP usage, and (while Venkat is the security expert not me) it seems like a potential security hole of the highest magnitude. I seriously believe that this breaks the authentication mechanism recently added to FC-BB-2 in support of multiple TCP Connections in a single FCIP Link. As I have noted before, the purpose of the Destination FC Fabric Entity World Wide Name field is to say, "This is the FC Fabric Entity I think I'm talking to; hang up if that is wrong." In other words, the field serves as a check on the correctness of the IP Address and Port used to make the TCP Connection. The purpose of the field as currently designed definitely is not to say, "This is the FC Fabric Entity I want to talk to." That would be using the FSF as an extension of the IP Addressing mechanism, when all the FSF was ever intended to do is replace IP Address as an FCIP Entity identifier. Surely, such a profound change in the design basis for FCIP connection setup, has implications that resonate far beyond adding a field here or there or changing the usage of some existing fields. This path is bogus. It is inconsistent with substantial parts of the current FCIP draft. If followed, it calls into question the FCIP usage of SLP, IPsec, IKE, and goodness knows what else. It is not "the right architectural approach". It is more like trying to build a pagoda using Roman columns. .Ralph "Mallikarjun C." wrote: > > I would think that sending a TCP connect request to the same IP Address > > and Port as was used in the previous TCP connect request would achieve > > the intended result. > > Not a correct assumption. You are using names (FC Fabric Entity WWN is > a name. The FC/FCIP Entity Identifier is a name unique within the scope of > the FC Fabric Entity.) in FSF only because IP addresses/TCP port associations > cannot provide the FCIP-end2end assurance that the right entities are talking. > > Besides, I don't see anything in the current document that prohibits multiple > FC/FCIP Entity Pairs from sharing the same IP/TCP address/port - and I believe > that is the right architectural approach. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > ----- Original Message ----- > From: "Ralph Weber" > To: > Cc: "Mallikarjun C." > Sent: Wednesday, May 08, 2002 6:26 AM > Subject: Re: FCIP: Comment 120 > > > "Mallikarjun C." wrote: > > > > > Upon further thought, it appears to me that the "Destination FC/FCIP > > > Entity Identifier" should be sent and received in the FSF. I can not > > > think of a way currently to build an FCIP_LEP with multiple FCIP_DEs > > > - for ex., how would a sender indicate his intention to add a TCP > > > connection to an FC/FCIP Entity Pair that it's already communicating > > > with? > > > > I would think that sending a TCP connect request to the same IP Address > > and Port as was used in the previous TCP connect request would achieve > > the intended result. > > > > The only alternative would be to REQUIRE SLP interrogation before every > > TCP connect request, and even then there would be zero assurance that > > the IP universe would not shape shift between the SLP activities and > > the TCP connect request. > > > > Surely, there is some stability in IP addressing. > > > > Thanks. > > > > .Ralph From owner-ips@ece.cmu.edu Thu May 9 09:08:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19109 for ; Thu, 9 May 2002 09:08:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49CSpM09560 for ips-outgoing; Thu, 9 May 2002 08:28:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49BsMw07668 for ; Thu, 9 May 2002 07:54:32 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16455; Thu, 9 May 2002 07:54:12 -0400 (EDT) Message-Id: <200205091154.HAA16455@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-helbig-stealthkey-00.txt Date: Thu, 09 May 2002 07:54:12 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Zyfer's StealthKey Management for frequent rekeying Author(s) : D. Au, P. Balke, H. Fruehauf, C. Helbig, K. Helbig Filename : draft-helbig-stealthkey-00.txt Pages : Date : 08-May-02 This document describes a key management, called StealthKey Management. StealthKey Management establishes short-term keys which are derived from a common long-term key in two entities, - called sender and receiver-, for symmetric encryption algorithms and cryptographic authentication protocols based on a common secret. Stealthkey Management covers two main parts: - Independent generation of the short-term keys by the sender and receiver from either the common long-term key and the time, or from the common long-term key and a sequence number. - Synchronization of the short-term keys between both entities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-helbig-stealthkey-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-helbig-stealthkey-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-helbig-stealthkey-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020508135937.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-helbig-stealthkey-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-helbig-stealthkey-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020508135937.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu May 9 09:08:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19161 for ; Thu, 9 May 2002 09:08:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49CYHi09926 for ips-outgoing; Thu, 9 May 2002 08:34:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mangelwurzel.iol.unh.edu ([132.177.117.182]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49CYFw09919 for ; Thu, 9 May 2002 08:34:15 -0400 (EDT) Received: from iol.unh.edu (localhost.localdomain [127.0.0.1]) by mangelwurzel.iol.unh.edu (8.11.6/8.11.6) with ESMTP id g49CXwJ03739 for ; Thu, 9 May 2002 08:33:58 -0400 Message-ID: <3CDA6CB6.6070202@iol.unh.edu> Date: Thu, 09 May 2002 08:33:58 -0400 From: Stephen Schaeffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: UNH page link Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit On the page http://www.ece.cmu.edu/~ips/IPS_Projects/ips_projects.html there is a link to some work UNH has done, but this is not the most current info. There is no indication on the page as to where to email corrections, but I'm hoping someone on this list either knows how or knows who to contact. The correct link is probably http://www.iol.unh.edu/consortiums/iscsi/ -- Stephen Schaeffer Fibre Channel and iSCSI Consortia Manager InterOperability Lab, University of New Hampshire Email: stephens@iol.unh.edu Phone: 603-862-5083 Lab Phone: 603-862-0701 URL: www.iol.unh.edu From owner-ips@ece.cmu.edu Thu May 9 09:56:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21850 for ; Thu, 9 May 2002 09:56:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49DGk312762 for ips-outgoing; Thu, 9 May 2002 09:16:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49DGiw12758 for ; Thu, 9 May 2002 09:16:44 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g49DI7UL093621; Thu, 9 May 2002 09:18:07 -0400 (EDT) Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g49DGZo36175; Thu, 9 May 2002 09:16:35 -0400 (EDT) Received: from research.bell-labs.com (philmac-pcmh1.research.bell-labs.com [135.104.54.81]) by aura.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g49DGYx6028509; Thu, 9 May 2002 09:16:34 -0400 (EDT) Message-ID: <3CDA7A76.8070707@research.bell-labs.com> Date: Thu, 09 May 2002 09:32:38 -0400 From: Philip MacKenzie Organization: Bell Labs, Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Elizabeth G. Rodriguez" CC: ips@ece.cmu.edu Subject: Re: iSCSI: DH-CHAP resolution References: <009001c1f5f5$44a289e0$1defc0d8@EGRodriguez> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Well, it looks like everything is going to CHAP. Before these last messages came out, I had already basically written up a document describing what I see are the main issues in authentication in iSCSI, along with the alternative approaches and their advantages and disadvantages. For anyone who's interested, you can find it at: http://cm.bell-labs.com/who/philmac/research/iscsi-authentication The last paragraph of that document desribes another approach that may be appropriate for iSCSI: Use CHAP with long keys, and if someone wants password authentication with high security, use another protocol *completely separate from iSCSI* to download user credentials (i.e., the long key for use with CHAP in iSCSI). Hopefully this protocol would be secured with PAK, or some other strong password authentication key exchange protocol, but that does not affect iSCSI. This type of approach is used in Plan 9. It is also similar to an approach currently being considered in the ipsra working group. -Phil From owner-ips@ece.cmu.edu Thu May 9 10:59:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24926 for ; Thu, 9 May 2002 10:59:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49EQ5m18037 for ips-outgoing; Thu, 9 May 2002 10:26:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49EQ2w18024 for ; Thu, 9 May 2002 10:26:03 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g49EPt9d042466 for ; Thu, 9 May 2002 16:25:55 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g49EPtV32498 for ; Thu, 9 May 2002 16:25:55 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: NOP-In X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 9 May 2002 17:25:53 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 09/05/2002 17:25:55, Serialize complete at 09/05/2002 17:25:55 Content-Type: multipart/alternative; boundary="=_alternative 004ED44BC2256BB4_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004ED44BC2256BB4_= Content-Type: text/plain; charset="us-ascii" OK - thanks - Julo "Robert D. Russell" 05/09/2002 04:44 PM Please respond to "Robert D. Russell" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, Subject: iSCSI: NOP-In Julian: A request for two small changes in wording in draft 12: 1) The last paragraph of section 9.19 says: "When a target sends a NOP-In as a "ping" (the Initiator Task Tag is 0xffffffff) it MUST NOT send any data in the data segment (DataSegmentLength MUST be 0)." I believe this should be restated to read simply: "When a target sends a NOP-In with an Initiator Task Tag value of 0xffffffff, it MUST NOT send any data in the data segment (DataSegmentLength MUST be 0)." The reason for this change is that the Initiator Task Tag can also be 0xffffffff when the target sends a NOP-In "as a means to carry a changed ExpCmdSN and/or MaxCmdSN". This is not a "ping", but I believe there should not be any data in the data segment for this case either. 2) For the same reason, I believe the last paragraph of section 9.19.1, which now reads: "Whenever the NOP-In is sent as a "ping" to an initiator (not as a response to a NOP-Out), the StatSN field will contain the next StatSN. However, StatSN for this connection is not advanced." should be changed to read: "The NOP-In always contains a valid StatSN field. However, when the NOP-In is sent with an Initiator Task Tag value of 0xffffffff, the StatSN field is not advanced." If this change is not made, it is unclear whether or not to advance the StatSN field when the target sends a NOP-In "as a means to carry a changed ExpCmdSN and/or MaxCmdSN". I believe this case should be treated the same as when the target sends a NOP-In as a "ping". Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 --=_alternative 004ED44BC2256BB4_= Content-Type: text/html; charset="us-ascii"
OK - thanks - Julo


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

05/09/2002 04:44 PM
Please respond to "Robert D. Russell"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, <owner-ips@ece.cmu.edu>
        Subject:        iSCSI: NOP-In

       


Julian:

A request for two small changes in wording in draft 12:

1) The last paragraph of section 9.19 says:

 "When a target sends a NOP-In as a "ping" (the Initiator
 Task Tag is 0xffffffff) it MUST NOT send any data in the
 data segment (DataSegmentLength MUST be 0)."

I believe this should be restated to read simply:

 "When a target sends a NOP-In with an Initiator Task Tag
 value of 0xffffffff, it MUST NOT send any data in the data
 segment (DataSegmentLength MUST be 0)."

The reason for this change is that the Initiator Task Tag can
also be 0xffffffff when the target sends a NOP-In "as a means
to carry a changed ExpCmdSN and/or MaxCmdSN".  This is not a
"ping", but I believe there should not be any data in the data
segment for this case either.


2) For the same reason, I believe the last paragraph of section
9.19.1, which now reads:

 "Whenever the NOP-In is sent as a "ping" to an initiator (not as
 a response to a NOP-Out), the StatSN field will contain the next
 StatSN.  However, StatSN for this connection is not advanced."

should be changed to read:

 "The NOP-In always contains a valid StatSN field.  However,
 when the NOP-In is sent with an Initiator Task Tag value of
 0xffffffff, the StatSN field is not advanced."

If this change is not made, it is unclear whether or not to advance
the StatSN field when the target sends a NOP-In "as a means
to carry a changed ExpCmdSN and/or MaxCmdSN".  I believe this case
should be treated the same as when the target sends a NOP-In as a
"ping".

Thanks,

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



--=_alternative 004ED44BC2256BB4_=-- From owner-ips@ece.cmu.edu Thu May 9 12:19:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27843 for ; Thu, 9 May 2002 12:19:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49Fi8324188 for ips-outgoing; Thu, 9 May 2002 11:44:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp4.electric.net (smtp4.electric.net [216.129.90.17]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g49Fi5w24184 for ; Thu, 9 May 2002 11:44:05 -0400 (EDT) Received: (qmail 69688 invoked from network); 9 May 2002 15:44:01 -0000 Received: from zhora.electric.net (216.129.90.89) by virusqueue.electric.net with SMTP; 9 May 2002 15:44:01 -0000 Received: from osmtp3.electric.net ([216.129.90.30]) by zhora.electric.net (NAVGW 2.5.2.9) with SMTP id M2002050908440004990 ; Thu, 09 May 2002 08:44:00 -0700 Received: from [216.192.240.44] (helo=EGRodriguez) by osmtp3.electric.net with esmtp (Exim 3.22 #1) id 175q5F-000GRH-04; Thu, 09 May 2002 08:44:00 -0700 From: "Elizabeth G. Rodriguez" To: "'Stephen Schaeffer'" , Subject: RE: UNH page link Date: Thu, 9 May 2002 10:42:38 -0600 Keywords: IETF-IPS Message-ID: <005b01c1f778$8d360b30$2cf0c0d8@EGRodriguez> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3CDA6CB6.6070202@iol.unh.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Note to all: The CMU additional page is no longer being maintained. We are in the process of trying to establish a new additional page for IPS. We will make sure the appropriate link for UNH is put on that page. Thanks, Elizabeth -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Stephen Schaeffer Sent: Thursday, May 09, 2002 6:34 AM To: ips@ece.cmu.edu Subject: UNH page link On the page http://www.ece.cmu.edu/~ips/IPS_Projects/ips_projects.html there is a link to some work UNH has done, but this is not the most current info. There is no indication on the page as to where to email corrections, but I'm hoping someone on this list either knows how or knows who to contact. The correct link is probably http://www.iol.unh.edu/consortiums/iscsi/ -- Stephen Schaeffer Fibre Channel and iSCSI Consortia Manager InterOperability Lab, University of New Hampshire Email: stephens@iol.unh.edu Phone: 603-862-5083 Lab Phone: 603-862-0701 URL: www.iol.unh.edu From owner-ips@ece.cmu.edu Thu May 9 12:20:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27866 for ; Thu, 9 May 2002 12:20:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49G8QH26109 for ips-outgoing; Thu, 9 May 2002 12:08:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from thunk.org (THANK.THUNK.ORG [216.175.175.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49G8Nw26103 for ; Thu, 9 May 2002 12:08:23 -0400 (EDT) Received: from think.thunk.org ([216.175.175.162]) by thunk.org with asmtp (Exim 3.35 #1 (Debian)) id 175qSf-0003UP-00; Thu, 09 May 2002 12:08:09 -0400 Received: from tytso by think.thunk.org with local (Exim 3.35 #1 (Debian)) id 175qSf-0001ah-00; Thu, 09 May 2002 12:08:09 -0400 Date: Thu, 9 May 2002 12:08:09 -0400 From: "Theodore Ts'o" To: Philip MacKenzie Cc: "Elizabeth G. Rodriguez" , ips@ece.cmu.edu Subject: Re: iSCSI: DH-CHAP resolution Message-ID: <20020509160809.GI2837@think.thunk.org> References: <009001c1f5f5$44a289e0$1defc0d8@EGRodriguez> <3CDA7A76.8070707@research.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CDA7A76.8070707@research.bell-labs.com> User-Agent: Mutt/1.3.28i Sender: owner-ips@ece.cmu.edu Precedence: bulk There's one other potential, very simple change we could make to DH-CHAP, which may mollify the people who are so worried about the lack of mutual authentication in CHAP. (I'll claim that the succeptibility to active attackers being able to carry out a dictionary attack on the password as far over-rated, since the data stream after the initial authentication is completely unprotected, which means the attacker and read *and* modify the data being transferred via iSCSI --- this could mean modifying executables so that trojan-horse code is executed, or modifying sensitive data records --- in other words, if you're worried about active attackers, the potential for a dictionary attack is the LEAST of your concerns, and you should be using IPSEC to protect your entire transaction, at which point the issue about active attackers is solved completely.) With respect to lack of mutual authentication, there is a very simple modification we can make to the DH-CHAP protocol that can solve this problem. It merely involves using a sufficiently large D-H modulos that the storage device can use a fixed (a,A) pair, ala the old Secure SunRPC protocol (which was always fine except for the fact that Sun stupidly used a way-too-small D-H moduolos, probably for export control reasons), and then adding a server-generated nonce to the exchange to guarantee freshness, since the server's D-H key is no longer ephemeral. This allows the client to cache the D-H key for a particular storage device, and if the D-H key is ever different from the one that the client has cached, it knows that it's being subject to a man-in-the-middle attack or the device has been substituted without its knowledge, so it can complain and refuse to mount the disk. (Note that the client doesn't *have* to do this check; if it doesn't, it is essentially identical to the current DH-CHAP scheme, and it simply doesn't have any mutual authentication guarantees.) This provides us with mutual authentication for everything except for the initial authentication exchange. However, in reality, it turns out that for almost all schemes, including SRP, this is actually all you get, because most systems cheat in order to solve the initial authentication problems. For example, in the case of SRP, how do you load the first user's verification data into the device? The hard drive will almost certainly used a fixed password which is constant across all of a vendor's devices and which is embedded in the install program. This means an active attacker who is active on the network during the initial setup can spoof the transaction. The right fix would be to use a randomly chosen password which is different for every single device ---- say, a long hex string which is printed on the device and which the system administrator must type in when the device is first being initialized. However, most implementations neglect to do this because users find it too inconvenient (by the time they figure out they need the hex string, they've already installed the device, and pulling out the device in order to read out the hex string becomes a major pain in the ass). As a result, most implementation cheat on the initial authentication problem, and hence their product is vulnerable to an active attack during the first exchange. (For example, this is true for Windows XP using Kerberos; when a newly installed Windows client first joins a domain, there is no initial secret to authenticate it to the domain controller, or that the domain controller can use to authenticate the initially installed Windows client. So, there is a hard coded secret buried deep within the Windows code, and if you know that "secret" --- which is constant across all copies of Windows, so it's hardly a secret --- you can attack the initial authentication exchange when a host first talks to the domain controller. It's not true for the MIT version of Kerberos, since we don't provide this shortcut, but the resulting loss in usability in the requirement to manually set up a srvtab file causes a huge number of complaints, and if MIT Kerberos were a commercial product that needed to be responsive to customer complaints, I suspect it would almost certainly make the same security shortcut/compromise --- so I'm not blaming Microsoft for making the decision which they made. This is by the way also the same compromise which SSH using public key authentication makes; it's a very common tradeoff.) So to the extent that we have protection from all but the initial exchange, I would claim that this should be good enough for most purposes, and no different from what SRP could provide in real life anyway. And, if we really want to assuage our consciences, we can require that the devices have printed on them a MD5 hash of the fixed Diffie-Helman public key, and we can pretend that the system administrator will type in the MD5 hash when setting up a new storage device (at which point the mutual authentication guarantees are just as strong as SRP or any other scheme) --- even though we know that less than .0005% of the system administrators will actually do so in real life. Is it worth making this change? Well, it depends on how important you think Mutual Authentication is for people who will be using iSCSI without IPSEC. For people who have critical security requirements, it's pretty clear that IPSEC will be a requirement. However, for people who don't need IPSEC, do we need to provide a greater level of security protection? The advantage of the scheme which I've outlined is that it's a relatively small change to the DH-CHAP protocol, so the cost of adding this protection is fairly cheap. - Ted From owner-ips@ece.cmu.edu Thu May 9 14:03:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02876 for ; Thu, 9 May 2002 14:03:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49HRh202487 for ips-outgoing; Thu, 9 May 2002 13:27:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from astutenetworks.com (2.astutenetworks.com [216.142.74.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49HRew02482; Thu, 9 May 2002 13:27:40 -0400 (EDT) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g49HRV730749; Thu, 9 May 2002 10:27:31 -0700 From: "Amir Shalit" To: "Julian Satran" Cc: , Subject: RE: Associating initiator names with SCSI commands Date: Thu, 9 May 2002 10:27:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit 1) Editorial comment: chapter 1 defines SCSI Port Name as: A name made up as UTF-8 characters and basically... +---+ Remove basically +---+ 2) The iSCSI namning model on page 49 shows two iSCSI target nodes sharing the same portal group and the same TCP/IP addresses. How can one steer PDU headers to the correct iSCSI node given that setup? Does it mean that a TCP connection doesn't belong to a single iSCSI session? Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, May 07, 2002 12:12 PM To: Ken Craig Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: Associating initiator names with SCSI commands No - the session is associated with the initiator - if you record the session on which you received the command you have the association. How you represent internally the session is an implementation issue - but I assume you will not uses the names for that! Julo |---------+----------------------------> | | "Ken Craig" | | | | | | Sent by: | | | owner-ips@ece.cmu| | | .edu | | | | | | | | | 05/07/2002 07:11 | | | PM | | | Please respond to| | | "Ken Craig" | | | | |---------+----------------------------> >--------------------------------------------------------------------------- ------------------------------------| | | | To: | | cc: | | Subject: Associating initiator names with SCSI commands | | | | | >--------------------------------------------------------------------------- ------------------------------------| I have a question concerning associating incoming SCSI commands with an initiator. I come from a parallel SCSI background and now find myself implementing a SCSI Target port in an iSCSI world. I have searched the mailing list archives for discussions on this subject but have been unable to find anything that succinctly answers my question so please bear with me. In the parallel SCSI world association of an initiator with a new command is very straight-forward as the initiator's ID is encapsulated in the Identify message that occurs with the SCSI Selection phase that precedes receiving the new command. When I read the latest version of the iSCSI draft (rev. 12) the only statement I seem to find that correlates to this association is in Section 2.2.3 on page 34 in the 2nd sentence of the 3rd paragraph. "Any persistent state (e.g., persistent reservations) on the target that is associated with a SCSI initiator port is identified based on the value pair (InitiatorName, ISID)." When I searched the mailing list archives I came across statements that said this association was done using ISID and TSID (now TSIH?) but I do not see these statements in the latest draft so I'm assuming that there was some reason this association method was dropped. My question is: In order to associate initiators with incoming commands to a SCSI Target do I have to compare the Initiator Name and ISID (up to ~268 bytes?) for every command I receive against a list of logged in initiators or is there another method using a lot fewer number of bytes? I had thought about using the IP address in the IP header but the draft seems to say that is not allowed because IP addresses can change. It seems like I must perform this potentially rather long comparison if I support multiple initiators because I can not be guaranteed that different initiators would not use the same ISID during their login. Am I wrong? Thanks in advance, Kenneth Ray Craig, Jr. From owner-ips@ece.cmu.edu Thu May 9 14:05:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02940 for ; Thu, 9 May 2002 14:05:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49Hf2F03606 for ips-outgoing; Thu, 9 May 2002 13:41:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from fed1mtao04.cox.net (fed1mtao04.cox.net [68.6.19.241]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49Heww03589 for ; Thu, 9 May 2002 13:40:59 -0400 (EDT) Received: from CX418298C ([68.5.217.92]) by fed1mtao04.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020509174053.TMWH26656.fed1mtao04.cox.net@CX418298C>; Thu, 9 May 2002 13:40:53 -0400 From: "Murali Rajagopal" To: "Mallikarjun C." Cc: , Subject: RE: FCIP: Comment 120 Date: Thu, 9 May 2002 10:42:01 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <002301c1f6b3$f4d4a500$edd52b0f@rose.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallikarjun: There is some text in FC-BB-2 (Clause 13.2. 3) that may also add some calrity to the discussion of sharing IP address: " The FC-BB-2_IP Reference Model supports one logical IP Interface and allows sharing a 4-byte IPv4 or 16-byte IPv6 address in the following ways: a)A single IP address per FC-BB-2_IP device - A single IP address shared by all FC/FCIP Entity pairs b) Multiple IP addresses per FC-BB-2_IP device - A single IP address per FC/FCIP Entity pair c) Multiple IP addresses per FC/FCIP Entity pair - A single IP address per VE_Port/LEP pair Use of two different IP address schemes at the two ends of an FCIP Link is not expected to cause inter operability problems." -Murali -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Mallikarjun C. Sent: Wednesday, May 08, 2002 10:16 AM To: roweber@acm.org; ips@ece.cmu.edu Subject: Re: FCIP: Comment 120 > I would think that sending a TCP connect request to the same IP Address > and Port as was used in the previous TCP connect request would achieve > the intended result. Not a correct assumption. You are using names (FC Fabric Entity WWN is a name. The FC/FCIP Entity Identifier is a name unique within the scope of the FC Fabric Entity.) in FSF only because IP addresses/TCP port associations cannot provide the FCIP-end2end assurance that the right entities are talking. Besides, I don't see anything in the current document that prohibits multiple FC/FCIP Entity Pairs from sharing the same IP/TCP address/port - and I believe that is the right architectural approach. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Ralph Weber" To: Cc: "Mallikarjun C." Sent: Wednesday, May 08, 2002 6:26 AM Subject: Re: FCIP: Comment 120 > "Mallikarjun C." wrote: > > > Upon further thought, it appears to me that the "Destination FC/FCIP > > Entity Identifier" should be sent and received in the FSF. I can not > > think of a way currently to build an FCIP_LEP with multiple FCIP_DEs > > - for ex., how would a sender indicate his intention to add a TCP > > connection to an FC/FCIP Entity Pair that it's already communicating > > with? > > I would think that sending a TCP connect request to the same IP Address > and Port as was used in the previous TCP connect request would achieve > the intended result. > > The only alternative would be to REQUIRE SLP interrogation before every > TCP connect request, and even then there would be zero assurance that > the IP universe would not shape shift between the SLP activities and > the TCP connect request. > > Surely, there is some stability in IP addressing. > > Thanks. > > .Ralph > > From owner-ips@ece.cmu.edu Thu May 9 14:06:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03007 for ; Thu, 9 May 2002 14:06:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49Hvim05041 for ips-outgoing; Thu, 9 May 2002 13:57:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49Hvfw05035; Thu, 9 May 2002 13:57:42 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g49HvQ5M015884; Thu, 9 May 2002 10:57:26 -0700 (PDT) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA26675; Thu, 9 May 2002 10:57:24 -0700 (PDT) Message-ID: <3CDAB452.923C7745@cisco.com> Date: Thu, 09 May 2002 12:39:30 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Amir Shalit CC: Julian Satran , ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: Re: Associating initiator names with SCSI commands References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Amir Shalit wrote: > > 1) Editorial comment: > chapter 1 defines SCSI Port Name as: > A name made up as UTF-8 characters and basically... > +---+ > Remove basically > +---+ > > 2) The iSCSI namning model on page 49 shows two iSCSI target nodes > sharing the same portal group and the same TCP/IP addresses. > How can one steer PDU headers to the correct iSCSI node given > that setup? Does it mean that a TCP connection doesn't belong > to a single iSCSI session? Amir- The portal group only contains the TCP address on which the target is listening. A TCP connection is identified by the 5-tuple (source-IP, dest-IP, protocol(TCP), source-port, dest-port). Different connections to the target from the same source-IP will have different source-ports. Connections from different hosts or host interfaces will have different source-IP addresses. The dest-IP and dest-port can be the same for all incoming connections to all targets. -- Mark > > Amir > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Tuesday, May 07, 2002 12:12 PM > To: Ken Craig > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu > Subject: Re: Associating initiator names with SCSI commands > > No - the session is associated with the initiator - if you record the > session on which you received the command you have the association. > How you represent internally the session is an implementation issue - but I > assume you will not uses the names for that! > > Julo > > |---------+----------------------------> > | | "Ken Craig" | > | | | | > | > | | Sent by: | > | | owner-ips@ece.cmu| > | | .edu | > | | | > | | | > | | 05/07/2002 07:11 | > | | PM | > | | Please respond to| > | | "Ken Craig" | > | | | > |---------+----------------------------> > > >--------------------------------------------------------------------------- > ------------------------------------| > | > | > | To: > | > | cc: > | > | Subject: Associating initiator names with SCSI commands > | > | > | > | > | > > >--------------------------------------------------------------------------- > ------------------------------------| > > I have a question concerning associating > incoming SCSI commands with an initiator. > I come from a parallel SCSI background and > now find myself implementing a SCSI Target > port in an iSCSI world. I have searched > the mailing list archives for discussions > on this subject but have been unable to find > anything that succinctly answers my question > so please bear with me. > > In the parallel SCSI world association of an > initiator with a new command is very > straight-forward as the initiator's ID is > encapsulated in the Identify message that > occurs with the SCSI Selection phase that > precedes receiving the new command. > > When I read the latest version of the iSCSI > draft (rev. 12) the only statement I seem to > find that correlates to this association is > in Section 2.2.3 on page 34 in the 2nd > sentence of the 3rd paragraph. > > "Any persistent state (e.g., persistent reservations) > on the target that is associated with a SCSI > initiator port is identified based on the > value pair (InitiatorName, ISID)." > > When I searched the mailing list archives I > came across statements that said this > association was done using ISID and TSID (now > TSIH?) but I do not see these statements in the > latest draft so I'm assuming that there was some > reason this association method was dropped. > > My question is: > In order to associate initiators with incoming > commands to a SCSI Target do I have to compare > the Initiator Name and ISID (up to ~268 bytes?) > for every command I receive against a list of > logged in initiators or is there another method > using a lot fewer number of bytes? > > I had thought about using the IP address in the > IP header but the draft seems to say that is not > allowed because IP addresses can change. It > seems like I must perform this potentially rather > long comparison if I support multiple initiators > because I can not be guaranteed that different > initiators would not use the same ISID during > their login. Am I wrong? > > Thanks in advance, > Kenneth Ray Craig, Jr. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu May 9 15:12:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05587 for ; Thu, 9 May 2002 15:12:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49Ik1e09156 for ips-outgoing; Thu, 9 May 2002 14:46:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from astutenetworks.com (2.astutenetworks.com [216.142.74.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49Ijww09144; Thu, 9 May 2002 14:45:58 -0400 (EDT) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g49Ijq705966; Thu, 9 May 2002 11:45:52 -0700 From: "Amir Shalit" To: , Subject: RE: Associating initiator names with SCSI commands Date: Thu, 9 May 2002 11:45:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please ignore (2) -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Amir Shalit Sent: Thursday, May 09, 2002 10:27 AM To: Julian Satran Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: Associating initiator names with SCSI commands 1) Editorial comment: chapter 1 defines SCSI Port Name as: A name made up as UTF-8 characters and basically... +---+ Remove basically +---+ 2) The iSCSI namning model on page 49 shows two iSCSI target nodes sharing the same portal group and the same TCP/IP addresses. How can one steer PDU headers to the correct iSCSI node given that setup? Does it mean that a TCP connection doesn't belong to a single iSCSI session? Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, May 07, 2002 12:12 PM To: Ken Craig Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: Associating initiator names with SCSI commands No - the session is associated with the initiator - if you record the session on which you received the command you have the association. How you represent internally the session is an implementation issue - but I assume you will not uses the names for that! Julo |---------+----------------------------> | | "Ken Craig" | | | | | | Sent by: | | | owner-ips@ece.cmu| | | .edu | | | | | | | | | 05/07/2002 07:11 | | | PM | | | Please respond to| | | "Ken Craig" | | | | |---------+----------------------------> >--------------------------------------------------------------------------- ------------------------------------| | | | To: | | cc: | | Subject: Associating initiator names with SCSI commands | | | | | >--------------------------------------------------------------------------- ------------------------------------| I have a question concerning associating incoming SCSI commands with an initiator. I come from a parallel SCSI background and now find myself implementing a SCSI Target port in an iSCSI world. I have searched the mailing list archives for discussions on this subject but have been unable to find anything that succinctly answers my question so please bear with me. In the parallel SCSI world association of an initiator with a new command is very straight-forward as the initiator's ID is encapsulated in the Identify message that occurs with the SCSI Selection phase that precedes receiving the new command. When I read the latest version of the iSCSI draft (rev. 12) the only statement I seem to find that correlates to this association is in Section 2.2.3 on page 34 in the 2nd sentence of the 3rd paragraph. "Any persistent state (e.g., persistent reservations) on the target that is associated with a SCSI initiator port is identified based on the value pair (InitiatorName, ISID)." When I searched the mailing list archives I came across statements that said this association was done using ISID and TSID (now TSIH?) but I do not see these statements in the latest draft so I'm assuming that there was some reason this association method was dropped. My question is: In order to associate initiators with incoming commands to a SCSI Target do I have to compare the Initiator Name and ISID (up to ~268 bytes?) for every command I receive against a list of logged in initiators or is there another method using a lot fewer number of bytes? I had thought about using the IP address in the IP header but the draft seems to say that is not allowed because IP addresses can change. It seems like I must perform this potentially rather long comparison if I support multiple initiators because I can not be guaranteed that different initiators would not use the same ISID during their login. Am I wrong? Thanks in advance, Kenneth Ray Craig, Jr. From owner-ips@ece.cmu.edu Thu May 9 15:14:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05650 for ; Thu, 9 May 2002 15:14:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49Ijn609139 for ips-outgoing; Thu, 9 May 2002 14:45:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49Dinw14883; Thu, 9 May 2002 09:44:49 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g49Dihe5018233; Thu, 9 May 2002 09:44:43 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g49DihBl018230; Thu, 9 May 2002 09:44:43 -0400 Date: Thu, 9 May 2002 09:44:43 -0400 (EDT) From: "Robert D. Russell" To: Julian Satran cc: ips@ece.cmu.edu, Subject: iSCSI: NOP-In In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: A request for two small changes in wording in draft 12: 1) The last paragraph of section 9.19 says: "When a target sends a NOP-In as a "ping" (the Initiator Task Tag is 0xffffffff) it MUST NOT send any data in the data segment (DataSegmentLength MUST be 0)." I believe this should be restated to read simply: "When a target sends a NOP-In with an Initiator Task Tag value of 0xffffffff, it MUST NOT send any data in the data segment (DataSegmentLength MUST be 0)." The reason for this change is that the Initiator Task Tag can also be 0xffffffff when the target sends a NOP-In "as a means to carry a changed ExpCmdSN and/or MaxCmdSN". This is not a "ping", but I believe there should not be any data in the data segment for this case either. 2) For the same reason, I believe the last paragraph of section 9.19.1, which now reads: "Whenever the NOP-In is sent as a "ping" to an initiator (not as a response to a NOP-Out), the StatSN field will contain the next StatSN. However, StatSN for this connection is not advanced." should be changed to read: "The NOP-In always contains a valid StatSN field. However, when the NOP-In is sent with an Initiator Task Tag value of 0xffffffff, the StatSN field is not advanced." If this change is not made, it is unclear whether or not to advance the StatSN field when the target sends a NOP-In "as a means to carry a changed ExpCmdSN and/or MaxCmdSN". I believe this case should be treated the same as when the target sends a NOP-In as a "ping". Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Thu May 9 15:26:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06092 for ; Thu, 9 May 2002 15:26:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49JDsq11691 for ips-outgoing; Thu, 9 May 2002 15:13:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mother.pmc-sierra.bc.ca (mother.pmc-sierra.bc.ca [216.241.224.12]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g49JDqw11686 for ; Thu, 9 May 2002 15:13:52 -0400 (EDT) Received: (qmail 16234 invoked by uid 104); 9 May 2002 19:13:45 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4202. . Clean. Processed in 0.525257 secs); 09 May 2002 19:13:45 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 9 May 2002 19:13:44 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g49JDfp04782 for ; Thu, 9 May 2002 12:13:41 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 12:13:45 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A7BC@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'ips@ece.cmu.edu'" Subject: iSCSI and IPSec Date: Thu, 9 May 2002 12:13:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, Is IPSec supported in iSCSI? and if so, is it optional to use or mandatory? Thanks, Shahram From owner-ips@ece.cmu.edu Thu May 9 16:30:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07737 for ; Thu, 9 May 2002 16:30:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49KBLh16800 for ips-outgoing; Thu, 9 May 2002 16:11:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from intotoinc.com (sdsl-66-80-10-146.dsl.sca.megapath.net [66.80.10.146]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49KBIw16792 for ; Thu, 9 May 2002 16:11:18 -0400 (EDT) Received: from localhost (srao@localhost) by intotoinc.com (8.11.0/8.11.0) with ESMTP id g49KKNu25311; Thu, 9 May 2002 13:20:23 -0700 Date: Thu, 9 May 2002 13:20:23 -0700 (PDT) From: Srinivasa Addepalli To: Shahram Davari cc: "'ips@ece.cmu.edu'" Subject: Re: iSCSI and IPSec In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE84A7BC@nt-exch-yow.pmc-sierra.bc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Text from IPS ipsec draft: "While IP block storage security is mandatory to implement, it is not mandatory to use. The security services used depend on the configuration and security policies put in place. For example, configuration will influence the authentication algorithm negotiated within iSCSI Login, as well as the security services (encryption, authentication, integrity, replay protection) and transforms negotiated when IPsec is used to protect IP block storage protocols such as iSCSI, iFCP and FCIP." Hope it helps. Srini On Thu, 9 May 2002, Shahram Davari wrote: > Hi, > > Is IPSec supported in iSCSI? and if so, is it optional to use or mandatory? > > Thanks, > Shahram > -- Srinivasa Rao Addepalli Intoto Inc. (Enabling Security Infrastructure) 3160, De La Cruz Blvd #100 Santa Clara, CA USA http://www.intotoinc.com From owner-ips@ece.cmu.edu Thu May 9 16:32:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07835 for ; Thu, 9 May 2002 16:32:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49K3Nc16052 for ips-outgoing; Thu, 9 May 2002 16:03:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49K3Lw16047 for ; Thu, 9 May 2002 16:03:21 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id DFE1230706; Thu, 9 May 2002 16:03:20 -0400 (EDT) Date: Thu, 9 May 2002 13:01:45 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Shahram Davari Cc: "'ips@ece.cmu.edu'" Subject: Re: iSCSI and IPSec In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE84A7BC@nt-exch-yow.pmc-sierra.bc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 9 May 2002, Shahram Davari wrote: > Hi, > > Is IPSec supported in iSCSI? and if so, is it optional to use or mandatory? IPsec is a MUST. Though you can get away with just tunnel mode. Take care, Bill From owner-ips@ece.cmu.edu Thu May 9 17:26:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09982 for ; Thu, 9 May 2002 17:26:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49Km5m19681 for ips-outgoing; Thu, 9 May 2002 16:48:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49Km3w19673 for ; Thu, 9 May 2002 16:48:03 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g49KeKS00164; Thu, 9 May 2002 16:40:23 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g49KeK716193; Thu, 9 May 2002 16:40:20 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 16:39:18 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293787C@CORPMX14> From: Black_David@emc.com To: roweber@acm.org, ips@ece.cmu.edu Cc: cbm@rose.hp.com Subject: RE: FCIP: Comment 120 Date: Thu, 9 May 2002 16:39:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-PerlMx-Spam: Gauge=XIIIIII, Probability=16%, Report="NO_REAL_NAME" Sender: owner-ips@ece.cmu.edu Precedence: bulk > > Besides, I don't see anything in the current document that prohibits multiple > > FC/FCIP Entity Pairs from sharing the same IP/TCP address/port - and I believe > > that is the right architectural approach. > > In the Orange County meeting, the FCIP contributors were told that we > had to stop relying on knowing the exact IP Address and Port to decide > the end points of the FCIP Links. We were NOT told that we had to > allow multiple FC/FCIP Entity Pairs to share a single IP Address/Port. > In fact, I believe we were told that we could proceed using such > an assumption. While Ralph doth protest a bit much, I believe he has the better part of this discussion. It is completely reasonable to identify an IP service instance as "that which responds when contacting TCP port X at IP address a.b.c.d" - for example, there's only one http server behind port 80, but there might be a different one behind port 8080. If there's a NAT involved, the discussion gets a bit subtle, but the principle remains - one opens a TCP connection to port X at IP address a.b.c.d, and expects to talk directly to a specific instance of an IP-based service. I don't see any need to change FCIP to allow multiple FC/FCIP Entity Pairs to share a single IP Address/Port; the fact that multiple TCP connections to the same FC/FCIP Entity Pair can share that TCP Port seems sufficient. Having seen no other participants in this discussion, I also believe that the rough consensus of the WG is not to change FCIP in this fashion. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu May 9 18:13:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11859 for ; Thu, 9 May 2002 18:13:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49LPVZ22500 for ips-outgoing; Thu, 9 May 2002 17:25:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49LPSw22495; Thu, 9 May 2002 17:25:28 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g49LP44Q009842; Thu, 9 May 2002 23:25:04 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g49LP3F51958; Thu, 9 May 2002 23:25:03 +0200 To: Mark Bakke Cc: Amir Shalit , ips@ece.cmu.edu, mbakke@cisco.com, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Associating initiator names with SCSI commands X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 10 May 2002 00:24:55 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/05/2002 00:25:04, Serialize complete at 10/05/2002 00:25:04 Content-Type: multipart/alternative; boundary="=_alternative 00750678C2256BB4_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00750678C2256BB4_= Content-Type: text/plain; charset="us-ascii" Amir, Even more - the targe part of the session name has two components - TPGT and Target name. Two session can start with the same INANE, ISID and terminate at different TNaMES behind a single TPGT. I addition a separation is performed at tcp port level on the initiator side (as Mark outline a tcp connection is identified by 5 elements) but iSCSI does not make explicit use of this separation. Julo Mark Bakke Sent by: mbakke@cisco.com 05/09/2002 08:39 PM Please respond to Mark Bakke To: Amir Shalit cc: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: Re: Associating initiator names with SCSI commands Amir Shalit wrote: > > 1) Editorial comment: > chapter 1 defines SCSI Port Name as: > A name made up as UTF-8 characters and basically... > +---+ > Remove basically > +---+ > > 2) The iSCSI namning model on page 49 shows two iSCSI target nodes > sharing the same portal group and the same TCP/IP addresses. > How can one steer PDU headers to the correct iSCSI node given > that setup? Does it mean that a TCP connection doesn't belong > to a single iSCSI session? Amir- The portal group only contains the TCP address on which the target is listening. A TCP connection is identified by the 5-tuple (source-IP, dest-IP, protocol(TCP), source-port, dest-port). Different connections to the target from the same source-IP will have different source-ports. Connections from different hosts or host interfaces will have different source-IP addresses. The dest-IP and dest-port can be the same for all incoming connections to all targets. -- Mark > > Amir > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Tuesday, May 07, 2002 12:12 PM > To: Ken Craig > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu > Subject: Re: Associating initiator names with SCSI commands > > No - the session is associated with the initiator - if you record the > session on which you received the command you have the association. > How you represent internally the session is an implementation issue - but I > assume you will not uses the names for that! > > Julo > > |---------+----------------------------> > | | "Ken Craig" | > | | | | > | > | | Sent by: | > | | owner-ips@ece.cmu| > | | .edu | > | | | > | | | > | | 05/07/2002 07:11 | > | | PM | > | | Please respond to| > | | "Ken Craig" | > | | | > |---------+----------------------------> > > >--------------------------------------------------------------------------- > ------------------------------------| > | > | > | To: > | > | cc: > | > | Subject: Associating initiator names with SCSI commands > | > | > | > | > | > > >--------------------------------------------------------------------------- > ------------------------------------| > > I have a question concerning associating > incoming SCSI commands with an initiator. > I come from a parallel SCSI background and > now find myself implementing a SCSI Target > port in an iSCSI world. I have searched > the mailing list archives for discussions > on this subject but have been unable to find > anything that succinctly answers my question > so please bear with me. > > In the parallel SCSI world association of an > initiator with a new command is very > straight-forward as the initiator's ID is > encapsulated in the Identify message that > occurs with the SCSI Selection phase that > precedes receiving the new command. > > When I read the latest version of the iSCSI > draft (rev. 12) the only statement I seem to > find that correlates to this association is > in Section 2.2.3 on page 34 in the 2nd > sentence of the 3rd paragraph. > > "Any persistent state (e.g., persistent reservations) > on the target that is associated with a SCSI > initiator port is identified based on the > value pair (InitiatorName, ISID)." > > When I searched the mailing list archives I > came across statements that said this > association was done using ISID and TSID (now > TSIH?) but I do not see these statements in the > latest draft so I'm assuming that there was some > reason this association method was dropped. > > My question is: > In order to associate initiators with incoming > commands to a SCSI Target do I have to compare > the Initiator Name and ISID (up to ~268 bytes?) > for every command I receive against a list of > logged in initiators or is there another method > using a lot fewer number of bytes? > > I had thought about using the IP address in the > IP header but the draft seems to say that is not > allowed because IP addresses can change. It > seems like I must perform this potentially rather > long comparison if I support multiple initiators > because I can not be guaranteed that different > initiators would not use the same ISID during > their login. Am I wrong? > > Thanks in advance, > Kenneth Ray Craig, Jr. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 --=_alternative 00750678C2256BB4_= Content-Type: text/html; charset="us-ascii"
Amir,

Even more - the targe part of the session name has two components - TPGT and Target name.
Two session can start with the same INANE, ISID and terminate at different TNaMES behind a single TPGT.
I addition a separation is performed at tcp port level on the initiator side (as Mark outline a tcp connection is identified by 5 elements) but iSCSI does not make explicit use of this separation.

Julo


Mark Bakke <mbakke@cisco.com>
Sent by: mbakke@cisco.com

05/09/2002 08:39 PM
Please respond to Mark Bakke

       
        To:        Amir Shalit <amir@astutenetworks.com>
        cc:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        Re: Associating initiator names with SCSI commands

       


Amir Shalit wrote:
>
> 1) Editorial comment:
>    chapter 1 defines SCSI Port Name as:
>    A name made up as UTF-8 characters and basically...
>    +---+
>    Remove basically
>    +---+
>
> 2) The iSCSI namning model on page 49 shows two iSCSI target nodes
>    sharing the same portal group and the same TCP/IP addresses.
>    How can one steer PDU headers to the correct iSCSI node given
>    that setup?  Does it mean that a TCP connection doesn't belong
>    to a single iSCSI session?

Amir-

The portal group only contains the TCP address on which the
target is listening.  A TCP connection is identified by the
5-tuple (source-IP, dest-IP, protocol(TCP), source-port, dest-port).

Different connections to the target from the same source-IP will
have different source-ports.  Connections from different hosts
or host interfaces will have different source-IP addresses.
The dest-IP and dest-port can be the same for all incoming
connections to all targets.

--
Mark

>
> Amir
>
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Tuesday, May 07, 2002 12:12 PM
> To: Ken Craig
> Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
> Subject: Re: Associating initiator names with SCSI commands
>
> No - the session is associated with the initiator - if you record the
> session on which you received the command you have the association.
> How you represent internally the session is an implementation issue - but I
> assume you will not uses the names for that!
>
> Julo
>
> |---------+---------------------------->
> |         |           "Ken Craig"      |
> |         |           <kcraig@istor.com|
> |         |           >                |
> |         |           Sent by:         |
> |         |           owner-ips@ece.cmu|
> |         |           .edu             |
> |         |                            |
> |         |                            |
> |         |           05/07/2002 07:11 |
> |         |           PM               |
> |         |           Please respond to|
> |         |           "Ken Craig"      |
> |         |                            |
> |---------+---------------------------->
>
> >---------------------------------------------------------------------------
> ------------------------------------|
>   |
> |
>   |       To:       <ips@ece.cmu.edu>
> |
>   |       cc:
> |
>   |       Subject:  Associating initiator names with SCSI commands
> |
>   |
> |
>   |
> |
>
> >---------------------------------------------------------------------------
> ------------------------------------|
>
> I have a question concerning associating
> incoming SCSI commands with an initiator.
> I come from a parallel SCSI background and
> now find myself implementing a SCSI Target
> port in an iSCSI world.  I have searched
> the mailing list archives for discussions
> on this subject but have been unable to find
> anything that succinctly answers my question
> so please bear with me.
>
> In the parallel SCSI world association of an
> initiator with a new command is very
> straight-forward as the initiator's ID is
> encapsulated in the Identify message that
> occurs with the SCSI Selection phase that
> precedes receiving the new command.
>
> When I read the latest version of the iSCSI
> draft (rev. 12) the only statement I seem to
> find that correlates to this association is
> in Section 2.2.3 on page 34 in the 2nd
> sentence of the 3rd paragraph.
>
> "Any persistent state (e.g., persistent reservations)
> on the target that is associated with a SCSI
> initiator port is identified based on the
> value pair (InitiatorName, ISID)."
>
> When I searched the mailing list archives I
> came across statements that said this
> association was done using ISID and TSID (now
> TSIH?) but I do not see these statements in the
> latest draft so I'm assuming that there was some
> reason this association method was dropped.
>
> My question is:
> In order to associate initiators with incoming
> commands to a SCSI Target do I have to compare
> the Initiator Name and ISID (up to ~268 bytes?)
> for every command I receive against a list of
> logged in initiators or is there another method
> using a lot fewer number of bytes?
>
> I had thought about using the IP address in the
> IP header but the draft seems to say that is not
> allowed because IP addresses can change.  It
> seems like I must perform this potentially rather
> long comparison if I support multiple initiators
> because I can not be guaranteed that different
> initiators would not use the same ISID during
> their login.  Am I wrong?
>
> Thanks in advance,
> Kenneth Ray Craig, Jr.

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054

--=_alternative 00750678C2256BB4_=-- From owner-ips@ece.cmu.edu Thu May 9 18:29:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12178 for ; Thu, 9 May 2002 18:29:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49M4Y625156 for ips-outgoing; Thu, 9 May 2002 18:04:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49M4Vw25149; Thu, 9 May 2002 18:04:31 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g49M4Uc3027498; Thu, 9 May 2002 18:04:30 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g49M4Gh63586; Thu, 9 May 2002 16:04:16 -0600 Importance: Normal Subject: Re: iSCSI: NOP-In To: "Robert D. Russell" Cc: "Julian Satran" , ips@ece.cmu.edu, X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Thu, 9 May 2002 14:53:49 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/09/2002 04:04:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk You may be correct, but I think we need to use the Ping word, so that it becomes obvious, as it does now, that Ping from Initiator can have data but ping from Target can not. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Thu May 9 19:02:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12933 for ; Thu, 9 May 2002 19:02:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49MaGh27210 for ips-outgoing; Thu, 9 May 2002 18:36:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49MaEw27205 for ; Thu, 9 May 2002 18:36:15 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g49MaDRS043470; Thu, 9 May 2002 18:36:13 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g49MYuC63598; Thu, 9 May 2002 16:34:56 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI and IPSec To: Bill Studenmund Cc: Shahram Davari , "'ips@ece.cmu.edu'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Thu, 9 May 2002 15:33:33 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/09/2002 04:34:56 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, Though you are correct, the way you state it is as if Tunnel mode is some how easier to implement then Transport mode, or as if Encryption is not needed to be implemented. Now I am sure you did not mean that, so perhaps I should restate you answer as follows: * IPsec is a MUST be implemented: That is Data Integrity and Authentication Must be implemented * IPsec is also a MUST implement Confidentiality (encryption). * All of the above MUST be implemented in Tunnel Mode, and If the IPsec implementation of an iSCSI initiator or target conforms to the [RFC2401] definition of a host, then to comply with section 4.1 of [RFC2401] it MUST also implement the above in Transport mode. * So the thing you know for sure is that Tunnel mode MUST be implemented, and sometimes Transport mode will also be implemented. *However, the end customer has the freedom to turn on all or part of what ever IPsec version it has implemented. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Bill Studenmund @ece.cmu.edu on 05/09/2002 01:01:45 PM Sent by: owner-ips@ece.cmu.edu To: Shahram Davari cc: "'ips@ece.cmu.edu'" Subject: Re: iSCSI and IPSec On Thu, 9 May 2002, Shahram Davari wrote: > Hi, > > Is IPSec supported in iSCSI? and if so, is it optional to use or mandatory? IPsec is a MUST. Though you can get away with just tunnel mode. Take care, Bill From owner-ips@ece.cmu.edu Thu May 9 19:24:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13600 for ; Thu, 9 May 2002 19:24:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49MrwT28251 for ips-outgoing; Thu, 9 May 2002 18:53:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49Mrvw28246 for ; Thu, 9 May 2002 18:53:57 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 6B272AF7D for ; Thu, 9 May 2002 16:53:56 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 38A91120 for ; Thu, 9 May 2002 16:53:56 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 09 May 2002 16:53:51 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 16:53:51 -0600 Message-ID: <9F8400020EC5D311AF62009027C396160902C37A@axcs09.cos.agilent.com> From: kevin_lemay@agilent.com To: ips@ece.cmu.edu Subject: iSCSI: Nop StatSN clarification Date: Thu, 9 May 2002 16:53:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Can we make a minor adjustment to the format of the text in 9.19.1 which says: "Whenever the NOP-In is sent as a "ping" to an initiator (not as a response to a NOP-Out), the StatSN field will contain the next StatSN. However, StatSN for this connection is not advanced." Since this affects the processing of the statSN, can Make a section for statSN and list it there. I feel that it is easily lost by listing it under the target transfer tag. I know that my first read was... look for the statsn, found nothing and assumed that it always incremented. Thanks, Kevin Lemay From owner-ips@ece.cmu.edu Thu May 9 19:26:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13688 for ; Thu, 9 May 2002 19:26:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49NFgq29474 for ips-outgoing; Thu, 9 May 2002 19:15:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49NFew29470 for ; Thu, 9 May 2002 19:15:40 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id C272D805066; Thu, 9 May 2002 19:15:34 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id QAA04549; Thu, 9 May 2002 16:17:19 -0700 (PDT) Message-ID: <008001c1f7af$6b28ad90$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , References: <00ca01c1f313$0296ccd0$edd52b0f@rose.hp.com> <3CD694BC.E01A5A32@compuserve.com> <005301c1f525$e162fb00$edd52b0f@rose.hp.com> <3CD6E797.845F0095@compuserve.com> <004201c1f5f0$6dd423a0$edd52b0f@rose.hp.com> <3CD92786.40BD4B3@compuserve.com> <002301c1f6b3$f4d4a500$edd52b0f@rose.hp.com> <3CD9E2F8.5A882A87@compuserve.com> Subject: Re: FCIP: Comment 120 Date: Thu, 9 May 2002 16:15:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, Let's look at issues carefully. >were told that we > had to stop relying on knowing the exact IP Address and Port to decide > the end points of the FCIP Links. Which was exactly what I pointed out - you're using the "IP Address and Port to decide the end points of the FCIP Links" now (the end point is FC/FCIP Entity Pair, and which the FSF doesn't identify). > Furthermore, I repeat what I said originally and you conveniently > ignored: I ignored it because it has no merit. Please tell me a specific problem with "SLP, IPsec, IKE, and goodness knows what else". My experience with iSCSI is that it did not have any issues with the concept of multiple iSCSI Nodes within one Network Entity sharing the same Portals - conceptually identical to the multiple FC/FCIP Entity Pairs within one FC Fabric Entity. > conclusion that nothing is stable in an IP Network and SLP doesn't work. I'm surprised about this claim. Address volatility is something all networked storage lives with, and O/Ses know how to live with - this is true at several levels. - FC (Nport_ID volatility due to changed fabric ports, fabric merges etc.) Solution: use FC WWN (and RSCN) to ensure you're talking to the right entity. - iSCSI (IP_address & portal group volatility due to node reconfiguration, changed IP addresses etc.) Solution: use iSCSI Node/Port name (and SLP advertisements) to ensure you're talking to the right entity. - LUN (changed LU "views", changed authentication credentials etc.) Solution: use WWU-device identifiers (and UA "REPORTED LUNS DATA HAS CHANGED") to ensure you're talking to the right LU. To make my original point very clear, FCIP allows certain architectural possibilities today and I don't see all the possibilities being completely addressed one way or the other in details (such as FSF). If you want to exclude certain possibilities, please do so explicitly and state why. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Ralph Weber" To: Cc: "Mallikarjun C." Sent: Wednesday, May 08, 2002 7:46 PM Subject: Re: FCIP: Comment 120 > Mallikarjun, > > > Besides, I don't see anything in the current document that prohibits multiple > > FC/FCIP Entity Pairs from sharing the same IP/TCP address/port - and I believe > > that is the right architectural approach. > > In the Orange County meeting, the FCIP contributors were told that we > had to stop relying on knowing the exact IP Address and Port to decide > the end points of the FCIP Links. We were NOT told that we had to > allow multiple FC/FCIP Entity Pairs to share a single IP Address/Port. > In fact, I believe we were told that we could proceed using such > an assumption. > > We have followed what we were told to do. > > If you are authorized to change the rules on us again, so be it. But > for sure, I will need need to hear that FCIP is getting jerked around > again by the IETF from a higher authority. > > Furthermore, I repeat what I said originally and you conveniently > ignored: > > > > The only alternative would be to REQUIRE SLP interrogation before every > > > TCP connect request, and even then there would be zero assurance that > > > the IP universe would not shape shift between the SLP activities and > > > the TCP connect request. > > As far as I can tell, the basis for your argument yields the unmistakable > conclusion that nothing is stable in an IP Network and SLP doesn't work. > Frankly, that is beyond belief. > > .Ralph > > "Mallikarjun C." wrote: > > > > > > I would think that sending a TCP connect request to the same IP Address > > > and Port as was used in the previous TCP connect request would achieve > > > the intended result. > > > > Not a correct assumption. You are using names (FC Fabric Entity WWN is > > a name. The FC/FCIP Entity Identifier is a name unique within the scope of > > the FC Fabric Entity.) in FSF only because IP addresses/TCP port associations > > cannot provide the FCIP-end2end assurance that the right entities are talking. > > > > Besides, I don't see anything in the current document that prohibits multiple > > FC/FCIP Entity Pairs from sharing the same IP/TCP address/port - and I believe > > that is the right architectural approach. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > ----- Original Message ----- > > From: "Ralph Weber" > > To: > > Cc: "Mallikarjun C." > > Sent: Wednesday, May 08, 2002 6:26 AM > > Subject: Re: FCIP: Comment 120 > > > > > "Mallikarjun C." wrote: > > > > > > > Upon further thought, it appears to me that the "Destination FC/FCIP > > > > Entity Identifier" should be sent and received in the FSF. I can not > > > > think of a way currently to build an FCIP_LEP with multiple FCIP_DEs > > > > - for ex., how would a sender indicate his intention to add a TCP > > > > connection to an FC/FCIP Entity Pair that it's already communicating > > > > with? > > > > > > I would think that sending a TCP connect request to the same IP Address > > > and Port as was used in the previous TCP connect request would achieve > > > the intended result. > > > > > > The only alternative would be to REQUIRE SLP interrogation before every > > > TCP connect request, and even then there would be zero assurance that > > > the IP universe would not shape shift between the SLP activities and > > > the TCP connect request. > > > > > > Surely, there is some stability in IP addressing. > > > > > > Thanks. > > > > > > .Ralph > > > > > > > > From owner-ips@ece.cmu.edu Thu May 9 20:04:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15086 for ; Thu, 9 May 2002 20:04:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49NWKZ00384 for ips-outgoing; Thu, 9 May 2002 19:32:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49NWIw00375 for ; Thu, 9 May 2002 19:32:18 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel6.hp.com (Postfix) with ESMTP id 56C73E1; Thu, 9 May 2002 19:32:04 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id QAA10101; Thu, 9 May 2002 16:33:49 -0700 (PDT) Message-ID: <009601c1f7b1$b8dbd010$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , , References: <277DD60FB639D511AC0400B0D068B71E0293787C@CORPMX14> Subject: Re: FCIP: Comment 120 Date: Thu, 9 May 2002 16:32:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, From the text that Murali posted on this thread - " The FC-BB-2_IP Reference Model supports one logical IP Interface and allows sharing a 4-byte IPv4 or 16-byte IPv6 address in the following ways: a)A single IP address per FC-BB-2_IP device - A single IP address shared by all FC/FCIP Entity pairs" It's a simple extension to assume that the same well-known TCP port *could* be used for all Pairs, which results in multiple Pairs at the same *address* necessitating a *name* of some sort to identify the intended FSF recipient. >Having seen no other > participants in this discussion, Please see Murali's message. >I also believe that the rough > consensus of the WG is not to change FCIP in this fashion. I am *not* advocating a change. I am simply concerned that the FCIP text is neither ruling out certain possibilities explicitly, nor defining the architectural hooks to cater to all possibilities. I'd be perfectly okay with a statement that states that each IP-TCP Address-Port belongs to exactly one Pair (though the text then should ideally say why). Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: To: ; Cc: Sent: Thursday, May 09, 2002 1:39 PM Subject: RE: FCIP: Comment 120 > > > Besides, I don't see anything in the current document that prohibits > multiple > > > FC/FCIP Entity Pairs from sharing the same IP/TCP address/port - and I > believe > > > that is the right architectural approach. > > > > In the Orange County meeting, the FCIP contributors were told that we > > had to stop relying on knowing the exact IP Address and Port to decide > > the end points of the FCIP Links. We were NOT told that we had to > > allow multiple FC/FCIP Entity Pairs to share a single IP Address/Port. > > In fact, I believe we were told that we could proceed using such > > an assumption. > > While Ralph doth protest a bit much, I believe he has the better part > of this discussion. It is completely reasonable to identify an IP > service instance as "that which responds when contacting TCP port X > at IP address a.b.c.d" - for example, there's only one http server > behind port 80, but there might be a different one behind port 8080. > > If there's a NAT involved, the discussion gets a bit subtle, but > the principle remains - one opens a TCP connection to port X at > IP address a.b.c.d, and expects to talk directly to a specific instance > of an IP-based service. I don't see any need to change FCIP to > allow multiple FC/FCIP Entity Pairs to share a single IP Address/Port; > the fact that multiple TCP connections to the same FC/FCIP Entity > Pair can share that TCP Port seems sufficient. Having seen no other > participants in this discussion, I also believe that the rough > consensus of the WG is not to change FCIP in this fashion. > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- > > > From owner-ips@ece.cmu.edu Thu May 9 20:06:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15153 for ; Thu, 9 May 2002 20:06:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g49NjMC01084 for ips-outgoing; Thu, 9 May 2002 19:45:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g49NjKw01079 for ; Thu, 9 May 2002 19:45:21 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 19:45:15 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293788D@CORPMX14> From: Black_David@emc.com To: cbm@rose.hp.com, ips@ece.cmu.edu Subject: RE: FCIP: Comment 120 Date: Thu, 9 May 2002 19:44:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > >I also believe that the rough > > consensus of the WG is not to change FCIP in this fashion. > > I am *not* advocating a change. I am simply concerned that the FCIP > text is neither ruling out certain possibilities explicitly, > nor defining the > architectural hooks to cater to all possibilities. I'd be > perfectly okay with > a statement that states that each IP-TCP Address-Port belongs > to exactly > one Pair (though the text then should ideally say why). That's a reasonable request that I'm sure the FCIP draft editor would be happy to accommodate. The reason why is probably going to be some version of simplicity. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Thursday, May 09, 2002 7:32 PM > To: Black_David@emc.com; roweber@acm.org; ips@ece.cmu.edu > Subject: Re: FCIP: Comment 120 > > > David, > > From the text that Murali posted on this thread - > > " The FC-BB-2_IP Reference Model supports one logical IP Interface and > allows sharing a 4-byte IPv4 or 16-byte IPv6 address in the > following ways: > > a)A single IP address per FC-BB-2_IP device > - A single IP address shared by all FC/FCIP Entity pairs" > > > It's a simple extension to assume that the same well-known TCP port > *could* be used for all Pairs, which results in multiple > Pairs at the same *address* > necessitating a *name* of some sort to identify the intended > FSF recipient. > > >Having seen no other > > participants in this discussion, > > Please see Murali's message. > > >I also believe that the rough > > consensus of the WG is not to change FCIP in this fashion. > > I am *not* advocating a change. I am simply concerned that the FCIP > text is neither ruling out certain possibilities explicitly, > nor defining the > architectural hooks to cater to all possibilities. I'd be > perfectly okay with > a statement that states that each IP-TCP Address-Port belongs > to exactly > one Pair (though the text then should ideally say why). > > Thanks. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > ----- Original Message ----- > From: > To: ; > Cc: > Sent: Thursday, May 09, 2002 1:39 PM > Subject: RE: FCIP: Comment 120 > > > > > > Besides, I don't see anything in the current document > that prohibits > > multiple > > > > FC/FCIP Entity Pairs from sharing the same IP/TCP > address/port - and I > > believe > > > > that is the right architectural approach. > > > > > > In the Orange County meeting, the FCIP contributors were > told that we > > > had to stop relying on knowing the exact IP Address and > Port to decide > > > the end points of the FCIP Links. We were NOT told that we had to > > > allow multiple FC/FCIP Entity Pairs to share a single IP > Address/Port. > > > In fact, I believe we were told that we could proceed using such > > > an assumption. > > > > While Ralph doth protest a bit much, I believe he has the > better part > > of this discussion. It is completely reasonable to identify an IP > > service instance as "that which responds when contacting TCP port X > > at IP address a.b.c.d" - for example, there's only one http server > > behind port 80, but there might be a different one behind port 8080. > > > > If there's a NAT involved, the discussion gets a bit subtle, but > > the principle remains - one opens a TCP connection to port X at > > IP address a.b.c.d, and expects to talk directly to a > specific instance > > of an IP-based service. I don't see any need to change FCIP to > > allow multiple FC/FCIP Entity Pairs to share a single IP > Address/Port; > > the fact that multiple TCP connections to the same FC/FCIP Entity > > Pair can share that TCP Port seems sufficient. Having seen no other > > participants in this discussion, I also believe that the rough > > consensus of the WG is not to change FCIP in this fashion. > > > > Thanks, > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > black_david@emc.com Cell: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > > > From owner-ips@ece.cmu.edu Thu May 9 21:47:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19832 for ; Thu, 9 May 2002 21:47:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4A11aO05369 for ips-outgoing; Thu, 9 May 2002 21:01:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4A11Yw05363 for ; Thu, 9 May 2002 21:01:34 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4A11P409397; Thu, 9 May 2002 21:01:25 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g4A11O715048; Thu, 9 May 2002 21:01:25 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 21:00:23 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293788F@CORPMX14> From: Black_David@emc.com To: hufferd@us.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI and IPSec Date: Thu, 9 May 2002 21:00:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-PerlMx-Spam: Gauge=XIIIIII, Probability=16%, Report="NO_REAL_NAME" Sender: owner-ips@ece.cmu.edu Precedence: bulk > Though you are correct, the way you state it is as if Tunnel mode is some > how easier to implement then Transport mode, or as if Encryption is not > needed to be implemented. Now I am sure you did not mean that, so perhaps > I should restate you answer as follows: > * IPsec is a MUST be implemented: That is Data Integrity and Authentication > Must be implemented > > * IPsec is also a MUST implement Confidentiality (encryption). > > * All of the above MUST be implemented in Tunnel Mode, and If the IPsec > implementation of an iSCSI initiator or target conforms to the [RFC2401] > definition of a host, then to comply with section 4.1 of [RFC2401] it MUST > also implement the above in Transport mode. That was the case before the March meeting in Minneapolis. The current situation is the Tunnel Mode MUST be implemented, Transport Mode is OPTIONAL, and there is no need to consult the [RFC2401] definition of a host to figure this out. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu May 9 21:47:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19864 for ; Thu, 9 May 2002 21:47:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4A18J405776 for ips-outgoing; Thu, 9 May 2002 21:08:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4A18Hw05771; Thu, 9 May 2002 21:08:17 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4A1884Q011356; Fri, 10 May 2002 03:08:08 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4A188V18266; Fri, 10 May 2002 03:08:08 +0200 To: kevin_lemay@agilent.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Nop StatSN clarification X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 10 May 2002 04:08:03 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/05/2002 04:08:08, Serialize complete at 10/05/2002 04:08:08 Content-Type: multipart/alternative; boundary="=_alternative 00055233C2256BB5_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00055233C2256BB5_= Content-Type: text/plain; charset="us-ascii" I'll try - Julo kevin_lemay@agilent.com Sent by: owner-ips@ece.cmu.edu 05/10/2002 01:53 AM Please respond to kevin_lemay To: ips@ece.cmu.edu cc: Subject: iSCSI: Nop StatSN clarification Julian, Can we make a minor adjustment to the format of the text in 9.19.1 which says: "Whenever the NOP-In is sent as a "ping" to an initiator (not as a response to a NOP-Out), the StatSN field will contain the next StatSN. However, StatSN for this connection is not advanced." Since this affects the processing of the statSN, can Make a section for statSN and list it there. I feel that it is easily lost by listing it under the target transfer tag. I know that my first read was... look for the statsn, found nothing and assumed that it always incremented. Thanks, Kevin Lemay --=_alternative 00055233C2256BB5_= Content-Type: text/html; charset="us-ascii"
I'll try - Julo


kevin_lemay@agilent.com
Sent by: owner-ips@ece.cmu.edu

05/10/2002 01:53 AM
Please respond to kevin_lemay

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: Nop StatSN clarification

       


Julian,

Can we make a minor adjustment to the format of the text in 9.19.1 which
says:

"Whenever the NOP-In is sent as a "ping" to an initiator (not as a response
to a NOP-Out), the StatSN field will contain the next StatSN. However,
StatSN for this connection is not advanced."

Since this affects the processing of the statSN, can Make a section for
statSN and list it there.

I feel that it is easily lost by listing it under the target transfer tag. I
know that my first read was... look for the statsn, found nothing and
assumed that it always incremented.

Thanks,

Kevin Lemay

--=_alternative 00055233C2256BB5_=-- From owner-ips@ece.cmu.edu Fri May 10 06:44:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13144 for ; Fri, 10 May 2002 06:44:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4A9urp17314 for ips-outgoing; Fri, 10 May 2002 05:56:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4A9upw17309 for ; Fri, 10 May 2002 05:56:52 -0400 (EDT) Received: from bursar.muttsnuts.com (213.190.135.30) by mail.san.yahoo.com (6.5.017.1) id 3CDB8C5C00001FB0 for ips@ece.cmu.edu; Fri, 10 May 2002 02:56:21 -0700 Message-Id: <5.1.0.14.2.20020510103455.0320bea8@mail.muttsnuts.com> X-Sender: markemuttsnuts@mail.muttsnuts.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 10 May 2002 10:51:56 +0100 To: ips@ece.cmu.edu From: "Mark S. Edwards" Subject: ISCSI: CmdSN in non-leading login Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk I am looking for clarification with regard the value that an initiator should put in the CmdSN field of a login request for a non-leading connection. There is a certain ambiguity about 9.12.8. The text describes how in a leading connection, the target takes must accept and use a non-zero CmdSN, but it does not explain what should be present for a non-leading connection. There are a couple of problems here for the target. At what point is a non-leading connection considered to be part of the session ? Is it the moment that the login request is received with a non-zero TSIH ? Or is it only when the non-leading login succeeds and it enters full feature phase ? So, should an initiator set the CmdSN in the first login request to zero and only synchronise with the session command stream after full feature phase is established ? This is my preferred option. What happens if the initiator tries using the current session command sequence number is that whilst the login negotiation occurs, other connections within the session can be issuing new commands, so by the time that the login is finished the CmdSN exchanged in the initial request is invalid anyway. I would like to see something along the lines that for a non-leading connection, the CmdSN field MUST be zero and that the connection can not be considered part of the session until full feature phase is entered, at which point any commands issued on the connection are now synchronised with the session command sequence number as observed by all other existing connections on the session. regards, Mark. From owner-ips@ece.cmu.edu Fri May 10 08:57:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19460 for ; Fri, 10 May 2002 08:57:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4ACOST24783 for ips-outgoing; Fri, 10 May 2002 08:24:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4A9oNw16978 for ; Fri, 10 May 2002 05:50:23 -0400 (EDT) Received: from monishabarooah [202.56.255.250] by myrealbox.com with NIMS ModWeb Module; Fri, 10 May 2002 09:50:25 +0000 Subject: Session Error From: "Monisha Barooah" To: ips@ece.cmu.edu Date: Fri, 10 May 2002 09:50:25 +0000 X-Mailer: NIMS ModWeb Module X-Sender: monishabarooah MIME-Version: 1.0 Message-ID: <1021024225.406e7ff1monishabarooah@myrealbox.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g4A9oNw16979 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi All, The following ia an extract from the draft: If all the connections of a session fail and cannot be re-established in a short time, or if initiators detect protocol errors repeatedly, an initiator may choose to terminate a session and establish a new session. In the above sentence "if initiators detect protocol errors repeatedly". What does this mean? Does it mean that consecutive protocol errors lead to session error? Regards, Monisha. From owner-ips@ece.cmu.edu Fri May 10 08:58:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19523 for ; Fri, 10 May 2002 08:57:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4ACOdd24796 for ips-outgoing; Fri, 10 May 2002 08:24:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4A9u6w17255 for ; Fri, 10 May 2002 05:56:06 -0400 (EDT) Received: from monishabarooah [202.56.255.250] by myrealbox.com with NIMS ModWeb Module; Fri, 10 May 2002 09:56:07 +0000 Subject: Task Reassign corresponding to logouts From: "Monisha Barooah" To: ips@ece.cmu.edu Date: Fri, 10 May 2002 09:56:07 +0000 X-Mailer: NIMS ModWeb Module X-Sender: monishabarooah MIME-Version: 1.0 Message-ID: <1021024567.4ba14ff1monishabarooah@myrealbox.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g4A9u6w17256 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi All, There is another doubt here. When the Error recovery level is 2, Is it necessary to perform Task Reassign after all successful logouts? Or is it that Task Reassign be performed only if the logout request is that corresponding to "remove the connection for recovery". Regards, Monisha. From owner-ips@ece.cmu.edu Fri May 10 08:59:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19612 for ; Fri, 10 May 2002 08:59:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4ACfF625780 for ips-outgoing; Fri, 10 May 2002 08:41:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2ab.compuserve.com (siaar2ab.compuserve.com [149.174.40.138]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4ACfDw25774 for ; Fri, 10 May 2002 08:41:13 -0400 (EDT) Received: (from mailgate@localhost) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id IAA07102 for ips@ece.cmu.edu; Fri, 10 May 2002 08:41:07 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkf-vty19.as.wcom.net [206.175.235.19]) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id IAA07015 for ; Fri, 10 May 2002 08:41:00 -0400 (EDT) Message-ID: <3CDBC137.464DBD84@compuserve.com> Date: Fri, 10 May 2002 07:46:47 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: FCIP Comment 44 - Proposed text for new section Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The following is the text proposed for the new FCIP section that is described in the response to Last Call comment 44. 8.2 Overview of FSF Usage in Connection Establishment When a new TCP Connection is established, an FCIP Special Frame makes one round trip from the FCIP Entity initiating the TCP connect operation to the FCIP Entity receiving the TCP connect request and back. This FSF usage serves three functions: - Identification of the FCIP Link endpoints - Conveyance of a few critical parameters shared by the FC/FCIP Entity pairs involved in the FCIP Link - Configuration discovery (used in place of SLP only when allowed by site security policies) The specific requirements for this usage of the FSF are found in section 9.1. This section provides an overview of the FSF usage without stating requirements. Because FCIP is only a tunnel for a Fibre Channel Fabric and because the Fabric has its own complex link setup algorithm that can be employed for many FCIP link setup needs, it is desirable to minimize the complexity of the FSF usage during TCP Connection setup. With this in mind, this FSF usage is not a login or parameter negotiation mechanism. A single FSF transits each newly established TCP connection as the first bytes sent in each direction. Note: This usage of the FSF cannot be eliminated entirely because a newly created TCP Connection must be associated with the correct FCIP Link before FC Fabric initialization of the connection can commence. The first bytes sent from the TCP connect request initiator to the receiver are an FSF identifying both the sender and who the sender thinks is the receiver. If the contents of this FSF are correct and acceptable to the receiver, the unchanged FSF is echoed back to the sender. This send/echo process is the only set of actions that allows the TCP Connection to be used to carry FC Fabric traffic. If the send and unchanged echo process does not occur, the algorithm followed at one or both ends of the TCP Connection results in the closure of the TCP Connection (see section 9.1 for specific algorithm requirements). Note: Owing to the limited manner in which the FSF is used and the requirement that the FSF be echoed without changes before a TCP Connection is allowed to carry user data, no error checking beyond that provided by TCP is deemed necessary. As described above, the primary purpose of the FSF usage during TCP Connection setup is identifying the FCIP Link to which the new TCP Connection belongs. From these beginnings, it is only a small stretch to envision using the FSF as a simplified configuration discovery tool, and the mechanics of such a usage are described in section 9.1. However, use of the FSF for configuration discovery lacks the broad range of capabilities provided by SLP v2 and most particularly lacks the security capabilities of SLP v2. For these reasons, using the FSF for configuration discovery is not appropriate for all environments. Thus the choice to use the FSF for discovery purposes is a policy choice to be included in the TCP Connection Establishment "shared" database described in section 9.1.1. When FSF-based configuration discovery is enabled, the normal TCP Connection setup rules outlined above are modified as follows. Normally, the algorithm executed by an FCIP Entity receiving an FSF includes verifying that its own identification information in the arriving FSF is correct and closing the TCP Connection if it is not. This can be viewed as requiring the initiator of a TCP connect request to know in advance the identity of the FCIP Entity that is the target of that request (using SLP, for example), and through the FSF effectively saying, "I think I'm talking to X." If the party at the other end of the TCP connect request is really Y, then it simply hangs up. FSF-based discovery allows the "I think I'm talking to X" to be replaced with "Please tell me who I am talking to?", which is accomplished by replacing an explicit value in the Destination FC Fabric Entity World Wide Name field with zero. If the policy at the receiving FCIP Entity allows FSF-based discovery, the zero is replaced with the correct Destination FC Fabric Entity World Wide Name value in the echoed FSF. This is still subject to the rules of sending with unchanged echo, and so closure of TCP Connection occurs after the echoed FSF is received by the TCP connect initiator. Despite the TCP Connection closure, however, the TCP connect initiator now knows the correct Destination FC Fabric Entity World Wide Name identity of the FCIP Entity at a given IP Address and a subsequent TCP Connection setup sequence probably will be successful. The Ch bit in the pFlags field (see section 6.6.1) allows for differentiation between changes in the FSF resulting from transmission errors and changes resulting from intentional acts by the FSF recipient. From owner-ips@ece.cmu.edu Fri May 10 08:59:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19625 for ; Fri, 10 May 2002 08:59:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4ACOPA24774 for ips-outgoing; Fri, 10 May 2002 08:24:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4A9kPw16782 for ; Fri, 10 May 2002 05:46:25 -0400 (EDT) Received: from monishabarooah [202.56.255.250] by myrealbox.com with NIMS ModWeb Module; Fri, 10 May 2002 09:46:26 +0000 Subject: Connection Recovery in case of a single connection in a session From: "Monisha Barooah" To: ips@ece.cmu.edu Date: Fri, 10 May 2002 09:46:26 +0000 X-Mailer: NIMS ModWeb Module X-Sender: monishabarooah MIME-Version: 1.0 Message-ID: <1021023986.406e7ff1monishabarooah@myrealbox.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g4A9kPw16783 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi All, I wanted to know how to perform Connection Recovery for a connection when it is the only connection of a session. Connection Recovery invloves the logout of the failed connection and the reassignment of the tasks of the failed connection to a full feature phased connection. In case there is only one connection in a session. How do we do the Connection Recovery? Shall we open up another connection to do implicit logout? But in this case the CID of the new connection will be the same as that of the failed connection and the task reassignment will not come into picture at all. Regards, Monisha. From owner-ips@ece.cmu.edu Fri May 10 09:37:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21847 for ; Fri, 10 May 2002 09:37:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4ACxRM26804 for ips-outgoing; Fri, 10 May 2002 08:59:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4ACxOw26799 for ; Fri, 10 May 2002 08:59:24 -0400 (EDT) Received: (from mailgate@localhost) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id IAA06661 for ips@ece.cmu.edu; Fri, 10 May 2002 08:59:18 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkf-vty19.as.wcom.net [206.175.235.19]) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id IAA06601; Fri, 10 May 2002 08:59:12 -0400 (EDT) Message-ID: <3CDBC595.3A55FD28@compuserve.com> Date: Fri, 10 May 2002 08:05:25 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu CC: Black_David@emc.com, cbm@rose.hp.com Subject: Re: FCIP: Comment 120 References: <277DD60FB639D511AC0400B0D068B71E0293788D@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Slight modifications to the first sentence after Figure 4 (in section 6.4) would seem to suffice for the requirement aspect. Change: The FCIP Entity is the connection interface point for the IP Network and is the owner of the IP Address and Well Known Port used to form TCP Connections. to: The FCIP Entity is the connection interface point for the IP Network and is the sole owner of at least one IP Address and Well Known Port used to form TCP Connections. The change from "owner" to "sole owner" addresses Mallikarjun's requirement issue, and the change from "one" to "at least one" addresses the FC-BB-2 text posted by Murali. A new sentence can be added immediately following the sentence cited above to address the "why" issue. Add: The TCP Connection establishment algorithms in section 9.1 and FSF usage described in section 8.2 assume that TCP connect requests for a given FC/FCIP Entity pair are received via uniquely identifiable IP Address and Well Known Port. Thanks. .Ralph Black_David@emc.com wrote: > > > >I also believe that the rough > > > consensus of the WG is not to change FCIP in this fashion. > > > > I am *not* advocating a change. I am simply concerned that the FCIP > > text is neither ruling out certain possibilities explicitly, > > nor defining the > > architectural hooks to cater to all possibilities. I'd be > > perfectly okay with > > a statement that states that each IP-TCP Address-Port belongs > > to exactly > > one Pair (though the text then should ideally say why). > > That's a reasonable request that I'm sure the FCIP draft editor > would be happy to accommodate. The reason why is probably going > to be some version of simplicity. > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- From owner-ips@ece.cmu.edu Fri May 10 10:15:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24355 for ; Fri, 10 May 2002 10:15:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4ADdFT29436 for ips-outgoing; Fri, 10 May 2002 09:39:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4ADdDw29432 for ; Fri, 10 May 2002 09:39:13 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4ADd5B12010; Fri, 10 May 2002 09:39:05 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g4ADd4724771; Fri, 10 May 2002 09:39:04 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 09:37:59 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937895@CORPMX14> From: Black_David@emc.com To: roweber@acm.org, ips@ece.cmu.edu Subject: RE: FCIP: Comment 120 Date: Fri, 10 May 2002 09:37:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-PerlMx-Spam: Gauge=XIIIIII, Probability=16%, Report="NO_REAL_NAME" Sender: owner-ips@ece.cmu.edu Precedence: bulk Ralph, I suggest the following change, which is mostly editorial, but may raise a different issue. Old text: is the sole owner of at least one IP Address and Well Known Port used to form TCP Connections New text: is the sole user of at least TCP port at the IP address used for TCP connections to the FCIP Entity. The editorial change is to remove any implication of sole ownership/ usership of the IP address. The potential new issue is that while FCIP has an IANA-assigned TCP port, the specification should not prohibit use of a different port for initial contact. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri May 10 11:51:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00211 for ; Fri, 10 May 2002 11:51:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AF6uo06449 for ips-outgoing; Fri, 10 May 2002 11:06:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from fed1mtao02.cox.net (fed1mtao02.cox.net [68.6.19.243]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AF6qw06431 for ; Fri, 10 May 2002 11:06:52 -0400 (EDT) Received: from cox.net ([68.6.87.123]) by fed1mtao02.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020510150646.GCWM24965.fed1mtao02.cox.net@cox.net>; Fri, 10 May 2002 11:06:46 -0400 Message-ID: <3CDBE239.6050100@cox.net> Date: Fri, 10 May 2002 08:07:37 -0700 From: Marinus De Jong User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Black_David@emc.com CC: roweber@acm.org, ips@ece.cmu.edu Subject: Re: FCIP: Comment 120 References: <277DD60FB639D511AC0400B0D068B71E02937895@CORPMX14> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, In the statement below can you tell me how someone would know which port to use for the initial contact. >...the specification should not prohibit use of a different port for initial contact. > Rienco De Jong From owner-ips@ece.cmu.edu Fri May 10 11:53:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00370 for ; Fri, 10 May 2002 11:53:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AFdoJ09248 for ips-outgoing; Fri, 10 May 2002 11:39:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AFdlw09242 for ; Fri, 10 May 2002 11:39:48 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4AFdgCo029264; Fri, 10 May 2002 17:39:42 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4AFdeS74232; Fri, 10 May 2002 17:39:40 +0200 Subject: Re: iSCSI - an improved text for 4.1 & 4.2 To: Martins Krikis Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Fri, 10 May 2002 09:54:29 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/05/2002 18:39:39 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk We are getting close - more comments in text. Julo Martins Krikis cc: Subject: Re: iSCSI - an improved text for 4.1 & 4.2 05/06/2002 11:26 PM Please respond to Martins Krikis --- Julian Satran wrote: > > comments in text - julo Thanks for your attention to these issues. I've deleted everything that I don't have any more immediate comments on. > How the encoding is done would be better put higher > up with the base-64-constant definition, then it > would > not need to be repeated again and again. > +++ that is what regular and large attempt +++ My point was this. The draft mentions 3 times how the base-64 encoding should be done (i.e., according to RFC2045). It does this for regular-numerical, regular-binary and large-binary values. It forgets to say this for large-numerical. Instead of these 3 (should have been 4?) times, it would have sufficed to say so once and say it where the base-64-constant is defined. And it would have been better to say it there because then one would know how to encode this constant immediately, before reading about its applicability to regular/large-numerical/binary values... +++ OK - now that I understand you +++ > > regular-binary-value : a binary string less than > > 64 bits encoded as a > > decimal > > constant, hex constant or base-64 con-stant. For > > base-64 encoding the > > encoding > > is done according to [RFC2045]. The length of the > > string is either > > specified > > by the key definition or is implied by the > > encoding as the mini-mum > > number of > > bytes that can hold the encoded string. > > The last sentence is ambiguous, IMHO, and incorrect > no matter how understood. If, encoded as > as a hex constant, the value is 0x000f, what is its > length when decoded? 6 bytes ("0x000f" w/o '\0') > or 1 byte (containing bits 00001111)? The answer > that I think we want is 2 bytes... The problem is > that > not knowing what the string is, we can't tell > how many bytes are required to hold it. Some other > description will be necessary, I'm afraid. > > +++ that is incorrect. the text says the minimum > number of BYTES: > 0xf or 0x0f fit in ONE byte, 0x000f fit in 2 bytes. It all depends on how "fit" is defined. Since it isn't, I can quite reasonably assume that 0x000f does fit in 1 byte. Therefore, the draft should say that for hex-encoded binary strings, the leading zeroes in hex encoding do count. Each hex digit results in 4 bits. Then we can say that the string consists of the minimum number of bytes that can hold all those bits. +++ well we must be a funny sort of computer geeks if we assume that the rest of the text is understandable but here we have an issue. How about the following text: Text Format The initiator and target send a set of key=value pairs encoded in UTF-8 Unicode. All the text keys and text values specified in this document are to be presented and interpreted in the case they appear in this document. They are case sensitive. The following character symbols are used in this document for text items: (a-z, A-Z) - letters (0-9) - digits " " (0x20) - space "." (0x2e) - dot "-" (0x2d) - minus "+" (0x2b) - plus "@" (0x40) - commercial at "_" (0x5f) - underscore "=" (0x3d) - equal ":" (0x3a) - colon "/" (0x2f) - solidus or slash "[" (0x5b) - left bracket "]" (0x5d) - right bracket nul (0x00) - nul separator "," (0x2c) - comma "~" (0x7e) - tilde A key-name is whatever precedes the first = in the key=value pair. The term key is used frequently in this document with the meaning of key-name. A value is whatever follows the = that follows the key-name up to a zero-byte delimiter that marks the end of any key=value pair (includ-ing the last in a PDU). The following definitions will be used in the rest of this document: key-name: a string of one or more characters consisting of letters, digits, dot, minus, plus, commercial at, and under-score, A key-name MUST begin with a capital letter an must not exceed 63 characters. text-value: a string of 0 or more characters consisting of let-ters, digits, dot, minus, plus, commercial at, underscore, slash, left bracket, right bracket and colon. iSCSI-name-value: a string of one or more characters consist-ing of minus, dot, colon and any character allowed by the output of the iSCSI string-prep template as specified in [STPREP-iSCSI] (see also Section 2.2.6.2 iSCSI Name Encoding). iSCSI-local-name-value: an UTF-8 string; no nul characters are allowed in the string. This encoding is to be used for local-ized (internationalized) aliases. boolean-value: the string "Yes" or "No". hex-constant: hexadecimal constant encoded as a string start-ing with "0x" or "0X" followed by 1 or more digits or the letters a, b, c, d, e, f, A, B, C, D, E and F. Hex-constants are used to encode numerical values or binary strings. When used to encode numerical values the excesive use of leading 0 digits is discouraged. When used to encode binary strings hexadecimal constants have an implicit byte-length that includes 4 bits for every hexadecimal digit of the constant, including eading zeroes (i.e., a hex-constant of n hexadeci-mal digits has a byte-length of (the integer part of) (n+1)/ 2). decimal-constant: an unsigned decimal number - the digit 0 or a string of 1 or more digits starting with a non-zero digit. This encoding is not used for numerical values equal or greater than 2**64. Decimal-constants are used to encode numerical values or binary strings. When used to encode binary strings decimal constants have an implicit byte-length that is the minimum number of bytes needed to represent the base2 encoding of the decimal number. base64-constant: base64 constant encoded as a string starting with "0b" or "0B" followed by 1 or more digits or letters or plus or slash or equal. The encoding is done according to [RFC2045]. base64-constants are used to encode numerical val-ues or binary strings. When used to encode numerical values the excesive use of leading 0s prior to encoding - encoded as "A" - is discouraged. When used to encode binary strings base64-constants have an implicit byte-length that includes 6 bits for every character of the constant excluding trailing equals (i.e., a base64-constant of n base64 characters with m trailing equals has a byte-length of ((the integer part of) ((n+3)*3/4) - m). regular-numerical-value : an unsigned integer less than 2**64 encoded as a decimal-constant, hex constant, or base64-con-stant. large-numerical-value : an unsigned integer larger than or equal to 2**64 encoded as a hex constant, or base64-constant. numerical-value: a regular-numerical-value or a large numeri-cal-value. Unsigned integer arithmetic applies to numeric-values. numeric-range: two numerical-values separated by a tilde where the value to the right of tilde must not be lower that the value to the left. regular-binary-value : a binary string less than 64 bits encoded as a decimal constant, hex constant or base64-con-stant. The length of the string is either specified by the key definition or is implicit byte-length of the encoded string. large-binary-value : a binary string encoded as a hex-con-stant or base64-constant. The length of the string is either specified by the key definition or is implicit byte-length of the encoded string. binary-value: a regular-binary-value or a large-binary-value. Operations on binary values are key specific. simple-value: text-value, iSCSI-name-value, boolean-value, numeric-value, a numeric-range or a binary-value. list-of-values: a sequence of text-values separated by comma If not otherwise specified, the maximum length of a simple-value (not its encoded representation) is 255 bytes not including the delimiter (comma or zero byte). Any iSCSI target or initiator MUST support receiving at least 16384 bytes of key=value data in a negotiation sequence except when indi-cating support for very long authentication items by offering or selecting authentication methods such as public key certificates in which case they MUST support receiving at least 64 kilobytes of key=value data. ++++ > Hex constant encode binary strings and not numbers. > to avoid any ambiguity I've rephrased it: > > The length of the string is either specified by the > key definition or is > implied by the encoding as the minimum number of > bytes that can hold all > hexadecimal digits of the encoded string. ++++ This, IMO, didn't clear the problem that I was referring to. Furthermore it made me notice that the length-of-string question is not applicable to base-64-constants, and therefore the explanation of how to determine the string length should say that this is only for hex encoding. (Currently it looks like this refers to all kinds of encodings, then refers to hexadecimal digits.) How about this: The length of the string is either specified by the key definition or by its encoding. For strings encoded as hex-constants, every hexadecimal digit of the encoding, including leading zeroes, represents 4 bits of the original string. Therefore, if the hex-constant has n hexadecimal digits, the length of the string that it encodes is (the integer part of) (n+1)/2. > > simple-value: text-value, iSCSI-name-value, > > boolean-value, > > numeric-value, a > > numeric-range or a binary-value. > > iSCSI-local-name-value seems to be missing. > > +++ they appear later not as simple-values ... +++ Only in the subsection Text Mode Negotiation, where all kinds of simple-values are listed again (begging the question, why was the simple-value defined if all this is listed again explicitly). OK, I take it that the main reason for defining simple-value was the 255 byte length restriction and that iSCSI-local-name-value doesn't have it and therefore isn't simple. If so, then please disregard my previous comment. Please note however, that should such values ever become negotiated, the draft hasn't described yet how to do that (only simple-values and lists-of-values are covered). > > ... If a responder does not support, > > does not understand or is not > > allowed to use all of the offered options with > > a specific originator, it MAY > > use the constant "Reject". > > If I don't support "all", but support at > least one of the offered values, > I should answer with something I support > and not with Reject. "Options" have not been > defined or used before. Alright, I'm not a > native English speaker myself, but I'll volunteer: > > If each of the offered values is not understood > or not supported, or the responder is not > allowed to use it with the specific > originator,it MAY use the constant "Reject". > +++ I have made it Anyone - I am sick about this > statement that everybody understands and > everybody tries to rephrase +++ Sorry, I wasn't aware of this statement even being noticed by anybody. I can't see how "Anyone" could make it better, but I'll wait for the text. > > The selection of a value not admissible > > under the selection rules is considered a > > nego-tiation failure and is handled > > as a protocol error. The selection rules > > are key-specific. > > It was just said above (I didn't quote it) > that the selection rule is to pick the first > value supported. Thus, I'm not sure why here the > rule is key-specific. > > +++ If you are offered a range and select ouside the > range or if you are > offered a key=no and you respond key=yes when the > specific rule is AND or > if you are given a buffer-size and you select a > larger value - those are > each errors but each according to a separate and key > specific rule +++ Yes, those are the generic rules, but the point was that this text is in the context of list negotiations, where the only rule is "pick-the-first". And it was just said that that's the rule. Therefore telling afterwards that the rule is key-specific can be confusing. +++ I'll fix the text for list +++ > > For a numerical range the value > > selected must > > be an integer within the offered range or > > "Reject" (if the range is > > unacceptable). An offer of a value not admissible > > MAY be answered with the > > constant "Reject" or the responder MAY > > select an admissible value. > > What was meant here by "value not admissible"? > Outside the legal range > of values or simply outside the range that the > responder supports? +++ See above +++ No, sorry, the above was about selection. This is about offers. Concrete example: IFMarkInt. The allowed range is 1 to 65535. The range I support is 1 to 16. If the other side sends 17 is this "value not admissible"? If the other side sends 65536, is that "value inadmissible"? The draft is not clear here, that's all I'm pointing out. > Am I right or wrong? +++ You are wrong! +++ I think I was right :-) But I am happy with how it was rephrased so I'll move on. Thanks, Martins Krikis, Intel Corp. P.S. I hope the next version will clearly address the repetition issues regarding Reject and Irrelevant. Previous confusion about this has severely impacted my own implementation. +++ 4.2 text is Text Mode Negotiation During login, and thereafter, some session or connection parameters are either declared or negotiated through an exchange of textual information. The initiator starts the negotiation and/or declaration through a Text/Login request and indicates when it is ready for completion (by setting to 1 and keeping to 1 the F bit in a Text Request or the T bit in the Login Request). The format of a declaration is: Declarer-> = The general format of text negotiation is: Originator-> = Responder-> =|NotUnderstood|Irrelevant|Reject The originator or declarer can either be the initiator or the target and the responder can either be the target or initiator, respec-tively. Target requests are not limited to respond to key=value pairs as offered by the initiator. The target may offer key=value pairs of its own. All negotiations are explicit (i.e., the result MUST be based only on newly exchanged or declared values). There are no implicit offers. If an explicit offer is not made then a reply cannot be expected. Con-servative design requires also that default values should not be relied upon when use of some other value has serious consequences. The value offered or declared can be an numerical-value, a numerical-range defined by lower and upper value - both integers separated by tilde, a binary value, a text-value, a iSCSI-name-value, an iSCSI-local-name-value, a boolean-value (Yes or No), or a list of comma separated text-values. A range MAY ONLY be offered if it is explic-itly allowed for a key. An iSCSI-name-value and an iSCSI-local-name-value can be used only where explicitly allowed. A selected value can be an numerical-value, a text-value or a boolean-value. If a specific key is not relevant for the current negotiation, the responder may answer with the constant "Irrelevant" for all types of negotiation. However the negotiation is not considered as failed if the response is Irrelevant. Any key not understood by the responder may be ignored by the responder without affecting the basic function. However, the Text Response for a key not understood MUST be key=NotUnderstood. The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and must only be used as described here. Reject or Irrelevant are legitimate negotiation options where allowed but their excessive use is discouraged. Some basic key=value pairs are described in Chapter 11. All keys in Chapter 11, except for the X- extension format, MUST be supported by iSCSI initiators and targets and MUST NOT be answered with NotUnder-stood. Implementers may introduce new keys by prefixing them with X- fol-lowed by their (reversed) domain name. For example the entity owning the domain acme.com can issue: X-com.acme.bar.foo.do_something=3 List negotiations In list negotiation, the originator sends a list of values (which may include "None") in its order of preference. The responding party MUST respond with the same key and select first value that it supports (and is allowed to use for the specific origi-nator) selected from the originator list. The constant "None" MUST always be used to indicate a missing func-tion. However, None is a valid selection only if it is explicitly offered. If a responder does not understand any particular value in a list it MUST ignore it. If a responder does not support, does not understand or is not allowed to use anyone of the offered options with a spe-cific originator, it MAY use the constant "Reject" or it respond with an admissible value. The selection of a value not offered is consid-ered a negotiation failure and is handled as a protocol error. Simple-value negotiations For simple-value negotiations, the responding party MUST respond with the same key. The value it selects, based on the selection rule spe-cific to the key, becomes the negotiation result. For a numerical range the value selected must be an integer within the offered range or "Reject" (if the range is unacceptable). An offer of a value not admissible (e.g., not within the specified bounds) MAY be answered with the constant "Reject" or the responder MAY select an admissible value. The selection, by the responder, of a value not admissible under the selection rules is considered a negotiation failure and is handled accordingly. The selection rules are key-specific. For boolean negotiations (keys taking the values Yes or No), the responding party MUST respond with the same key and the result of the negotiation when the received value does not determine that result by itself. The last value transmitted becomes the negotiation result. The rules for selecting the value with which to respond are expressed as Boolean functions of the value received and the value that the responding party would have selected if given a choice. Specifically, the two cases in which responses are OPTIONAL are: - The boolean function is "AND" and the value "No" is received. The outcome of the negotiation is "No". - The boolean function is "OR" and the value "Yes" is received. The outcome of the negotiation is "Yes". Responses are REQUIRED in all other cases, and the value chosen and sent by the responder becomes the outcome of the negotiation. __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com From owner-ips@ece.cmu.edu Fri May 10 11:54:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00410 for ; Fri, 10 May 2002 11:54:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AFMUj07729 for ips-outgoing; Fri, 10 May 2002 11:22:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AFMSw07724 for ; Fri, 10 May 2002 11:22:28 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 9E12E30706; Fri, 10 May 2002 11:22:27 -0400 (EDT) Date: Fri, 10 May 2002 08:20:47 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: John Hufferd Cc: Shahram Davari , "'ips@ece.cmu.edu'" Subject: Re: iSCSI and IPSec In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 9 May 2002, John Hufferd wrote: > > Bill, > Though you are correct, the way you state it is as if Tunnel mode is some > how easier to implement then Transport mode, or as if Encryption is not > needed to be implemented. Now I am sure you did not mean that, so perhaps > I should restate you answer as follows: You are correct. I don't see how I said you didn't have to have Encryption, but then again I don't see how you could have an IPsec implementation without Encryption, so I didn't think to say it. :-) > * IPsec is a MUST be implemented: That is Data Integrity and Authentication > Must be implemented > > * IPsec is also a MUST implement Confidentiality (encryption). > > * All of the above MUST be implemented in Tunnel Mode, and If the IPsec > implementation of an iSCSI initiator or target conforms to the [RFC2401] > definition of a host, then to comply with section 4.1 of [RFC2401] it MUST > also implement the above in Transport mode. > > * So the thing you know for sure is that Tunnel mode MUST be implemented, > and sometimes Transport mode will also be implemented. > > *However, the end customer has the freedom to turn on all or part of what > ever IPsec version it has implemented. Yep. Nicely put. Take care, Bill From owner-ips@ece.cmu.edu Fri May 10 12:07:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01170 for ; Fri, 10 May 2002 12:07:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AFg8q09462 for ips-outgoing; Fri, 10 May 2002 11:42:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AFg6w09458 for ; Fri, 10 May 2002 11:42:07 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 11:40:58 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937898@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: IPS: Number of Authors Date: Fri, 10 May 2002 11:40:54 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1F839.123AEB00" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1F839.123AEB00 Content-Type: text/plain; charset="iso-8859-1" Everyone, The Internet-Draft with guidance on this issue has just appeared; the announcement is forwarded below. The IPS WG co-chairs will implement these guidelines as follows: WG Last Call will not be started for drafts that do not meet the guidelines. What this means is that: - Drafts with 5 or less authors will enter WG Last Call without a hitch. - Drafts with more than 5 authors will be delayed and the draft authors should expect instructions to reduce author count to result. For the current drafts in or approaching WG Last Call: - FC Encapsulation. This has completed WG Last Call. It was the product of a 6 person design team, and the WG chairs will consult with the ADs about listing all 6 members of that team as authors. - iFCP needs to reduce its author count. - FCIP has already reduced its author count. - iSCSI needs to reduce its author count. Authors of all other drafts should consider themselves warned. If a draft's author count cannot be reduced in an expeditious fashion the WG Chairs may have to resort to instructing that the draft list only the primary editor at the top of the first page. Thanks, David Black and Elizabeth Rodriguez, IPS WG co-chairs -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, May 10, 2002 7:35 AM Subject: I-D ACTION:draft-rfc-editor-author-lists-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RFC Editor Guidelines on Author Lists Author(s) : J. Reynolds, B. Braden Filename : draft-rfc-editor-author-lists-00.txt Pages : 6 Date : 09-May-02 This memo presents a new set of guidelines to govern lists of authors on RFC documents. It is intended to counteract a recent tendency towards author list inflation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rfc-editor-author-lists-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rfc-editor-author-lists-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rfc-editor-author-lists-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C1F839.123AEB00 Content-Type: message/rfc822 To: Subject: Date: Fri, 10 May 2002 11:40:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C1F839.123AEB00" ------_=_NextPart_002_01C1F839.123AEB00 Content-Type: text/plain ------_=_NextPart_002_01C1F839.123AEB00 Content-Type: application/octet-stream; name="ATT13572" Content-Disposition: attachment; filename="ATT13572" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020509124227.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rfc-editor-author-lists-00.txt ------_=_NextPart_002_01C1F839.123AEB00 Content-Type: message/external-body; site="internet-drafts"; dir="draft-rfc-editor-author-lists-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C1F839.123AEB00-- ------_=_NextPart_000_01C1F839.123AEB00-- From owner-ips@ece.cmu.edu Fri May 10 12:21:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02113 for ; Fri, 10 May 2002 12:21:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AFmHT09937 for ips-outgoing; Fri, 10 May 2002 11:48:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AFmGw09932 for ; Fri, 10 May 2002 11:48:16 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4AFm7d08155; Fri, 10 May 2002 11:48:08 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g4AFm7725575; Fri, 10 May 2002 11:48:07 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 11:47:03 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937899@CORPMX14> From: Black_David@emc.com To: rdejong@cox.net Cc: ips@ece.cmu.edu Subject: RE: FCIP: Comment 120 Date: Fri, 10 May 2002 11:47:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-PerlMx-Spam: Gauge=XIIIIII, Probability=16%, Report="NO_REAL_NAME" Sender: owner-ips@ece.cmu.edu Precedence: bulk > In the statement below can you tell me how someone would know which port > to use for the initial contact. > > >...the specification should not prohibit use of a different > > port for initial contact. That's a configuration matter. For example, the FCIP template for SLP allows a TCP port number to be conveyed as part of the URL - see draft-ietf-ips-fcip-slp-02.txt. This could also be configured manually. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri May 10 12:31:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02835 for ; Fri, 10 May 2002 12:31:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AGFLH12229 for ips-outgoing; Fri, 10 May 2002 12:15:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AGFKw12225 for ; Fri, 10 May 2002 12:15:20 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 73DFF30706; Fri, 10 May 2002 12:15:19 -0400 (EDT) Date: Fri, 10 May 2002 09:13:40 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "Mark S. Edwards" Cc: Subject: Re: ISCSI: CmdSN in non-leading login In-Reply-To: <5.1.0.14.2.20020510103455.0320bea8@mail.muttsnuts.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 10 May 2002, Mark S. Edwards wrote: > There are a couple of problems here for the target. At what point is a > non-leading connection considered to be part of the session ? Is it the > moment that the login request is received with a non-zero TSIH ? Or is it > only when the non-leading login succeeds and it enters full feature phase ? I think the target shouldn't let anything from a new connection influence things until after at least the security phase has been passed. Otherwise we have a security hole. After operational negotiation would probably be best. > So, should an initiator set the CmdSN in the first login request to zero > and only synchronise with the session command stream after full feature > phase is established ? This is my preferred option. > > What happens if the initiator tries using the current session command > sequence number is that whilst the login negotiation occurs, other > connections within the session can be issuing new commands, so by the time > that the login is finished the CmdSN exchanged in the initial request is > invalid anyway. > > I would like to see something along the lines that for a non-leading > connection, the CmdSN field MUST be zero and that the connection can not be > considered part of the session until full feature phase is entered, at > which point any commands issued on the connection are now synchronised with > the session command sequence number as observed by all other existing > connections on the session. I thought login counted as a command, so it got its own command number, in the stream of all other commands. ?? Take care, Bill From owner-ips@ece.cmu.edu Fri May 10 13:34:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06984 for ; Fri, 10 May 2002 13:34:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AHFia16695 for ips-outgoing; Fri, 10 May 2002 13:15:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AHFfw16689 for ; Fri, 10 May 2002 13:15:41 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4AHFZAH081736; Fri, 10 May 2002 13:15:35 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4AHFYi46080; Fri, 10 May 2002 11:15:34 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: ISCSI: CmdSN in non-leading login To: "Mark S. Edwards" Cc: Bill Studenmund , X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Fri, 10 May 2002 10:14:08 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/10/2002 11:15:33 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I do not see the issue, it works as is, it does not effect the first non immediate command unless it completes as a authorized connection. Again, I do not see the issue, in fact it works as is. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Mark S. Edwards" @ece.cmu.edu on 05/10/2002 09:47:53 AM Sent by: owner-ips@ece.cmu.edu To: Bill Studenmund cc: Subject: Re: ISCSI: CmdSN in non-leading login At 09:13 AM 5/10/2002 -0700, Bill Studenmund wrote: >On Fri, 10 May 2002, Mark S. Edwards wrote: > > > There are a couple of problems here for the target. At what point is a > > non-leading connection considered to be part of the session ? Is it the > > moment that the login request is received with a non-zero TSIH ? Or is it > > only when the non-leading login succeeds and it enters full feature phase ? > >I think the target shouldn't let anything from a new connection influence >things until after at least the security phase has been passed. Otherwise >we have a security hole. After operational negotiation would probably be >best. Good, as far as I can see, a new connection should not be allowed to influence any session context until the connection reached full-feature phase. But this is a problem if we have to follow the CmdSN rules of 9.12.8. See next comment. > > So, should an initiator set the CmdSN in the first login request to zero > > and only synchronise with the session command stream after full feature > > phase is established ? This is my preferred option. > > > > What happens if the initiator tries using the current session command > > sequence number is that whilst the login negotiation occurs, other > > connections within the session can be issuing new commands, so by the time > > that the login is finished the CmdSN exchanged in the initial request is > > invalid anyway. > > > > I would like to see something along the lines that for a non-leading > > connection, the CmdSN field MUST be zero and that the connection can not be > > considered part of the session until full feature phase is entered, at > > which point any commands issued on the connection are now synchronised with > > the session command sequence number as observed by all other existing > > connections on the session. > >I thought login counted as a command, so it got its own command number, in >the stream of all other commands. ?? For a leading connection the CmdSN, whether zero or non-zero, is regarded as a primer with which to set the initial session command sequence number, all the login requests exchanged in the negotiation, no matter how many carry the same CmdSN as does the first non-immediate command. In other words, the first pdu in a leading connection does influence session state. So if we agree that a non-leading connection can not influence session state until full-feature phase, then we have to also state that the rule in 9.12.8 about the first non-immediate command carrying the same CmdSN as the initial login request can not work for a non-leading connection. In this case, the first non-immediate command must be set from the next logical value in the session context. I would like the spec to have this added and to explicitly say that the CmdSN in a login request for a non-leading connection is ignored by the target. I'd really prefer that the actual value be zero, but that's not necessary from a protocol perspective if the target ignores the field. Mark. From owner-ips@ece.cmu.edu Fri May 10 13:36:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07104 for ; Fri, 10 May 2002 13:36:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AGqvp15095 for ips-outgoing; Fri, 10 May 2002 12:52:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AGquw15089 for ; Fri, 10 May 2002 12:52:56 -0400 (EDT) Received: from bursar.muttsnuts.com (213.190.135.30) by mail.san.yahoo.com (6.5.017.1) id 3CDB8C5C0001A60E; Fri, 10 May 2002 09:52:36 -0700 Message-Id: <5.1.0.14.2.20020510172843.031ef000@mail.muttsnuts.com> X-Sender: markemuttsnuts@mail.muttsnuts.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 10 May 2002 17:47:53 +0100 To: Bill Studenmund From: "Mark S. Edwards" Subject: Re: ISCSI: CmdSN in non-leading login Cc: In-Reply-To: References: <5.1.0.14.2.20020510103455.0320bea8@mail.muttsnuts.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk At 09:13 AM 5/10/2002 -0700, Bill Studenmund wrote: >On Fri, 10 May 2002, Mark S. Edwards wrote: > > > There are a couple of problems here for the target. At what point is a > > non-leading connection considered to be part of the session ? Is it the > > moment that the login request is received with a non-zero TSIH ? Or is it > > only when the non-leading login succeeds and it enters full feature phase ? > >I think the target shouldn't let anything from a new connection influence >things until after at least the security phase has been passed. Otherwise >we have a security hole. After operational negotiation would probably be >best. Good, as far as I can see, a new connection should not be allowed to influence any session context until the connection reached full-feature phase. But this is a problem if we have to follow the CmdSN rules of 9.12.8. See next comment. > > So, should an initiator set the CmdSN in the first login request to zero > > and only synchronise with the session command stream after full feature > > phase is established ? This is my preferred option. > > > > What happens if the initiator tries using the current session command > > sequence number is that whilst the login negotiation occurs, other > > connections within the session can be issuing new commands, so by the time > > that the login is finished the CmdSN exchanged in the initial request is > > invalid anyway. > > > > I would like to see something along the lines that for a non-leading > > connection, the CmdSN field MUST be zero and that the connection can not be > > considered part of the session until full feature phase is entered, at > > which point any commands issued on the connection are now synchronised with > > the session command sequence number as observed by all other existing > > connections on the session. > >I thought login counted as a command, so it got its own command number, in >the stream of all other commands. ?? For a leading connection the CmdSN, whether zero or non-zero, is regarded as a primer with which to set the initial session command sequence number, all the login requests exchanged in the negotiation, no matter how many carry the same CmdSN as does the first non-immediate command. In other words, the first pdu in a leading connection does influence session state. So if we agree that a non-leading connection can not influence session state until full-feature phase, then we have to also state that the rule in 9.12.8 about the first non-immediate command carrying the same CmdSN as the initial login request can not work for a non-leading connection. In this case, the first non-immediate command must be set from the next logical value in the session context. I would like the spec to have this added and to explicitly say that the CmdSN in a login request for a non-leading connection is ignored by the target. I'd really prefer that the actual value be zero, but that's not necessary from a protocol perspective if the target ignores the field. Mark. From owner-ips@ece.cmu.edu Fri May 10 14:22:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09983 for ; Fri, 10 May 2002 14:22:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AI69B20689 for ips-outgoing; Fri, 10 May 2002 14:06:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AI68w20683 for ; Fri, 10 May 2002 14:06:08 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4AI5xB09366; Fri, 10 May 2002 14:05:59 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g4AI5x721164; Fri, 10 May 2002 14:05:59 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 14:04:55 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E029378A0@CORPMX14> From: Black_David@emc.com To: marke@muttsnuts.com, ips@ece.cmu.edu Subject: RE: ISCSI: CmdSN in non-leading login Date: Fri, 10 May 2002 14:04:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-PerlMx-Spam: Gauge=XIIIIII, Probability=16%, Report="NO_REAL_NAME" Sender: owner-ips@ece.cmu.edu Precedence: bulk > There is a certain ambiguity about 9.12.8. The text describes how in a > leading connection, the target takes must accept and use a non-zero CmdSN, > but it does not explain what should be present for a non-leading connection. > > There are a couple of problems here for the target. At what point is a > non-leading connection considered to be part of the session ? Is it the > moment that the login request is received with a non-zero TSIH ? Or is it > only when the non-leading login succeeds and it enters full feature phase ? My recollection is the latter, so a non-leading login carries a CmdSN that only applies to that login, and it starts using session-wide CmdSN numbering when it enters full-feature phase. I see the ambiguity in the 9.12.8 text, and believe the answer is that a non-leading login can use any CmdSN it likes, but only for login purposes, and starts using the session CmdSN numbering when it enters full-feature phase. > So, should an initiator set the CmdSN in the first login request to zero > and only synchronise with the session command stream after full feature > phase is established ? This is my preferred option. Synchronization in full feature phase should be required. Zero should be allowed, but not required. As long as the Initiator chooses the number and can use what it wants, Mark's initiators are free to choose zero. Text would need to be added to explain this. > What happens if the initiator tries using the current session command > sequence number is that whilst the login negotiation occurs, other > connections within the session can be issuing new commands, so by the time > that the login is finished the CmdSN exchanged in the initial request is > invalid anyway. Non-leading login should not affect the session until it enters full- feature phase. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri May 10 14:24:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10093 for ; Fri, 10 May 2002 14:24:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AHh7Y18684 for ips-outgoing; Fri, 10 May 2002 13:43:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AHh4w18675 for ; Fri, 10 May 2002 13:43:04 -0400 (EDT) Received: from bursar.muttsnuts.com (213.190.135.30) by mail.san.yahoo.com (6.5.017.1) id 3CDB8C5C0001E05C; Fri, 10 May 2002 10:42:49 -0700 Message-Id: <5.1.0.14.2.20020510182920.03d9cba0@mail.muttsnuts.com> X-Sender: markemuttsnuts@mail.muttsnuts.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 10 May 2002 18:38:07 +0100 To: "John Hufferd" From: "Mark S. Edwards" Subject: Re: ISCSI: CmdSN in non-leading login Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk John, If an initiator opens a new connection on a session and in the first login request uses the current session CmdSN, the lifetime of that CmdSN continues all the way through until the completion of the first non-immediate command on that new connection. This means that the initiator has to reserve the use of that CmdSN for the first non-immediate command on that particular session. That's stupid. Especially bearing in mind that it could be pumping commands like crazy down other open connections in the session. There is also another side effect, if the login takes any length of time, like computing a DH or having to make external calls to a Radius or a Kerberos server, then because this CmdSN is outstanding, the other connections in the session will block as soon as the command window is filled. The final sentence in 9.12.8 is meaningless for a non-leading connection. The target either has to block the whole session until the login is completed, or run the risk of corrupting session state. Mark At 10:14 AM 5/10/2002 -0700, John Hufferd wrote: >I do not see the issue, it works as is, it does not effect the first non >immediate command unless it completes as a authorized connection. Again, I >do not see the issue, in fact it works as is. > >. >. >. >John L. Hufferd >Senior Technical Staff Member (STSM) >IBM/SSG San Jose Ca >Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 >Home Office (408) 997-6136, Cell: (408) 499-9702 >Internet address: hufferd@us.ibm.com > > >"Mark S. Edwards" @ece.cmu.edu on 05/10/2002 09:47:53 >AM > >Sent by: owner-ips@ece.cmu.edu > > >To: Bill Studenmund >cc: >Subject: Re: ISCSI: CmdSN in non-leading login > > > >At 09:13 AM 5/10/2002 -0700, Bill Studenmund wrote: > >On Fri, 10 May 2002, Mark S. Edwards wrote: > > > > > There are a couple of problems here for the target. At what point is a > > > non-leading connection considered to be part of the session ? Is it >the > > > moment that the login request is received with a non-zero TSIH ? Or is >it > > > only when the non-leading login succeeds and it enters full feature >phase ? > > > >I think the target shouldn't let anything from a new connection influence > >things until after at least the security phase has been passed. Otherwise > >we have a security hole. After operational negotiation would probably be > >best. > >Good, as far as I can see, a new connection should not be allowed to >influence any session context until the connection reached full-feature >phase. But this is a problem if we have to follow the CmdSN rules of >9.12.8. See next comment. > > > > > So, should an initiator set the CmdSN in the first login request to >zero > > > and only synchronise with the session command stream after full feature > > > phase is established ? This is my preferred option. > > > > > > What happens if the initiator tries using the current session command > > > sequence number is that whilst the login negotiation occurs, other > > > connections within the session can be issuing new commands, so by the >time > > > that the login is finished the CmdSN exchanged in the initial request >is > > > invalid anyway. > > > > > > I would like to see something along the lines that for a non-leading > > > connection, the CmdSN field MUST be zero and that the connection can >not be > > > considered part of the session until full feature phase is entered, at > > > which point any commands issued on the connection are now synchronised >with > > > the session command sequence number as observed by all other existing > > > connections on the session. > > > >I thought login counted as a command, so it got its own command number, in > >the stream of all other commands. ?? > > >For a leading connection the CmdSN, whether zero or non-zero, is regarded >as a primer with which to set the initial session command sequence number, >all the login requests exchanged in the negotiation, no matter how many >carry the same CmdSN as does the first non-immediate command. In other >words, the first pdu in a leading connection does influence session state. > >So if we agree that a non-leading connection can not influence session >state until full-feature phase, then we have to also state that the rule in >9.12.8 about the first non-immediate command carrying the same CmdSN as the >initial login request can not work for a non-leading connection. In this >case, the first non-immediate command must be set from the next logical >value in the session context. I would like the spec to have this added and >to explicitly say that the CmdSN in a login request for a non-leading >connection is ignored by the target. I'd really prefer that the actual >value be zero, but that's not necessary from a protocol perspective if the >target ignores the field. > >Mark. From owner-ips@ece.cmu.edu Fri May 10 14:44:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11286 for ; Fri, 10 May 2002 14:44:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AIIwv21712 for ips-outgoing; Fri, 10 May 2002 14:18:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AIIuw21708 for ; Fri, 10 May 2002 14:18:56 -0400 (EDT) Received: from bursar.muttsnuts.com (213.190.135.30) by mail.san.yahoo.com (6.5.017.1) id 3CDB8C5C00020C3C; Fri, 10 May 2002 11:18:34 -0700 Message-Id: <5.1.0.14.2.20020510190603.03dee008@mail.muttsnuts.com> X-Sender: markemuttsnuts@mail.muttsnuts.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 10 May 2002 19:13:54 +0100 To: Black_David@emc.com, ips@ece.cmu.edu From: "Mark S. Edwards" Subject: RE: ISCSI: CmdSN in non-leading login In-Reply-To: <277DD60FB639D511AC0400B0D068B71E029378A0@CORPMX14> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk David, At 02:04 PM 5/10/2002 -0400, Black_David@emc.com wrote: > > There is a certain ambiguity about 9.12.8. The text describes how in a > > leading connection, the target takes must accept and use a non-zero CmdSN, > > > but it does not explain what should be present for a non-leading >connection. > > > > There are a couple of problems here for the target. At what point is a > > non-leading connection considered to be part of the session ? Is it the > > moment that the login request is received with a non-zero TSIH ? Or is it > > > only when the non-leading login succeeds and it enters full feature phase >? > >My recollection is the latter, so a non-leading login carries a CmdSN >that only applies to that login, and it starts using session-wide CmdSN >numbering when it enters full-feature phase. I see the ambiguity in the >9.12.8 text, and believe the answer is that a non-leading login can use >any CmdSN it likes, but only for login purposes, and starts using the >session CmdSN numbering when it enters full-feature phase. We can live with that. The text as it stands is applicable only to the leading connection, it just needs additional words to describe the more limited scope of a CmdSN in a non-leading connection. > > So, should an initiator set the CmdSN in the first login request to zero > > and only synchronise with the session command stream after full feature > > phase is established ? This is my preferred option. > >Synchronization in full feature phase should be required. Zero should >be allowed, but not required. As long as the Initiator chooses the >number and can use what it wants, Mark's initiators are free to choose >zero. Text would need to be added to explain this. Fine, our target will just echo the CmdSN that the initiator chooses. All we wanted was text to clarify that whatever this value is in a non-leading connection is meaningless within the context of the real session CmdSN. > > What happens if the initiator tries using the current session command > > sequence number is that whilst the login negotiation occurs, other > > connections within the session can be issuing new commands, so by the time > > > that the login is finished the CmdSN exchanged in the initial request is > > invalid anyway. > >Non-leading login should not affect the session until it enters full- >feature phase. That's exactly what I wanted to hear ... over to you Julian :) Mark. From owner-ips@ece.cmu.edu Fri May 10 15:08:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12625 for ; Fri, 10 May 2002 15:08:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AIomS24490 for ips-outgoing; Fri, 10 May 2002 14:50:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AIokw24483 for ; Fri, 10 May 2002 14:50:46 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4AIobB29365; Fri, 10 May 2002 14:50:38 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g4AIob729501; Fri, 10 May 2002 14:50:37 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 14:49:33 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E029378A7@CORPMX14> From: Black_David@emc.com To: monishabarooah@myrealbox.com, ips@ece.cmu.edu Subject: RE: Session Error Date: Fri, 10 May 2002 14:48:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" X-PerlMx-Spam: Gauge=XIIIIII, Probability=16%, Report="NO_REAL_NAME" Sender: owner-ips@ece.cmu.edu Precedence: bulk The key words are "an initiator may choose". If an initiator decides that it's seeing too many errors on a session, it can decide to terminate the session and start a new one in hopes that things will improve as a result. "if initiators detect" should be edited to read "if an initiator detects". Thanks, --David > -----Original Message----- > From: Monisha Barooah [mailto:monishabarooah@myrealbox.com] > Sent: Friday, May 10, 2002 5:50 AM > To: ips@ece.cmu.edu > Subject: Session Error > > > > Hi All, > The following ia an extract from the draft: > > If all the connections of a session fail and cannot be > re-established in a short time, or if initiators detect > protocol errors repeatedly, an initiator may choose to > terminate a session and establish a new session. > > In the above sentence "if initiators detect protocol errors > repeatedly". What does this mean? Does it mean that > consecutive protocol errors lead to session error? > > Regards, > Monisha. > From owner-ips@ece.cmu.edu Fri May 10 15:08:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12650 for ; Fri, 10 May 2002 15:08:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AIlNc24178 for ips-outgoing; Fri, 10 May 2002 14:47:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AIlLw24174 for ; Fri, 10 May 2002 14:47:21 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 14:46:13 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E029378A6@CORPMX14> From: Black_David@emc.com To: monishabarooah@myrealbox.com, ips@ece.cmu.edu Subject: RE: Connection Recovery in case of a single connection in a sessi on Date: Fri, 10 May 2002 14:46:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" Sender: owner-ips@ece.cmu.edu Precedence: bulk This recovery requires the ability to support more than one connection in a session. Once the first connection is logged out, its tasks are gone. An implementation that does not support multi-connection sessions cannot do this sort of recovery. Thanks, --David > -----Original Message----- > From: Monisha Barooah [mailto:monishabarooah@myrealbox.com] > Sent: Friday, May 10, 2002 5:46 AM > To: ips@ece.cmu.edu > Subject: Connection Recovery in case of a single connection > in a session > > > > Hi All, > I wanted to know how to perform Connection Recovery for a > connection when it is the only connection of a session. > > Connection Recovery invloves the logout of the failed > connection and the reassignment of the tasks of the failed > connection to a full feature phased connection. > > In case there is only one connection in a session. How do we > do the Connection Recovery? Shall we open up another > connection to do implicit logout? But in this case the CID of > the new connection will be the same as that of the failed > connection and the task reassignment will not come into > picture at all. > > Regards, > Monisha. > From owner-ips@ece.cmu.edu Fri May 10 15:44:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14380 for ; Fri, 10 May 2002 15:44:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AJFmi26638 for ips-outgoing; Fri, 10 May 2002 15:15:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2aa.compuserve.com (siaar2aa.compuserve.com [149.174.40.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AJFjw26633 for ; Fri, 10 May 2002 15:15:45 -0400 (EDT) Received: (from mailgate@localhost) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id PAA29585 for ips@ece.cmu.edu; Fri, 10 May 2002 15:15:39 -0400 (EDT) Received: from compuserve.com (dal-tgn-tlu-vty27.as.wcom.net [216.192.235.27]) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id PAA29572; Fri, 10 May 2002 15:15:37 -0400 (EDT) Message-ID: <3CDC1DCD.16295328@compuserve.com> Date: Fri, 10 May 2002 14:21:50 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu CC: Black_David@emc.com Subject: Re: FCIP: Comment 120 References: <277DD60FB639D511AC0400B0D068B71E02937895@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, The "one" got lost in the proposed change and I got lost over how the sentence was supposed to end. Checkout the following: Change: The FCIP Entity is the connection interface point for the IP Network and is the owner of the IP Address and Well Known Port used to form TCP Connections. to: The FCIP Entity is the connection interface point for the IP Network and is the sole owner of at least one TCP port/IP Address combination used to form TCP Connections. The TCP port may be the FCIP well known port at a given IP Address. Thanks. .Ralph Black_David@emc.com wrote: > Ralph, > > I suggest the following change, which is mostly editorial, but > may raise a different issue. Old text: > > is the sole owner of at least one IP Address and Well Known Port > used to form TCP Connections > > New text: > > is the sole user of at least TCP port at the IP address > used for TCP connections to the FCIP Entity. > > The editorial change is to remove any implication of sole ownership/ > usership of the IP address. The potential new issue is that while > FCIP has an IANA-assigned TCP port, the specification should not > prohibit use of a different port for initial contact. > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- From owner-ips@ece.cmu.edu Fri May 10 16:33:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16114 for ; Fri, 10 May 2002 16:33:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AJuYY00095 for ips-outgoing; Fri, 10 May 2002 15:56:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AJuWw00090 for ; Fri, 10 May 2002 15:56:32 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel6.hp.com (Postfix) with ESMTP id 266EA261; Fri, 10 May 2002 15:56:23 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA23001; Fri, 10 May 2002 12:58:07 -0700 (PDT) Message-ID: <00b601c1f85c$c1c92870$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , , References: <277DD60FB639D511AC0400B0D068B71E02937895@CORPMX14> Subject: Re: FCIP: Comment 120 Date: Fri, 10 May 2002 12:56:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Ralph, > > I suggest the following change, which is mostly editorial, but > may raise a different issue. Old text: > > is the sole owner of at least one IP Address and Well Known Port > used to form TCP Connections > > New text: > > is the sole user of at least TCP port at the IP address > used for TCP connections to the FCIP Entity. I'd suggest an additional tweak (since my understanding from Murali's bullet (c) is that each Pair can avail multiple IP addresses - one per LEP). "The FCIP Entity is the connection interface point for the IP Network and is the sole user of one TCP port for each IP address used for TCP connections to the FCIP Entity." Further, I think the term "connection interface point" needs to be consistently used in the draft. The last para on page 10 defines that the "connection interface point" is the *FCIP_DE* that's part of FCIP_LEP. The second-to-last para on the same page further says that FCIP_LEP is on the "line" joining FCIP Entity with the FC Entity - IOW, belongs to neither. > > The editorial change is to remove any implication of sole ownership/ > usership of the IP address. The potential new issue is that while > FCIP has an IANA-assigned TCP port, the specification should not > prohibit use of a different port for initial contact. Yes. From Ralph: >A new sentence can be added immediately following the sentence cited >above to address the "why" issue. Please do. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com From owner-ips@ece.cmu.edu Fri May 10 16:37:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16269 for ; Fri, 10 May 2002 16:37:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AK8hb01079 for ips-outgoing; Fri, 10 May 2002 16:08:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AK8fw01074 for ; Fri, 10 May 2002 16:08:41 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel6.hp.com (Postfix) with ESMTP id 4A321533; Fri, 10 May 2002 16:08:35 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id NAA27318; Fri, 10 May 2002 13:10:20 -0700 (PDT) Message-ID: <00ca01c1f85e$764a4e40$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , , References: <277DD60FB639D511AC0400B0D068B71E029378A6@CORPMX14> Subject: Re: Connection Recovery in case of a single connection in a session Date: Fri, 10 May 2002 13:08:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: To: ; Sent: Friday, May 10, 2002 11:46 AM Subject: RE: Connection Recovery in case of a single connection in a session > This recovery requires the ability to support more than one > connection in a session. Once the first connection is logged > out, its tasks are gone. An implementation that does not > support multi-connection sessions cannot do this sort of > recovery. Not quite accurate. A single-connection session could do task reassignment. A connection reinstatement (same CID) login (when operational ErrorRecoveryLevel=2) would be an implicit recovery Logout. The initiator has the option either to reassign the tasks, or simply let the tasks timeout (or even abort the non-allegiant tasks). New wording regarding the mapping of session/connection reinstatements to Logout reason codes was posted to this list two weeks ago (by me), and will appear in rev13. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com > > > -----Original Message----- > > From: Monisha Barooah [mailto:monishabarooah@myrealbox.com] > > Sent: Friday, May 10, 2002 5:46 AM > > To: ips@ece.cmu.edu > > Subject: Connection Recovery in case of a single connection > > in a session > > > > > > > > Hi All, > > I wanted to know how to perform Connection Recovery for a > > connection when it is the only connection of a session. > > > > Connection Recovery invloves the logout of the failed > > connection and the reassignment of the tasks of the failed > > connection to a full feature phased connection. > > > > In case there is only one connection in a session. How do we > > do the Connection Recovery? Shall we open up another > > connection to do implicit logout? But in this case the CID of > > the new connection will be the same as that of the failed > > connection and the task reassignment will not come into > > picture at all. > > > > Regards, > > Monisha. > > > From owner-ips@ece.cmu.edu Fri May 10 17:40:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19822 for ; Fri, 10 May 2002 17:40:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AL7EA05453 for ips-outgoing; Fri, 10 May 2002 17:07:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail2.hd.intel.com (hdfdns02.hd.intel.com [192.52.58.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AL7Bw05446 for ; Fri, 10 May 2002 17:07:11 -0400 (EDT) Received: from mkrikis-laptop (mkrikis-laptop.hd.intel.com [10.127.144.247]) by mail2.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.38 2002/05/09 18:12:41 root Exp $) with ESMTP id g4AL75V06387 for ; Fri, 10 May 2002 21:07:05 GMT Received: from martinsk by mkrikis-laptop with local (Exim 3.35 #1 (Debian)) id 176IXT-0000Jy-00 for ; Fri, 10 May 2002 17:06:59 -0500 To: ips@ece.cmu.edu Subject: Re: iSCSI - an improved text for 4.1 & 4.2 Message-Id: From: Martins Krikis Date: Fri, 10 May 2002 17:06:59 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk > +++ well we must be a funny sort of computer geeks if we assume that the > rest of the text is understandable but here we have an issue. How about the > following text: I never said that the rest^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H :-) And I am a fairly typical geek, not of the funny sort... Seriously, though, I've deleted most everything, except where I have something more to say. > hex-constant: hexadecimal constant encoded as a string start-ing typo, late in the paragraph (not quoted here), "eading" should be "leading". > base64-constant: base64 constant encoded as a string starting > with "0b" or "0B" followed by 1 or more digits or letters or > plus or slash or equal. The encoding is done according to > [RFC2045]. base64-constants are used to encode numerical > val-ues or binary strings. When used to encode numerical values > the excesive use of leading 0s prior to encoding - encoded as > "A" - is discouraged. When used to encode binary strings > base64-constants have an implicit byte-length that includes 6 > bits for every character of the constant excluding trailing > equals (i.e., a base64-constant of n base64 characters with m > trailing equals has a byte-length of ((the integer part of) > ((n+3)*3/4) - m). Do the n base64 characters include the m equals or not? Either way, I don't think the formula is right, but I'm too lazy to look up the RFC. I do know however, that the RFC makes it perfectly unambiguous what the encoded string is, so giving this formula may not be necessary. If it is given then I think "the integer part of n*3/4" would do, "where n is the number of base64 digits excluding the trailing equals, if any". > The originator or declarer can either be the initiator or the target > and the responder can either be the target or initiator, > respec-tively. Target requests are not limited to respond to > key=value pairs as offered by the initiator. The target may offer > key=value pairs of its own. Shouldn't "Target requests" be changed to "Targets"? > If a responder does not understand any particular value in a list it > MUST ignore it. If a responder does not support, does not understand > or is not allowed to use anyone of the offered options with a > spe-cific originator, it MAY use the constant "Reject" or it respond > with an admissible value. The selection of a value not offered is > consid-ered a negotiation failure and is handled as a protocol > error. I don't think the word "anyone" (which may have been meant as "any one"?) was any improvement, but I'll let the native english speakers object to this. In order to really put it unambiguously the whole sentence has to be redone (and I did offer a suggestion); just a one word change will not suffice, IMHO. (And I think "options" should be "values".) The phrase "or it respond with an admissible value" is new, has an extra word "it", and is inapropriate here. After all, if the responder could not use any of the offered values, yet instead of using Reject it chose another "admissible" value, then this value is clearly not from the offered list of values and therefore the next sentence classifies it as a negotiation failure and a protocol error. I don't think the specification should give instructions using "MAY" on how to create protocol errors. > For simple-value negotiations, the responding party MUST respond > with the same key. The value it selects, based on the selection rule > spe-cific to the key, becomes the negotiation result. For a > numerical range the value selected must be an integer within the > offered range or "Reject" (if the range is unacceptable). An offer > of a value not admissible (e.g., not within the specified bounds) > MAY be answered with the constant "Reject" or the responder MAY > select an admissible value. The selection, by the responder, of a > value not admissible under the selection rules is considered a > negotiation failure and is handled accordingly. The selection rules > are key-specific. Why exactly is it allowed to tolerate an offer that is not admissible? It looks like the originator that sends complete garbage may be treated better than an originator that sends an admissible value that is not good for the responder. I guess what I'm saying mostly applies to ranges. This is not very important, just a weird "feature" the purpose of which I don't really get. Thanks, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer From owner-ips@ece.cmu.edu Fri May 10 18:43:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21513 for ; Fri, 10 May 2002 18:43:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AM6lm09397 for ips-outgoing; Fri, 10 May 2002 18:06:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AM6iw09392; Fri, 10 May 2002 18:06:44 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4AM6b9d031932; Sat, 11 May 2002 00:06:37 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4AM6b3122402; Sat, 11 May 2002 00:06:37 +0200 To: "Mark S. Edwards" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: ISCSI: CmdSN in non-leading login X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 11 May 2002 01:06:33 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 11/05/2002 01:06:37, Serialize complete at 11/05/2002 01:06:37 Content-Type: multipart/alternative; boundary="=_alternative 00774C2EC2256BB5_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00774C2EC2256BB5_= Content-Type: text/plain; charset="us-ascii" Logins are all immediate. CmdSN is the current one and not advancing by the sender and should not be checked by the receiver. Nothing special needs to be mentioned. Julo "Mark S. Edwards" Sent by: owner-ips@ece.cmu.edu 05/10/2002 12:51 PM Please respond to "Mark S. Edwards" To: ips@ece.cmu.edu cc: Subject: ISCSI: CmdSN in non-leading login I am looking for clarification with regard the value that an initiator should put in the CmdSN field of a login request for a non-leading connection. There is a certain ambiguity about 9.12.8. The text describes how in a leading connection, the target takes must accept and use a non-zero CmdSN, but it does not explain what should be present for a non-leading connection. There are a couple of problems here for the target. At what point is a non-leading connection considered to be part of the session ? Is it the moment that the login request is received with a non-zero TSIH ? Or is it only when the non-leading login succeeds and it enters full feature phase ? So, should an initiator set the CmdSN in the first login request to zero and only synchronise with the session command stream after full feature phase is established ? This is my preferred option. What happens if the initiator tries using the current session command sequence number is that whilst the login negotiation occurs, other connections within the session can be issuing new commands, so by the time that the login is finished the CmdSN exchanged in the initial request is invalid anyway. I would like to see something along the lines that for a non-leading connection, the CmdSN field MUST be zero and that the connection can not be considered part of the session until full feature phase is entered, at which point any commands issued on the connection are now synchronised with the session command sequence number as observed by all other existing connections on the session. regards, Mark. --=_alternative 00774C2EC2256BB5_= Content-Type: text/html; charset="us-ascii"
Logins are all immediate. CmdSN is the current one and not advancing by the sender and should not be checked by the receiver.
Nothing special needs to be mentioned.

Julo


"Mark S. Edwards" <marke@muttsnuts.com>
Sent by: owner-ips@ece.cmu.edu

05/10/2002 12:51 PM
Please respond to "Mark S. Edwards"

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        ISCSI: CmdSN in non-leading login

       


I am looking for clarification with regard the value that an initiator
should put in the CmdSN field of a login request for a non-leading connection.

There is a certain ambiguity about 9.12.8.  The text describes how in a
leading connection, the target takes must accept and use a non-zero CmdSN,
but it does not explain what should be present for a non-leading connection.

There are a couple of problems here for the target.  At what point is a
non-leading connection considered to be part of the session ?  Is it the
moment that the login request is received with a non-zero TSIH ?  Or is it
only when the non-leading login succeeds and it enters full feature phase ?

So, should an initiator set the CmdSN in the first login request to zero
and only synchronise with the session command stream after full feature
phase is established ?  This is my preferred option.

What happens if the initiator tries using the current session command
sequence number is that whilst the login negotiation occurs, other
connections within the session can be issuing new commands, so by the time
that the login is finished the CmdSN exchanged in the initial request is
invalid anyway.

I would like to see something along the lines that for a non-leading
connection, the CmdSN field MUST be zero and that the connection can not be
considered part of the session until full feature phase is entered, at
which point any commands issued on the connection are now synchronised with
the session command sequence number as observed by all other existing
connections on the session.

regards,

Mark.

--=_alternative 00774C2EC2256BB5_=-- From owner-ips@ece.cmu.edu Fri May 10 18:45:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21552 for ; Fri, 10 May 2002 18:45:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AM6ij09389 for ips-outgoing; Fri, 10 May 2002 18:06:44 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4AM6fw09381; Fri, 10 May 2002 18:06:41 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4AM6YMe016592; Sat, 11 May 2002 00:06:35 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4AM6Yn15446; Sat, 11 May 2002 00:06:34 +0200 To: Martins Krikis Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI - an improved text for 4.1 & 4.2 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 11 May 2002 01:06:23 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 11/05/2002 01:06:34, Serialize complete at 11/05/2002 01:06:34 Content-Type: multipart/alternative; boundary="=_alternative 00769835C2256BB5_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00769835C2256BB5_= Content-Type: text/plain; charset="us-ascii" Comments in text - Julo Martins Krikis Sent by: owner-ips@ece.cmu.edu 05/11/2002 01:06 AM Please respond to Martins Krikis To: ips@ece.cmu.edu cc: Subject: Re: iSCSI - an improved text for 4.1 & 4.2 > +++ well we must be a funny sort of computer geeks if we assume that the > rest of the text is understandable but here we have an issue. How about the > following text: I never said that the rest^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H :-) And I am a fairly typical geek, not of the funny sort... Seriously, though, I've deleted most everything, except where I have something more to say. > hex-constant: hexadecimal constant encoded as a string start-ing typo, late in the paragraph (not quoted here), "eading" should be "leading". > base64-constant: base64 constant encoded as a string starting > with "0b" or "0B" followed by 1 or more digits or letters or > plus or slash or equal. The encoding is done according to > [RFC2045]. base64-constants are used to encode numerical > val-ues or binary strings. When used to encode numerical values > the excesive use of leading 0s prior to encoding - encoded as > "A" - is discouraged. When used to encode binary strings > base64-constants have an implicit byte-length that includes 6 > bits for every character of the constant excluding trailing > equals (i.e., a base64-constant of n base64 characters with m > trailing equals has a byte-length of ((the integer part of) > ((n+3)*3/4) - m). Do the n base64 characters include the m equals or not? Either way, I don't think the formula is right, but I'm too lazy to look up the RFC. I do know however, that the RFC makes it perfectly unambiguous what the encoded string is, so giving this formula may not be necessary. If it is given then I think "the integer part of n*3/4" would do, "where n is the number of base64 digits excluding the trailing equals, if any". +++ i will check +++ > The originator or declarer can either be the initiator or the target > and the responder can either be the target or initiator, > respec-tively. Target requests are not limited to respond to > key=value pairs as offered by the initiator. The target may offer > key=value pairs of its own. Shouldn't "Target requests" be changed to "Targets"? +++ target qualifies requests +++ > If a responder does not understand any particular value in a list it > MUST ignore it. If a responder does not support, does not understand > or is not allowed to use anyone of the offered options with a > spe-cific originator, it MAY use the constant "Reject" or it respond > with an admissible value. The selection of a value not offered is > consid-ered a negotiation failure and is handled as a protocol > error. I don't think the word "anyone" (which may have been meant as "any one"?) was any improvement, but I'll let the native english speakers object to this. In order to really put it unambiguously the whole sentence has to be redone (and I did offer a suggestion); just a one word change will not suffice, IMHO. (And I think "options" should be "values".) The phrase "or it respond with an admissible value" is new, has an extra word "it", and is inapropriate here. After all, if the responder could not use any of the offered values, yet instead of using Reject it chose another "admissible" value, then this value is clearly not from the offered list of values and therefore the next sentence classifies it as a negotiation failure and a protocol error. I don't think the specification should give instructions using "MAY" on how to create protocol errors. +++ selection of an admisible value is out of context here it was meant only for simple values+++ > For simple-value negotiations, the responding party MUST respond > with the same key. The value it selects, based on the selection rule > spe-cific to the key, becomes the negotiation result. For a > numerical range the value selected must be an integer within the > offered range or "Reject" (if the range is unacceptable). An offer > of a value not admissible (e.g., not within the specified bounds) > MAY be answered with the constant "Reject" or the responder MAY > select an admissible value. The selection, by the responder, of a > value not admissible under the selection rules is considered a > negotiation failure and is handled accordingly. The selection rules > are key-specific. Why exactly is it allowed to tolerate an offer that is not admissible? It looks like the originator that sends complete garbage may be treated better than an originator that sends an admissible value that is not good for the responder. I guess what I'm saying mostly applies to ranges. This is not very important, just a weird "feature" the purpose of which I don't really get. Thanks, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer --=_alternative 00769835C2256BB5_= Content-Type: text/html; charset="us-ascii"
Comments in text - Julo


Martins Krikis <mkrikis@yahoo.com>
Sent by: owner-ips@ece.cmu.edu

05/11/2002 01:06 AM
Please respond to Martins Krikis

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        Re: iSCSI - an improved text for 4.1 & 4.2

       


> +++ well we must be a funny sort of computer geeks if we assume that the
> rest of the text is understandable but here we have an issue. How about the
> following text:

I never said that the rest^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H

:-)

And I am a fairly typical geek, not of the funny sort...
Seriously, though, I've deleted most everything, except where I have
something more to say.

>          hex-constant: hexadecimal constant encoded as a string start-ing

typo, late in the paragraph (not quoted here), "eading" should be "leading".

>          base64-constant: base64 constant encoded as a string starting
>            with "0b" or "0B" followed by 1 or more digits or letters or
>            plus or slash or equal. The encoding is done according to
>            [RFC2045]. base64-constants are used to encode numerical
>            val-ues or binary strings. When used to encode numerical values
>            the excesive use of leading 0s prior to encoding - encoded as
>            "A" - is discouraged. When used to encode binary strings
>            base64-constants have an implicit byte-length that includes 6
>            bits for every character of the constant excluding trailing
>            equals (i.e., a base64-constant of n base64 characters with m
>            trailing equals has a byte-length of ((the integer part of)
>            ((n+3)*3/4) - m).

Do the n base64 characters include the m equals or not? Either way,
I don't think the formula is right, but I'm too lazy to look up the RFC.
I do know however, that the RFC makes it perfectly unambiguous what the
encoded string is, so giving this formula may not be necessary.
If it is given then I think "the integer part of n*3/4" would do,
"where n is the number of base64 digits excluding the trailing equals,
if any".
+++ i will check +++
>       The originator or declarer can either be the initiator or the target
>       and the responder can either be the target or initiator,
>       respec-tively. Target requests are not limited to respond to
>       key=value pairs as offered by the initiator. The target may offer
>       key=value pairs of its own.

Shouldn't "Target requests" be changed to "Targets"?
+++ target qualifies requests +++
>       If a responder does not understand any particular value in a list it
>       MUST ignore it. If a responder does not support, does not understand
>       or is not allowed to use anyone of the offered options with a
>       spe-cific originator, it MAY use the constant "Reject" or it respond
>       with an admissible value.  The selection of a value not offered is
>       consid-ered a negotiation failure and is handled as a protocol
>       error.

I don't think the word "anyone" (which may have been meant as "any one"?)
was any improvement, but I'll let the native english speakers object to this.
In order to really put it unambiguously the whole sentence has to be redone
(and I did offer a suggestion); just a one word change will not suffice, IMHO.
(And I think "options" should be "values".)

The phrase "or it respond with an admissible value" is new,
has an extra word "it", and is inapropriate here. After all, if the
responder could not use any of the offered values, yet instead of using
Reject it chose another "admissible" value, then this value is clearly
not from the offered list of values and therefore the next sentence
classifies it as a negotiation failure and a protocol error. I don't think
the specification should give instructions using "MAY" on how to create
protocol errors.
+++ selection of an admisible value is out of context here it was meant only for simple values+++
>       For simple-value negotiations, the responding party MUST respond
>       with the same key. The value it selects, based on the selection rule
>       spe-cific to the key, becomes the negotiation result. For a
>       numerical range the value selected must be an integer within the
>       offered range or "Reject" (if the range is unacceptable).  An offer
>       of a value not admissible (e.g., not within the specified bounds)
>       MAY be answered with the constant "Reject" or the responder MAY
>       select an admissible value. The selection, by the responder, of a
>       value not admissible under the selection rules is considered a
>       negotiation failure and is handled accordingly. The selection rules
>       are key-specific.

Why exactly is it allowed to tolerate an offer that is not admissible?
It looks like the originator that sends complete garbage may be treated
better than an originator that sends an admissible value that is not
good for the responder. I guess what I'm saying mostly applies to ranges.
This is not very important, just a weird "feature" the purpose of which
I don't really get.

Thanks,

 Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not be those of my employer

--=_alternative 00769835C2256BB5_=-- From owner-ips@ece.cmu.edu Fri May 10 19:23:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22514 for ; Fri, 10 May 2002 19:22:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4AMhW211772 for ips-outgoing; Fri, 10 May 2002 18:43:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13703.mail.yahoo.com (web13703.mail.yahoo.com [216.136.175.136]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4AMhUw11767 for ; Fri, 10 May 2002 18:43:30 -0400 (EDT) Message-ID: <20020510224329.16281.qmail@web13703.mail.yahoo.com> Received: from [192.52.58.4] by web13703.mail.yahoo.com via HTTP; Fri, 10 May 2002 15:43:29 PDT Date: Fri, 10 May 2002 15:43:29 -0700 (PDT) From: Martins Krikis Subject: Re: iSCSI - an improved text for 4.1 & 4.2 To: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Julian Satran wrote: > > Target requests are not > > limited to respond to > > key=value pairs as offered by the initiator. > > The target may offer > > key=value pairs of its own. > > Shouldn't "Target requests" be changed to "Targets"? > +++ target qualifies requests +++ But targets don't send requests, they send responses. Anyway, I'm done commenting on these sections. Thanks very much for addressing all the isssues. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Mother's Day is May 12th! http://shopping.yahoo.com From owner-ips@ece.cmu.edu Fri May 10 20:24:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24531 for ; Fri, 10 May 2002 20:24:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4ANfre15019 for ips-outgoing; Fri, 10 May 2002 19:41:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4ANfpw15014 for ; Fri, 10 May 2002 19:41:51 -0400 (EDT) Received: (from mailgate@localhost) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id TAA04661 for ips@ece.cmu.edu; Fri, 10 May 2002 19:41:45 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkf-vty12.as.wcom.net [206.175.235.12]) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id TAA04650; Fri, 10 May 2002 19:41:42 -0400 (EDT) Message-ID: <3CDC5C26.7BC3FCF4@compuserve.com> Date: Fri, 10 May 2002 18:47:50 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu CC: "Mallikarjun C." , Black_David@emc.com Subject: Re: FCIP: Comment 120 References: <277DD60FB639D511AC0400B0D068B71E02937895@CORPMX14> <00b601c1f85c$c1c92870$edd52b0f@rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallikarjun, > Further, I think the term "connection interface point" needs to be > consistently used in the draft. The last para on page 10 defines > that the "connection interface point" is the *FCIP_DE* that's part > of FCIP_LEP. The second-to-last para on the same page further says > that FCIP_LEP is on the "line" joining FCIP Entity with the FC Entity > - IOW, belongs to neither. My search of the draft finds exactly one use of the phrase "connection interface point" and that usage is in the sentence under discussion in section 6.4 on page 12. Looking at page 10 all I see are terms like "endpoint" and "end of the FCIP Link". I guess there is an assumption that "endpoint" is somehow synonymous with "connection interface point". That is not true. The phrase "connection interface point" was chosen for the text in page 12 because what is being discussed on page 12 is not exactly the same thing as an "endpoint". Consider the revised sentence again: "The FCIP Entity is the connection interface point for the IP Network and is the sole owner of at least one TCP port/IP Address combination used to form TCP Connections. The TCP port may be the FCIP well known port at a given IP Address." Viewed in context, "connection interface point" is synonymous with "the place to which TCP connect requests are directed". It is not and is not intended to be synonymous with the endpoint of a TCP Connection once that TCP connection is formed. Thanks. .Ralph From owner-ips@ece.cmu.edu Fri May 10 21:11:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26544 for ; Fri, 10 May 2002 21:11:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4B0pJ218741 for ips-outgoing; Fri, 10 May 2002 20:51:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4B0pHw18737 for ; Fri, 10 May 2002 20:51:17 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id 9DA53C00872; Fri, 10 May 2002 17:51:11 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id RAA09492; Fri, 10 May 2002 17:52:56 -0700 (PDT) Message-ID: <011a01c1f885$f0d7d520$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , References: <277DD60FB639D511AC0400B0D068B71E02937895@CORPMX14> <00b601c1f85c$c1c92870$edd52b0f@rose.hp.com> <3CDC5C26.7BC3FCF4@compuserve.com> Subject: Re: FCIP: Comment 120 - connection endpoint Date: Fri, 10 May 2002 17:51:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, > Mallikarjun, > > > Further, I think the term "connection interface point" needs to be > > consistently used in the draft. The last para on page 10 defines > > that the "connection interface point" is the *FCIP_DE* that's part > > of FCIP_LEP. The second-to-last para on the same page further says > > that FCIP_LEP is on the "line" joining FCIP Entity with the FC Entity > > - IOW, belongs to neither. > > My search of the draft finds exactly one use of the phrase "connection > interface point" and that usage is in the sentence under discussion in > section 6.4 on page 12. > > Looking at page 10 all I see are terms like "endpoint" and "end of > the FCIP Link". I guess there is an assumption that "endpoint" is > somehow synonymous with "connection interface point". Sorry, that's what I meant though my phrasing incorrectly implied otherwise... >That is not > true. The phrase "connection interface point" was chosen for the > text in page 12 because what is being discussed on page 12 is not > exactly the same thing as an "endpoint". > > Consider the revised sentence again: > > "The FCIP Entity is the connection interface point for the IP Network > and is the sole owner of at least one TCP port/IP Address combination > used to form TCP Connections. The TCP port may be the FCIP well > known port at a given IP Address." This is good (but see below). > > Viewed in context, "connection interface point" is synonymous with > "the place to which TCP connect requests are directed". It is not > and is not intended to be synonymous with the endpoint of a TCP > Connection once that TCP connection is formed. It's unclear to me how the two are different. In all the implementations I had seen, your connection endpoint is where you sent the connection requests to - i.e. the connection interface point..... -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com From owner-ips@ece.cmu.edu Fri May 10 21:12:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26600 for ; Fri, 10 May 2002 21:12:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4B0dcl18074 for ips-outgoing; Fri, 10 May 2002 20:39:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4B0daw18069 for ; Fri, 10 May 2002 20:39:36 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4B0dYc3090508; Fri, 10 May 2002 20:39:34 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4B0dXi124296; Fri, 10 May 2002 18:39:33 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: ISCSI: CmdSN in non-leading login To: "Mark S. Edwards" Cc: X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Fri, 10 May 2002 17:38:06 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/10/2002 06:39:33 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk The text as it is written has not been updated since we at one point had the Login command marked as and Immediate command. Therefore, it always had to pick up the next value that would be assigned to the next non immediate command. Also since it was an immediate command the ExpCmdSN was not advanced so it did not effect the commands in the rest of the session. They would continue with the next CmdSN as usual. Login is still not suppose to advance the ExpCmdSN, so there should still not be a problem. When we removed the flag that said that it was an immediate command, the wording in the draft about the Initial Login was not adjusted. I suggest that the only thing that needs to be changed is the following: At the end of the first paragraph under 9.12.8, we should add, the words "Similar rules exist for the Leading Login for a non leading connection, that is, the next CmdSN value is used for the Leading Login of the non leading connection, and that same number is used with all the subsequent Login PDUs on that connection. But at completion of the Login of the connection, the ExpCmdSN is not advanced and the subsequent commands take the next CmdSN value in the session." This is what we were all doing, and simply did not change anything with the Immediate bit was dropped from the Login PDU. I suggest we leave it with that operational intent, since it was so long ago that we establish this way of operating I can not remember exactly why, but would not like to be surprised sometime in the future, and I do not see why we would have to change it. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Mark S. Edwards" @ece.cmu.edu on 05/10/2002 10:38:07 AM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: Re: ISCSI: CmdSN in non-leading login John, If an initiator opens a new connection on a session and in the first login request uses the current session CmdSN, the lifetime of that CmdSN continues all the way through until the completion of the first non-immediate command on that new connection. This means that the initiator has to reserve the use of that CmdSN for the first non-immediate command on that particular session. That's stupid. Especially bearing in mind that it could be pumping commands like crazy down other open connections in the session. There is also another side effect, if the login takes any length of time, like computing a DH or having to make external calls to a Radius or a Kerberos server, then because this CmdSN is outstanding, the other connections in the session will block as soon as the command window is filled. The final sentence in 9.12.8 is meaningless for a non-leading connection. The target either has to block the whole session until the login is completed, or run the risk of corrupting session state. Mark At 10:14 AM 5/10/2002 -0700, John Hufferd wrote: >I do not see the issue, it works as is, it does not effect the first non >immediate command unless it completes as a authorized connection. Again, I >do not see the issue, in fact it works as is. > >. >. >. >John L. Hufferd >Senior Technical Staff Member (STSM) >IBM/SSG San Jose Ca >Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 >Home Office (408) 997-6136, Cell: (408) 499-9702 >Internet address: hufferd@us.ibm.com > > >"Mark S. Edwards" @ece.cmu.edu on 05/10/2002 09:47:53 >AM > >Sent by: owner-ips@ece.cmu.edu > > >To: Bill Studenmund >cc: >Subject: Re: ISCSI: CmdSN in non-leading login > > > >At 09:13 AM 5/10/2002 -0700, Bill Studenmund wrote: > >On Fri, 10 May 2002, Mark S. Edwards wrote: > > > > > There are a couple of problems here for the target. At what point is a > > > non-leading connection considered to be part of the session ? Is it >the > > > moment that the login request is received with a non-zero TSIH ? Or is >it > > > only when the non-leading login succeeds and it enters full feature >phase ? > > > >I think the target shouldn't let anything from a new connection influence > >things until after at least the security phase has been passed. Otherwise > >we have a security hole. After operational negotiation would probably be > >best. > >Good, as far as I can see, a new connection should not be allowed to >influence any session context until the connection reached full-feature >phase. But this is a problem if we have to follow the CmdSN rules of >9.12.8. See next comment. > > > > > So, should an initiator set the CmdSN in the first login request to >zero > > > and only synchronise with the session command stream after full feature > > > phase is established ? This is my preferred option. > > > > > > What happens if the initiator tries using the current session command > > > sequence number is that whilst the login negotiation occurs, other > > > connections within the session can be issuing new commands, so by the >time > > > that the login is finished the CmdSN exchanged in the initial request >is > > > invalid anyway. > > > > > > I would like to see something along the lines that for a non-leading > > > connection, the CmdSN field MUST be zero and that the connection can >not be > > > considered part of the session until full feature phase is entered, at > > > which point any commands issued on the connection are now synchronised >with > > > the session command sequence number as observed by all other existing > > > connections on the session. > > > >I thought login counted as a command, so it got its own command number, in > >the stream of all other commands. ?? > > >For a leading connection the CmdSN, whether zero or non-zero, is regarded >as a primer with which to set the initial session command sequence number, >all the login requests exchanged in the negotiation, no matter how many >carry the same CmdSN as does the first non-immediate command. In other >words, the first pdu in a leading connection does influence session state. > >So if we agree that a non-leading connection can not influence session >state until full-feature phase, then we have to also state that the rule in >9.12.8 about the first non-immediate command carrying the same CmdSN as the >initial login request can not work for a non-leading connection. In this >case, the first non-immediate command must be set from the next logical >value in the session context. I would like the spec to have this added and >to explicitly say that the CmdSN in a login request for a non-leading >connection is ignored by the target. I'd really prefer that the actual >value be zero, but that's not necessary from a protocol perspective if the >target ignores the field. > >Mark. From owner-ips@ece.cmu.edu Fri May 10 22:20:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00503 for ; Fri, 10 May 2002 22:20:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4B1oRE21745 for ips-outgoing; Fri, 10 May 2002 21:50:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (ultrex.nishansystems.com [12.36.127.195]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4B1oPw21738 for ; Fri, 10 May 2002 21:50:25 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 18:50:18 -0700 Message-ID: From: Charles Monia To: "Ips (E-mail)" Subject: RE: iFCP: Responses to David Black iFCP Technical review comment s Date: Fri, 10 May 2002 18:50:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi David: Please see responses in line. > -- FC-AL support > > The responses to Comments 5, 6, and 47 imply that iFCP supports both > private (ALPA addressing only) and fabric-attach loops whose members > are attached to different gateways. I don't understand how this > can work because it requires forwarding FC-AL loop initialization > ELSs (LINIT) among gateways, but those ELSs do not have a usable > destination port (they're passed directly among neighbors), and > the ports involved in the loop have not performed either FLOGI or > PLOGI when the loop is initializing. So how does a gateway figure > out whether and where to forward a LINIT that it receives? I can > figure out how to make this work if only fabric-attached loops are > supported and loops never span gateways, but even that will need > some explanation. > The issue is whether or not a gateway can support a loop topology. Currently deployed gateway and FC switch products support such topologies in one of the following ways: a) Loop topology emulation in which remotely attached N_PORTs are presented locally as loop-connected devices. As you suggest, the loop is emulated locally and does not span gateways. The emulated device can support either the public or private loop protocol. The 'view' looking into the gateway port from the fibre channel side is a series of N_PORTs presented as loop-attached devices (NL_Ports). The loop population consists of externally attached devices and gateway-emulated NL_Ports. b) An FL port, which provides fabric access for loop-connected devices. Neither of these approaches requires anything special on the part of the iFCP protocol. The primitives with the behavior you ascribe to LINIT are those such as LIRP (Loop Initialization Report Position) and LILP (Loop Initialization Loop Position), which are frames serviced sequentially as they flow though NL_Ports on the loop. The loop primitive semantics may emulated locally by the gateway implementation and need not be propagated by iFCP. How the gateway populates the loop with emulated NL_Ports is up to the implementation. As to LINIT, it is one in a set of ELS functions for remote control of a fibre channel public loop. As such, these are standard ELSs which are sent to the 'Loop Fabric Address' (LFA) of the FL port controlling the loop. This, however, does bring up the issue of exposing the fc network topology of the remote gateway region. A gateway that chooses to expose remote, loop-connected devices as NL_Ports should assign the local alias such that the corresponding LFA can be derived by setting the port_id component of the address to zero. The discussion in the spec should be expanded to include these issues. > --- Multiple Gateways > > The proposed new text is: > > For either iFCP fabric type, an N_PORT may be > behind more than > one gateway provided: > > a) One gateway becomes the 'principal switch' and > > b) All gateways attached to a given gateway > region coordinate > the assignment of N_PORT IDs and N_PORT > aliases such that > each N_PORT has one and only one assigned address. > > The above will be added to the specification. > > The implications of multiple gateways for the same N_Port on iSNS > servers and other gateways needs to be discussed. This may be short, > because if the Port's Network Address is registered with iSNS as > a consequence of FLOGI, only one address will be registered because > FLOGI only occurs once, and hence all traffic to the N_Port will > flow through one gateway. > The constraints that should be documented are as follows: a) Within a gateway region, all N_PORTs whether locally or remotely attached, must have one and only one N_PORT address. b) All iFCP frame traffic between any two N_PORT pairs must flow through a single iFCP session. However, each session may traverse a different gateway attached to the region. In order to meet these constraints, a multi-gateway implementation may require an out of band mechanism for redirecting frame traffic from one physical gateway to another. Charles From owner-ips@ece.cmu.edu Fri May 10 22:22:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00574 for ; Fri, 10 May 2002 22:22:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4B1wd322187 for ips-outgoing; Fri, 10 May 2002 21:58:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4B1wcw22183 for ; Fri, 10 May 2002 21:58:38 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4B1wWAH086746 for ; Fri, 10 May 2002 21:58:32 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4B1wVi150266 for ; Fri, 10 May 2002 19:58:31 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: ISCSI: CmdSN in non-leading login To: Mark__S.__Edwards" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Fri, 10 May 2002 18:57:04 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/10/2002 07:58:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I have a correction to the previous note (below). We removed the Immediate bit but there is clear statement that "Login requests are always considered as immediate.". (This means they always get the next CmdSN but do not advance the ExpCmdSN.) The rest of the message is correct, and the suggested update of the wording, is approprate. It will not, however, change the way things work. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com ---------------------- Forwarded by John Hufferd/San Jose/IBM on 05/10/2002 06:49 PM --------------------------- John Hufferd 05/10/2002 05:38 PM To: "Mark S. Edwards" cc: From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: ISCSI: CmdSN in non-leading login (Document link: John Hufferd) The text as it is written has not been updated since we at one point had the Login command marked as and Immediate command. Therefore, it always had to pick up the next value that would be assigned to the next non immediate command. Also since it was an immediate command the ExpCmdSN was not advanced so it did not effect the commands in the rest of the session. They would continue with the next CmdSN as usual. Login is still not suppose to advance the ExpCmdSN, so there should still not be a problem. When we removed the flag that said that it was an immediate command, the wording in the draft about the Initial Login was not adjusted. I suggest that the only thing that needs to be changed is the following: At the end of the first paragraph under 9.12.8, we should add, the words "Similar rules exist for the Leading Login for a non leading connection, that is, the next CmdSN value is used for the Leading Login of the non leading connection, and that same number is used with all the subsequent Login PDUs on that connection. But at completion of the Login of the connection, the ExpCmdSN is not advanced and the subsequent commands take the next CmdSN value in the session." This is what we were all doing, and simply did not change anything with the Immediate bit was dropped from the Login PDU. I suggest we leave it with that operational intent, since it was so long ago that we establish this way of operating I can not remember exactly why, but would not like to be surprised sometime in the future, and I do not see why we would have to change it. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Mark S. Edwards" @ece.cmu.edu on 05/10/2002 10:38:07 AM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: Re: ISCSI: CmdSN in non-leading login John, If an initiator opens a new connection on a session and in the first login request uses the current session CmdSN, the lifetime of that CmdSN continues all the way through until the completion of the first non-immediate command on that new connection. This means that the initiator has to reserve the use of that CmdSN for the first non-immediate command on that particular session. That's stupid. Especially bearing in mind that it could be pumping commands like crazy down other open connections in the session. There is also another side effect, if the login takes any length of time, like computing a DH or having to make external calls to a Radius or a Kerberos server, then because this CmdSN is outstanding, the other connections in the session will block as soon as the command window is filled. The final sentence in 9.12.8 is meaningless for a non-leading connection. The target either has to block the whole session until the login is completed, or run the risk of corrupting session state. Mark At 10:14 AM 5/10/2002 -0700, John Hufferd wrote: >I do not see the issue, it works as is, it does not effect the first non >immediate command unless it completes as a authorized connection. Again, I >do not see the issue, in fact it works as is. > >. >. >. >John L. Hufferd >Senior Technical Staff Member (STSM) >IBM/SSG San Jose Ca >Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 >Home Office (408) 997-6136, Cell: (408) 499-9702 >Internet address: hufferd@us.ibm.com > > >"Mark S. Edwards" @ece.cmu.edu on 05/10/2002 09:47:53 >AM > >Sent by: owner-ips@ece.cmu.edu > > >To: Bill Studenmund >cc: >Subject: Re: ISCSI: CmdSN in non-leading login > > > >At 09:13 AM 5/10/2002 -0700, Bill Studenmund wrote: > >On Fri, 10 May 2002, Mark S. Edwards wrote: > > > > > There are a couple of problems here for the target. At what point is a > > > non-leading connection considered to be part of the session ? Is it >the > > > moment that the login request is received with a non-zero TSIH ? Or is >it > > > only when the non-leading login succeeds and it enters full feature >phase ? > > > >I think the target shouldn't let anything from a new connection influence > >things until after at least the security phase has been passed. Otherwise > >we have a security hole. After operational negotiation would probably be > >best. > >Good, as far as I can see, a new connection should not be allowed to >influence any session context until the connection reached full-feature >phase. But this is a problem if we have to follow the CmdSN rules of >9.12.8. See next comment. > > > > > So, should an initiator set the CmdSN in the first login request to >zero > > > and only synchronise with the session command stream after full feature > > > phase is established ? This is my preferred option. > > > > > > What happens if the initiator tries using the current session command > > > sequence number is that whilst the login negotiation occurs, other > > > connections within the session can be issuing new commands, so by the >time > > > that the login is finished the CmdSN exchanged in the initial request >is > > > invalid anyway. > > > > > > I would like to see something along the lines that for a non-leading > > > connection, the CmdSN field MUST be zero and that the connection can >not be > > > considered part of the session until full feature phase is entered, at > > > which point any commands issued on the connection are now synchronised >with > > > the session command sequence number as observed by all other existing > > > connections on the session. > > > >I thought login counted as a command, so it got its own command number, in > >the stream of all other commands. ?? > > >For a leading connection the CmdSN, whether zero or non-zero, is regarded >as a primer with which to set the initial session command sequence number, >all the login requests exchanged in the negotiation, no matter how many >carry the same CmdSN as does the first non-immediate command. In other >words, the first pdu in a leading connection does influence session state. > >So if we agree that a non-leading connection can not influence session >state until full-feature phase, then we have to also state that the rule in >9.12.8 about the first non-immediate command carrying the same CmdSN as the >initial login request can not work for a non-leading connection. In this >case, the first non-immediate command must be set from the next logical >value in the session context. I would like the spec to have this added and >to explicitly say that the CmdSN in a login request for a non-leading >connection is ignored by the target. I'd really prefer that the actual >value be zero, but that's not necessary from a protocol perspective if the >target ignores the field. > >Mark. From owner-ips@ece.cmu.edu Fri May 10 23:29:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04115 for ; Fri, 10 May 2002 23:29:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4B2pPR24911 for ips-outgoing; Fri, 10 May 2002 22:51:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4B2pFw24899 for ; Fri, 10 May 2002 22:51:17 -0400 (EDT) Received: (from mailgate@localhost) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id WAA06988 for ips@ece.cmu.edu; Fri, 10 May 2002 22:51:04 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkl-vty12.as.wcom.net [216.192.224.12]) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id WAA06926; Fri, 10 May 2002 22:50:57 -0400 (EDT) Message-ID: <3CDC887E.8BE354F9@compuserve.com> Date: Fri, 10 May 2002 21:57:02 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu CC: "Mallikarjun C." Subject: Re: FCIP: Comment 120 - connection endpoint References: <277DD60FB639D511AC0400B0D068B71E02937895@CORPMX14> <00b601c1f85c$c1c92870$edd52b0f@rose.hp.com> <3CDC5C26.7BC3FCF4@compuserve.com> <011a01c1f885$f0d7d520$edd52b0f@rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallikarjun, It looks like we are between a rock and a hard place here. > ... In all the implementations I had seen, your connection endpoint > is where you sent the connection requests to - i.e. the connection > interface point..... FCIP appears to be a case where everything you have ever seen is turned on its head. In FCIP, the FCIP Entity is the place to which TCP connect requests are sent. When the TCP connect request arrives, the FCIP_DE does not exist, meaning that FCIP cannot have the TCP connect requests being directed to the FCIP_DE because it is flat out not there. Only after a TCP connect request arrives and is validated (FSF exchange, and possibly ASF exchange) does the FCIP_DE get created at tied to the endpoint of the newly established TCP Connection. Thus there is a very real difference between the TCP endpoint (which is connected to the FCIP_DE) and the connection interface point (which is inside the FCIP Entity). Short of a serious FCIP rewrite (probably with major confusion added), I do not see any way around this critical distinction. Sorry. .Ralph > > Consider the revised sentence again: > > > > "The FCIP Entity is the connection interface point for the IP Network > > and is the sole owner of at least one TCP port/IP Address combination > > used to form TCP Connections. The TCP port may be the FCIP well > > known port at a given IP Address." > > This is good (but see below). > > > > > Viewed in context, "connection interface point" is synonymous with > > "the place to which TCP connect requests are directed". It is not > > and is not intended to be synonymous with the endpoint of a TCP > > Connection once that TCP connection is formed. > > It's unclear to me how the two are different. In all the implementations I > had seen, your connection endpoint is where you sent the connection > requests to - i.e. the connection interface point..... > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com From owner-ips@ece.cmu.edu Sat May 11 04:42:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22363 for ; Sat, 11 May 2002 04:42:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4B83Uv09402 for ips-outgoing; Sat, 11 May 2002 04:03:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4B83Rw09396; Sat, 11 May 2002 04:03:27 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4B83LCo022886; Sat, 11 May 2002 10:03:21 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4B83JV164062; Sat, 11 May 2002 10:03:19 +0200 To: "John Hufferd" Cc: ips@ece.cmu.edu, "Mark S. Edwards" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: ISCSI: CmdSN in non-leading login X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 11 May 2002 11:03:15 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 11/05/2002 11:03:20, Serialize complete at 11/05/2002 11:03:20 Content-Type: multipart/alternative; boundary="=_alternative 002A0B4FC2256BB6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002A0B4FC2256BB6_= Content-Type: text/plain; charset="us-ascii" John, The current text starts by stating that login requests are immediate. It then states: CmdSN is either the initial command sequence number of a session (for the first Login request of a session - the "leading" login) or the command sequence number in the command stream (e.g., if the leading login carries the CmdSN 123 all other Login requests carry the CmdSN 123 and the first non-immediate command also carries the CmdSN 123). It has all the information needed. I am puzzled by your comments. Julo John Hufferd/San Jose/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 05/11/2002 03:38 AM Please respond to John Hufferd To: "Mark S. Edwards" cc: Subject: Re: ISCSI: CmdSN in non-leading login The text as it is written has not been updated since we at one point had the Login command marked as and Immediate command. Therefore, it always had to pick up the next value that would be assigned to the next non immediate command. Also since it was an immediate command the ExpCmdSN was not advanced so it did not effect the commands in the rest of the session. They would continue with the next CmdSN as usual. Login is still not suppose to advance the ExpCmdSN, so there should still not be a problem. When we removed the flag that said that it was an immediate command, the wording in the draft about the Initial Login was not adjusted. I suggest that the only thing that needs to be changed is the following: At the end of the first paragraph under 9.12.8, we should add, the words "Similar rules exist for the Leading Login for a non leading connection, that is, the next CmdSN value is used for the Leading Login of the non leading connection, and that same number is used with all the subsequent Login PDUs on that connection. But at completion of the Login of the connection, the ExpCmdSN is not advanced and the subsequent commands take the next CmdSN value in the session." This is what we were all doing, and simply did not change anything with the Immediate bit was dropped from the Login PDU. I suggest we leave it with that operational intent, since it was so long ago that we establish this way of operating I can not remember exactly why, but would not like to be surprised sometime in the future, and I do not see why we would have to change it. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Mark S. Edwards" @ece.cmu.edu on 05/10/2002 10:38:07 AM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: Re: ISCSI: CmdSN in non-leading login John, If an initiator opens a new connection on a session and in the first login request uses the current session CmdSN, the lifetime of that CmdSN continues all the way through until the completion of the first non-immediate command on that new connection. This means that the initiator has to reserve the use of that CmdSN for the first non-immediate command on that particular session. That's stupid. Especially bearing in mind that it could be pumping commands like crazy down other open connections in the session. There is also another side effect, if the login takes any length of time, like computing a DH or having to make external calls to a Radius or a Kerberos server, then because this CmdSN is outstanding, the other connections in the session will block as soon as the command window is filled. The final sentence in 9.12.8 is meaningless for a non-leading connection. The target either has to block the whole session until the login is completed, or run the risk of corrupting session state. Mark At 10:14 AM 5/10/2002 -0700, John Hufferd wrote: >I do not see the issue, it works as is, it does not effect the first non >immediate command unless it completes as a authorized connection. Again, I >do not see the issue, in fact it works as is. > >. >. >. >John L. Hufferd >Senior Technical Staff Member (STSM) >IBM/SSG San Jose Ca >Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 >Home Office (408) 997-6136, Cell: (408) 499-9702 >Internet address: hufferd@us.ibm.com > > >"Mark S. Edwards" @ece.cmu.edu on 05/10/2002 09:47:53 >AM > >Sent by: owner-ips@ece.cmu.edu > > >To: Bill Studenmund >cc: >Subject: Re: ISCSI: CmdSN in non-leading login > > > >At 09:13 AM 5/10/2002 -0700, Bill Studenmund wrote: > >On Fri, 10 May 2002, Mark S. Edwards wrote: > > > > > There are a couple of problems here for the target. At what point is a > > > non-leading connection considered to be part of the session ? Is it >the > > > moment that the login request is received with a non-zero TSIH ? Or is >it > > > only when the non-leading login succeeds and it enters full feature >phase ? > > > >I think the target shouldn't let anything from a new connection influence > >things until after at least the security phase has been passed. Otherwise > >we have a security hole. After operational negotiation would probably be > >best. > >Good, as far as I can see, a new connection should not be allowed to >influence any session context until the connection reached full-feature >phase. But this is a problem if we have to follow the CmdSN rules of >9.12.8. See next comment. > > > > > So, should an initiator set the CmdSN in the first login request to >zero > > > and only synchronise with the session command stream after full feature > > > phase is established ? This is my preferred option. > > > > > > What happens if the initiator tries using the current session command > > > sequence number is that whilst the login negotiation occurs, other > > > connections within the session can be issuing new commands, so by the >time > > > that the login is finished the CmdSN exchanged in the initial request >is > > > invalid anyway. > > > > > > I would like to see something along the lines that for a non-leading > > > connection, the CmdSN field MUST be zero and that the connection can >not be > > > considered part of the session until full feature phase is entered, at > > > which point any commands issued on the connection are now synchronised >with > > > the session command sequence number as observed by all other existing > > > connections on the session. > > > >I thought login counted as a command, so it got its own command number, in > >the stream of all other commands. ?? > > >For a leading connection the CmdSN, whether zero or non-zero, is regarded >as a primer with which to set the initial session command sequence number, >all the login requests exchanged in the negotiation, no matter how many >carry the same CmdSN as does the first non-immediate command. In other >words, the first pdu in a leading connection does influence session state. > >So if we agree that a non-leading connection can not influence session >state until full-feature phase, then we have to also state that the rule in >9.12.8 about the first non-immediate command carrying the same CmdSN as the >initial login request can not work for a non-leading connection. In this >case, the first non-immediate command must be set from the next logical >value in the session context. I would like the spec to have this added and >to explicitly say that the CmdSN in a login request for a non-leading >connection is ignored by the target. I'd really prefer that the actual >value be zero, but that's not necessary from a protocol perspective if the >target ignores the field. > >Mark. --=_alternative 002A0B4FC2256BB6_= Content-Type: text/html; charset="us-ascii"
John,

The current text starts by stating that login requests are immediate.

It then states:

CmdSN is either the initial command sequence number of a session (for the first Login request of a session - the "leading" login) or the command sequence number in the command stream (e.g., if the leading login carries the CmdSN 123 all other Login requests carry the CmdSN 123 and the first non-immediate command also carries the CmdSN 123).

It has all the information needed.
I am puzzled by your comments.

Julo


John Hufferd/San Jose/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu

05/11/2002 03:38 AM
Please respond to John Hufferd

       
        To:        "Mark S. Edwards" <marke@muttsnuts.com>
        cc:        <ips@ece.cmu.edu>
        Subject:        Re: ISCSI: CmdSN in non-leading login

       



The text as it is written has not been updated since we at one point had
the Login command marked as and Immediate command.  Therefore, it always
had to pick up the next value that would be assigned to the next non
immediate command.  Also since it was an immediate command the ExpCmdSN was
not advanced so it did not effect the commands in the rest of the session.
They would continue with the next CmdSN as usual.  Login is still not
suppose to advance the ExpCmdSN, so there should still not be a problem.

When we removed the flag that said that it was an immediate command, the
wording in the draft about the Initial Login was not adjusted.

I suggest that the only thing that needs to be changed is the following:
At the end of the first paragraph under 9.12.8, we should add, the words
"Similar rules exist for the Leading Login for a non leading connection,
that is, the next CmdSN value is used for the Leading Login of the non
leading connection, and that same number is used with all the subsequent
Login PDUs on that connection. But at completion of the Login of the
connection, the ExpCmdSN is not advanced and the subsequent commands take
the next CmdSN value in the session."

This is what we were all doing, and simply did not change anything with the
Immediate bit was dropped from the Login PDU.  I suggest we leave it with
that operational intent, since it was so long ago that we establish this
way of operating I can not remember exactly why, but would not like to be
surprised sometime in the future, and I do not see why we would have to
change it.




.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


"Mark S. Edwards" <marke@muttsnuts.com>@ece.cmu.edu on 05/10/2002 10:38:07
AM

Sent by:    owner-ips@ece.cmu.edu


To:    John Hufferd/San Jose/IBM@IBMUS
cc:    <ips@ece.cmu.edu>
Subject:    Re: ISCSI: CmdSN in non-leading login



John,

If an initiator opens a new connection on a session and in the first login
request uses the current session CmdSN, the lifetime of that CmdSN
continues all the way through until the completion of the first
non-immediate command on that new connection.

This means that the initiator has to reserve the use of that CmdSN for the
first non-immediate command on that particular session.  That's stupid.

Especially bearing in mind that it could be pumping commands like crazy
down other open connections in the session.

There is also another side effect, if the login takes any length of time,
like computing a DH or having to make external calls to a Radius or a
Kerberos server, then because this CmdSN is outstanding, the other
connections in the session will block as soon as the command window is
filled.

The final sentence in 9.12.8 is meaningless for a non-leading
connection.  The target either has to block the whole session until the
login is completed, or run the risk of corrupting session state.

Mark
At 10:14 AM 5/10/2002 -0700, John Hufferd wrote:

>I do not see the issue, it works as is, it does not effect the first non
>immediate command unless it completes as a authorized connection. Again, I
>do not see the issue, in fact it works as is.
>
>.
>.
>.
>John L. Hufferd
>Senior Technical Staff Member (STSM)
>IBM/SSG San Jose Ca
>Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
>Home Office (408) 997-6136, Cell: (408) 499-9702
>Internet address: hufferd@us.ibm.com
>
>
>"Mark S. Edwards" <marke@muttsnuts.com>@ece.cmu.edu on 05/10/2002 09:47:53
>AM
>
>Sent by:    owner-ips@ece.cmu.edu
>
>
>To:    Bill Studenmund <wrstuden@wasabisystems.com>
>cc:    <ips@ece.cmu.edu>
>Subject:    Re: ISCSI: CmdSN in non-leading login
>
>
>
>At 09:13 AM 5/10/2002 -0700, Bill Studenmund wrote:
> >On Fri, 10 May 2002, Mark S. Edwards wrote:
> >
> > > There are a couple of problems here for the target.  At what point is
a
> > > non-leading connection considered to be part of the session ?  Is it
>the
> > > moment that the login request is received with a non-zero TSIH ?  Or
is
>it
> > > only when the non-leading login succeeds and it enters full feature
>phase ?
> >
> >I think the target shouldn't let anything from a new connection
influence
> >things until after at least the security phase has been passed.
Otherwise
> >we have a security hole. After operational negotiation would probably be
> >best.
>
>Good, as far as I can see, a new connection should not be allowed to
>influence any session context until the connection reached full-feature
>phase.  But this is a problem if we have to follow the CmdSN rules of
>9.12.8.   See next comment.
>
>
> > > So, should an initiator set the CmdSN in the first login request to
>zero
> > > and only synchronise with the session command stream after full
feature
> > > phase is established ?  This is my preferred option.
> > >
> > > What happens if the initiator tries using the current session command
> > > sequence number is that whilst the login negotiation occurs, other
> > > connections within the session can be issuing new commands, so by the
>time
> > > that the login is finished the CmdSN exchanged in the initial request
>is
> > > invalid anyway.
> > >
> > > I would like to see something along the lines that for a non-leading
> > > connection, the CmdSN field MUST be zero and that the connection can
>not be
> > > considered part of the session until full feature phase is entered,
at
> > > which point any commands issued on the connection are now
synchronised
>with
> > > the session command sequence number as observed by all other existing
> > > connections on the session.
> >
> >I thought login counted as a command, so it got its own command number,
in
> >the stream of all other commands. ??
>
>
>For a leading connection the CmdSN, whether zero or non-zero, is regarded
>as a primer with which to set the initial session command sequence number,
>all the login requests exchanged in the negotiation, no matter how many
>carry the same CmdSN as does the first non-immediate command.  In other
>words, the first pdu in a leading connection does influence session state.
>
>So if we agree that a non-leading connection can not influence session
>state until full-feature phase, then we have to also state that the rule
in
>9.12.8 about the first non-immediate command carrying the same CmdSN as
the
>initial login request can not work for a non-leading connection.  In this
>case, the first non-immediate command must be set from the next logical
>value in the session context.  I would like the spec to have this added
and
>to explicitly say that the CmdSN in a login request for a non-leading
>connection is ignored by the target.  I'd really prefer that the actual
>value be zero, but that's not necessary from a protocol perspective if the
>target ignores the field.
>
>Mark.

--=_alternative 002A0B4FC2256BB6_=-- From owner-ips@ece.cmu.edu Sat May 11 14:58:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08201 for ; Sat, 11 May 2002 14:58:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4BIDAj20431 for ips-outgoing; Sat, 11 May 2002 14:13:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4BHouw19282 for ; Sat, 11 May 2002 13:50:56 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Sat, 11 May 2002 13:50:55 -0400 Message-ID: <25369470B6F0D41194820002B328BDD22F5B5B@ATLOPS> From: Eddy Quicksall To: John Hufferd , Mark__S.__Edwards" cc: From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: ISCSI: CmdSN in non-leading login (Document link: John Hufferd) The text as it is written has not been updated since we at one point had the Login command marked as and Immediate command. Therefore, it always had to pick up the next value that would be assigned to the next non immediate command. Also since it was an immediate command the ExpCmdSN was not advanced so it did not effect the commands in the rest of the session. They would continue with the next CmdSN as usual. Login is still not suppose to advance the ExpCmdSN, so there should still not be a problem. When we removed the flag that said that it was an immediate command, the wording in the draft about the Initial Login was not adjusted. I suggest that the only thing that needs to be changed is the following: At the end of the first paragraph under 9.12.8, we should add, the words "Similar rules exist for the Leading Login for a non leading connection, that is, the next CmdSN value is used for the Leading Login of the non leading connection, and that same number is used with all the subsequent Login PDUs on that connection. But at completion of the Login of the connection, the ExpCmdSN is not advanced and the subsequent commands take the next CmdSN value in the session." This is what we were all doing, and simply did not change anything with the Immediate bit was dropped from the Login PDU. I suggest we leave it with that operational intent, since it was so long ago that we establish this way of operating I can not remember exactly why, but would not like to be surprised sometime in the future, and I do not see why we would have to change it. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Mark S. Edwards" @ece.cmu.edu on 05/10/2002 10:38:07 AM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: Re: ISCSI: CmdSN in non-leading login John, If an initiator opens a new connection on a session and in the first login request uses the current session CmdSN, the lifetime of that CmdSN continues all the way through until the completion of the first non-immediate command on that new connection. This means that the initiator has to reserve the use of that CmdSN for the first non-immediate command on that particular session. That's stupid. Especially bearing in mind that it could be pumping commands like crazy down other open connections in the session. There is also another side effect, if the login takes any length of time, like computing a DH or having to make external calls to a Radius or a Kerberos server, then because this CmdSN is outstanding, the other connections in the session will block as soon as the command window is filled. The final sentence in 9.12.8 is meaningless for a non-leading connection. The target either has to block the whole session until the login is completed, or run the risk of corrupting session state. Mark At 10:14 AM 5/10/2002 -0700, John Hufferd wrote: >I do not see the issue, it works as is, it does not effect the first non >immediate command unless it completes as a authorized connection. Again, I >do not see the issue, in fact it works as is. > >. >. >. >John L. Hufferd >Senior Technical Staff Member (STSM) >IBM/SSG San Jose Ca >Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 >Home Office (408) 997-6136, Cell: (408) 499-9702 >Internet address: hufferd@us.ibm.com > > >"Mark S. Edwards" @ece.cmu.edu on 05/10/2002 09:47:53 >AM > >Sent by: owner-ips@ece.cmu.edu > > >To: Bill Studenmund >cc: >Subject: Re: ISCSI: CmdSN in non-leading login > > > >At 09:13 AM 5/10/2002 -0700, Bill Studenmund wrote: > >On Fri, 10 May 2002, Mark S. Edwards wrote: > > > > > There are a couple of problems here for the target. At what point is a > > > non-leading connection considered to be part of the session ? Is it >the > > > moment that the login request is received with a non-zero TSIH ? Or is >it > > > only when the non-leading login succeeds and it enters full feature >phase ? > > > >I think the target shouldn't let anything from a new connection influence > >things until after at least the security phase has been passed. Otherwise > >we have a security hole. After operational negotiation would probably be > >best. > >Good, as far as I can see, a new connection should not be allowed to >influence any session context until the connection reached full-feature >phase. But this is a problem if we have to follow the CmdSN rules of >9.12.8. See next comment. > > > > > So, should an initiator set the CmdSN in the first login request to >zero > > > and only synchronise with the session command stream after full feature > > > phase is established ? This is my preferred option. > > > > > > What happens if the initiator tries using the current session command > > > sequence number is that whilst the login negotiation occurs, other > > > connections within the session can be issuing new commands, so by the >time > > > that the login is finished the CmdSN exchanged in the initial request >is > > > invalid anyway. > > > > > > I would like to see something along the lines that for a non-leading > > > connection, the CmdSN field MUST be zero and that the connection can >not be > > > considered part of the session until full feature phase is entered, at > > > which point any commands issued on the connection are now synchronised >with > > > the session command sequence number as observed by all other existing > > > connections on the session. > > > >I thought login counted as a command, so it got its own command number, in > >the stream of all other commands. ?? > > >For a leading connection the CmdSN, whether zero or non-zero, is regarded >as a primer with which to set the initial session command sequence number, >all the login requests exchanged in the negotiation, no matter how many >carry the same CmdSN as does the first non-immediate command. In other >words, the first pdu in a leading connection does influence session state. > >So if we agree that a non-leading connection can not influence session >state until full-feature phase, then we have to also state that the rule in >9.12.8 about the first non-immediate command carrying the same CmdSN as the >initial login request can not work for a non-leading connection. In this >case, the first non-immediate command must be set from the next logical >value in the session context. I would like the spec to have this added and >to explicitly say that the CmdSN in a login request for a non-leading >connection is ignored by the target. I'd really prefer that the actual >value be zero, but that's not necessary from a protocol perspective if the >target ignores the field. > >Mark. From owner-ips@ece.cmu.edu Sat May 11 16:06:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10304 for ; Sat, 11 May 2002 16:06:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4BJR2Z24279 for ips-outgoing; Sat, 11 May 2002 15:27:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4BJQxw24264; Sat, 11 May 2002 15:26:59 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4BJQrAH083748; Sat, 11 May 2002 15:26:53 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4BJQqN67346; Sat, 11 May 2002 13:26:52 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: ISCSI: CmdSN in non-leading login To: "Julian Satran" Cc: ips@ece.cmu.edu, "Mark S. Edwards" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Sat, 11 May 2002 12:25:22 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/11/2002 01:26:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g4BJR0w24265 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julian, (watch out long note to follow) Sometimes our messages pass by each other in the night. I had corrected my note to indicate that I had overlooked the very obvious statement that we kept in the draft that the Login command was immediate. But the rest of the note I think is correct. That is, the command that follows the completion of the non leading-connection Login should take its CmdSN from the next command sequence number in the "Session" stream, not the CmdSN of the Login for that connection. Here is the thinking, 1. The second connection is started while commands are flowing on the Leading connection, 2. The CmdSN in the stream when the Login for the second connection is started is lets say 123. 3. Since the Login command is immediate, and does not change the ExpCmdSN then one of three things can happen a. Initiator uses the same CmdSN for the next command that it sends on the first connection, etc. (123, 124, 125, etc.) OR b. Initiator uses the next CmdSN 124 on the leading connection and thereby creates a delivery hole, for the target until the CmdSN 123 is finally received on the secondary connection and then all the commands 123----125, etc, are delivered c. No commands are sent on any connection until the Login of the secondary connection is completed and the next command is given the CmdSN of 123 4. If 3a is done, then the first command after the delivery will use the next CmdSN in the stream and no blockage would have occurred. 5. If 3b is done there will be a blockage of the delivery of commands until the secondary Login in completed 6. If 3c is done, then the first command after the delivery will use the same CmdSN (123) as the Login, but the commands will have a blockage at the initiator until the secondary Login is completed. So I believe, that IF the subsequent commands in a secondary connection has to have the same CmdSN as the Initial Login of that connection, either all commands in the entire session must stop being sent on other connections, or commands will not be delivered until the delivery hole is closed at the end of the secondary Login. If we were to handle the Login for secondary connections like other immediate commands, the 3a. path would be done (the ExpCmdSN would not be advanced, but other commands will continue and they will advance the ExpCmdSN as normal, and when the next non immediate command is sent on the same connection as the immediate command, it is simply given the very next CmdSN from the session stream. The problem of treating the secondary connection Login exactly like the leading Connection, when it comes to the next command, is that, unlike the leading connection, other things continue to move on the other connections. Therefore, in my opinion the correct way of interpreting the current wordage in 9.12.8 is at the point it says: "....and the first non-immediate command also carries the CmdSN 123.)" we should read that as "... the next non-immediate command IN THE SESSION also carries the CmdSN 123)". In this way the words mean the same for both the leading connection and secondary connection. This is how I believed the implementations have been built. Anyway, that was the essences of my words where I suggested: At the end of the first paragraph under 9.12.8, we should add, the words "Similar rules exist for the Leading Login for a non leading connection, that is, the next CmdSN value is used for the Leading Login of the non leading connection, and that same number is used with all the subsequent Login PDUs on that connection. But at completion of the Login of the connection, the ExpCmdSN is not advanced and the subsequent commands take the next CmdSN value in the session." Now perhaps we can have some better words, perhaps the words but clearly the current word have confused some folks. Perhaps even me :-) . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 05/11/2002 01:03:15 AM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu, "Mark S. Edwards" , owner-ips@ece.cmu.edu Subject: Re: ISCSI: CmdSN in non-leading login John, The current text starts by stating that login requests are immediate. It then states: CmdSN is either the initial command sequence number of a session (for the first Login request of a session - the "leading" login) or the command sequence number in the command stream (e.g., if the leading login carries the CmdSN 123 all other Login requests carry the CmdSN 123 and the first non-immediate command also carries the CmdSN 123). It has all the information needed. I am puzzled by your comments. Julo John Hufferd/San         To:        "Mark S. Edwards" Jose/IBM@IBMU S         cc:         Sent by:         Subject:        Re: ISCSI: CmdSN in owner-ips@ece non-leading login .cmu.edu 05/11/2002 03:38 AM Please respond to John Hufferd The text as it is written has not been updated since we at one point had the Login command marked as and Immediate command.  Therefore, it always had to pick up the next value that would be assigned to the next non immediate command.  Also since it was an immediate command the ExpCmdSN was not advanced so it did not effect the commands in the rest of the session. They would continue with the next CmdSN as usual.  Login is still not suppose to advance the ExpCmdSN, so there should still not be a problem. When we removed the flag that said that it was an immediate command, the wording in the draft about the Initial Login was not adjusted. I suggest that the only thing that needs to be changed is the following: At the end of the first paragraph under 9.12.8, we should add, the words "Similar rules exist for the Leading Login for a non leading connection, that is, the next CmdSN value is used for the Leading Login of the non leading connection, and that same number is used with all the subsequent Login PDUs on that connection. But at completion of the Login of the connection, the ExpCmdSN is not advanced and the subsequent commands take the next CmdSN value in the session." This is what we were all doing, and simply did not change anything with the Immediate bit was dropped from the Login PDU.  I suggest we leave it with that operational intent, since it was so long ago that we establish this way of operating I can not remember exactly why, but would not like to be surprised sometime in the future, and I do not see why we would have to change it. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Mark S. Edwards" @ece.cmu.edu on 05/10/2002 10:38:07 AM Sent by:    owner-ips@ece.cmu.edu To:    John Hufferd/San Jose/IBM@IBMUS cc:     Subject:    Re: ISCSI: CmdSN in non-leading login John, If an initiator opens a new connection on a session and in the first login request uses the current session CmdSN, the lifetime of that CmdSN continues all the way through until the completion of the first non-immediate command on that new connection. This means that the initiator has to reserve the use of that CmdSN for the first non-immediate command on that particular session.  That's stupid. Especially bearing in mind that it could be pumping commands like crazy down other open connections in the session. There is also another side effect, if the login takes any length of time, like computing a DH or having to make external calls to a Radius or a Kerberos server, then because this CmdSN is outstanding, the other connections in the session will block as soon as the command window is filled. The final sentence in 9.12.8 is meaningless for a non-leading connection.  The target either has to block the whole session until the login is completed, or run the risk of corrupting session state. Mark At 10:14 AM 5/10/2002 -0700, John Hufferd wrote: >I do not see the issue, it works as is, it does not effect the first non >immediate command unless it completes as a authorized connection. Again, I >do not see the issue, in fact it works as is. > >. >. >. >John L. Hufferd >Senior Technical Staff Member (STSM) >IBM/SSG San Jose Ca >Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688 >Home Office (408) 997-6136, Cell: (408) 499-9702 >Internet address: hufferd@us.ibm.com > > >"Mark S. Edwards" @ece.cmu.edu on 05/10/2002 09:47:53 >AM > >Sent by:    owner-ips@ece.cmu.edu > > >To:    Bill Studenmund >cc:     >Subject:    Re: ISCSI: CmdSN in non-leading login > > > >At 09:13 AM 5/10/2002 -0700, Bill Studenmund wrote: > >On Fri, 10 May 2002, Mark S. Edwards wrote: > > > > > There are a couple of problems here for the target.  At what point is a > > > non-leading connection considered to be part of the session ?  Is it >the > > > moment that the login request is received with a non-zero TSIH ?  Or is >it > > > only when the non-leading login succeeds and it enters full feature >phase ? > > > >I think the target shouldn't let anything from a new connection influence > >things until after at least the security phase has been passed. Otherwise > >we have a security hole. After operational negotiation would probably be > >best. > >Good, as far as I can see, a new connection should not be allowed to >influence any session context until the connection reached full-feature >phase.  But this is a problem if we have to follow the CmdSN rules of >9.12.8.   See next comment. > > > > > So, should an initiator set the CmdSN in the first login request to >zero > > > and only synchronise with the session command stream after full feature > > > phase is established ?  This is my preferred option. > > > > > > What happens if the initiator tries using the current session command > > > sequence number is that whilst the login negotiation occurs, other > > > connections within the session can be issuing new commands, so by the >time > > > that the login is finished the CmdSN exchanged in the initial request >is > > > invalid anyway. > > > > > > I would like to see something along the lines that for a non-leading > > > connection, the CmdSN field MUST be zero and that the connection can >not be > > > considered part of the session until full feature phase is entered, at > > > which point any commands issued on the connection are now synchronised >with > > > the session command sequence number as observed by all other existing > > > connections on the session. > > > >I thought login counted as a command, so it got its own command number, in > >the stream of all other commands. ?? > > >For a leading connection the CmdSN, whether zero or non-zero, is regarded >as a primer with which to set the initial session command sequence number, >all the login requests exchanged in the negotiation, no matter how many >carry the same CmdSN as does the first non-immediate command.  In other >words, the first pdu in a leading connection does influence session state. > >So if we agree that a non-leading connection can not influence session >state until full-feature phase, then we have to also state that the rule in >9.12.8 about the first non-immediate command carrying the same CmdSN as the >initial login request can not work for a non-leading connection.  In this >case, the first non-immediate command must be set from the next logical >value in the session context.  I would like the spec to have this added and >to explicitly say that the CmdSN in a login request for a non-leading >connection is ignored by the target.  I'd really prefer that the actual >value be zero, but that's not necessary from a protocol perspective if the >target ignores the field. > >Mark. From owner-ips@ece.cmu.edu Sun May 12 02:14:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08033 for ; Sun, 12 May 2002 02:14:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4C5MXi23843 for ips-outgoing; Sun, 12 May 2002 01:22:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4C5MTw23837; Sun, 12 May 2002 01:22:29 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4C5MM9d041314; Sun, 12 May 2002 07:22:22 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4C5ML2117784; Sun, 12 May 2002 07:22:21 +0200 To: "John Hufferd" Cc: ips@ece.cmu.edu, "Mark S. Edwards" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: ISCSI: CmdSN in non-leading login X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 12 May 2002 08:22:19 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/05/2002 08:22:21, Serialize complete at 12/05/2002 08:22:21 Content-Type: multipart/alternative; boundary="=_alternative 00162FBFC2256BB7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00162FBFC2256BB7_= Content-Type: text/plain; charset="us-ascii" John, My only point was that there is enough information in the section to describe correct behavior. And immediate commands do not create any blockage regardless of their CmdSN. I am still trying to understand what your point was (is). Julo John Hufferd@IBMUS 05/11/2002 10:25 PM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, "Mark S. Edwards" , owner-ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: ISCSI: CmdSN in non-leading login Julian, (watch out long note to follow) Sometimes our messages pass by each other in the night. I had corrected my note to indicate that I had overlooked the very obvious statement that we kept in the draft that the Login command was immediate. But the rest of the note I think is correct. That is, the command that follows the completion of the non leading-connection Login should take its CmdSN from the next command sequence number in the "Session" stream, not the CmdSN of the Login for that connection. Here is the thinking, 1. The second connection is started while commands are flowing on the Leading connection, 2. The CmdSN in the stream when the Login for the second connection is started is lets say 123. 3. Since the Login command is immediate, and does not change the ExpCmdSN then one of three things can happen a. Initiator uses the same CmdSN for the next command that it sends on the first connection, etc. (123, 124, 125, etc.) OR b. Initiator uses the next CmdSN 124 on the leading connection and thereby creates a delivery hole, for the target until the CmdSN 123 is finally received on the secondary connection and then all the commands 123----125, etc, are delivered c. No commands are sent on any connection until the Login of the secondary connection is completed and the next command is given the CmdSN of 123 4. If 3a is done, then the first command after the delivery will use the next CmdSN in the stream and no blockage would have occurred. 5. If 3b is done there will be a blockage of the delivery of commands until the secondary Login in completed 6. If 3c is done, then the first command after the delivery will use the same CmdSN (123) as the Login, but the commands will have a blockage at the initiator until the secondary Login is completed. So I believe, that IF the subsequent commands in a secondary connection has to have the same CmdSN as the Initial Login of that connection, either all commands in the entire session must stop being sent on other connections, or commands will not be delivered until the delivery hole is closed at the end of the secondary Login. If we were to handle the Login for secondary connections like other immediate commands, the 3a. path would be done (the ExpCmdSN would not be advanced, but other commands will continue and they will advance the ExpCmdSN as normal, and when the next non immediate command is sent on the same connection as the immediate command, it is simply given the very next CmdSN from the session stream. The problem of treating the secondary connection Login exactly like the leading Connection, when it comes to the next command, is that, unlike the leading connection, other things continue to move on the other connections. Therefore, in my opinion the correct way of interpreting the current wordage in 9.12.8 is at the point it says: "....and the first non-immediate command also carries the CmdSN 123.)" we should read that as "... the next non-immediate command IN THE SESSION also carries the CmdSN 123)". In this way the words mean the same for both the leading connection and secondary connection. This is how I believed the implementations have been built. Anyway, that was the essences of my words where I suggested: At the end of the first paragraph under 9.12.8, we should add, the words "Similar rules exist for the Leading Login for a non leading connection, that is, the next CmdSN value is used for the Leading Login of the non leading connection, and that same number is used with all the subsequent Login PDUs on that connection. But at completion of the Login of the connection, the ExpCmdSN is not advanced and the subsequent commands take the next CmdSN value in the session." Now perhaps we can have some better words, perhaps the words but clearly the current word have confused some folks. Perhaps even me :-) . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu, "Mark S. Edwards" , owner-ips@ece.cmu.edu Subject: Re: ISCSI: CmdSN in non-leading login John, The current text starts by stating that login requests are immediate. It then states: CmdSN is either the initial command sequence number of a session (for the first Login request of a session - the "leading" login) or the command sequence number in the command stream (e.g., if the leading login carries the CmdSN 123 all other Login requests carry the CmdSN 123 and the first non-immediate command also carries the CmdSN 123). It has all the information needed. I am puzzled by your comments. Julo John Hufferd/San Jose/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 05/11/2002 03:38 AM Please respond to John Hufferd To: "Mark S. Edwards" cc: Subject: Re: ISCSI: CmdSN in non-leading login The text as it is written has not been updated since we at one point had the Login command marked as and Immediate command. Therefore, it always had to pick up the next value that would be assigned to the next non immediate command. Also since it was an immediate command the ExpCmdSN was not advanced so it did not effect the commands in the rest of the session. They would continue with the next CmdSN as usual. Login is still not suppose to advance the ExpCmdSN, so there should still not be a problem. When we removed the flag that said that it was an immediate command, the wording in the draft about the Initial Login was not adjusted. I suggest that the only thing that needs to be changed is the following: At the end of the first paragraph under 9.12.8, we should add, the words "Similar rules exist for the Leading Login for a non leading connection, that is, the next CmdSN value is used for the Leading Login of the non leading connection, and that same number is used with all the subsequent Login PDUs on that connection. But at completion of the Login of the connection, the ExpCmdSN is not advanced and the subsequent commands take the next CmdSN value in the session." This is what we were all doing, and simply did not change anything with the Immediate bit was dropped from the Login PDU. I suggest we leave it with that operational intent, since it was so long ago that we establish this way of operating I can not remember exactly why, but would not like to be surprised sometime in the future, and I do not see why we would have to change it. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Mark S. Edwards" @ece.cmu.edu on 05/10/2002 10:38:07 AM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: Re: ISCSI: CmdSN in non-leading login John, If an initiator opens a new connection on a session and in the first login request uses the current session CmdSN, the lifetime of that CmdSN continues all the way through until the completion of the first non-immediate command on that new connection. This means that the initiator has to reserve the use of that CmdSN for the first non-immediate command on that particular session. That's stupid. Especially bearing in mind that it could be pumping commands like crazy down other open connections in the session. There is also another side effect, if the login takes any length of time, like computing a DH or having to make external calls to a Radius or a Kerberos server, then because this CmdSN is outstanding, the other connections in the session will block as soon as the command window is filled. The final sentence in 9.12.8 is meaningless for a non-leading connection. The target either has to block the whole session until the login is completed, or run the risk of corrupting session state. Mark At 10:14 AM 5/10/2002 -0700, John Hufferd wrote: >I do not see the issue, it works as is, it does not effect the first non >immediate command unless it completes as a authorized connection. Again, I >do not see the issue, in fact it works as is. > >. >. >. >John L. Hufferd >Senior Technical Staff Member (STSM) >IBM/SSG San Jose Ca >Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 >Home Office (408) 997-6136, Cell: (408) 499-9702 >Internet address: hufferd@us.ibm.com > > >"Mark S. Edwards" @ece.cmu.edu on 05/10/2002 09:47:53 >AM > >Sent by: owner-ips@ece.cmu.edu > > >To: Bill Studenmund >cc: >Subject: Re: ISCSI: CmdSN in non-leading login > > > >At 09:13 AM 5/10/2002 -0700, Bill Studenmund wrote: > >On Fri, 10 May 2002, Mark S. Edwards wrote: > > > > > There are a couple of problems here for the target. At what point is a > > > non-leading connection considered to be part of the session ? Is it >the > > > moment that the login request is received with a non-zero TSIH ? Or is >it > > > only when the non-leading login succeeds and it enters full feature >phase ? > > > >I think the target shouldn't let anything from a new connection influence > >things until after at least the security phase has been passed. Otherwise > >we have a security hole. After operational negotiation would probably be > >best. > >Good, as far as I can see, a new connection should not be allowed to >influence any session context until the connection reached full-feature >phase. But this is a problem if we have to follow the CmdSN rules of >9.12.8. See next comment. > > > > > So, should an initiator set the CmdSN in the first login request to >zero > > > and only synchronise with the session command stream after full feature > > > phase is established ? This is my preferred option. > > > > > > What happens if the initiator tries using the current session command > > > sequence number is that whilst the login negotiation occurs, other > > > connections within the session can be issuing new commands, so by the >time > > > that the login is finished the CmdSN exchanged in the initial request >is > > > invalid anyway. > > > > > > I would like to see something along the lines that for a non-leading > > > connection, the CmdSN field MUST be zero and that the connection can >not be > > > considered part of the session until full feature phase is entered, at > > > which point any commands issued on the connection are now synchronised >with > > > the session command sequence number as observed by all other existing > > > connections on the session. > > > >I thought login counted as a command, so it got its own command number, in > >the stream of all other commands. ?? > > >For a leading connection the CmdSN, whether zero or non-zero, is regarded >as a primer with which to set the initial session command sequence number, >all the login requests exchanged in the negotiation, no matter how many >carry the same CmdSN as does the first non-immediate command. In other >words, the first pdu in a leading connection does influence session state. > >So if we agree that a non-leading connection can not influence session >state until full-feature phase, then we have to also state that the rule in >9.12.8 about the first non-immediate command carrying the same CmdSN as the >initial login request can not work for a non-leading connection. In this >case, the first non-immediate command must be set from the next logical >value in the session context. I would like the spec to have this added and >to explicitly say that the CmdSN in a login request for a non-leading >connection is ignored by the target. I'd really prefer that the actual >value be zero, but that's not necessary from a protocol perspective if the >target ignores the field. > >Mark. --=_alternative 00162FBFC2256BB7_= Content-Type: text/html; charset="us-ascii"
John,

My only point was that there is enough information in the section to describe correct behavior.
And immediate commands do not create any blockage regardless of their CmdSN.

I am still trying to understand what your point was (is).

Julo


John Hufferd@IBMUS

05/11/2002 10:25 PM


        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, "Mark S. Edwards" <marke@muttsnuts.com>, owner-ips@ece.cmu.edu
        From:        John Hufferd/San Jose/IBM@IBMUS
        Subject:        Re: ISCSI: CmdSN in non-leading loginLink
 





Julian,  (watch out long note to follow)
Sometimes our messages pass by each other in the night.  I had corrected my note to indicate that I had overlooked the very obvious statement that we kept in the draft that the Login command was immediate.  But the rest of the note I think is correct.

That is, the command that follows the completion of the non leading-connection Login should take its CmdSN from the next command sequence number in the "Session" stream, not the CmdSN of the Login for that connection.  

Here is the thinking,

1. The second connection is started while commands are flowing on the Leading connection,
2. The CmdSN in the stream when the Login for the second connection is started is lets say 123.  
3. Since the Login command is immediate, and does not change the ExpCmdSN then one of three things can happen
    a. Initiator uses the same CmdSN for the next command that it sends on the first connection, etc. (123, 124, 125, etc.)
    OR    
    b. Initiator uses the next CmdSN 124 on the leading connection and thereby creates a delivery hole, for the target until the CmdSN 123 is finally received on the secondary connection and then all the commands 123----125, etc, are delivered
    c. No commands are sent on any connection until the Login of the secondary connection is completed and the next command is given the CmdSN of 123
4. If 3a is done, then the first command after the delivery will use the next CmdSN in the stream and no blockage would have occurred.
5. If 3b is done there will be a blockage of the delivery of commands until the secondary Login in completed
6. If 3c is done, then the first command after the delivery will use the same CmdSN (123) as the Login, but the commands will have a blockage at the initiator until the secondary Login is completed.

So I believe, that IF the subsequent commands in a secondary connection has to have the same CmdSN as the Initial Login of that  connection, either all commands in the entire session must stop being sent on other connections, or commands will not be delivered until the delivery hole is closed at the end of the secondary Login.

If we were to handle the Login for secondary connections like other immediate commands,  the 3a. path would be done (the ExpCmdSN would not be advanced, but other commands will continue and they will advance the ExpCmdSN as normal, and when the next  non immediate command is sent on the same connection as the immediate command, it is simply given the very next CmdSN from the session stream.

The problem of treating the secondary connection Login exactly like the leading Connection, when it comes to the next command, is that, unlike the leading connection, other things continue to move on the other connections.

Therefore, in my opinion the correct way of interpreting the current wordage in 9.12.8 is at the point it says:
  "....and the first non-immediate command also carries the CmdSN 123.)"  
we should read that as "... the next non-immediate command IN THE SESSION also carries the CmdSN 123)".  In this way the words mean the same for both the leading connection and secondary connection.

This is how I believed the implementations have been built.

Anyway, that was the essences of my words where I suggested:
 
At the end of the first paragraph under 9.12.8, we should add, the words
"Similar rules exist for the Leading Login for a non leading connection,
that is, the next CmdSN value is used for the Leading Login of the non
leading connection, and that same number is used with all the subsequent
Login PDUs on that connection. But at completion of the Login of the
connection, the ExpCmdSN is not advanced and the subsequent commands take
the next CmdSN value in the session."

Now perhaps we can have some better words, perhaps the words but clearly the current word have confused some folks.  Perhaps even me :-)


.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com

Sent by:        owner-ips@ece.cmu.edu

To:        John Hufferd/San Jose/IBM@IBMUS
cc:        ips@ece.cmu.edu, "Mark S. Edwards" <marke@muttsnuts.com>, owner-ips@ece.cmu.edu
Subject:        Re: ISCSI: CmdSN in non-leading login




John,

The current text starts by stating that login requests are immediate.

It then states:

CmdSN is either the initial command sequence number of a session (for the first Login request of a session - the "leading" login) or the command sequence number in the command stream (e.g., if the leading login carries the CmdSN 123 all other Login requests carry the CmdSN 123 and the first non-immediate command also carries the CmdSN 123).

It has all the information needed.
I am puzzled by your comments.

Julo


John Hufferd/San Jose/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu

05/11/2002 03:38 AM
Please respond to John Hufferd
       
        To:        "Mark S. Edwards" <marke@muttsnuts.com>
        cc:        <ips@ece.cmu.edu>
        Subject:        Re: ISCSI: CmdSN in non-leading login

       



The text as it is written has not been updated since we at one point had
the Login command marked as and Immediate command.  Therefore, it always
had to pick up the next value that would be assigned to the next non
immediate command.  Also since it was an immediate command the ExpCmdSN was
not advanced so it did not effect the commands in the rest of the session.
They would continue with the next CmdSN as usual.  Login is still not
suppose to advance the ExpCmdSN, so there should still not be a problem.

When we removed the flag that said that it was an immediate command, the
wording in the draft about the Initial Login was not adjusted.

I suggest that the only thing that needs to be changed is the following:
At the end of the first paragraph under 9.12.8, we should add, the words
"Similar rules exist for the Leading Login for a non leading connection,
that is, the next CmdSN value is used for the Leading Login of the non
leading connection, and that same number is used with all the subsequent
Login PDUs on that connection. But at completion of the Login of the
connection, the ExpCmdSN is not advanced and the subsequent commands take
the next CmdSN value in the session."

This is what we were all doing, and simply did not change anything with the
Immediate bit was dropped from the Login PDU.  I suggest we leave it with
that operational intent, since it was so long ago that we establish this
way of operating I can not remember exactly why, but would not like to be
surprised sometime in the future, and I do not see why we would have to
change it.




.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


"Mark S. Edwards" <marke@muttsnuts.com>@ece.cmu.edu on 05/10/2002 10:38:07
AM

Sent by:    owner-ips@ece.cmu.edu


To:    John Hufferd/San Jose/IBM@IBMUS
cc:    <ips@ece.cmu.edu>
Subject:    Re: ISCSI: CmdSN in non-leading login



John,

If an initiator opens a new connection on a session and in the first login
request uses the current session CmdSN, the lifetime of that CmdSN
continues all the way through until the completion of the first
non-immediate command on that new connection.

This means that the initiator has to reserve the use of that CmdSN for the
first non-immediate command on that particular session.  That's stupid.

Especially bearing in mind that it could be pumping commands like crazy
down other open connections in the session.

There is also another side effect, if the login takes any length of time,
like computing a DH or having to make external calls to a Radius or a
Kerberos server, then because this CmdSN is outstanding, the other
connections in the session will block as soon as the command window is
filled.

The final sentence in 9.12.8 is meaningless for a non-leading
connection.  The target either has to block the whole session until the
login is completed, or run the risk of corrupting session state.

Mark

 
At 10:14 AM 5/10/2002 -0700, John Hufferd wrote:

>I do not see the issue, it works as is, it does not effect the first non
>immediate command unless it completes as a authorized connection. Again, I
>do not see the issue, in fact it works as is.
>
>.
>.
>.
>John L. Hufferd
>Senior Technical Staff Member (STSM)
>IBM/SSG San Jose Ca
>Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
>Home Office (408) 997-6136, Cell: (408) 499-9702
>Internet address: hufferd@us.ibm.com
>
>
>"Mark S. Edwards" <marke@muttsnuts.com>@ece.cmu.edu on 05/10/2002 09:47:53
>AM
>
>Sent by:    owner-ips@ece.cmu.edu
>
>
>To:    Bill Studenmund <wrstuden@wasabisystems.com>
>cc:    <ips@ece.cmu.edu>
>Subject:    Re: ISCSI: CmdSN in non-leading login
>
>
>
>At 09:13 AM 5/10/2002 -0700, Bill Studenmund wrote:
> >On Fri, 10 May 2002, Mark S. Edwards wrote:
> >
> > > There are a couple of problems here for the target.  At what point is
a
> > > non-leading connection considered to be part of the session ?  Is it
>the
> > > moment that the login request is received with a non-zero TSIH ?  Or
is
>it
> > > only when the non-leading login succeeds and it enters full feature
>phase ?
> >
> >I think the target shouldn't let anything from a new connection
influence
> >things until after at least the security phase has been passed.
Otherwise
> >we have a security hole. After operational negotiation would probably be
> >best.
>
>Good, as far as I can see, a new connection should not be allowed to
>influence any session context until the connection reached full-feature
>phase.  But this is a problem if we have to follow the CmdSN rules of
>9.12.8.   See next comment.
>
>
> > > So, should an initiator set the CmdSN in the first login request to
>zero
> > > and only synchronise with the session command stream after full
feature
> > > phase is established ?  This is my preferred option.
> > >
> > > What happens if the initiator tries using the current session command
> > > sequence number is that whilst the login negotiation occurs, other
> > > connections within the session can be issuing new commands, so by the
>time
> > > that the login is finished the CmdSN exchanged in the initial request
>is
> > > invalid anyway.
> > >
> > > I would like to see something along the lines that for a non-leading
> > > connection, the CmdSN field MUST be zero and that the connection can
>not be
> > > considered part of the session until full feature phase is entered,
at
> > > which point any commands issued on the connection are now
synchronised
>with
> > > the session command sequence number as observed by all other existing
> > > connections on the session.
> >
> >I thought login counted as a command, so it got its own command number,
in
> >the stream of all other commands. ??
>
>
>For a leading connection the CmdSN, whether zero or non-zero, is regarded
>as a primer with which to set the initial session command sequence number,
>all the login requests exchanged in the negotiation, no matter how many
>carry the same CmdSN as does the first non-immediate command.  In other
>words, the first pdu in a leading connection does influence session state.
>
>So if we agree that a non-leading connection can not influence session
>state until full-feature phase, then we have to also state that the rule
in
>9.12.8 about the first non-immediate command carrying the same CmdSN as
the
>initial login request can not work for a non-leading connection.  In this
>case, the first non-immediate command must be set from the next logical
>value in the session context.  I would like the spec to have this added
and
>to explicitly say that the CmdSN in a login request for a non-leading
>connection is ignored by the target.  I'd really prefer that the actual
>value be zero, but that's not necessary from a protocol perspective if the
>target ignores the field.
>
>Mark.




 





--=_alternative 00162FBFC2256BB7_=-- From owner-ips@ece.cmu.edu Sun May 12 02:17:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08072 for ; Sun, 12 May 2002 02:17:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4C5tCL25294 for ips-outgoing; Sun, 12 May 2002 01:55:12 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4C5t8w25282; Sun, 12 May 2002 01:55:08 -0400 (EDT) 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 g4C5t1Me032126; Sun, 12 May 2002 07:55:01 +0200 Received: from d10hubm1.telaviv.ibm.com (d10hubm1.telaviv.ibm.com [9.148.216.39]) by d12relay02.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4C5sx2136436; Sun, 12 May 2002 07:54:59 +0200 X-Priority: 1 (High) Importance: Normal Subject: Re: ISCSI: CmdSN in non-leading login To: "Julian Satran" Cc: "ips" , "\"\"Mark S. Edwards\" , "owner-ips" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Sat, 11 May 2002 22:53:15 -0700 X-MIMETrack: Serialize by Router on D10HUBM1/10/H/IBM(Release 5.0.9a |January 7, 2002) at 12/05/2002 08:54:59 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g4C5t9w25285 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julian, You need to make it clear that the Initiator CmdSN that follows the secondary connection Login, is the next CmdSN in the session. The current text make it sounds that the next non immediate command on the same connection as the secondary connection Login, must have the same CmdSN as that Login. And that is NOT the case. The problem words are "(e.g., if the leading login carries the CmdSN 123 all other Login requests carry the CmdSN 123 and the first non-immediate command also carries the CmdSN 123.)" If you don't like the other words I suggested before then at least change the statement to: "(e.g., if the leading login carries the CmdSN 123 all other Login requests carry the CmdSN 123 and the first non-immediate command in the session also carries the CmdSN 123.)" But I think my other words are better :-) . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Julian Satran@IBMIL 05/11/2002 09:02 PM To: John Hufferd/San Jose/IBM@IBMUS@IBMDE cc: ips@ece.cmu.edu, "Mark S. Edwards" , owner-ips@ece.cmu.edu From: Julian Satran/Haifa/IBM@IBMIL Subject: Re: ISCSI: CmdSN in non-leading login (Document link: John Hufferd) John, My only point was that there is enough information in the section to describe correct behavior. And immediate commands do not create any blockage regardless of their CmdSN. I am still trying to understand what your point was (is). Julo John Hufferd@IBMUS To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, "Mark S. Edwards" , 05/11/2002 10:25 owner-ips@ece.cmu.edu PM From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: ISCSI: CmdSN in non-leading login(Document link: Julian Satran - Mail) Julian, (watch out long note to follow) Sometimes our messages pass by each other in the night. I had corrected my note to indicate that I had overlooked the very obvious statement that we kept in the draft that the Login command was immediate. But the rest of the note I think is correct. That is, the command that follows the completion of the non leading-connection Login should take its CmdSN from the next command sequence number in the "Session" stream, not the CmdSN of the Login for that connection. Here is the thinking, 1. The second connection is started while commands are flowing on the Leading connection, 2. The CmdSN in the stream when the Login for the second connection is started is lets say 123. 3. Since the Login command is immediate, and does not change the ExpCmdSN then one of three things can happen a. Initiator uses the same CmdSN for the next command that it sends on the first connection, etc. (123, 124, 125, etc.) OR b. Initiator uses the next CmdSN 124 on the leading connection and thereby creates a delivery hole, for the target until the CmdSN 123 is finally received on the secondary connection and then all the commands 123----125, etc, are delivered c. No commands are sent on any connection until the Login of the secondary connection is completed and the next command is given the CmdSN of 123 4. If 3a is done, then the first command after the delivery will use the next CmdSN in the stream and no blockage would have occurred. 5. If 3b is done there will be a blockage of the delivery of commands until the secondary Login in completed 6. If 3c is done, then the first command after the delivery will use the same CmdSN (123) as the Login, but the commands will have a blockage at the initiator until the secondary Login is completed. So I believe, that IF the subsequent commands in a secondary connection has to have the same CmdSN as the Initial Login of that connection, either all commands in the entire session must stop being sent on other connections, or commands will not be delivered until the delivery hole is closed at the end of the secondary Login. If we were to handle the Login for secondary connections like other immediate commands, the 3a. path would be done (the ExpCmdSN would not be advanced, but other commands will continue and they will advance the ExpCmdSN as normal, and when the next non immediate command is sent on the same connection as the immediate command, it is simply given the very next CmdSN from the session stream. The problem of treating the secondary connection Login exactly like the leading Connection, when it comes to the next command, is that, unlike the leading connection, other things continue to move on the other connections. Therefore, in my opinion the correct way of interpreting the current wordage in 9.12.8 is at the point it says: "....and the first non-immediate command also carries the CmdSN 123.)" we should read that as "... the next non-immediate command IN THE SESSION also carries the CmdSN 123)". In this way the words mean the same for both the leading connection and secondary connection. This is how I believed the implementations have been built. Anyway, that was the essences of my words where I suggested: At the end of the first paragraph under 9.12.8, we should add, the words "Similar rules exist for the Leading Login for a non leading connection, that is, the next CmdSN value is used for the Leading Login of the non leading connection, and that same number is used with all the subsequent Login PDUs on that connection. But at completion of the Login of the connection, the ExpCmdSN is not advanced and the subsequent commands take the next CmdSN value in the session." Now perhaps we can have some better words, perhaps the words but clearly the current word have confused some folks. Perhaps even me :-) . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 05/11/2002 01:03:15 AM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu, "Mark S. Edwards" , owner-ips@ece.cmu.edu Subject: Re: ISCSI: CmdSN in non-leading login John, The current text starts by stating that login requests are immediate. It then states: CmdSN is either the initial command sequence number of a session (for the first Login request of a session - the "leading" login) or the command sequence number in the command stream (e.g., if the leading login carries the CmdSN 123 all other Login requests carry the CmdSN 123 and the first non-immediate command also carries the CmdSN 123). It has all the information needed. I am puzzled by your comments. Julo John Hufferd/San         To:        "Mark S. Edwards" Jose/IBM@IBMU S         cc:         Sent by:         Subject:        Re: ISCSI: CmdSN in owner-ips@ece non-leading login .cmu.edu 05/11/2002 03:38 AM Please respond to John Hufferd The text as it is written has not been updated since we at one point had the Login command marked as and Immediate command.  Therefore, it always had to pick up the next value that would be assigned to the next non immediate command.  Also since it was an immediate command the ExpCmdSN was not advanced so it did not effect the commands in the rest of the session. They would continue with the next CmdSN as usual.  Login is still not suppose to advance the ExpCmdSN, so there should still not be a problem. When we removed the flag that said that it was an immediate command, the wording in the draft about the Initial Login was not adjusted. I suggest that the only thing that needs to be changed is the following: At the end of the first paragraph under 9.12.8, we should add, the words "Similar rules exist for the Leading Login for a non leading connection, that is, the next CmdSN value is used for the Leading Login of the non leading connection, and that same number is used with all the subsequent Login PDUs on that connection. But at completion of the Login of the connection, the ExpCmdSN is not advanced and the subsequent commands take the next CmdSN value in the session." This is what we were all doing, and simply did not change anything with the Immediate bit was dropped from the Login PDU.  I suggest we leave it with that operational intent, since it was so long ago that we establish this way of operating I can not remember exactly why, but would not like to be surprised sometime in the future, and I do not see why we would have to change it. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Mark S. Edwards" @ece.cmu.edu on 05/10/2002 10:38:07 AM Sent by:    owner-ips@ece.cmu.edu To:    John Hufferd/San Jose/IBM@IBMUS cc:     Subject:    Re: ISCSI: CmdSN in non-leading login John, If an initiator opens a new connection on a session and in the first login request uses the current session CmdSN, the lifetime of that CmdSN continues all the way through until the completion of the first non-immediate command on that new connection. This means that the initiator has to reserve the use of that CmdSN for the first non-immediate command on that particular session.  That's stupid. Especially bearing in mind that it could be pumping commands like crazy down other open connections in the session. There is also another side effect, if the login takes any length of time, like computing a DH or having to make external calls to a Radius or a Kerberos server, then because this CmdSN is outstanding, the other connections in the session will block as soon as the command window is filled. The final sentence in 9.12.8 is meaningless for a non-leading connection.  The target either has to block the whole session until the login is completed, or run the risk of corrupting session state. Mark At 10:14 AM 5/10/2002 -0700, John Hufferd wrote: >I do not see the issue, it works as is, it does not effect the first non >immediate command unless it completes as a authorized connection. Again, I >do not see the issue, in fact it works as is. > >. >. >. >John L. Hufferd >Senior Technical Staff Member (STSM) >IBM/SSG San Jose Ca >Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688 >Home Office (408) 997-6136, Cell: (408) 499-9702 >Internet address: hufferd@us.ibm.com > > >"Mark S. Edwards" @ece.cmu.edu on 05/10/2002 09:47:53 >AM > >Sent by:    owner-ips@ece.cmu.edu > > >To:    Bill Studenmund >cc:     >Subject:    Re: ISCSI: CmdSN in non-leading login > > > >At 09:13 AM 5/10/2002 -0700, Bill Studenmund wrote: > >On Fri, 10 May 2002, Mark S. Edwards wrote: > > > > > There are a couple of problems here for the target.  At what point is a > > > non-leading connection considered to be part of the session ?  Is it >the > > > moment that the login request is received with a non-zero TSIH ?  Or is >it > > > only when the non-leading login succeeds and it enters full feature >phase ? > > > >I think the target shouldn't let anything from a new connection influence > >things until after at least the security phase has been passed. Otherwise > >we have a security hole. After operational negotiation would probably be > >best. > >Good, as far as I can see, a new connection should not be allowed to >influence any session context until the connection reached full-feature >phase.  But this is a problem if we have to follow the CmdSN rules of >9.12.8.   See next comment. > > > > > So, should an initiator set the CmdSN in the first login request to >zero > > > and only synchronise with the session command stream after full feature > > > phase is established ?  This is my preferred option. > > > > > > What happens if the initiator tries using the current session command > > > sequence number is that whilst the login negotiation occurs, other > > > connections within the session can be issuing new commands, so by the >time > > > that the login is finished the CmdSN exchanged in the initial request >is > > > invalid anyway. > > > > > > I would like to see something along the lines that for a non-leading > > > connection, the CmdSN field MUST be zero and that the connection can >not be > > > considered part of the session until full feature phase is entered, at > > > which point any commands issued on the connection are now synchronised >with > > > the session command sequence number as observed by all other existing > > > connections on the session. > > > >I thought login counted as a command, so it got its own command number, in > >the stream of all other commands. ?? > > >For a leading connection the CmdSN, whether zero or non-zero, is regarded >as a primer with which to set the initial session command sequence number, >all the login requests exchanged in the negotiation, no matter how many >carry the same CmdSN as does the first non-immediate command.  In other >words, the first pdu in a leading connection does influence session state. > >So if we agree that a non-leading connection can not influence session >state until full-feature phase, then we have to also state that the rule in >9.12.8 about the first non-immediate command carrying the same CmdSN as the >initial login request can not work for a non-leading connection.  In this >case, the first non-immediate command must be set from the next logical >value in the session context.  I would like the spec to have this added and >to explicitly say that the CmdSN in a login request for a non-leading >connection is ignored by the target.  I'd really prefer that the actual >value be zero, but that's not necessary from a protocol perspective if the >target ignores the field. > >Mark. From owner-ips@ece.cmu.edu Sun May 12 08:02:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13374 for ; Sun, 12 May 2002 08:02:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4CBOQJ20859 for ips-outgoing; Sun, 12 May 2002 07:24:26 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4CBONw20850; Sun, 12 May 2002 07:24:23 -0400 (EDT) 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 g4CBOHMe030066; Sun, 12 May 2002 13:24:17 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4CBOG229116; Sun, 12 May 2002 13:24:17 +0200 To: "John Hufferd" Cc: ips@ece.cmu.edu, "Mark S. Edwards" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: ISCSI: CmdSN in non-leading login X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 12 May 2002 14:24:14 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/05/2002 14:24:16, Serialize complete at 12/05/2002 14:24:16 Content-Type: multipart/alternative; boundary="=_alternative 003E4DAFC2256BB7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003E4DAFC2256BB7_= Content-Type: text/plain; charset="us-ascii" John, Here is the text I suggest for 9.12.8 CmdSN CmdSN is either the initial command sequence number of a session (for the first Login request of a session - the "leading" login) or the command sequence number in the command stream if the login is for a new connection in an existing session. Examples: - A leading login phase - if the leading login carries the CmdSN 123 all other login requests in the same login phase carry the CmdSN 123 and the first non-immediate command in FullFeaturePhase also carries the CmdSN 123. - A non-leading login phase - the current CmdSN at the time the first login on the connection is issued is 500 - the login request carries CmdSN=500 the second login request carries a CmdSN not lower than 500 (higher if non-immediate requests where issued in the session between the first and the second request in the new login phase) etc.. If the login request is a leading login request the target MUST use the value presented in CmdSN as the target value for ExpCmdSN. Regards, Julo --=_alternative 003E4DAFC2256BB7_= Content-Type: text/html; charset="us-ascii"
John,

Here is the text I suggest for 9.12.8

CmdSN

CmdSN is either the initial command sequence number of a session (for the first Login request of a session - the "leading" login) or the command sequence number in the command stream if the login is for a new connection in an existing session.

Examples:

- A leading login phase - if the leading login carries the CmdSN 123 all other login requests in the same login phase carry the CmdSN 123 and the first non-immediate command in FullFeaturePhase also carries the CmdSN 123.

- A non-leading login phase - the current CmdSN at the time the first login on the connection is issued is 500 - the login request carries CmdSN=500 the second login request carries a CmdSN not lower than 500 (higher if non-immediate requests where issued in the session between the first and the second request in the new login phase) etc..

If the login request is a leading login request the target MUST use the value presented in CmdSN as the target value for ExpCmdSN.

Regards,
Julo --=_alternative 003E4DAFC2256BB7_=-- From owner-ips@ece.cmu.edu Sun May 12 08:05:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13454 for ; Sun, 12 May 2002 08:05:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4CBwoC22299 for ips-outgoing; Sun, 12 May 2002 07:58:50 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4CBwlw22293; Sun, 12 May 2002 07:58:48 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4CBwfMe032512; Sun, 12 May 2002 13:58:41 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4CBweN49950; Sun, 12 May 2002 13:58:40 +0200 To: "John Hufferd" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, "Robert D. Russell" MIME-Version: 1.0 Subject: Re: iSCSI: NOP-In X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 12 May 2002 14:58:38 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/05/2002 14:58:40, Serialize complete at 12/05/2002 14:58:40 Content-Type: multipart/alternative; boundary="=_alternative 0040C9AFC2256BB7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0040C9AFC2256BB7_= Content-Type: text/plain; charset="us-ascii" John. Ping from target is prohibited from having data only if TTT is 0xfffffffff i.e., when no reply request is requested. Julo John Hufferd@IBMUS 05/10/2002 12:53 AM To: "Robert D. Russell" cc: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu, From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: iSCSI: NOP-In You may be correct, but I think we need to use the Ping word, so that it becomes obvious, as it does now, that Ping from Initiator can have data but ping from Target can not. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com --=_alternative 0040C9AFC2256BB7_= Content-Type: text/html; charset="us-ascii"
John.

Ping from target is prohibited from having data only if  TTT is 0xfffffffff i.e., when no reply request is requested.

Julo


John Hufferd@IBMUS

05/10/2002 12:53 AM


        To:        "Robert D. Russell" <rdr@io.iol.unh.edu>
        cc:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu, <owner-ips@ece.cmu.edu>
        From:        John Hufferd/San Jose/IBM@IBMUS
        Subject:        Re: iSCSI: NOP-InLink
 





You may be correct, but I think we need to use the Ping word, so that it becomes obvious, as it does now, that Ping from Initiator can have data but ping from Target can not.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com

--=_alternative 0040C9AFC2256BB7_=-- From owner-ips@ece.cmu.edu Sun May 12 14:27:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24008 for ; Sun, 12 May 2002 14:27:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4CHsRm09181 for ips-outgoing; Sun, 12 May 2002 13:54:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4CHsPw09173; Sun, 12 May 2002 13:54:25 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4CHsI9d044318; Sun, 12 May 2002 19:54:18 +0200 Received: from d10hubm1.telaviv.ibm.com (d10hubm1.telaviv.ibm.com [9.148.216.39]) by d12relay02.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4CHsG2124740; Sun, 12 May 2002 19:54:17 +0200 X-Priority: 1 (High) Importance: Normal Subject: Re: ISCSI: CmdSN in non-leading login To: "Julian Satran" Cc: "ips" , "\"\"Mark S. Edwards\" , "owner-ips" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Sun, 12 May 2002 10:52:45 -0700 X-MIMETrack: Serialize by Router on D10HUBM1/10/H/IBM(Release 5.0.9a |January 7, 2002) at 12/05/2002 20:54:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk That works for me. Thanks. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Julian Satran@IBMIL 05/12/2002 04:20 AM To: John Hufferd/San Jose/IBM@IBMUS@IBMDE cc: ips@ece.cmu.edu, "Mark S. Edwards" , owner-ips@ece.cmu.edu From: Julian Satran/Haifa/IBM@IBMIL Subject: Re: ISCSI: CmdSN in non-leading login (Document link: John Hufferd) John, Here is the text I suggest for 9.12.8 CmdSN CmdSN is either the initial command sequence number of a session (for the first Login request of a session - the "leading" login) or the command sequence number in the command stream if the login is for a new connection in an existing session. Examples: - A leading login phase - if the leading login carries the CmdSN 123 all other login requests in the same login phase carry the CmdSN 123 and the first non-immediate command in FullFeaturePhase also carries the CmdSN 123. - A non-leading login phase - the current CmdSN at the time the first login on the connection is issued is 500 - the login request carries CmdSN=500 the second login request carries a CmdSN not lower than 500 (higher if non-immediate requests where issued in the session between the first and the second request in the new login phase) etc.. If the login request is a leading login request the target MUST use the value presented in CmdSN as the target value for ExpCmdSN. Regards, Julo From owner-ips@ece.cmu.edu Sun May 12 15:50:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26742 for ; Sun, 12 May 2002 15:50:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4CJBiD13117 for ips-outgoing; Sun, 12 May 2002 15:11:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4CJBfw13109; Sun, 12 May 2002 15:11:41 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4CJBY9d031390; Sun, 12 May 2002 21:11:34 +0200 Received: from d10hubm1.telaviv.ibm.com (d10hubm1.telaviv.ibm.com [9.148.216.39]) by d12relay01.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4CJBXN73552; Sun, 12 May 2002 21:11:33 +0200 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: NOP-In To: "Julian Satran" Cc: "ips" , "owner-ips" , "\"\"Robert D. Russell\" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Sun, 12 May 2002 12:10:02 -0700 X-MIMETrack: Serialize by Router on D10HUBM1/10/H/IBM(Release 5.0.9a |January 7, 2002) at 12/05/2002 22:11:33 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, you are of course correct. My implied (though perhaps not so well written) point was that a ping INITIATED by the target, is also possible, but can not have data. And that the removal of the word "ping" would perhaps prevent that concept from being obvious. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Julian Satran@IBMIL 05/12/2002 04:47 AM To: John Hufferd/San Jose/IBM@IBMUS@IBMDE cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, "Robert D. Russell" From: Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI: NOP-In (Document link: John Hufferd) John. Ping from target is prohibited from having data only if TTT is 0xfffffffff i.e., when no reply request is requested. Julo John Hufferd@IBMUS To: "Robert D. Russell" cc: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu, 05/10/2002 12:53 AM From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: iSCSI: NOP-In(Document link: Julian Satran - Mail) You may be correct, but I think we need to use the Ping word, so that it becomes obvious, as it does now, that Ping from Initiator can have data but ping from Target can not. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Sun May 12 23:01:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13226 for ; Sun, 12 May 2002 23:01:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4D2LtK05454 for ips-outgoing; Sun, 12 May 2002 22:21:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4D0ffw00048; Sun, 12 May 2002 20:41:41 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Sun, 12 May 2002 20:41:41 -0400 Message-ID: <25369470B6F0D41194820002B328BDD22F5B6A@ATLOPS> From: Eddy Quicksall To: Julian Satran , John Hufferd Cc: ips@ece.cmu.edu, "Mark S. Edwards" , owner-ips@ece.cmu.edu Subject: RE: ISCSI: CmdSN in non-leading login Date: Sun, 12 May 2002 20:41:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FA16.EF620ED0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FA16.EF620ED0 Content-Type: text/plain; charset="iso-8859-1" Julian, I like your 1st paragraph but I think it so clear that the examples are not necessary. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, May 12, 2002 7:24 AM To: John Hufferd Cc: ips@ece.cmu.edu; Mark S. Edwards; owner-ips@ece.cmu.edu Subject: Re: ISCSI: CmdSN in non-leading login John, Here is the text I suggest for 9.12.8 CmdSN CmdSN is either the initial command sequence number of a session (for the first Login request of a session - the "leading" login) or the command sequence number in the command stream if the login is for a new connection in an existing session. Examples: - A leading login phase - if the leading login carries the CmdSN 123 all other login requests in the same login phase carry the CmdSN 123 and the first non-immediate command in FullFeaturePhase also carries the CmdSN 123. - A non-leading login phase - the current CmdSN at the time the first login on the connection is issued is 500 - the login request carries CmdSN=500 the second login request carries a CmdSN not lower than 500 (higher if non-immediate requests where issued in the session between the first and the second request in the new login phase) etc.. If the login request is a leading login request the target MUST use the value presented in CmdSN as the target value for ExpCmdSN. Regards, Julo ------_=_NextPart_001_01C1FA16.EF620ED0 Content-Type: text/html; charset="iso-8859-1"

Julian,
 
I like your 1st paragraph but I think it so clear that the examples are not necessary.
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, May 12, 2002 7:24 AM
To: John Hufferd
Cc: ips@ece.cmu.edu; Mark S. Edwards; owner-ips@ece.cmu.edu
Subject: Re: ISCSI: CmdSN in non-leading login


John,

Here is the text I suggest for 9.12.8

CmdSN

CmdSN is either the initial command sequence number of a session (for the first Login request of a session - the "leading" login) or the command sequence number in the command stream if the login is for a new connection in an existing session.

Examples:

- A leading login phase - if the leading login carries the CmdSN 123 all other login requests in the same login phase carry the CmdSN 123 and the first non-immediate command in FullFeaturePhase also carries the CmdSN 123.

- A non-leading login phase - the current CmdSN at the time the first login on the connection is issued is 500 - the login request carries CmdSN=500 the second login request carries a CmdSN not lower than 500 (higher if non-immediate requests where issued in the session between the first and the second request in the new login phase) etc..

If the login request is a leading login request the target MUST use the value presented in CmdSN as the target value for ExpCmdSN.

Regards,
Julo

------_=_NextPart_001_01C1FA16.EF620ED0-- From owner-ips@ece.cmu.edu Sun May 12 23:01:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13248 for ; Sun, 12 May 2002 23:01:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4D2LkX05434 for ips-outgoing; Sun, 12 May 2002 22:21:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4D0Saw29358; Sun, 12 May 2002 20:28:37 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Sun, 12 May 2002 20:28:21 -0400 Message-ID: <25369470B6F0D41194820002B328BDD22F5B69@ATLOPS> From: Eddy Quicksall To: John Hufferd , Julian Satran Cc: ips , owner-ips , "\"\"Robert D. Russell\" Subject: RE: iSCSI: NOP-In Date: Sun, 12 May 2002 20:28:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk BTW, What is the reason for a Target Ping not to carry any data? Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Sunday, May 12, 2002 3:10 PM To: Julian Satran Cc: ips; owner-ips; ""Robert D. Russell" From: Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI: NOP-In (Document link: John Hufferd) John. Ping from target is prohibited from having data only if TTT is 0xfffffffff i.e., when no reply request is requested. Julo John Hufferd@IBMUS To: "Robert D. Russell" cc: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu, 05/10/2002 12:53 AM From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: iSCSI: NOP-In(Document link: Julian Satran - Mail) You may be correct, but I think we need to use the Ping word, so that it becomes obvious, as it does now, that Ping from Initiator can have data but ping from Target can not. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon May 13 02:18:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28146 for ; Mon, 13 May 2002 02:17:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4D5gh816580 for ips-outgoing; Mon, 13 May 2002 01:42:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4D5ggw16576 for ; Mon, 13 May 2002 01:42:42 -0400 (EDT) Received: from bursar.muttsnuts.com (213.190.135.30) by mail.san.yahoo.com (6.5.017.1) id 3CDE2F5E00029169; Sun, 12 May 2002 22:42:09 -0700 Message-Id: <5.1.0.14.2.20020513064004.03957218@mail.muttsnuts.com> X-Sender: markemuttsnuts@mail.muttsnuts.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 13 May 2002 06:41:42 +0100 To: "Julian Satran" , "John Hufferd" From: "Mark S. Edwards" Subject: Re: ISCSI: CmdSN in non-leading login Cc: ips@ece.cmu.edu In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_732883==_.ALT" Sender: owner-ips@ece.cmu.edu Precedence: bulk --=====================_732883==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Julo, Seems to work well enough. Thanks, Mark. At 02:24 PM 5/12/2002 +0300, Julian Satran wrote: >John, > >Here is the text I suggest for 9.12.8 > >CmdSN > >CmdSN is either the initial command sequence number of a session (for the >first Login request of a session - the "leading" login) or the command >sequence number in the command stream if the login is for a new connection >in an existing session. > >Examples: > >- A leading login phase - if the leading login carries the CmdSN 123 all >other login requests in the same login phase carry the CmdSN 123 and the >first non-immediate command in FullFeaturePhase also carries the CmdSN 123. > >- A non-leading login phase - the current CmdSN at the time the first >login on the connection is issued is 500 - the login request carries >CmdSN=500 the second login request carries a CmdSN not lower than 500 >(higher if non-immediate requests where issued in the session between the >first and the second request in the new login phase) etc.. > >If the login request is a leading login request the target MUST use the >value presented in CmdSN as the target value for ExpCmdSN. > >Regards, >Julo --=====================_732883==_.ALT Content-Type: text/html; charset="us-ascii" Julo,

Seems to work well enough.

Thanks,

Mark.

At 02:24 PM 5/12/2002 +0300, Julian Satran wrote:

John,

Here is the text I suggest for 9.12.8

CmdSN

CmdSN is either the initial command sequence number of a session (for the first Login request of a session - the "leading" login) or the command sequence number in the command stream if the login is for a new connection in an existing session.

Examples:

- A leading login phase - if the leading login carries the CmdSN 123 all other login requests in the same login phase carry the CmdSN 123 and the first non-immediate command in FullFeaturePhase also carries the CmdSN 123.

- A non-leading login phase - the current CmdSN at the time the first login on the connection is issued is 500 - the login request carries CmdSN=500 the second login request carries a CmdSN not lower than 500 (higher if non-immediate requests where issued in the session between the first and the second request in the new login phase) etc..

If the login request is a leading login request the target MUST use the value presented in CmdSN as the target value for ExpCmdSN.

Regards,
Julo
--=====================_732883==_.ALT-- From owner-ips@ece.cmu.edu Mon May 13 02:18:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28168 for ; Mon, 13 May 2002 02:18:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4D5uY217237 for ips-outgoing; Mon, 13 May 2002 01:56:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4D5uWw17230; Mon, 13 May 2002 01:56:32 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4D5uP9d046212; Mon, 13 May 2002 07:56:25 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4D5uPL54562; Mon, 13 May 2002 07:56:25 +0200 To: Eddy Quicksall Cc: ips , John Hufferd , owner-ips MIME-Version: 1.0 Subject: RE: iSCSI: NOP-In X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 13 May 2002 08:56:23 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/05/2002 08:56:25, Serialize complete at 13/05/2002 08:56:25 Content-Type: multipart/alternative; boundary="=_alternative 00201847C2256BB8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00201847C2256BB8_= Content-Type: text/plain; charset="us-ascii" The implied use for data is to echo it. Julo Eddy Quicksall 05/13/2002 03:28 AM Please respond to Eddy Quicksall To: John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL cc: ips , owner-ips , "\"\"Robert D. Russell\" From: Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI: NOP-In (Document link: John Hufferd) John. Ping from target is prohibited from having data only if TTT is 0xfffffffff i.e., when no reply request is requested. Julo John Hufferd@IBMUS To: "Robert D. Russell" cc: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu, 05/10/2002 12:53 AM From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: iSCSI: NOP-In(Document link: Julian Satran - Mail) You may be correct, but I think we need to use the Ping word, so that it becomes obvious, as it does now, that Ping from Initiator can have data but ping from Target can not. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com --=_alternative 00201847C2256BB8_= Content-Type: text/html; charset="us-ascii"
The implied use for data is to echo it. Julo


Eddy Quicksall <eddyq@ivivity.com>

05/13/2002 03:28 AM
Please respond to Eddy Quicksall

       
        To:        John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL
        cc:        ips <ips@ece.cmu.edu>, owner-ips <owner-ips@ece.cmu.edu>, "\"\"Robert D. Russell\" <rdr\""
        Subject:        RE: iSCSI: NOP-In

       


BTW, What is the reason for a Target Ping not to carry any data?

Eddy

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Sunday, May 12, 2002 3:10 PM
To: Julian Satran
Cc: ips; owner-ips; ""Robert D. Russell" <rdr"
Subject: Re: iSCSI: NOP-In



Julian,
you are of course correct.  My implied (though perhaps not so well written)
point was that a ping INITIATED by the target, is also possible, but can
not have data.  And that the removal of the word "ping" would perhaps
prevent that concept from being obvious.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


Julian Satran@IBMIL
05/12/2002 04:47 AM

To:    John Hufferd/San Jose/IBM@IBMUS@IBMDE
cc:    ips@ece.cmu.edu, owner-ips@ece.cmu.edu, "Robert D. Russell"
      <rdr@io.iol.unh.edu>
From:  Julian Satran/Haifa/IBM@IBMIL
Subject:    Re: iSCSI: NOP-In  (Document link: John Hufferd)

John.

Ping from target is prohibited from having data only if  TTT is 0xfffffffff
i.e., when no reply request is requested.

Julo




                     John

                     Hufferd@IBMUS            To:      "Robert D. Russell"
<rdr@io.iol.unh.edu>                              
                                              cc:      Julian
Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu,                      
                     05/10/2002 12:53         <owner-ips@ece.cmu.edu>

                     AM                       From:    John Hufferd/San
Jose/IBM@IBMUS                                      
                                              Subject: Re: iSCSI:
NOP-In(Document link: Julian Satran - Mail)                















You may be correct, but I think we need to use the Ping word, so that it
becomes obvious, as it does now, that Ping from Initiator can have data but
ping from Target can not.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com

--=_alternative 00201847C2256BB8_=-- From owner-ips@ece.cmu.edu Mon May 13 09:23:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08860 for ; Mon, 13 May 2002 09:23:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DCnne18736 for ips-outgoing; Mon, 13 May 2002 08:49:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DCnkw18719 for ; Mon, 13 May 2002 08:49:46 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4DCndV8041678 for ; Mon, 13 May 2002 14:49:39 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4DCncL71856 for ; Mon, 13 May 2002 14:49:39 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - started countdown to 13 (12-90) X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 13 May 2002 15:49:36 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/05/2002 15:49:38, Serialize complete at 13/05/2002 15:49:38 Content-Type: multipart/alternative; boundary="=_alternative 0045F78AC2256BB8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0045F78AC2256BB8_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, I've put on my site (http://www.haifa.il.ibm.com/satran/ips) a "working" version of the draft labeled 12-90. Only the pdf version (with change bars vs. 12) is available. It contains only one minor change vs. 12 - decimal encoding is limited to 64 bit integers. Open: Security - what is the MUST in-band authentication We have an open request to change the function(reason) field position in the Logout request for which we have the requester and myself supporting it (it is benign and brings more order) and one vocal opponent. Unless I hear otherwise from you I will make the change. The draft includes all the editorial changes collected during our "mockup" last-call. Julo --=_alternative 0045F78AC2256BB8_= Content-Type: text/html; charset="us-ascii"



Dear colleagues,

I've put on my site (http://www.haifa.il.ibm.com/satran/ips) a "working" version of the draft labeled 12-90.
Only the pdf version (with change bars vs. 12) is available.
It contains only one minor change vs. 12 - decimal encoding is limited to 64 bit integers.

Open:

Security - what is the MUST in-band authentication

We have an open request to change the function(reason) field position in the Logout request for which we have the requester and myself supporting it (it is benign and brings more order) and one vocal opponent. Unless I hear otherwise from you I will make the change.

The draft includes all the editorial changes collected during our "mockup" last-call.

Julo















--=_alternative 0045F78AC2256BB8_=-- From owner-ips@ece.cmu.edu Mon May 13 09:23:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08883 for ; Mon, 13 May 2002 09:23:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DCnnk18735 for ips-outgoing; Mon, 13 May 2002 08:49:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DCnkw18720 for ; Mon, 13 May 2002 08:49:46 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4DCncIw040392 for ; Mon, 13 May 2002 14:49:38 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4DCnc140926 for ; Mon, 13 May 2002 14:49:38 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - started countdown to 13 (12-90) X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 13 May 2002 15:49:36 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/05/2002 15:49:38, Serialize complete at 13/05/2002 15:49:38 Content-Type: multipart/alternative; boundary="=_alternative 0045D412C2256BB8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0045D412C2256BB8_= Content-Type: text/plain; charset="us-ascii" ----- Forwarded by Julian Satran/Haifa/IBM on 05/13/2002 03:34 PM ----- Julian Satran 04/10/2002 08:34 PM To: ips@ece.cmu.edu cc: From: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI - started countdown to 12 (11-94) Dear colleagues, I've put on my site (http://www.haifa.il.ibm.com/satran/ips) a "working" version of the draft labeled 12-90. Only the pdf version (with change bars vs. 12) is available. It contains only one minor change vs. 12 - decimal encoding is limited to 64 bit integers. Open: Security - what is the MUST in-band authentication We have an open request to change the function(reason) field position in the Logout request for which we have the requester and myself supporting it (it is benign and brings more order) and one vocal opponent. Unless I hear otherwise from you I will make the change. The draft includes all the editorial changes collected during our "mockup" last-call. Julo --=_alternative 0045D412C2256BB8_= Content-Type: text/html; charset="us-ascii"
----- Forwarded by Julian Satran/Haifa/IBM on 05/13/2002 03:34 PM -----
Julian Satran

04/10/2002 08:34 PM

       
        To:        ips@ece.cmu.edu
        cc:        
        From:        Julian Satran/Haifa/IBM@IBMIL
        Subject:        iSCSI - started countdown to 12 (11-94)

       




Dear colleagues,

I've put on my site (http://www.haifa.il.ibm.com/satran/ips) a "working" version of the draft labeled 12-90.
Only the pdf version (with change bars vs. 12) is available.
It contains only one minor change vs. 12 - decimal encoding is limited to 64 bit integers.

Open:

Security - what is the MUST in-band authentication

We have an open request to change the function(reason) field position in the Logout request for which we have the requester and myself supporting it (it is benign and brings more order) and one vocal opponent. Unless I hear otherwise from you I will make the change.

The draft includes all the editorial changes collected during our "mockup" last-call.

Julo













--=_alternative 0045D412C2256BB8_=-- From owner-ips@ece.cmu.edu Mon May 13 12:09:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17813 for ; Mon, 13 May 2002 12:09:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DFOKR01247 for ips-outgoing; Mon, 13 May 2002 11:24:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DFOFw01240; Mon, 13 May 2002 11:24:15 -0400 (EDT) Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel11.hp.com (Postfix) with ESMTP id 264E36004AD; Mon, 13 May 2002 08:24:10 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 1DA37E00091; Mon, 13 May 2002 08:24:10 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 08:24:09 -0700 Message-ID: <499DC368E25AD411B3F100902740AD6510075380@xrose03.rose.hp.com> From: "BARRY,BOB (HP-Roseville,ex1)" To: Julian Satran Cc: "'ips@ece.cmu.edu'" , owner-ips@ece.cmu.edu Subject: RE: Comments on v12 of iSCSI Specification Date: Mon, 13 May 2002 08:24:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1FA92.357F50F0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1FA92.357F50F0 Content-Type: text/plain; charset="iso-8859-1" My comments are in line. Bob Barry > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Sunday, May 05, 2002 12:33 PM > To: BARRY,BOB (HP-Roseville,ex1) > Cc: 'ips@ece.cmu.edu'; owner-ips@ece.cmu.edu > Subject: Re: Comments on v12 of iSCSI Specification > > > > Thanks for tanking your time to do such a thorough review. > > my comments in text -Thanks again - Julo > > The following comments are submitted against the April 17, 2002, > draft-ietf-ips-iSCSI-12.txt. > > Bob Barry > ==================================================== > > General Comments > 1) An acronym section would make it easier to read > this document. Acronyms such as SW for session > wide, IO for initialize-only, and others are not > immediately obvious. > +++ If you volunteer to do it, I will volunteer to review it > and add it > with proper acknowledgements +++ > An acronym section is attached. This is the list of acronyms that I found in v12 of the spec. A special thanks to Michael Fischer of Adaptec for the starting list. > 4) Each table should be numbered and titled. Currently, > there is no way to reference an individual table, accept > a page number which may change over revisions. > > +++ All references - are made with a tool that takes care of it. I am thinking about references to tables in the spec by developers/users. It would help if the table had numbers or titles. > > > 3) p 31: second paragraph, sixth line, how the > parathesized example applies to the preceding > sentence is not immediately obvous. > +++ wht do you suggest? +++ I spoke with Mallikarjun about this and he has some ideas. > > 6) p 36: third paragraph, third line: the sentence ends > right in the middle; need to complete the thought. > +++ I can't locate it - context would help ++ Sorry, I meant second paragraph, third line: "is negotiated at login as the. A target . . ." > 15) p 118: section 9 - why are some bits marked as reserved > and some marked as '0' or '1' in the PDU definitions. If > the bits marked as '0' or '1' in the PDUs will > never change, > then this needs to be stated. In other words, there are > not treated the same as reserved bits. > > +++ ??? +++ Some bits in the PDUs are explicitly defined to be '1' or '0'. In the wording, some fields are declared as reserved (or '.'), which must have a value of '0'. It is my understanding that the reserved bits could change in the future, but that bits explicitly defined to be '0' or '1' cannot change. Is this true? If true, then why won't the defined bits change? ------_=_NextPart_000_01C1FA92.357F50F0 Content-Type: application/msword; name="Acronym.doc" Content-Disposition: attachment; filename="Acronym.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJwAAAAAAAAAA EAAAKQAAAAEAAAD+////AAAAACYAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAayAJBAAA8BK/AAAAAAAAEAAAAAAABAAAiA0AAA4AYmpiah+uH64AAAAAAAAAAAAAAAAAAAAA AAAJBBYAJRoAAH3EAAB9xAAAiAkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAKAAAAAAAAAAoAAAAKAA AAAAAAAAoAAAAAAAAACgAAAAAAAAAKAAAAAAAAAAoAAAABQAAAAAAAAAAAAAALQAAAAAAAAAHAgA AAAAAAAcCAAAAAAAABwIAAAAAAAAHAgAAAwAAAAoCAAAJAAAALQAAAAAAAAAywsAAPYAAABYCAAA AAAAAFgIAAAAAAAAWAgAAAAAAABYCAAAAAAAAFgIAAAAAAAAWAgAAAAAAABYCAAAAAAAAFgIAAAA AAAAbgsAAAIAAABwCwAAAAAAAHALAAAAAAAAcAsAAAAAAABwCwAAAAAAAHALAAAAAAAAcAsAAAAA AADBDAAAIAIAAOEOAACCAAAAcAsAABUAAAAAAAAAAAAAAAAAAAAAAAAAoAAAAAAAAABYCAAAAAAA AAAAAAAAAAAAAAAAAAAAAABYCAAAAAAAAFgIAAAAAAAAWAgAAAAAAABYCAAAAAAAAHALAAAAAAAA hAgAAAAAAACgAAAAAAAAAKAAAAAAAAAAWAgAAAAAAAAAAAAAAAAAAFgIAAAAAAAAhQsAABYAAACE CAAAAAAAAIQIAAAAAAAAhAgAAAAAAABYCAAAFgAAAKAAAAAAAAAAWAgAAAAAAACgAAAAAAAAAFgI AAAAAAAAbgsAAAAAAAAAAAAAAAAAAIQIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAWAgAAAAAAABuCwAAAAAAAIQIAADqAgAAhAgAAAAAAAAAAAAA AAAAAG4LAAAAAAAAoAAAAAAAAACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbgsAAAAAAABYCAAAAAAAAEwIAAAMAAAAgM5rmzz6 wQG0AAAAaAcAABwIAAAAAAAAbggAABYAAABuCwAAAAAAAAAAAAAAAAAAbgsAAAAAAACbCwAAMAAA AMsLAAAAAAAAbgsAAAAAAABjDwAAAAAAAIQIAAAAAAAAYw8AAAAAAABuCwAAAAAAAIQIAAAAAAAA tAAAAAAAAAC0AAAAAAAAAKAAAAAAAAAAoAAAAAAAAACgAAAAAAAAAKAAAAAAAAAAAgDZAAAAQWNy b255bQlEZWZpbml0aW9uDS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDTNERVMJVHJpcGxlIERhdGEgRW5jcnlwdGlv biBTdGFuZGFyZA1BQ0EJQXV0byBDb250aW5nZW50IEFsbGVnaWFuY2UNQUVOCUFzeW5jaHJvbm91 cyBFdmVudCBOb3RpZmljYXRpb24NQUVTCUFkdmFuY2VkIEVuY3J5cHRpb24gU3RhbmRhcmQNQUgJ QWRkaXRpb25hbCBIZWFkZXINQUhTCUFkZGl0aW9uYWwgSGVhZGVyIFNlZ21lbnQNQVBJCUFwcGxp Y2F0aW9uIFByb2dyYW1taW5nIEludGVyZmFjZQ1BU0MJQWRkaXRpb25hbCBTZW5zZSBDb2RlDUFT Q0lJCUFtZXJpY2FuIFN0YW5kYXJkIENvZGUgZm9yIEluZm9ybWF0aW9uIEludGVyY2hhbmdlICg4 LWJpdCBjaGFyYWN0ZXIgc2V0KQ1BU0NRCUFkZGl0aW9uYWwgU2Vuc2UgQ29kZSBRdWFsaWZpZXIN QkhTCUJhc2ljIEhlYWRlciBTZWdtZW50DUNCQwlDaXBoZXIgQmxvY2sgQ2hhaW5pbmcNQ0RCCUNv bW1hbmQgRGVzY3JpcHRvciBCbG9jaw1DSEFQCUNoYWxsZW5nZSBIYW5kc2hha2UgQXV0aGVudGlj YXRpb24gUHJvdG9jb2wNQ0lECUNvbm5lY3Rpb24gSUQNQ08JQ29ubmVjdGlvbiBPbmx5DUNSQwlD eWNsaWMgUmVkdW5kYW5jeSBDaGVjaw1DUkwJQ2VydGlmaWNhdGUgUmV2b2NhdGlvbiBMaXN0DUNT RwlDdXJyZW50IFN0YWdlDUNTTQlDb25uZWN0aW9uIFN0YXRlIE1hY2hpbmUNREVTCURhdGEgRW5j cnlwdGlvbiBTdGFuZGFyZA1ETlMJRG9tYWluIE5hbWUgU2VydmVyDURPSQlEb21haW4gb2YgSW50 ZXJwcmV0YXRpb24NRVNQCUVuY2Fwc3VsYXRpbmcgU2VjdXJpdHkgUGF5bG9hZA1FVUkJRXh0ZW5k ZWQgVW5pcXVlIElkZW50aWZpZXINRkZQCUZ1bGwgRmVhdHVyZSBQaGFzZQ1GRlBPCUZ1bGwgRmVh dHVyZSBQaGFzZSBPbmx5DUdicHMJR2lnYUJpdHMgcGVyIFNlY29uZA1IQkEJSG9zdCBCdXMgQWRh cHRlcg1ITUFDCUhhc2hlZCBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIA1JQU5BCUludGVybmV0IEFz c2lnbmVkIE51bWJlcnMgQXV0aG9yaXR5DUlECUlkZW50aWZpZXINSUROCUludGVybmF0aW9uYWxp emVkIERvbWFpbiBOYW1lDUlFRUUJSW5zdGl0dXRlIG9mIEVsZWN0cmljYWwgJiBFbGVjdHJvbmlj cyBFbmdpbmVlcnMNSUVURglJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlDUlLRQlJbnRl cm5ldCBLZXkgRXhjaGFuZ2UNSS9PCUlucHV0IC0gT3V0cHV0DUlPCUluaXRpYWxpemUgT25seQ1J UAlJbnRlcm5ldCBQcm90b2NvbA1JUHNlYwlJbnRlcm5ldCBQcm90b2NvbCBTZWN1cml0eQ1JUHY0 CUludGVybmV0IFByb3RvY29sIFZlcnNpb24gNA1JUHY2CUludGVybmV0IFByb3RvY29sIFZlcnNp b24gNg1JUU4JaVNDU0kgUXVhbGlmaWVkIE5hbWUNSVNDU0kJU0NTSSBvdmVyIElQDUlTSUQJSW5p dGlhdG9yIFNlc3Npb24gSUQNSVROCUluaXRpYXRvciBUYXNrIE5hbWUNSVRUCUluaXRpYXRvciBU YXNrIFRhZw1LUkI1CUtlcmJlcm9zIFY1DUxGTAlMb3dlciBGdW5jdGlvbmFsIExheWVyDUxPCUxl YWRpbmcgT25seQ1MVQlMb2dpY2FsIFVuaXQNTFVOCUxvZ2ljYWwgVW5pdCBOdW1iZXINTUFDCU1l c3NhZ2UgQXV0aGVudGljYXRpb24gQ29kZXMNTkEJTm90IEFwcGxpY2FibGUNTklDCU5ldHdvcmsg SW50ZXJmYWNlIENhcmQNTk9QCU5vIE9wZXJhdGlvbg1OU0cJTmV4dCBTdGFnZQ1PUwlPcGVyYXRp bmcgU3lzdGVtDVBEVQlQcm90b2NvbCBEYXRhIFVuaXQNUEtJCVB1YmxpYyBLZXkgSW5mcmFzdHJ1 Y3R1cmUNUjJUCVJlYWR5IFRvIFRyYW5zZmVyDVIyVFNOCVJlYWR5IFRvIFRyYW5zZmVyIFNlcXVl bmNlIE51bWJlcg1SRE1BCVJlbW90ZSBEaXJlY3QgTWVtb3J5IEFjY2Vzcw1TQU0JU0NTSSBBcmNo aXRlY3R1cmFsIE1vZGVsDVNBTTIJU0NTSSBBcmNoaXRlY3R1cmFsIE1vZGVsIC0gMg1TQU4JU3Rv cmFnZSBBcmVhIE5ldHdvcmsNU0NTSQlTbWFsbCBDb21wdXRlciBTeXN0ZW1zIEludGVyZmFjZQ1T TglTZXF1ZW5jZSBOdW1iZXINU05BQ0sJU2VxdWVuY2UgTnVtYmVyIEFja25vd2xlZGdtZW50DVNQ S00JU2ltcGxlIFB1YmxpYy1LZXkgTWVjaGFuaXNtDVNSUAlTZWN1cmUgUmVtb3RlIFBhc3N3b3Jk DVNTSUQJU2Vzc2lvbiBJRA1TVwlTZXNzaW9uIFdpZGUgb3IgU29mdHdhcmUNVENCCVRhc2sgQ29u dHJvbCBCbG9jaw1UQ1AJVHJhbnNtaXNzaW9uIENvbnRyb2wgUHJvdG9jb2wNVFBHVAlUYXJnZXQg UG9ydGFsIEdyb3VwIFRhZw1UU0lICVRhcmdldCBTZXNzaW9uIElkZW50aWZ5aW5nIEhhbmRsZQ1U VFQJVGFyZ2V0IFRyYW5zZmVyIFRhc2sNVUZMCVVwcGVyIEZ1bmN0aW9uYWwgTGF5ZXINVUxQCVVw cGVyIExldmVsIFByb3RvY29sDVVSTglVbmlmb3JtIFJlc291cmNlIE5hbWVzDVVURglVbml2ZXJz YWwgVHJhbnNmb3JtYXRpb24gRm9ybWF0DVdHCVdvcmtpbmcgR3JvdXANDQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAACIDQAA +QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxPSgMAUUoDAF5KAwABAAQAABMEAABb BAAAgAQAAJ8EAADDBAAA5AQAAPkEAAAXBQAAPQUAAFcFAACmBQAAywUAAOQFAAD+BQAAGwYAAEwG AABeBgAAcQYAAI0GAACtBgAAvwYAANwGAAD5BgAAEAcAAC0HAABQBwAAbwcAAPEAAAAAAAAAAAAA AADrAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAA AAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAA AAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA 8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAA AAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAA AAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAAAA AAAAAAAGAAA3JAA4JABIJAAOAAAPhHAIEYSQ9zckADgkAEgkAF6EcAhghJD3ABsABAAAiA0AAP4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEBAW8HAACGBwAAowcA ALwHAADRBwAA9QcAAB4IAAAsCAAATggAAIMIAACoCAAAwggAANUIAADoCAAA/QgAAB4JAAA/CQAA YAkAAHkJAACMCQAApgkAAL4JAADVCQAA5gkAAAEKAAARCgAAIQoAADkKAABaCgAA8QAAAAAAAAAA AAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADx AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAA AAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAA AADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAA AAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAA AAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA 8QAAAAAAAAAAAAAAAAAADgAAD4RwCBGEkPc3JAA4JABIJABehHAIYISQ9wAcWgoAAGwKAACHCgAA mAoAAKcKAAC7CgAA0goAAPAKAAAGCwAALgsAAE8LAABsCwAAjgsAAKcLAADNCwAA4AsAAAUMAAAm DAAAQQwAAFEMAABtDAAAhAwAAKYMAADDDAAA6gwAAAMNAAAeDQAANw0AAFINAADxAAAAAAAAAAAA AAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEA AAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAA AAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAA APEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAA AAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAA AAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADx AAAAAAAAAAAAAAAAAAAOAAAPhHAIEYSQ9zckADgkAEgkAF6EcAhghJD3ABxSDQAAdg0AAIcNAACI DQAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA4AAA+EcAgRhJD3NyQAOCQASCQAXoRwCGCEkPcAAyMAEjAAHFABAB+w0C8g sOA9IbAIByKwCAcjkKAFJJCgBSWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAPAAoAAQBpAA8AAwAA AAAAAAAAADAAAEDx/wIAMAAMAAYATgBvAHIAbQBhAGwAAAACAAAAEABfSAEEbUgJBHNICQR0SAkE AAAAAAAAAAAAAAAAAAAAAAAAPABBQPL/oQA8AAwAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBn AHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAAAAAAACICQAABQAAGgAABwD/////AAAAABMA AABbAAAAgAAAAJ8AAADDAAAA5AAAAPkAAAAXAQAAPQEAAFcBAACmAQAAywEAAOQBAAD+AQAAGwIA AEwCAABeAgAAcQIAAI0CAACtAgAAvwIAANwCAAD5AgAAEAMAAC0DAABQAwAAbwMAAIYDAACjAwAA vAMAANEDAAD1AwAAHgQAACwEAABOBAAAgwQAAKgEAADCBAAA1QQAAOgEAAD9BAAAHgUAAD8FAABg BQAAeQUAAIwFAACmBQAAvgUAANUFAADmBQAAAQYAABEGAAAhBgAAOQYAAFoGAABsBgAAhwYAAJgG AACnBgAAuwYAANIGAADwBgAABgcAAC4HAABPBwAAbAcAAI4HAACnBwAAzQcAAOAHAAAFCAAAJggA AEEIAABRCAAAbQgAAIQIAACmCAAAwwgAAOoIAAADCQAAHgkAADcJAABSCQAAdgkAAIcJAACKCQAA mAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAA AAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAA AAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAA AIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAA AACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACA mAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAA AAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAA AAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAA AIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAA AACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACA mAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAA AAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAA AAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAA AIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAA AACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACA mAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAA AAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAA AAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAA AIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAA AACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACA mAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAA AAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAA AAAAAIAAAACAAAQAAIgNAAAHAAAAAAQAAG8HAABaCgAAUg0AAIgNAAAIAAAACgAAAAsAAAAMAAAA AAQAAIgNAAAJAAAAAAAAAPUDAAD5AwAAigkAAAcABAAHAAAAAAD1AwAAHQQAAIoJAAAHAAQABwD/ /w4AAAAJAGIAbwBiAF8AYgBhAHIAcgB5ADIAQwA6AFwAZABhAHQAYQBcAG0AcwBcAHcAbwByAGQA XABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABEAG8AYwB1AG0AZQBu AHQAMwAuAGEAcwBkAAkAYgBvAGIAXwBiAGEAcgByAHkAIQBDADoAXABEAEEAVABBAFwATQBTAFwA dwBvAHIAZABcAGkAUwBDAFMASQBcAEEAYwByAG8AbgB5AG0ALgBkAG8AYwAJAGIAbwBiAF8AYgBh AHIAcgB5ADAAQwA6AFwAZABhAHQAYQBcAG0AcwBcAHcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8A dgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABBAGMAcgBvAG4AeQBtAC4AYQBzAGQACQBiAG8AYgBf AGIAYQByAHIAeQAwAEMAOgBcAGQAYQB0AGEAXABtAHMAXAB3AG8AcgBkAFwAQQB1AHQAbwBSAGUA YwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAAQQBjAHIAbwBuAHkAbQAuAGEAcwBkAAkAYgBv AGIAXwBiAGEAcgByAHkAMABDADoAXABkAGEAdABhAFwAbQBzAFwAdwBvAHIAZABcAEEAdQB0AG8A UgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAEEAYwByAG8AbgB5AG0ALgBhAHMAZAAJ AGIAbwBiAF8AYgBhAHIAcgB5ACEAQwA6AFwARABBAFQAQQBcAE0AUwBcAHcAbwByAGQAXABpAFMA QwBTAEkAXABBAGMAcgBvAG4AeQBtAC4AZABvAGMACQBiAG8AYgBfAGIAYQByAHIAeQAhAEMAOgBc AEQAQQBUAEEAXABNAFMAXAB3AG8AcgBkAFwAaQBTAEMAUwBJAFwAQQBjAHIAbwBuAHkAbQAuAGQA bwBjAP9AAhAAAAAAAAAAiAkAAFAAAAgAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAA AAAAAAAAAAD//wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAQAAABHFpABAAACAgYDBQQF AgMEhzoAAAAAAAAAAAAAAAAAAP8AAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4A AAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAz JpABAAACCwYEAgICAgIEhzoAAAAAAAAAAAAAAAAAAP8AAAAAAAAAQQByAGkAYQBsAAAAPzWQAQAA AgcDCQICBQIEBIc6AAAAAAAAAAAAAAAAAAD/AAAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAA ACIABADxCIgYAPDQAgAAaAEAAAAANltlxotlZQYAAAAAAwCzAAAAYAEAANwHAAABAAQAAAAEAAMQ EAAAAAAAAAAAAAAAAQABAAAAAQAAAAAAAAAkAwDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAClBsAHtAC0AIAAcjAAABAAGQBkAAAAGQAAAKYJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAygxEA8BAA 3wMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAAGgBBAGMAcgBvAG4AeQBt ACAAIAAgACAAIAAgACAAIAAgAEQAZQBmAGkAbgBpAHQAaQBvAG4AAAAAAAAACQBiAG8AYgBfAGIA YQByAHIAeQAJAGIAbwBiAF8AYgBhAHIAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAECgIAAAAAAAAAAAAAAAAAAAAA AAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAIgBAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAAC8AAAA BAAAAMgAAAAFAAAA3AAAAAYAAADoAAAABwAAAPQAAAAIAAAACAEAAAkAAAAcAQAAEgAAACgBAAAK AAAARAEAAAwAAABQAQAADQAAAFwBAAAOAAAAaAEAAA8AAABwAQAAEAAAAHgBAAATAAAAgAEAAAIA AADkBAAAHgAAABsAAABBY3JvbnltICAgICAgICAgRGVmaW5pdGlvbgAAHgAAAAEAAAAAY3JvHgAA AAoAAABib2JfYmFycnkAICAeAAAAAQAAAABvYl8eAAAAAQAAAABvYl8eAAAACwAAAE5vcm1hbC5k b3QAIB4AAAAKAAAAYm9iX2JhcnJ5AAAgHgAAAAIAAAAzAGJfHgAAABMAAABNaWNyb3NvZnQgV29y ZCA5LjAAaUAAAAAA8okBGQAAAEAAAAAAfNyXJfnBAUAAAAAAiiWSPPrBAQMAAAABAAAAAwAAAGAB AAADAAAA3AcAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN 1ZwuGxCTlwgAKyz5rjAAAAAQAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAiAAAAAYAAACQAAAA EQAAAJgAAAAXAAAAoAAAAAsAAACoAAAAEAAAALAAAAATAAAAuAAAABYAAADAAAAADQAAAMgAAAAM AAAA7wAAAAIAAADkBAAAHgAAABAAAABIZXdsZXR0LVBhY2thcmQAAwAAABAAAAADAAAABAAAAAMA AACmCQAAAwAAADIRCQALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAGwAA AEFjcm9ueW0gICAgICAgICBEZWZpbml0aW9uAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAA AAsAAAAMAAAADQAAAP7///8PAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAA/v///xcAAAAYAAAA GQAAABoAAAAbAAAAHAAAAB0AAAD+////HwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAAP7////9 ////KAAAAP7////+/////v////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYA AAAAAAAAAAAAAACAOISbPPrBASoAAACAAAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIA////////////////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAAAQAAAAAAAAVwBvAHIAZABEAG8A YwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEF AAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJRoAAAAA AAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAKAACAQIAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABYAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwBy AG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAHgAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgEBAAAABgAAAP////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAABPAGIAagBlAGMAdABQ AG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgABAP// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAgDiEmzz6wQGAOISbPPrBAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQAAAP7///////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBX b3JkIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA== ------_=_NextPart_000_01C1FA92.357F50F0-- From owner-ips@ece.cmu.edu Mon May 13 12:58:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19804 for ; Mon, 13 May 2002 12:58:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DGH6u05628 for ips-outgoing; Mon, 13 May 2002 12:17:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DGH4w05623 for ; Mon, 13 May 2002 12:17:04 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4DGGuAH109352; Mon, 13 May 2002 12:16:56 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4DGGuH27640; Mon, 13 May 2002 10:16:56 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: NOP-In To: Eddy Quicksall Cc: ips X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Mon, 13 May 2002 09:15:26 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/13/2002 10:16:55 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g4DGH4w05625 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Eddy, et.al. Initiators can not originate a ping with data. But it can echo a ping with data. That is, it can reflect back to the initiator, via a NOP-In, the data that was sent to it within a NOP-Out from the initiator. However, the target may not originate a ping via a NOP-In and include Data. This was done, if I remember the history correctly, because initiators are never prepared to accept unsolicited data of any kind. They always solicit data if they are to receive it. Hence, an unsolicited NOP-In with data, seemed to some to be problematical, and that capability was removed. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Eddy Quicksall on 05/13/2002 05:21:11 AM To: Julian Satran/Haifa/IBM@IBMIL cc: ips , John Hufferd/San Jose/IBM@IBMUS Subject: RE: iSCSI: NOP-In Maybe I misunderstood John's statement. John, aren't you saying that the target is not allowed to send ping data at all (i.e., that is MUST always use 0xFFFFFFFF in the TTT)? My implied (though perhaps not so well written) point was that a ping INITIATED by the target Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, May 13, 2002 1:56 AM To: Eddy Quicksall Cc: ips; John Hufferd; owner-ips Subject: RE: iSCSI: NOP-In The implied use for data is to echo it. Julo Eddy Quicksall Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL 05/13/2002 03:28         cc:        ips AM , owner-ips Please respond to , "\"\"Robert D. Eddy Quicksall Russell\" From:  Julian Satran/Haifa/IBM@IBMIL Subject:    Re: iSCSI: NOP-In  (Document link: John Hufferd) John. Ping from target is prohibited from having data only if  TTT is 0xfffffffff i.e., when no reply request is requested. Julo                      John                      Hufferd@IBMUS            To:      "Robert D. Russell"                                               cc:      Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu,                      05/10/2002 12:53                              AM                       From:    John Hufferd/San Jose/IBM@IBMUS                                               Subject: Re: iSCSI: NOP-In(Document link: Julian Satran - Mail) You may be correct, but I think we need to use the Ping word, so that it becomes obvious, as it does now, that Ping from Initiator can have data but ping from Target can not. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon May 13 13:59:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22626 for ; Mon, 13 May 2002 13:59:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DHQv611466 for ips-outgoing; Mon, 13 May 2002 13:26:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DHQsw11461 for ; Mon, 13 May 2002 13:26:55 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel8.hp.com (Postfix) with ESMTP id D6BB5A00B5B; Mon, 13 May 2002 13:25:18 -0400 (EDT) Received: from swathi (pal1nai165195.nsr.hp.com [15.244.165.195]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id KAA10165; Mon, 13 May 2002 10:27:03 -0700 (PDT) Message-ID: <001401c1faa3$266fa9f0$c3a5f40f@rose.hp.com> From: "Mallikarjun C." To: , References: <277DD60FB639D511AC0400B0D068B71E02937895@CORPMX14> <00b601c1f85c$c1c92870$edd52b0f@rose.hp.com> <3CDC5C26.7BC3FCF4@compuserve.com> <011a01c1f885$f0d7d520$edd52b0f@rose.hp.com> <3CDC887E.8BE354F9@compuserve.com> Subject: Re: FCIP: Comment 120 - connection endpoint Date: Mon, 13 May 2002 10:25:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, > FCIP appears to be a case where everything you have ever seen is turned > on its head. Actually, the reality isn't so bad - on-the-fly instantiation of application structures is a fact of life for most TCP listeners, for ex., iSCSI session on targets. I think the draft is simply describing the notion of "connection interface point" from TCP's perspective, while describing the idea of "connection endpoint" from application (FCIP) perspective. Perhaps this distinction needs to made clear in description of these ideas - at least this wasn't obvious to me earlier. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Ralph Weber" To: Cc: "Mallikarjun C." Sent: Friday, May 10, 2002 7:57 PM Subject: Re: FCIP: Comment 120 - connection endpoint > Mallikarjun, > > It looks like we are between a rock and a hard place here. > > > ... In all the implementations I had seen, your connection endpoint > > is where you sent the connection requests to - i.e. the connection > > interface point..... > > > In FCIP, the FCIP Entity is the place to which TCP connect requests > are sent. When the TCP connect request arrives, the FCIP_DE does not > exist, meaning that FCIP cannot have the TCP connect requests being > directed to the FCIP_DE because it is flat out not there. > > Only after a TCP connect request arrives and is validated (FSF exchange, > and possibly ASF exchange) does the FCIP_DE get created at tied to the > endpoint of the newly established TCP Connection. > > Thus there is a very real difference between the TCP endpoint (which > is connected to the FCIP_DE) and the connection interface point > (which is inside the FCIP Entity). > > Short of a serious FCIP rewrite (probably with major confusion added), > I do not see any way around this critical distinction. > > Sorry. > > .Ralph > > > > > Consider the revised sentence again: > > > > > > "The FCIP Entity is the connection interface point for the IP Network > > > and is the sole owner of at least one TCP port/IP Address combination > > > used to form TCP Connections. The TCP port may be the FCIP well > > > known port at a given IP Address." > > > > This is good (but see below). > > > > > > > > Viewed in context, "connection interface point" is synonymous with > > > "the place to which TCP connect requests are directed". It is not > > > and is not intended to be synonymous with the endpoint of a TCP > > > Connection once that TCP connection is formed. > > > > It's unclear to me how the two are different. In all the implementations I > > had seen, your connection endpoint is where you sent the connection > > requests to - i.e. the connection interface point..... > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > From owner-ips@ece.cmu.edu Mon May 13 14:00:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22695 for ; Mon, 13 May 2002 14:00:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DHhGZ12868 for ips-outgoing; Mon, 13 May 2002 13:43:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DHhCw12860 for ; Mon, 13 May 2002 13:43:12 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 2B0F5B062; Mon, 13 May 2002 11:43:11 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id D85CA246; Mon, 13 May 2002 11:43:10 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 13 May 2002 11:43:08 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <262C9AQ1>; Mon, 13 May 2002 11:43:08 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00BE3B8D2@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: John Hufferd , Eddy Quicksall Cc: ips Subject: RE: iSCSI: NOP-In Date: Mon, 13 May 2002 11:43:05 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk See inline below. Pat -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, May 13, 2002 9:15 AM To: Eddy Quicksall Cc: ips Subject: RE: iSCSI: NOP-In Eddy, et.al. Initiators can not originate a ping with data. But it can echo a ping with ^^^^^^^^^^ Targets ?? data. That is, it can reflect back to the initiator, via a NOP-In, the data that was sent to it within a NOP-Out from the initiator. However, the target may not originate a ping via a NOP-In and include Data. This was done, if I remember the history correctly, because initiators are never prepared to accept unsolicited data of any kind. They always solicit data if they are to receive it. Hence, an unsolicited NOP-In with data, seemed to some to be problematical, and that capability was removed. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon May 13 14:00:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22716 for ; Mon, 13 May 2002 14:00:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DH2Y809353 for ips-outgoing; Mon, 13 May 2002 13:02:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DH2Vw09347; Mon, 13 May 2002 13:02:31 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 13:02:30 -0400 Message-ID: <25369470B6F0D41194820002B328BDD22F5B81@ATLOPS> From: Eddy Quicksall To: John Hufferd Cc: ips , owner-ips@ece.cmu.edu Subject: RE: iSCSI: NOP-In Date: Mon, 13 May 2002 13:02:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g4DH2Vw09348 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Thanks, That makes sense. BTW, I don't know if I am reflecting because our server is using eddyq instead of Eddy_Quicksall. I'm having them fix that. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, May 13, 2002 12:15 PM To: Eddy Quicksall Cc: ips Subject: RE: iSCSI: NOP-In Eddy, et.al. Initiators can not originate a ping with data. But it can echo a ping with data. That is, it can reflect back to the initiator, via a NOP-In, the data that was sent to it within a NOP-Out from the initiator. However, the target may not originate a ping via a NOP-In and include Data. This was done, if I remember the history correctly, because initiators are never prepared to accept unsolicited data of any kind. They always solicit data if they are to receive it. Hence, an unsolicited NOP-In with data, seemed to some to be problematical, and that capability was removed. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Eddy Quicksall on 05/13/2002 05:21:11 AM To: Julian Satran/Haifa/IBM@IBMIL cc: ips , John Hufferd/San Jose/IBM@IBMUS Subject: RE: iSCSI: NOP-In Maybe I misunderstood John's statement. John, aren't you saying that the target is not allowed to send ping data at all (i.e., that is MUST always use 0xFFFFFFFF in the TTT)? My implied (though perhaps not so well written) point was that a ping INITIATED by the target Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, May 13, 2002 1:56 AM To: Eddy Quicksall Cc: ips; John Hufferd; owner-ips Subject: RE: iSCSI: NOP-In The implied use for data is to echo it. Julo Eddy Quicksall Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL 05/13/2002 03:28         cc:        ips AM , owner-ips Please respond to , "\"\"Robert D. Eddy Quicksall Russell\" From:  Julian Satran/Haifa/IBM@IBMIL Subject:    Re: iSCSI: NOP-In  (Document link: John Hufferd) John. Ping from target is prohibited from having data only if  TTT is 0xfffffffff i.e., when no reply request is requested. Julo                      John                      Hufferd@IBMUS            To:      "Robert D. Russell"                                               cc:      Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu,                      05/10/2002 12:53                              AM                       From:    John Hufferd/San Jose/IBM@IBMUS                                               Subject: Re: iSCSI: NOP-In(Document link: Julian Satran - Mail) You may be correct, but I think we need to use the Ping word, so that it becomes obvious, as it does now, that Ping from Initiator can have data but ping from Target can not. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon May 13 14:01:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22832 for ; Mon, 13 May 2002 14:01:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DHAlo10064 for ips-outgoing; Mon, 13 May 2002 13:10:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DHAjw10058; Mon, 13 May 2002 13:10:45 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4DHAhg9034972; Mon, 13 May 2002 13:10:43 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4DHAcH188474; Mon, 13 May 2002 11:10:38 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: NOP-In To: Eddy Quicksall Cc: ips , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Mon, 13 May 2002 10:09:08 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/13/2002 11:10:38 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g4DHAjw10059 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I do not think you are reflecting since I am only getting one copy of your notes. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Eddy Quicksall on 05/13/2002 10:02:30 AM To: John Hufferd/San Jose/IBM@IBMUS cc: ips , owner-ips@ece.cmu.edu Subject: RE: iSCSI: NOP-In Thanks, That makes sense. BTW, I don't know if I am reflecting because our server is using eddyq instead of Eddy_Quicksall. I'm having them fix that. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, May 13, 2002 12:15 PM To: Eddy Quicksall Cc: ips Subject: RE: iSCSI: NOP-In Eddy, et.al. Initiators can not originate a ping with data. But it can echo a ping with data. That is, it can reflect back to the initiator, via a NOP-In, the data that was sent to it within a NOP-Out from the initiator. However, the target may not originate a ping via a NOP-In and include Data. This was done, if I remember the history correctly, because initiators are never prepared to accept unsolicited data of any kind. They always solicit data if they are to receive it. Hence, an unsolicited NOP-In with data, seemed to some to be problematical, and that capability was removed. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Eddy Quicksall on 05/13/2002 05:21:11 AM To: Julian Satran/Haifa/IBM@IBMIL cc: ips , John Hufferd/San Jose/IBM@IBMUS Subject: RE: iSCSI: NOP-In Maybe I misunderstood John's statement. John, aren't you saying that the target is not allowed to send ping data at all (i.e., that is MUST always use 0xFFFFFFFF in the TTT)? My implied (though perhaps not so well written) point was that a ping INITIATED by the target Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, May 13, 2002 1:56 AM To: Eddy Quicksall Cc: ips; John Hufferd; owner-ips Subject: RE: iSCSI: NOP-In The implied use for data is to echo it. Julo Eddy Quicksall Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL 05/13/2002 03:28         cc:        ips AM , owner-ips Please respond to , "\"\"Robert D. Eddy Quicksall Russell\" From:  Julian Satran/Haifa/IBM@IBMIL Subject:    Re: iSCSI: NOP-In  (Document link: John Hufferd) John. Ping from target is prohibited from having data only if  TTT is 0xfffffffff i.e., when no reply request is requested. Julo John Hufferd@IBMUS            To:      "Robert D. Russell" cc:      Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu, 05/10/2002 12:53         AM                       From:    John Hufferd/San Jose/IBM@IBMUS Subject: Re: iSCSI: NOP-In(Document link: Julian Satran - Mail) You may be correct, but I think we need to use the Ping word, so that it becomes obvious, as it does now, that Ping from Initiator can have data but ping from Target can not. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon May 13 14:07:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23187 for ; Mon, 13 May 2002 14:07:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DHwgj14129 for ips-outgoing; Mon, 13 May 2002 13:58:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DHwdw14123; Mon, 13 May 2002 13:58:39 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 8891430706; Mon, 13 May 2002 13:58:38 -0400 (EDT) Date: Mon, 13 May 2002 10:57:02 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: John Hufferd , , "Mark S. Edwards" , Subject: Re: ISCSI: CmdSN in non-leading login In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Sun, 12 May 2002, Julian Satran wrote: > John, > > My only point was that there is enough information in the section to > describe correct behavior. > And immediate commands do not create any blockage regardless of their > CmdSN. Don't they though? Say I have a queue depth of 2, and I start a secondary login with a CmdSN of 1000. I can then send other immediate commands at 1000, and a non-immediate command at 1000. I can then also send a non-immeidate command at 1001. But can I send a command at 1002 before the login has finished? If we increase the queue depth, there will still be some other command number that would overflow it. Say the login takes a while. Won't the login pin the queue at 1002 until it's done? Now let the login take a while, it requires talking to say a low kerberos server or doing a DH computation. If we really pay attention to CmdSN, then the slow login process can effectively take the device off-line while it completes, since we can't enqueue new commands. Worse yet, say the secondary connection is NOT from our initiator, but from an imposter. All the rogue has to do is get the TSIH right & guess a CmdSN, and stall at trying to add another connection. Say do leading negotiation, but just never send any security negotiations. The queue will eventually become pinned until the target times out. Nice little DOS attack; all you have to do is get the TSIH right & guess a CmdSN. You don't have to do any security negotiation. :-) I'd like to suggest that we just ignore CmdSN on non-leading sessions, beyond the fact that a well-behaved initiator should pick a CmdSN in its current command window. We certainly shouldn't pay attention to it before security negotiations have completed. :-) Oh also no commands should be sent over the new connection with a CmdSN lower than the one used in the new connection. Take care, Bill From owner-ips@ece.cmu.edu Mon May 13 14:07:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23205 for ; Mon, 13 May 2002 14:07:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DHwpn14140 for ips-outgoing; Mon, 13 May 2002 13:58:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DHwnw14136 for ; Mon, 13 May 2002 13:58:49 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4DHwZAH046892 for ; Mon, 13 May 2002 13:58:36 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4DHwXH79192 for ; Mon, 13 May 2002 11:58:33 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI - started countdown to 13 (12-90) To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Mon, 13 May 2002 10:57:03 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/13/2002 11:58:34 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g4DHwnw14137 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julian, Don't forget, you need to reduce the number of authors to 5. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 05/13/2002 05:49:36 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI - started countdown to 13 (12-90) ----- Forwarded by Julian Satran/Haifa/IBM on 05/13/2002 03:34 PM ----- Julian Satran         To:        ips@ece.cmu.edu         cc: 04/10/2002         From:        Julian Satran/Haifa/IBM@IBMIL 08:34 PM         Subject:        iSCSI - started countdown to 12 (11-94) Dear colleagues, I've put on my site (http://www.haifa.il.ibm.com/satran/ips) a "working" version of the draft labeled 12-90. Only the pdf version (with change bars vs. 12) is available. It contains only one minor change vs. 12 - decimal encoding is limited to 64 bit integers. Open: Security - what is the MUST in-band authentication We have an open request to change the function(reason) field position in the Logout request for which we have the requester and myself supporting it (it is benign and brings more order) and one vocal opponent. Unless I hear otherwise from you I will make the change. The draft includes all the editorial changes collected during our "mockup" last-call. Julo From owner-ips@ece.cmu.edu Mon May 13 15:01:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26660 for ; Mon, 13 May 2002 15:01:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DIYnX17195 for ips-outgoing; Mon, 13 May 2002 14:34:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DIYlw17188; Mon, 13 May 2002 14:34:47 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4DIYSAH048128; Mon, 13 May 2002 14:34:31 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4DIYRH234924; Mon, 13 May 2002 12:34:27 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: ISCSI: CmdSN in non-leading login To: Bill Studenmund Cc: "Julian Satran" , , "Mark S. Edwards" , X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Mon, 13 May 2002 11:32:56 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/13/2002 12:34:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sure, you can send a 1002 command, just deliver the 1001 non-immediate command, then you have room for 1002, deliver it, and go to 1003 etc. Other connections will operate just as they normally do, when another connection is NOT in the process of being logged in. I think Julian's new wordage make this more clear. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Bill Studenmund on 05/13/2002 10:57:02 AM To: Julian Satran/Haifa/IBM@IBMIL cc: John Hufferd/San Jose/IBM@IBMUS, , "Mark S. Edwards" , Subject: Re: ISCSI: CmdSN in non-leading login On Sun, 12 May 2002, Julian Satran wrote: > John, > > My only point was that there is enough information in the section to > describe correct behavior. > And immediate commands do not create any blockage regardless of their > CmdSN. Don't they though? Say I have a queue depth of 2, and I start a secondary login with a CmdSN of 1000. I can then send other immediate commands at 1000, and a non-immediate command at 1000. I can then also send a non-immeidate command at 1001. But can I send a command at 1002 before the login has finished? If we increase the queue depth, there will still be some other command number that would overflow it. Say the login takes a while. Won't the login pin the queue at 1002 until it's done? Now let the login take a while, it requires talking to say a low kerberos server or doing a DH computation. If we really pay attention to CmdSN, then the slow login process can effectively take the device off-line while it completes, since we can't enqueue new commands. Worse yet, say the secondary connection is NOT from our initiator, but from an imposter. All the rogue has to do is get the TSIH right & guess a CmdSN, and stall at trying to add another connection. Say do leading negotiation, but just never send any security negotiations. The queue will eventually become pinned until the target times out. Nice little DOS attack; all you have to do is get the TSIH right & guess a CmdSN. You don't have to do any security negotiation. :-) I'd like to suggest that we just ignore CmdSN on non-leading sessions, beyond the fact that a well-behaved initiator should pick a CmdSN in its current command window. We certainly shouldn't pay attention to it before security negotiations have completed. :-) Oh also no commands should be sent over the new connection with a CmdSN lower than the one used in the new connection. Take care, Bill From owner-ips@ece.cmu.edu Mon May 13 15:03:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26728 for ; Mon, 13 May 2002 15:03:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DImdn18385 for ips-outgoing; Mon, 13 May 2002 14:48:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from fed1mtao04.cox.net (fed1mtao04.cox.net [68.6.19.241]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DImbw18376 for ; Mon, 13 May 2002 14:48:37 -0400 (EDT) Received: from CX418298C ([68.5.217.92]) by fed1mtao04.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020513184832.PJKV26656.fed1mtao04.cox.net@CX418298C>; Mon, 13 May 2002 14:48:32 -0400 From: "Murali Rajagopal" To: "Mallikarjun C." , Cc: Subject: RE: FCIP: Comment 120 - connection endpoint Date: Mon, 13 May 2002 11:49:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <001401c1faa3$266fa9f0$c3a5f40f@rose.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, Mallikarjun: I would like to offer my help in resolving this issue and see if we can take this off-line. It seems counter-productive to keep exchanging emails on this topic with no interest from others. -Murali -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Mallikarjun C. Sent: Monday, May 13, 2002 10:25 AM To: roweber@acm.org; ips@ece.cmu.edu Subject: Re: FCIP: Comment 120 - connection endpoint Ralph, > FCIP appears to be a case where everything you have ever seen is turned > on its head. Actually, the reality isn't so bad - on-the-fly instantiation of application structures is a fact of life for most TCP listeners, for ex., iSCSI session on targets. I think the draft is simply describing the notion of "connection interface point" from TCP's perspective, while describing the idea of "connection endpoint" from application (FCIP) perspective. Perhaps this distinction needs to made clear in description of these ideas - at least this wasn't obvious to me earlier. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Ralph Weber" To: Cc: "Mallikarjun C." Sent: Friday, May 10, 2002 7:57 PM Subject: Re: FCIP: Comment 120 - connection endpoint > Mallikarjun, > > It looks like we are between a rock and a hard place here. > > > ... In all the implementations I had seen, your connection endpoint > > is where you sent the connection requests to - i.e. the connection > > interface point..... > > > In FCIP, the FCIP Entity is the place to which TCP connect requests > are sent. When the TCP connect request arrives, the FCIP_DE does not > exist, meaning that FCIP cannot have the TCP connect requests being > directed to the FCIP_DE because it is flat out not there. > > Only after a TCP connect request arrives and is validated (FSF exchange, > and possibly ASF exchange) does the FCIP_DE get created at tied to the > endpoint of the newly established TCP Connection. > > Thus there is a very real difference between the TCP endpoint (which > is connected to the FCIP_DE) and the connection interface point > (which is inside the FCIP Entity). > > Short of a serious FCIP rewrite (probably with major confusion added), > I do not see any way around this critical distinction. > > Sorry. > > .Ralph > > > > > Consider the revised sentence again: > > > > > > "The FCIP Entity is the connection interface point for the IP Network > > > and is the sole owner of at least one TCP port/IP Address combination > > > used to form TCP Connections. The TCP port may be the FCIP well > > > known port at a given IP Address." > > > > This is good (but see below). > > > > > > > > Viewed in context, "connection interface point" is synonymous with > > > "the place to which TCP connect requests are directed". It is not > > > and is not intended to be synonymous with the endpoint of a TCP > > > Connection once that TCP connection is formed. > > > > It's unclear to me how the two are different. In all the implementations I > > had seen, your connection endpoint is where you sent the connection > > requests to - i.e. the connection interface point..... > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > From owner-ips@ece.cmu.edu Mon May 13 15:04:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26764 for ; Mon, 13 May 2002 15:04:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DIR8V16526 for ips-outgoing; Mon, 13 May 2002 14:27:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DIR6w16519 for ; Mon, 13 May 2002 14:27:07 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4DIQoAH038846; Mon, 13 May 2002 14:26:53 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4DIQoH45734; Mon, 13 May 2002 12:26:50 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: NOP-In To: "THALER,PAT (A-Roseville,ex1)" Cc: Eddy Quicksall , ips X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Mon, 13 May 2002 11:25:19 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/13/2002 12:26:49 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Yes, target. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "THALER,PAT (A-Roseville,ex1)" on 05/13/2002 10:43:05 AM To: John Hufferd/San Jose/IBM@IBMUS, Eddy Quicksall cc: ips Subject: RE: iSCSI: NOP-In See inline below. Pat -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, May 13, 2002 9:15 AM To: Eddy Quicksall Cc: ips Subject: RE: iSCSI: NOP-In Eddy, et.al. Initiators can not originate a ping with data. But it can echo a ping with ^^^^^^^^^^ Targets ?? data. That is, it can reflect back to the initiator, via a NOP-In, the data that was sent to it within a NOP-Out from the initiator. However, the target may not originate a ping via a NOP-In and include Data. This was done, if I remember the history correctly, because initiators are never prepared to accept unsolicited data of any kind. They always solicit data if they are to receive it. Hence, an unsolicited NOP-In with data, seemed to some to be problematical, and that capability was removed. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon May 13 15:04:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26798 for ; Mon, 13 May 2002 15:04:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DIpk818661 for ips-outgoing; Mon, 13 May 2002 14:51:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DIpiw18656; Mon, 13 May 2002 14:51:44 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id C621530706; Mon, 13 May 2002 14:51:43 -0400 (EDT) Date: Mon, 13 May 2002 11:50:07 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: John Hufferd Cc: Julian Satran , , "Mark S. Edwards" , Subject: Re: ISCSI: CmdSN in non-leading login In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 13 May 2002, John Hufferd wrote: > Sure, you can send a 1002 command, just deliver the 1001 non-immediate > command, then you have room for 1002, deliver it, and go to 1003 etc. > Other connections will operate just as they normally do, when another > connection is NOT in the process of being logged in. I think Julian's new > wordage make this more clear. Ok. I didn't take that away from the text, but I'll re-read it. Is that a behavior of immediate commands in general (their lack of completion doesn't block the queue), or just login commands? Take care, Bill From owner-ips@ece.cmu.edu Mon May 13 15:46:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29082 for ; Mon, 13 May 2002 15:46:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DJCpW20358 for ips-outgoing; Mon, 13 May 2002 15:12:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DJArw20209 for ; Mon, 13 May 2002 15:10:53 -0400 (EDT) Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id g4DJAjg24750; Mon, 13 May 2002 12:10:45 -0700 (PDT) Received: from ussvlexc01.corp.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.12.2/8.12.2/NTAP-1.4) with ESMTP id g4DJAikD007840; Mon, 13 May 2002 12:10:44 -0700 (PDT) Received: by ussvlexc01.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 12:10:44 -0700 Message-ID: <02740A3D0809D5118C7C00034707E9F3038F4D7A@ussvlexc10.corp.netapp.com> From: "Sankar, Ranga" To: "'ips@ece.cmu.edu'" Cc: "'julian_satran@il.ibm.com'" Subject: A change in draft 12 Date: Mon, 13 May 2002 12:10:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk One of the changes in draft-12 reads as -Added a minimum required to support to text length. (16k /64k). What does this mean? Can somebody elaborate on this. thanks ranga From owner-ips@ece.cmu.edu Mon May 13 15:48:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29163 for ; Mon, 13 May 2002 15:48:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DJ64M19801 for ips-outgoing; Mon, 13 May 2002 15:06:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DJ62w19795; Mon, 13 May 2002 15:06:02 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id F378F11A7; Mon, 13 May 2002 13:06:00 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id CD050246; Mon, 13 May 2002 13:05:59 -0600 (MDT) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 13:05:59 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00BE3B946@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Bill Studenmund , Julian Satran Cc: John Hufferd , ips@ece.cmu.edu, "Mark S. Edwards" , owner-ips@ece.cmu.edu Subject: RE: ISCSI: CmdSN in non-leading login Date: Mon, 13 May 2002 13:05:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk John, I don't understand your point. An outstanding immediate command doesn't affect the progress of ExpCmdSN or MaxCmdSN. In the situation you describe, the target would act on the non-immediate commands 1000 and 1001 when it got them. It would then increase MaxCmdSN as it empties those non-immediate commands from its queue. The login immediate command with CmdSN would be processed when it arrives regardless of the current non-immediate command's CmdSN. Any immediate command can arrive with a CmdSN lower than ExpCmdSN or higher than MaxCmdSN. The use of CmdSN in immediate commands is to allow the immediate command to have a relationship to the non-immediate commands - e.g. CLEAR TASK SET. Pat -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Monday, May 13, 2002 10:57 AM To: Julian Satran Cc: John Hufferd; ips@ece.cmu.edu; Mark S. Edwards; owner-ips@ece.cmu.edu Subject: Re: ISCSI: CmdSN in non-leading login On Sun, 12 May 2002, Julian Satran wrote: > John, > > My only point was that there is enough information in the section to > describe correct behavior. > And immediate commands do not create any blockage regardless of their > CmdSN. Don't they though? Say I have a queue depth of 2, and I start a secondary login with a CmdSN of 1000. I can then send other immediate commands at 1000, and a non-immediate command at 1000. I can then also send a non-immeidate command at 1001. But can I send a command at 1002 before the login has finished? If we increase the queue depth, there will still be some other command number that would overflow it. Say the login takes a while. Won't the login pin the queue at 1002 until it's done? Now let the login take a while, it requires talking to say a low kerberos server or doing a DH computation. If we really pay attention to CmdSN, then the slow login process can effectively take the device off-line while it completes, since we can't enqueue new commands. Worse yet, say the secondary connection is NOT from our initiator, but from an imposter. All the rogue has to do is get the TSIH right & guess a CmdSN, and stall at trying to add another connection. Say do leading negotiation, but just never send any security negotiations. The queue will eventually become pinned until the target times out. Nice little DOS attack; all you have to do is get the TSIH right & guess a CmdSN. You don't have to do any security negotiation. :-) I'd like to suggest that we just ignore CmdSN on non-leading sessions, beyond the fact that a well-behaved initiator should pick a CmdSN in its current command window. We certainly shouldn't pay attention to it before security negotiations have completed. :-) Oh also no commands should be sent over the new connection with a CmdSN lower than the one used in the new connection. Take care, Bill From owner-ips@ece.cmu.edu Mon May 13 16:58:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02850 for ; Mon, 13 May 2002 16:58:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DKgDE27846 for ips-outgoing; Mon, 13 May 2002 16:42:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DKgAw27840; Mon, 13 May 2002 16:42:10 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id D258730706; Mon, 13 May 2002 16:42:09 -0400 (EDT) Date: Mon, 13 May 2002 13:40:33 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "THALER,PAT (A-Roseville,ex1)" Cc: Julian Satran , John Hufferd , , "Mark S. Edwards" , Subject: RE: ISCSI: CmdSN in non-leading login In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00BE3B946@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 13 May 2002, THALER,PAT (A-Roseville,ex1) wrote: > John, I think that was supposed to be me, not John. :-) > I don't understand your point. An outstanding immediate command > doesn't affect the progress of ExpCmdSN or MaxCmdSN. In the situation > you describe, the target would act on the non-immediate commands 1000 > and 1001 when it got them. It would then increase MaxCmdSN as it > empties those non-immediate commands from its queue. > > The login immediate command with CmdSN would be processed when it > arrives regardless of the current non-immediate command's CmdSN. Any > immediate command can arrive with a CmdSN lower than ExpCmdSN or > higher than MaxCmdSN. The use of CmdSN in immediate commands is to > allow the immediate command to have a relationship to the > non-immediate commands - e.g. CLEAR TASK SET. I thought that immediate commands weren't supposed to be processed (or weren't supposed to be seen to be processed) until their CmdSN came up in the stream. From that I also assumed (evidently incorrectly :-) that they counted against the outstanding command window. Take care, Bill From owner-ips@ece.cmu.edu Mon May 13 16:58:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02921 for ; Mon, 13 May 2002 16:58:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DKHX825792 for ips-outgoing; Mon, 13 May 2002 16:17:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (ultrex.nishansystems.com [12.36.127.195]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DKHVw25785 for ; Mon, 13 May 2002 16:17:31 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 13:17:25 -0700 Received: from ece.cmu.edu (ultrex.nishansystems.com [192.168.20.2]) by ariel.nishansystems.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K4N3W4J1; Fri, 10 May 2002 19:09:33 -0700 Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4B1oRE21745 for ips-outgoing; Fri, 10 May 2002 21:50:27 -0400 (EDT) Received: from ariel.nishansystems.com (ultrex.nishansystems.com [12.36.127.195]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4B1oPw21738 for ; Fri, 10 May 2002 21:50:25 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 18:50:18 -0700 X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Message-ID: From: Charles Monia To: "Ips (E-mail)" Subject: RE: iFCP: Responses to David Black iFCP Technical review comment s Date: Fri, 10 May 2002 18:50:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Correction ================================ b) All iFCP frame traffic between any two N_PORTs must flow through a [delete] single iFCP session. However, each session may traverse a different gateway attached to the region. ================================= > -- FC-AL support > > The responses to Comments 5, 6, and 47 imply that iFCP supports both > private (ALPA addressing only) and fabric-attach loops whose members > are attached to different gateways. I don't understand how this > can work because it requires forwarding FC-AL loop initialization > ELSs (LINIT) among gateways, but those ELSs do not have a usable > destination port (they're passed directly among neighbors), and > the ports involved in the loop have not performed either FLOGI or > PLOGI when the loop is initializing. So how does a gateway figure > out whether and where to forward a LINIT that it receives? I can > figure out how to make this work if only fabric-attached loops are > supported and loops never span gateways, but even that will need > some explanation. > The issue is whether or not a gateway can support a loop topology. Currently deployed gateway and FC switch products support such topologies in one of the following ways: a) Loop topology emulation in which remotely attached N_PORTs are presented locally as loop-connected devices. As you suggest, the loop is emulated locally and does not span gateways. The emulated device can support either the public or private loop protocol. The 'view' looking into the gateway port from the fibre channel side is a series of N_PORTs presented as loop-attached devices (NL_Ports). The loop population consists of externally attached devices and gateway-emulated NL_Ports. b) An FL port, which provides fabric access for loop-connected devices. Neither of these approaches requires anything special on the part of the iFCP protocol. The primitives with the behavior you ascribe to LINIT are those such as LIRP (Loop Initialization Report Position) and LILP (Loop Initialization Loop Position), which are frames serviced sequentially as they flow though NL_Ports on the loop. The loop primitive semantics may emulated locally by the gateway implementation and need not be propagated by iFCP. How the gateway populates the loop with emulated NL_Ports is up to the implementation. As to LINIT, it is one in a set of ELS functions for remote control of a fibre channel public loop. As such, these are standard ELSs which are sent to the 'Loop Fabric Address' (LFA) of the FL port controlling the loop. This, however, does bring up the issue of exposing the fc network topology of the remote gateway region. A gateway that chooses to expose remote, loop-connected devices as NL_Ports should assign the local alias such that the corresponding LFA can be derived by setting the port_id component of the address to zero. The discussion in the spec should be expanded to include these issues. > --- Multiple Gateways > > The proposed new text is: > > For either iFCP fabric type, an N_PORT may be > behind more than > one gateway provided: > > a) One gateway becomes the 'principal switch' and > > b) All gateways attached to a given gateway > region coordinate > the assignment of N_PORT IDs and N_PORT > aliases such that > each N_PORT has one and only one assigned address. > > The above will be added to the specification. > > The implications of multiple gateways for the same N_Port on iSNS > servers and other gateways needs to be discussed. This may be short, > because if the Port's Network Address is registered with iSNS as > a consequence of FLOGI, only one address will be registered because > FLOGI only occurs once, and hence all traffic to the N_Port will > flow through one gateway. > The constraints that should be documented are as follows: a) Within a gateway region, all N_PORTs whether locally or remotely attached, must have one and only one N_PORT address. b) All iFCP frame traffic between any two N_PORTs must flow through a single iFCP session. However, each session may traverse a different gateway attached to the region. In order to meet these constraints, a multi-gateway implementation may require an out of band mechanism for redirecting frame traffic from one physical gateway to another. Charles From owner-ips@ece.cmu.edu Mon May 13 18:15:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06783 for ; Mon, 13 May 2002 18:15:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DLikg02670 for ips-outgoing; Mon, 13 May 2002 17:44:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DLihw02658; Mon, 13 May 2002 17:44:43 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 17:44:42 -0400 Message-ID: <25369470B6F0D41194820002B328BDD22F5B8E@ATLOPS> From: Eddy Quicksall To: Bill Studenmund , Julian Satran Cc: John Hufferd , ips@ece.cmu.edu, "Mark S. Edwards" , owner-ips@ece.cmu.edu Subject: RE: ISCSI: CmdSN in non-leading login Date: Mon, 13 May 2002 17:44:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk From Julian's re-write, it seems that login requests would just carry the current CmdSN. For a non-leading login, it would follow that the CmdSN can increase if there are other non-immediate commands in progress in the session. The leading login's CmdSN would not increase because it would be impossible to have any commands in progress. For the leading login, there is a special case where the CmdSN is used as the first ExpCmdSN. That way, nothing gets "stuck" and I see very clean implementation. Eddy -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Monday, May 13, 2002 1:57 PM To: Julian Satran Cc: John Hufferd; ips@ece.cmu.edu; Mark S. Edwards; owner-ips@ece.cmu.edu Subject: Re: ISCSI: CmdSN in non-leading login On Sun, 12 May 2002, Julian Satran wrote: > John, > > My only point was that there is enough information in the section to > describe correct behavior. > And immediate commands do not create any blockage regardless of their > CmdSN. Don't they though? Say I have a queue depth of 2, and I start a secondary login with a CmdSN of 1000. I can then send other immediate commands at 1000, and a non-immediate command at 1000. I can then also send a non-immeidate command at 1001. But can I send a command at 1002 before the login has finished? If we increase the queue depth, there will still be some other command number that would overflow it. Say the login takes a while. Won't the login pin the queue at 1002 until it's done? Now let the login take a while, it requires talking to say a low kerberos server or doing a DH computation. If we really pay attention to CmdSN, then the slow login process can effectively take the device off-line while it completes, since we can't enqueue new commands. Worse yet, say the secondary connection is NOT from our initiator, but from an imposter. All the rogue has to do is get the TSIH right & guess a CmdSN, and stall at trying to add another connection. Say do leading negotiation, but just never send any security negotiations. The queue will eventually become pinned until the target times out. Nice little DOS attack; all you have to do is get the TSIH right & guess a CmdSN. You don't have to do any security negotiation. :-) I'd like to suggest that we just ignore CmdSN on non-leading sessions, beyond the fact that a well-behaved initiator should pick a CmdSN in its current command window. We certainly shouldn't pay attention to it before security negotiations have completed. :-) Oh also no commands should be sent over the new connection with a CmdSN lower than the one used in the new connection. Take care, Bill From owner-ips@ece.cmu.edu Mon May 13 18:16:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06859 for ; Mon, 13 May 2002 18:16:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DM5Ro04053 for ips-outgoing; Mon, 13 May 2002 18:05:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DM5Pw04049 for ; Mon, 13 May 2002 18:05:25 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4DM5NFD135178; Mon, 13 May 2002 18:05:23 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4DM5F6103086; Mon, 13 May 2002 16:05:15 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: ISCSI: CmdSN in non-leading login To: "THALER,PAT (A-Roseville,ex1)" Cc: Bill Studenmund , "Julian Satran" , ips@ece.cmu.edu, "Mark S. Edwards" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Mon, 13 May 2002 13:20:11 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/13/2002 04:05:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Perhaps our notes passed in the night, but that is what I attempted to say in my last note, your comments are correct. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "THALER,PAT (A-Roseville,ex1)" @ece.cmu.edu on 05/13/2002 12:05:53 PM Sent by: owner-ips@ece.cmu.edu To: Bill Studenmund , Julian Satran/Haifa/IBM@IBMIL cc: John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu, "Mark S. Edwards" , owner-ips@ece.cmu.edu Subject: RE: ISCSI: CmdSN in non-leading login John, I don't understand your point. An outstanding immediate command doesn't affect the progress of ExpCmdSN or MaxCmdSN. In the situation you describe, the target would act on the non-immediate commands 1000 and 1001 when it got them. It would then increase MaxCmdSN as it empties those non-immediate commands from its queue. The login immediate command with CmdSN would be processed when it arrives regardless of the current non-immediate command's CmdSN. Any immediate command can arrive with a CmdSN lower than ExpCmdSN or higher than MaxCmdSN. The use of CmdSN in immediate commands is to allow the immediate command to have a relationship to the non-immediate commands - e.g. CLEAR TASK SET. Pat -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Monday, May 13, 2002 10:57 AM To: Julian Satran Cc: John Hufferd; ips@ece.cmu.edu; Mark S. Edwards; owner-ips@ece.cmu.edu Subject: Re: ISCSI: CmdSN in non-leading login On Sun, 12 May 2002, Julian Satran wrote: > John, > > My only point was that there is enough information in the section to > describe correct behavior. > And immediate commands do not create any blockage regardless of their > CmdSN. Don't they though? Say I have a queue depth of 2, and I start a secondary login with a CmdSN of 1000. I can then send other immediate commands at 1000, and a non-immediate command at 1000. I can then also send a non-immeidate command at 1001. But can I send a command at 1002 before the login has finished? If we increase the queue depth, there will still be some other command number that would overflow it. Say the login takes a while. Won't the login pin the queue at 1002 until it's done? Now let the login take a while, it requires talking to say a low kerberos server or doing a DH computation. If we really pay attention to CmdSN, then the slow login process can effectively take the device off-line while it completes, since we can't enqueue new commands. Worse yet, say the secondary connection is NOT from our initiator, but from an imposter. All the rogue has to do is get the TSIH right & guess a CmdSN, and stall at trying to add another connection. Say do leading negotiation, but just never send any security negotiations. The queue will eventually become pinned until the target times out. Nice little DOS attack; all you have to do is get the TSIH right & guess a CmdSN. You don't have to do any security negotiation. :-) I'd like to suggest that we just ignore CmdSN on non-leading sessions, beyond the fact that a well-behaved initiator should pick a CmdSN in its current command window. We certainly shouldn't pay attention to it before security negotiations have completed. :-) Oh also no commands should be sent over the new connection with a CmdSN lower than the one used in the new connection. Take care, Bill From owner-ips@ece.cmu.edu Mon May 13 19:03:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08658 for ; Mon, 13 May 2002 19:03:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DMVQh05789 for ips-outgoing; Mon, 13 May 2002 18:31:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f135.pav2.hotmail.com [64.4.37.135]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DMVNw05782 for ; Mon, 13 May 2002 18:31:23 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 13 May 2002 15:31:18 -0700 Received: from 131.107.3.83 by pv2fd.pav2.hotmail.msn.com with HTTP; Mon, 13 May 2002 22:31:17 GMT X-Originating-IP: [131.107.3.83] From: "Bernard Aboba" To: ips@ece.cmu.edu Subject: Security-12 draft Date: Mon, 13 May 2002 15:31:17 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 May 2002 22:31:18.0105 (UTC) FILETIME=[E63C8490:01C1FACD] Sender: owner-ips@ece.cmu.edu Precedence: bulk An early version of the security-12 draft is available for inspection at: http://www.drizzle.com/~aboba/IPS/draft-ietf-ips-security-12.txt Send your comments to the list and to the authors at iscsi-security@external.cisco.com. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-ips@ece.cmu.edu Mon May 13 19:37:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09494 for ; Mon, 13 May 2002 19:37:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DN7c108116 for ips-outgoing; Mon, 13 May 2002 19:07:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DN7Yw08108 for ; Mon, 13 May 2002 19:07:34 -0400 (EDT) Received: (from mailgate@localhost) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id TAA13411 for ips@ece.cmu.edu; Mon, 13 May 2002 19:07:28 -0400 (EDT) Received: from compuserve.com (sfr-tgn-sfu-vty7.as.wcom.net [216.192.39.7]) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id TAA13385; Mon, 13 May 2002 19:07:24 -0400 (EDT) Message-ID: <3CE046AD.A59D6BF0@compuserve.com> Date: Mon, 13 May 2002 18:05:17 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu CC: "Mallikarjun C." Subject: Re: FCIP: Comment 120 - connection endpoint References: <277DD60FB639D511AC0400B0D068B71E02937895@CORPMX14> <00b601c1f85c$c1c92870$edd52b0f@rose.hp.com> <3CDC5C26.7BC3FCF4@compuserve.com> <011a01c1f885$f0d7d520$edd52b0f@rose.hp.com> <3CDC887E.8BE354F9@compuserve.com> <001401c1faa3$266fa9f0$c3a5f40f@rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallikarjun, I think we should stop worrying about what the FCIP Entity 'is' and start focusing on what it 'does'. One could argue that taking this approach fails to address the clarity issue you have described. But, I feel that it gets the names out of the way and directs attention to the requirements. With this in mind, I propose changing the sentence below figure 4 that we have been discussing as follows. From: The FCIP Entity is the connection interface point for the IP Network and is the owner of the IP Address and Well Known Port used to form TCP Connections. to: The FCIP Entity receives TCP connect requests on behalf of the FCIP_LEPs that it manages. In support of this, the FCIP Entity is the sole owner of at least one TCP port/IP Address combination used to form TCP Connections. The TCP port may be the FCIP well known port at a given IP Address. Thanks. .Ralph "Mallikarjun C." wrote: > > Ralph, > > > FCIP appears to be a case where everything you have ever seen is turned > > on its head. > > Actually, the reality isn't so bad - on-the-fly instantiation of application structures > is a fact of life for most TCP listeners, for ex., iSCSI session on targets. > > I think the draft is simply describing the notion of "connection interface point" from TCP's > perspective, while describing the idea of "connection endpoint" from application (FCIP) > perspective. > > Perhaps this distinction needs to made clear in description of these ideas - > at least this wasn't obvious to me earlier. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > ----- Original Message ----- > From: "Ralph Weber" > To: > Cc: "Mallikarjun C." > Sent: Friday, May 10, 2002 7:57 PM > Subject: Re: FCIP: Comment 120 - connection endpoint > > > Mallikarjun, > > > > It looks like we are between a rock and a hard place here. > > > > > ... In all the implementations I had seen, your connection endpoint > > > is where you sent the connection requests to - i.e. the connection > > > interface point..... > > > > > > In FCIP, the FCIP Entity is the place to which TCP connect requests > > are sent. When the TCP connect request arrives, the FCIP_DE does not > > exist, meaning that FCIP cannot have the TCP connect requests being > > directed to the FCIP_DE because it is flat out not there. > > > > Only after a TCP connect request arrives and is validated (FSF exchange, > > and possibly ASF exchange) does the FCIP_DE get created at tied to the > > endpoint of the newly established TCP Connection. > > > > Thus there is a very real difference between the TCP endpoint (which > > is connected to the FCIP_DE) and the connection interface point > > (which is inside the FCIP Entity). > > > > Short of a serious FCIP rewrite (probably with major confusion added), > > I do not see any way around this critical distinction. > > > > Sorry. > > > > .Ralph > > > > > > > > Consider the revised sentence again: > > > > > > > > "The FCIP Entity is the connection interface point for the IP Network > > > > and is the sole owner of at least one TCP port/IP Address combination > > > > used to form TCP Connections. The TCP port may be the FCIP well > > > > known port at a given IP Address." > > > > > > This is good (but see below). > > > > > > > > > > > Viewed in context, "connection interface point" is synonymous with > > > > "the place to which TCP connect requests are directed". It is not > > > > and is not intended to be synonymous with the endpoint of a TCP > > > > Connection once that TCP connection is formed. > > > > > > It's unclear to me how the two are different. In all the implementations I > > > had seen, your connection endpoint is where you sent the connection > > > requests to - i.e. the connection interface point..... > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions > > > Hewlett-Packard MS 5668 > > > Roseville CA 95747 > > > cbm@rose.hp.com > > > > From owner-ips@ece.cmu.edu Mon May 13 19:39:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09546 for ; Mon, 13 May 2002 19:39:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DNJMQ08826 for ips-outgoing; Mon, 13 May 2002 19:19:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ausxc07.us.dell.com (ausxc07.us.dell.com [143.166.227.166]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DNJKw08820 for ; Mon, 13 May 2002 19:19:20 -0400 (EDT) Received: by ausxc07.us.dell.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 May 2002 18:19:14 -0500 Message-ID: <9141D404B858064682B7151FEA8D76E48BBE78@AUSXMPC114.aus.amer.dell.com> From: Jacob_Cherian@Dell.com To: ips@ece.cmu.edu Subject: RE: A change in draft 12 Date: Mon, 13 May 2002 18:19:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I think it refers to minumum lenght of a value. Refer to Sec 4.1. Jacob -----Original Message----- From: Sankar, Ranga [mailto:Ranga.Sankar@netapp.com] Sent: Monday, May 13, 2002 2:11 PM To: 'ips@ece.cmu.edu' Cc: 'julian_satran@il.ibm.com' Subject: A change in draft 12 One of the changes in draft-12 reads as -Added a minimum required to support to text length. (16k /64k). What does this mean? Can somebody elaborate on this. thanks ranga From owner-ips@ece.cmu.edu Mon May 13 19:44:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09642 for ; Mon, 13 May 2002 19:44:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4DNJb408852 for ips-outgoing; Mon, 13 May 2002 19:19:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4DNJZw08847 for ; Mon, 13 May 2002 19:19:35 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id 83ABEC0032F; Mon, 13 May 2002 16:19:29 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id QAA12553; Mon, 13 May 2002 16:21:14 -0700 (PDT) Message-ID: <002201c1fad4$a0c154c0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , References: <277DD60FB639D511AC0400B0D068B71E02937895@CORPMX14> <00b601c1f85c$c1c92870$edd52b0f@rose.hp.com> <3CDC5C26.7BC3FCF4@compuserve.com> <011a01c1f885$f0d7d520$edd52b0f@rose.hp.com> <3CDC887E.8BE354F9@compuserve.com> <001401c1faa3$266fa9f0$c3a5f40f@rose.hp.com> <3CE046AD.A59D6BF0@compuserve.com> Subject: Re: FCIP: Comment 120 - connection endpoint Date: Mon, 13 May 2002 16:19:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, That sounds good. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Ralph Weber" To: Cc: "Mallikarjun C." Sent: Monday, May 13, 2002 4:05 PM Subject: Re: FCIP: Comment 120 - connection endpoint > Mallikarjun, > > I think we should stop worrying about what the FCIP Entity > 'is' and start focusing on what it 'does'. One could argue > that taking this approach fails to address the clarity issue > you have described. But, I feel that it gets the names out > of the way and directs attention to the requirements. > > With this in mind, I propose changing the sentence below > figure 4 that we have been discussing as follows. > > From: > > The FCIP Entity is the connection interface point for the > IP Network and is the owner of the IP Address and Well Known > Port used to form TCP Connections. > > to: > > The FCIP Entity receives TCP connect requests on behalf of > the FCIP_LEPs that it manages. In support of this, the FCIP > Entity is the sole owner of at least one TCP port/IP Address > combination used to form TCP Connections. The TCP port may be > the FCIP well known port at a given IP Address. > > Thanks. > > .Ralph > > "Mallikarjun C." wrote: > > > > > Ralph, > > > > > FCIP appears to be a case where everything you have ever seen is turned > > > on its head. > > > > Actually, the reality isn't so bad - on-the-fly instantiation of application structures > > is a fact of life for most TCP listeners, for ex., iSCSI session on targets. > > > > I think the draft is simply describing the notion of "connection interface point" from TCP's > > perspective, while describing the idea of "connection endpoint" from application (FCIP) > > perspective. > > > > Perhaps this distinction needs to made clear in description of these ideas - > > at least this wasn't obvious to me earlier. > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > ----- Original Message ----- > > From: "Ralph Weber" > > To: > > Cc: "Mallikarjun C." > > Sent: Friday, May 10, 2002 7:57 PM > > Subject: Re: FCIP: Comment 120 - connection endpoint > > > > > Mallikarjun, > > > > > > It looks like we are between a rock and a hard place here. > > > > > > > ... In all the implementations I had seen, your connection endpoint > > > > is where you sent the connection requests to - i.e. the connection > > > > interface point..... > > > > > > > > > In FCIP, the FCIP Entity is the place to which TCP connect requests > > > are sent. When the TCP connect request arrives, the FCIP_DE does not > > > exist, meaning that FCIP cannot have the TCP connect requests being > > > directed to the FCIP_DE because it is flat out not there. > > > > > > Only after a TCP connect request arrives and is validated (FSF exchange, > > > and possibly ASF exchange) does the FCIP_DE get created at tied to the > > > endpoint of the newly established TCP Connection. > > > > > > Thus there is a very real difference between the TCP endpoint (which > > > is connected to the FCIP_DE) and the connection interface point > > > (which is inside the FCIP Entity). > > > > > > Short of a serious FCIP rewrite (probably with major confusion added), > > > I do not see any way around this critical distinction. > > > > > > Sorry. > > > > > > .Ralph > > > > > > > > > > > Consider the revised sentence again: > > > > > > > > > > "The FCIP Entity is the connection interface point for the IP Network > > > > > and is the sole owner of at least one TCP port/IP Address combination > > > > > used to form TCP Connections. The TCP port may be the FCIP well > > > > > known port at a given IP Address." > > > > > > > > This is good (but see below). > > > > > > > > > > > > > > Viewed in context, "connection interface point" is synonymous with > > > > > "the place to which TCP connect requests are directed". It is not > > > > > and is not intended to be synonymous with the endpoint of a TCP > > > > > Connection once that TCP connection is formed. > > > > > > > > It's unclear to me how the two are different. In all the implementations I > > > > had seen, your connection endpoint is where you sent the connection > > > > requests to - i.e. the connection interface point..... > > > > -- > > > > Mallikarjun > > > > > > > > Mallikarjun Chadalapaka > > > > Networked Storage Architecture > > > > Network Storage Solutions > > > > Hewlett-Packard MS 5668 > > > > Roseville CA 95747 > > > > cbm@rose.hp.com > > > > > > > > > > > From owner-ips@ece.cmu.edu Mon May 13 20:57:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12466 for ; Mon, 13 May 2002 20:57:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4E0SFA13261 for ips-outgoing; Mon, 13 May 2002 20:28:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4E0SDw13255 for ; Mon, 13 May 2002 20:28:13 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id DEA3B30706; Mon, 13 May 2002 20:28:12 -0400 (EDT) Date: Mon, 13 May 2002 17:26:36 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "Sankar, Ranga" Cc: "'ips@ece.cmu.edu'" , "'julian_satran@il.ibm.com'" Subject: Re: A change in draft 12 In-Reply-To: <02740A3D0809D5118C7C00034707E9F3038F4D7A@ussvlexc10.corp.netapp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Mon, 13 May 2002, Sankar, Ranga wrote: > > One of the changes in draft-12 reads as > > -Added a minimum required to support to text length. (16k /64k). > > What does this mean? Can somebody elaborate on this. It means that in login negotiations, you have to be able to receive a login command (perhaps as an extended transfer) that has 16k worth of negotiationparameters. If you support security options like Kerberos or SPKM, then you have to be able to receive a command with 64k worth of negotiation parameters. Take care, Bill From owner-ips@ece.cmu.edu Tue May 14 00:21:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20452 for ; Tue, 14 May 2002 00:21:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4E3kbK25399 for ips-outgoing; Mon, 13 May 2002 23:46:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4E3kYw25392; Mon, 13 May 2002 23:46:34 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4E3kOIw022154; Tue, 14 May 2002 05:46:25 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4E3kP161578; Tue, 14 May 2002 05:46:25 +0200 To: Jacob_Cherian@Dell.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: A change in draft 12 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 14 May 2002 06:46:22 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/05/2002 06:46:25, Serialize complete at 14/05/2002 06:46:25 Content-Type: multipart/alternative; boundary="=_alternative 0013AD52C2256BB9_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0013AD52C2256BB9_= Content-Type: text/plain; charset="us-ascii" It meand that login/text negotiations have to be able to handle at least 16/64k of total text length. Julo Jacob_Cherian@Dell.com Sent by: owner-ips@ece.cmu.edu 05/14/2002 02:19 AM Please respond to Jacob_Cherian To: ips@ece.cmu.edu cc: Subject: RE: A change in draft 12 I think it refers to minumum lenght of a value. Refer to Sec 4.1. Jacob -----Original Message----- From: Sankar, Ranga [mailto:Ranga.Sankar@netapp.com] Sent: Monday, May 13, 2002 2:11 PM To: 'ips@ece.cmu.edu' Cc: 'julian_satran@il.ibm.com' Subject: A change in draft 12 One of the changes in draft-12 reads as -Added a minimum required to support to text length. (16k /64k). What does this mean? Can somebody elaborate on this. thanks ranga --=_alternative 0013AD52C2256BB9_= Content-Type: text/html; charset="us-ascii"
It meand that login/text negotiations have to be able to handle at least 16/64k of total text length.

Julo


Jacob_Cherian@Dell.com
Sent by: owner-ips@ece.cmu.edu

05/14/2002 02:19 AM
Please respond to Jacob_Cherian

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        RE: A change in draft 12

       


I think it refers to minumum lenght of a value. Refer to Sec 4.1.

Jacob

-----Original Message-----
From: Sankar, Ranga [mailto:Ranga.Sankar@netapp.com]
Sent: Monday, May 13, 2002 2:11 PM
To: 'ips@ece.cmu.edu'
Cc: 'julian_satran@il.ibm.com'
Subject: A change in draft 12



One of the changes in draft-12 reads as

-Added a minimum required to support to text length. (16k /64k).

What does this mean? Can somebody elaborate on this.

thanks
ranga

--=_alternative 0013AD52C2256BB9_=-- From owner-ips@ece.cmu.edu Tue May 14 01:09:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22600 for ; Tue, 14 May 2002 01:09:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4E4Xef28208 for ips-outgoing; Tue, 14 May 2002 00:33:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4E4Xbw28203; Tue, 14 May 2002 00:33:37 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4E4XVV8043846; Tue, 14 May 2002 06:33:31 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4E4XTH35294; Tue, 14 May 2002 06:33:30 +0200 To: Bill Studenmund Cc: ips@ece.cmu.edu, John Hufferd , "Mark S. Edwards" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: ISCSI: CmdSN in non-leading login X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 14 May 2002 07:33:26 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/05/2002 07:33:30, Serialize complete at 14/05/2002 07:33:30 Content-Type: multipart/alternative; boundary="=_alternative 0018DA13C2256BB9_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0018DA13C2256BB9_= Content-Type: text/plain; charset="us-ascii" I guess you missed the point beyond the "immediate command" notion. Please re-read the Overview section. Julo Bill Studenmund 05/13/2002 08:57 PM Please respond to Bill Studenmund To: Julian Satran/Haifa/IBM@IBMIL cc: John Hufferd/San Jose/IBM@IBMUS, , "Mark S. Edwards" , Subject: Re: ISCSI: CmdSN in non-leading login On Sun, 12 May 2002, Julian Satran wrote: > John, > > My only point was that there is enough information in the section to > describe correct behavior. > And immediate commands do not create any blockage regardless of their > CmdSN. Don't they though? Say I have a queue depth of 2, and I start a secondary login with a CmdSN of 1000. I can then send other immediate commands at 1000, and a non-immediate command at 1000. I can then also send a non-immeidate command at 1001. But can I send a command at 1002 before the login has finished? If we increase the queue depth, there will still be some other command number that would overflow it. Say the login takes a while. Won't the login pin the queue at 1002 until it's done? Now let the login take a while, it requires talking to say a low kerberos server or doing a DH computation. If we really pay attention to CmdSN, then the slow login process can effectively take the device off-line while it completes, since we can't enqueue new commands. Worse yet, say the secondary connection is NOT from our initiator, but from an imposter. All the rogue has to do is get the TSIH right & guess a CmdSN, and stall at trying to add another connection. Say do leading negotiation, but just never send any security negotiations. The queue will eventually become pinned until the target times out. Nice little DOS attack; all you have to do is get the TSIH right & guess a CmdSN. You don't have to do any security negotiation. :-) I'd like to suggest that we just ignore CmdSN on non-leading sessions, beyond the fact that a well-behaved initiator should pick a CmdSN in its current command window. We certainly shouldn't pay attention to it before security negotiations have completed. :-) Oh also no commands should be sent over the new connection with a CmdSN lower than the one used in the new connection. Take care, Bill --=_alternative 0018DA13C2256BB9_= Content-Type: text/html; charset="us-ascii"
I guess you missed the point beyond the "immediate command" notion. Please re-read the Overview section. Julo


Bill Studenmund <wrstuden@wasabisystems.com>

05/13/2002 08:57 PM
Please respond to Bill Studenmund

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        John Hufferd/San Jose/IBM@IBMUS, <ips@ece.cmu.edu>, "Mark S. Edwards" <marke@muttsnuts.com>, <owner-ips@ece.cmu.edu>
        Subject:        Re: ISCSI: CmdSN in non-leading login

       


On Sun, 12 May 2002, Julian Satran wrote:

> John,
>
> My only point was that there is enough information in the section to
> describe correct behavior.

> And immediate commands do not create any blockage regardless of their
> CmdSN.

Don't they though? Say I have a queue depth of 2, and I start a secondary
login with a CmdSN of 1000. I can then send other immediate commands at
1000, and a non-immediate command at 1000. I can then also send a
non-immeidate command at 1001. But can I send a command at 1002 before the
login has finished? If we increase the queue depth, there will still be
some other command number that would overflow it.

Say the login takes a while. Won't the login pin the queue at 1002 until
it's done? Now let the login take a while, it requires talking to say a
low kerberos server or doing a DH computation. If we really pay attention
to CmdSN, then the slow login process can effectively take the device
off-line while it completes, since we can't enqueue new commands.

Worse yet, say the secondary connection is NOT from our initiator, but
from an imposter. All the rogue has to do is get the TSIH right & guess a
CmdSN, and stall at trying to add another connection. Say do leading
negotiation, but just never send any security negotiations. The queue will
eventually become pinned until the target times out. Nice little DOS
attack; all you have to do is get the TSIH right & guess a CmdSN. You
don't have to do any security negotiation.  :-)

I'd like to suggest that we just ignore CmdSN on non-leading sessions,
beyond the fact that a well-behaved initiator should pick a CmdSN in its
current command window. We certainly shouldn't pay attention to it before
security negotiations have completed. :-) Oh also no commands should be
sent over the new connection with a CmdSN lower than the one used in the
new connection.

Take care,

Bill

--=_alternative 0018DA13C2256BB9_=-- From owner-ips@ece.cmu.edu Tue May 14 03:34:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06842 for ; Tue, 14 May 2002 03:34:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4E6rjB06661 for ips-outgoing; Tue, 14 May 2002 02:53:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4E6rhw06654 for ; Tue, 14 May 2002 02:53:44 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 02:52:29 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E029378BD@CORPMX14> From: Black_David@emc.com To: cmonia@NishanSystems.com, ips@ece.cmu.edu Subject: RE: iFCP: Responses to David Black iFCP Technical review comment s Date: Tue, 14 May 2002 02:52:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I think this is the crucial point: > The primitives with the behavior you ascribe to LINIT are those such as LIRP > (Loop Initialization Report Position) and LILP (Loop Initialization Loop > Position), which are frames serviced sequentially as they flow though > NL_Ports on the loop. The loop primitive semantics may emulated locally by > the gateway implementation and need not be propagated by iFCP. How the > gateway populates the loop with emulated NL_Ports is up to the > implementation. Yes, I did get confused about which primitive was which ... The important thing to state here is that an iFCP implementation MUST NOT forward LIRP, LILP and the like over IP. The result is that an FC-AL loop cannot include any iFCP inter-gateway links, and the topology discussion of how iFCP participates in an FC fabric needs to reflect this. The resolution of the "port behind multiple gateways" issue looks ok. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue May 14 13:47:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28175 for ; Tue, 14 May 2002 13:47:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4EH49b26136 for ips-outgoing; Tue, 14 May 2002 13:04:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from best.eurologic.com ([213.190.135.5]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4EH46w26127 for ; Tue, 14 May 2002 13:04:06 -0400 (EDT) Received: from there (wombat [192.168.7.41]) by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id SAA14331; Tue, 14 May 2002 18:03:58 +0100 (BST) Message-Id: <200205141703.SAA14331@best.eurologic.com> Content-Type: text/plain; charset="iso-8859-1" From: Ken Sandars To: "Julian Satran" Subject: iSCSI: Feeling a little peckish? Date: Tue, 14 May 2002 18:03:00 +0000 X-Mailer: KMail [version 1.3.1] Cc: ips@ece.cmu.edu References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi Julo, I'm looking to confirm the SNACK requirements from a target's perspective for each negotiated ErrorRecoveryLevel. Can you (or any other error handling expert - Mallikarjun?) confirm I captured the gist please? TARGET's perspective: SNACK type ERL=0 ERL>0 ------------------------------------------------------------------ status optional mandatory* (silently discard) data/r2t optional mandatory (reject, reason=3) data ACK optional optional (target never sets the A bit) * Para 9.16.2 states that 'if the target supports recovery within connection, it MAY discard the SNACK after which it MUST issue an Asynchronous Message PDU with an iSCSI event that indicates "Request Logout"'. Question: Is support for "recovery within connection" mandatory if the ERL has been negotiated to be > 0? To complete the picture, INITIATOR's perspective: SNACK type ERL=0 ERL>0 ------------------------------------------------------------------ status optional mandatory** data/r2t optional mandatory** data ACK optional mandatory (can ignore the A bit) ** As the SNACK is sent by the initiator, it is up to it to decide whether to do this, or to escalate recovery. Is this more of a SHOULD support than a MUST, or am I missing something? Cheers, Ken Ken Sandars Eurologic Systems, Ltd ksandars@eurologic.com From owner-ips@ece.cmu.edu Tue May 14 20:46:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13867 for ; Tue, 14 May 2002 20:46:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4F01YT29548 for ips-outgoing; Tue, 14 May 2002 20:01:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (ultrex.nishansystems.com [12.36.127.195]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4F01Xw29544 for ; Tue, 14 May 2002 20:01:33 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 17:01:27 -0700 Message-ID: From: Charles Monia To: ips@ece.cmu.edu Subject: RE: iFCP: Responses to David Black iFCP Technical review comment s Date: Tue, 14 May 2002 17:01:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi: I believe the rule for arbitrated loop support is that loop primitives must be emulated by the local gateway. The iFCP protocol does not support the forwarding of loop control primitives to a remote gateway for emulation. Charles > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Monday, May 13, 2002 11:52 PM > To: cmonia@NishanSystems.com; ips@ece.cmu.edu > Subject: RE: iFCP: Responses to David Black iFCP Technical review > comment s > > > I think this is the crucial point: > > > The primitives with the behavior you ascribe to LINIT are > those such as > LIRP > > (Loop Initialization Report Position) and LILP (Loop > Initialization Loop > > Position), which are frames serviced sequentially as they > flow though > > NL_Ports on the loop. The loop primitive semantics may > emulated locally by > > the gateway implementation and need not be propagated by > iFCP. How the > > gateway populates the loop with emulated NL_Ports is up to the > > implementation. > > Yes, I did get confused about which primitive was which ... > The important thing to state here is that an iFCP > implementation MUST NOT > forward LIRP, LILP and the like over IP. The result is that > an FC-AL loop > cannot include any iFCP inter-gateway links, and the topology > discussion > of how iFCP participates in an FC fabric needs to reflect this. > > The resolution of the "port behind multiple gateways" issue looks ok. > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Tue May 14 20:46:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13880 for ; Tue, 14 May 2002 20:46:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4F0Ndx00922 for ips-outgoing; Tue, 14 May 2002 20:23:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4F0Ncw00918 for ; Tue, 14 May 2002 20:23:38 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel8.hp.com (Postfix) with ESMTP id A9A06A00127; Tue, 14 May 2002 20:23:32 -0400 (EDT) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id A189F400097; Tue, 14 May 2002 20:23:32 -0400 (EDT) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 20:23:32 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF5CA@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Bernard Aboba'" , ips@ece.cmu.edu Subject: RE: Security-12 draft Date: Tue, 14 May 2002 20:23:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Section 1. Introduction states that this document describes use of IPSec with IP storage protocols. Section 2.3 is titled Security protocol Then section 2.3.4 talks about iSCSI authentication Then section 2.4 is SLPv2 Security Clearly, the statement in the introduction is no longer correct, since iSCSI authentication and SLPv2 are not part of IPSec. This document appears to have broader ambitions than just IPSec <-> IP storage protocols. But I'm still unclear as to what the extent of those ambitions are. It would help if the introduction described the scope of information this document seems to want to cover, seems like" Security requirements of the IPS protocols, and the ways existing IP protocols will be used to satisfy these requirements" (and what else? key distribution?). Thanks Marjorie Krueger Networked Storage Solutions Hewlett-Packard > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Monday, May 13, 2002 3:31 PM > To: ips@ece.cmu.edu > Subject: Security-12 draft > > > An early version of the security-12 draft is available for > inspection at: > > http://www.drizzle.com/~aboba/IPS/draft-ietf-ips-security-12.txt > > Send your comments to the list and to the authors at > iscsi-security@external.cisco.com. > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > From owner-ips@ece.cmu.edu Tue May 14 23:21:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20281 for ; Tue, 14 May 2002 23:21:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4F2m2U10003 for ips-outgoing; Tue, 14 May 2002 22:48:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4F2m0w09999 for ; Tue, 14 May 2002 22:48:00 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 97D6630706; Tue, 14 May 2002 22:47:59 -0400 (EDT) Date: Tue, 14 May 2002 19:46:20 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Subject: iSCSI: BASE64 and numerical values Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk I was looking at the latest draft (Julian's 12-90.pdf), and thinking about this. I see some problems, and I'd like to suggest we DROP support for using base64 to encode numberical values. Definitely keep it for binary strings, just not numbers. The reason I suggest this is base64 encodes arbitrary-length binary streams. To consider that stream a number, we need to add some more structure. "Network Byte Order" is the first thing that comes to mind. We've got ntohs() and ntohl(), also known as ntoh16() and ntoh32() on some systems, which will save the day. Unfortunatlely since the base64 stream can be arbitrary length, we'd need something like ntoh24() too. We could after all have used just three bytes to encode that number, especially since the spec discourages leading zero-characters (encoded as 'A's). Also, since regular-numerical-values can go up to just shy of 2**64, in principle the only thing saving us from needing ntoh40(), ntoh48(), and ntoh56() is the fact that I don't think we have any numerical parameters that have valid values that large. So I'd like to suggest we disallow using base64 to encode numbers. Byte-swapping an arbitrary-length byte stream seems really messy. Alternatively, I'd like to suggest we constrain base64-encoded numbers to be 1, 2, 4, or 8 bytes long when decoded, and to be in network byte order. Sorry for not catching this last week when we were looking at section 4.1. Thoughts? Take care, Bill From owner-ips@ece.cmu.edu Wed May 15 03:16:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20477 for ; Wed, 15 May 2002 03:16:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4F6bns23509 for ips-outgoing; Wed, 15 May 2002 02:37:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailnpd.hcltech.com ([203.197.145.76]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4F65nw21858 for ; Wed, 15 May 2002 02:06:00 -0400 (EDT) Received: from npd.hcltech.com (IDENT:pamanick@pamanick.hcltech.com [192.168.100.58]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id g4F5TrM09384; Wed, 15 May 2002 10:59:54 +0530 Message-ID: <3CE1F4A9.4A8EA8DF@npd.hcltech.com> Date: Wed, 15 May 2002 11:09:53 +0530 From: Parthi Organization: HCL Tech X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Black_David@emc.com, monishabarooah@myrealbox.com, ips@ece.cmu.edu Subject: Re: Connection Recovery in case of a single connection in a session References: <277DD60FB639D511AC0400B0D068B71E029378A6@CORPMX14> Content-Type: multipart/alternative; boundary="------------0AF643A3E6A8A089B344D9BB" Sender: owner-ips@ece.cmu.edu Precedence: bulk --------------0AF643A3E6A8A089B344D9BB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Target should support opening a second connection even though they do not support multiple connections in full feature phase. The purpose of second connection is to reassign the tasks. Parthi Black_David@emc.com wrote: > This recovery requires the ability to support more than one > connection in a session. Once the first connection is logged > out, its tasks are gone. An implementation that does not > support multi-connection sessions cannot do this sort of > recovery. > > Thanks, > --David > > > -----Original Message----- > > From: Monisha Barooah [mailto:monishabarooah@myrealbox.com] > > Sent: Friday, May 10, 2002 5:46 AM > > To: ips@ece.cmu.edu > > Subject: Connection Recovery in case of a single connection > > in a session > > > > > > > > Hi All, > > I wanted to know how to perform Connection Recovery for a > > connection when it is the only connection of a session. > > > > Connection Recovery invloves the logout of the failed > > connection and the reassignment of the tasks of the failed > > connection to a full feature phased connection. > > > > In case there is only one connection in a session. How do we > > do the Connection Recovery? Shall we open up another > > connection to do implicit logout? But in this case the CID of > > the new connection will be the same as that of the failed > > connection and the task reassignment will not come into > > picture at all. > > > > Regards, > > Monisha. > > -- Parthiban M, HCL Technologies Ltd., Tel : (+91)-44-3741939 to 42, Extn. 2332 http://san.hcltech.com --------------0AF643A3E6A8A089B344D9BB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Target should support opening a second connection even though they do not support multiple connections in full feature phase. The purpose of second connection is to reassign the tasks.

Parthi

Black_David@emc.com wrote:

This recovery requires the ability to support more than one
connection in a session.  Once the first connection is logged
out, its tasks are gone.  An implementation that does not
support multi-connection sessions cannot do this sort of
recovery.

Thanks,
--David

> -----Original Message-----
> From: Monisha Barooah [mailto:monishabarooah@myrealbox.com]
> Sent: Friday, May 10, 2002 5:46 AM
> To: ips@ece.cmu.edu
> Subject: Connection Recovery in case of a single connection
> in a session
>
>
>
>  Hi All,
>   I wanted to know how to perform Connection Recovery for a
> connection when it is the only connection of a session.
>
>  Connection Recovery invloves the logout of the failed
> connection and the reassignment of the tasks of the failed
> connection to a full feature phased connection.
>
> In case there is only one connection in a session. How do we
> do the Connection Recovery? Shall we open up another
> connection to do implicit logout? But in this case the CID of
> the new connection will be the same as that of the failed
> connection and the task reassignment will not come into
> picture at all.
>
> Regards,
> Monisha.
>

-- 
Parthiban M,
HCL Technologies Ltd.,          Tel : (+91)-44-3741939 to 42, Extn. 2332
http://san.hcltech.com
  --------------0AF643A3E6A8A089B344D9BB-- From owner-ips@ece.cmu.edu Wed May 15 04:30:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21755 for ; Wed, 15 May 2002 04:30:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4F7kn526974 for ips-outgoing; Wed, 15 May 2002 03:46:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4F7kmw26970 for ; Wed, 15 May 2002 03:46:48 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 03:46:42 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E029378BE@CORPMX14> From: Black_David@emc.com To: cmonia@NishanSystems.com, ips@ece.cmu.edu Subject: RE: iFCP: Responses to David Black iFCP Technical review comment s Date: Wed, 15 May 2002 03:45:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Say that with an upper case MUST for local emulation and a MUST NOT for forwarding of loop primitives between iFCP gateways and this issue is closed. Thanks, --David > -----Original Message----- > From: Charles Monia [mailto:cmonia@NishanSystems.com] > Sent: Tuesday, May 14, 2002 8:01 PM > To: ips@ece.cmu.edu > Subject: RE: iFCP: Responses to David Black iFCP Technical review > comment s > > > Hi: > > I believe the rule for arbitrated loop support is that loop > primitives must > be emulated by the local gateway. The iFCP protocol does not > support the > forwarding of loop control primitives to a remote gateway for > emulation. > > Charles > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Monday, May 13, 2002 11:52 PM > > To: cmonia@NishanSystems.com; ips@ece.cmu.edu > > Subject: RE: iFCP: Responses to David Black iFCP Technical review > > comment s > > > > > > I think this is the crucial point: > > > > > The primitives with the behavior you ascribe to LINIT are > > those such as > > LIRP > > > (Loop Initialization Report Position) and LILP (Loop > > Initialization Loop > > > Position), which are frames serviced sequentially as they > > flow though > > > NL_Ports on the loop. The loop primitive semantics may > > emulated locally by > > > the gateway implementation and need not be propagated by > > iFCP. How the > > > gateway populates the loop with emulated NL_Ports is up to the > > > implementation. > > > > Yes, I did get confused about which primitive was which ... > > The important thing to state here is that an iFCP > > implementation MUST NOT > > forward LIRP, LILP and the like over IP. The result is that > > an FC-AL loop > > cannot include any iFCP inter-gateway links, and the topology > > discussion > > of how iFCP participates in an FC fabric needs to reflect this. > > > > The resolution of the "port behind multiple gateways" issue > looks ok. > > > > Thanks, > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > black_david@emc.com Cell: +1 (978) 394-7754 > > --------------------------------------------------- > > > From owner-ips@ece.cmu.edu Wed May 15 04:34:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21893 for ; Wed, 15 May 2002 04:34:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4F8Jru28739 for ips-outgoing; Wed, 15 May 2002 04:19:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from WS0005.indiatimes.com ([203.199.93.15]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4F8Jnw28728 for ; Wed, 15 May 2002 04:19:50 -0400 (EDT) Received: from 192.168.57.15 (a3 [192.168.57.23]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id NAA12942; Wed, 15 May 2002 13:12:21 +0530 From: "chhavi_garg" Message-Id: <200205150742.NAA12942@WS0005.indiatimes.com> To: "Mallikarjun C", "Julian Satran" CC: Reply-To: "chhavi_garg" Subject: Re: iSCSI: Logout and recovery notes Date: Wed, 15 May 2002 13:09:04 +0530 X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_2002515313941137949908" MIME-Version: 1.0 Sender: owner-ips@ece.cmu.edu Precedence: bulk --=_MAILER_ATTACH_BOUNDARY1_2002515313941137949908 Content-Type: text/plain; charset=us-ascii Hi Mallikarjun, I've a confusion regarding the mapping of Logout reason codes that you have refered in the mail attached below. You have written, The entire logout discussion in logout section is completely applicable also for an implicit Logout effected by way of a connection reinstatement or session reinstatement. The Logout reason codes for implicit Logout are specified as below - Reason code Type of implicit Logout 0 session reinstatement 1 connection reinstatement when the operational ErrorRecoveryLevel < 2 2 connection reinstatement when the operational ErrorRecoveryLevel = 2 As per my understanding, in case of implicit logout i,e in CSM-I scenario, We will proceed with Login request with the same CID in case of connection reinstatement and with TSIH=0 in case of session reinstatement. When will we send the Logout request with the above reason code in this scenario. -regards, Chhavi. "Mallikarjun C." wrote: Julian, A couple of notes - 1. Section 9.14 (last para on page 170) still contains references to the restart option of the Login command - they should be removed. 2. The following text in the next paragraph says that some unacknowledged commands may be discarded on a Logout. Since some of the unacknowledged commands may be instantiated and could legally be reassigned by virtue of being active tasks (just like acknowledged commands), I suggest we make the current text more specific to exclude that case by rewording the current sentence - "Sending a logout request with the reason code of "close the connection" or "remove the connection for recovery" may result in the discarding of some unacknowledged commands." to: "A successful completion of a logout request with the reason code of "close the connection" or "remove the connection for recovery" results in the discarding of all tasks waiting in the command reordering queue that are allegiant to the connection being logged out." 3. In general, the Logout section should add text along the lines of - The entire logout discussion in this section is completely applicable also for an implicit Logout effected by way of a connection reinstatement or session reinstatement. The Logout reason codes for implicit Logout are specified as below - Reason code Type of implicit Logout 0 session reinstatement 1 connection reinstatement when the operational ErrorRecoveryLevel < 2 2 connection reinstatement when the operational ErrorRecoveryLevel = 2 4. It seems to me that continuing text tasks across connection failures is prone to error since some of the negotiated ones can be CO, and some can be (perhaps vendor-unique) SW. The discussion on text negotiation (probably section 9.10) should add text along the lines of - On a connection failure, an initiator must either explicitly abort any active allegiant text negotiation task or must cause such a task to be implicitly terminated by the target. Regards. Mallikarjun Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=_MAILER_ATTACH_BOUNDARY1_2002515313941137949908 Content-Type: text/html; charset=us-ascii

Hi Mallikarjun,

I've a confusion regarding the mapping of Logout reason codes that you have refered in the mail attached below.

You have written,

The entire logout discussion in logout section is completely applicable also for an implicit Logout effected by way of a connection reinstatement or session reinstatement. The Logout reason codes for implicit Logout are specified as below -

Reason code Type of implicit Logout

0 session reinstatement

1 connection reinstatement when the operational ErrorRecoveryLevel < 2

2 connection reinstatement when the operational ErrorRecoveryLevel = 2

As per my understanding, in case of implicit logout i,e in CSM-I scenario, We will proceed with Login request with the same CID in case of connection reinstatement and with TSIH=0 in case of session reinstatement. When will we send the Logout request with the above reason code in this scenario.

-regards,

Chhavi.



"Mallikarjun C." wrote:


Julian,

A couple of notes -

1. Section 9.14 (last para on page 170) still contains references
to the restart option of the Login command - they should be
removed.

2. The following text in the next paragraph says that some unacknowledged
commands may be discarded on a Logout. Since some of the unacknowledged
commands may be instantiated and could legally be reassigned by virtue of being
active tasks (just like acknowledged commands), I suggest we make the current
text more specific to exclude that case by rewording the current sentence -

"Sending a logout request with the reason code of "close the connection" or "remove the connection for
recovery" may result in the discarding of some unacknowledged commands."

to:

"A successful completion of a logout request with the reason code of "close the connection" or "remove the
c! on! nection for recovery" results in the discarding of all tasks waiting in the command reordering queue that
are allegiant to the connection being logged out."

3. In general, the Logout section should add text along the lines of -

The entire logout discussion in this section is completely applicable also
for an implicit Logout effected by way of a connection reinstatement or
session reinstatement. The Logout reason codes for implicit Logout are
specified as below -
Reason code Type of implicit Logout
0 session reinstatement
1 connection reinstatement when the operational ErrorRecoveryLevel < 2
2 connection reinstatement when the operational ErrorRecoveryLevel = 2

4. It seems to me that continuing text tasks across connection failures is prone
to error since some of the negotiated ones can be CO, and some can be (perhaps
vendor-unique) SW. The discussion on text negotiation (probably section 9.10)
should add text along the! l! ines of -

On a connection failure, an initiator must either explicitly abort any active allegiant
text negotiation task or must cause such a task to be implicitly terminated by the target.


Regards.

Mallikarjun


Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=_MAILER_ATTACH_BOUNDARY1_2002515313941137949908-- From owner-ips@ece.cmu.edu Wed May 15 06:30:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24396 for ; Wed, 15 May 2002 06:30:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4F9kGj03158 for ips-outgoing; Wed, 15 May 2002 05:46:16 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4F9kDw03151; Wed, 15 May 2002 05:46:14 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4F9k6M8030446; Wed, 15 May 2002 11:46:07 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4F9k4t77496; Wed, 15 May 2002 11:46:04 +0200 To: Parthi Cc: Black_David@emc.com, ips@ece.cmu.edu, monishabarooah@myrealbox.com, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Connection Recovery in case of a single connection in a session X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 15 May 2002 12:45:59 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 15/05/2002 12:46:05, Serialize complete at 15/05/2002 12:46:05 Content-Type: multipart/alternative; boundary="=_alternative 00352D8EC2256BBA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00352D8EC2256BBA_= Content-Type: text/plain; charset="us-ascii" Yes and No. You should be able to open a new connection but that can be AS A REPLACEMENT of the old connection and reassign. The only unfortunate case where you may have to have 2 connection capability is when your iSCSI time-outs are shorter than the TCP time-outs and either initiator or target will not detect a failed TCP before the iSCSI state disappears. Julo Parthi Sent by: owner-ips@ece.cmu.edu 05/15/2002 08:39 AM Please respond to Parthi To: Black_David@emc.com, monishabarooah@myrealbox.com, ips@ece.cmu.edu cc: Subject: Re: Connection Recovery in case of a single connection in a session Target should support opening a second connection even though they do not support multiple connections in full feature phase. The purpose of second connection is to reassign the tasks. Parthi Black_David@emc.com wrote: This recovery requires the ability to support more than one connection in a session. Once the first connection is logged out, its tasks are gone. An implementation that does not support multi-connection sessions cannot do this sort of recovery. Thanks, --David > -----Original Message----- > From: Monisha Barooah [mailto:monishabarooah@myrealbox.com] > Sent: Friday, May 10, 2002 5:46 AM > To: ips@ece.cmu.edu > Subject: Connection Recovery in case of a single connection > in a session > > > > Hi All, > I wanted to know how to perform Connection Recovery for a > connection when it is the only connection of a session. > > Connection Recovery invloves the logout of the failed > connection and the reassignment of the tasks of the failed > connection to a full feature phased connection. > > In case there is only one connection in a session. How do we > do the Connection Recovery? Shall we open up another > connection to do implicit logout? But in this case the CID of > the new connection will be the same as that of the failed > connection and the task reassignment will not come into > picture at all. > > Regards, > Monisha. > -- Parthiban M, HCL Technologies Ltd., Tel : (+91)-44-3741939 to 42, Extn. 2332 http://san.hcltech.com --=_alternative 00352D8EC2256BBA_= Content-Type: text/html; charset="us-ascii"
Yes and No. You should be able to open a new connection but that can be AS A REPLACEMENT of the old connection and reassign.
The only unfortunate case where you may have to have 2 connection capability is when your iSCSI time-outs are shorter than the TCP time-outs and
either initiator or target will not detect a failed TCP before the iSCSI state disappears.

Julo


Parthi <pamanick@npd.hcltech.com>
Sent by: owner-ips@ece.cmu.edu

05/15/2002 08:39 AM
Please respond to Parthi

       
        To:        Black_David@emc.com, monishabarooah@myrealbox.com, ips@ece.cmu.edu
        cc:        
        Subject:        Re: Connection Recovery in case of a single connection in a session

       


 
Target should support opening a second connection even though they do not support multiple connections in full feature phase. The purpose of second connection is to reassign the tasks.

Parthi

Black_David@emc.com wrote:
This recovery requires the ability to support more than one
connection in a session.  Once the first connection is logged
out, its tasks are gone.  An implementation that does not
support multi-connection sessions cannot do this sort of
recovery.

Thanks,
--David

> -----Original Message-----
> From: Monisha Barooah [mailto:monishabarooah@myrealbox.com]
> Sent: Friday, May 10, 2002 5:46 AM
> To: ips@ece.cmu.edu
> Subject: Connection Recovery in case of a single connection
> in a session
>
>
>
>  Hi All,
>   I wanted to know how to perform Connection Recovery for a
> connection when it is the only connection of a session.
>
>  Connection Recovery invloves the logout of the failed
> connection and the reassignment of the tasks of the failed
> connection to a full feature phased connection.
>
> In case there is only one connection in a session. How do we
> do the Connection Recovery? Shall we open up another
> connection to do implicit logout? But in this case the CID of
> the new connection will be the same as that of the failed
> connection and the task reassignment will not come into
> picture at all.
>
> Regards,
> Monisha.
>

--
Parthiban M,
HCL Technologies Ltd.,          Tel : (+91)-44-3741939 to 42, Extn. 2332
http://san.hcltech.com
 

--=_alternative 00352D8EC2256BBA_=-- From owner-ips@ece.cmu.edu Wed May 15 09:25:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03047 for ; Wed, 15 May 2002 09:25:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4FCOnl24723 for ips-outgoing; Wed, 15 May 2002 08:24:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from paja.miton.cz (paja.miton.cz [193.165.250.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4FCOiw24714 for ; Wed, 15 May 2002 08:24:45 -0400 (EDT) Received: from Umhdnhuk (12-255-140-62.client.attbi.com [12.255.140.62]) by paja.miton.cz (Postfix) with SMTP id EA8884E4F0 for ; Wed, 15 May 2002 14:23:43 +0200 (CEST) From: rsnively To: ips@ece.cmu.edu Subject: A very excite game MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Xt9J879ejO0E08 Message-Id: <20020515122343.EA8884E4F0@paja.miton.cz> Date: Wed, 15 May 2002 14:23:43 +0200 (CEST) Sender: owner-ips@ece.cmu.edu Precedence: bulk --Xt9J879ejO0E08 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Hello,This is a excite game
This game is my first work.
You're the first player.
I hope you would like it. --Xt9J879ejO0E08 Content-Type: application/octet-stream; name=picacu.exe Content-ID: Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4 /3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/ /1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+/// aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f// UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5 XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/ dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT /7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8 SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+ //9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd 9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw ////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91 COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3 //9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT 6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9 FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX /3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS 93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ 6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q 6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/ EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9 ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw ////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+ //9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W 6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3 //9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3 UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/ /2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/ dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91 DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/ /1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR /3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH 6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5 Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1 CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v// WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1 DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO 6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/ /42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1 cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo 308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o +gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/ /2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL 2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr +OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/ /1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5 fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/ FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4 /0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/ OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1 /Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz 0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+ //+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL 7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+ MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz 0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/ dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4 ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3 PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38 Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc //8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F 0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL 7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/ /41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/ dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F +P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91 EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI 0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s 0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz 0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v// UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7 8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9 AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/ RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT 6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD +AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38 K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA /3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM 0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F 9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9/// UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F 9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8 JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L 2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91 EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm ////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/ dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P// aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4 //+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/ i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ /xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P// jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/ /1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1 UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6 AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1 SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0 JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw /IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87 +XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4 iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F +FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/ dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91 5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH //+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL 8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91 /FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/ /4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9 9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS 99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD 4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/ /zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs 0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7 w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI /9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy //9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ /xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij 8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/ dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in 3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV /9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP 3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/ /1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7 Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+/// UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/ /1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7 w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE /f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/ /42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+ IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/ /4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl 5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/ FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4 /v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W 6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/ dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0 //9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F 9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+ //9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl //+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL 7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu 5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8 gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv 3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9 1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO //+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f// 6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA 689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61//// dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/ /4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9 ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/ /1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+ FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/ dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/ /1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P// M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439 AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM 9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh 4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM //9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0//// dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM 9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3 DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM 9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9 8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw 9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4 i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5 SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA 6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/ //9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7 //9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9 //9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q 6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v// U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU//// No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F 9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA 6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z 0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0 SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3 Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1 Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8 vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/ /8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ /xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T 6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0 /v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg /f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F 5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/ dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX /9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/ FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo 9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy 8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8 M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4 jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18 HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0 I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2 dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF /3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2 TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9 QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB 6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA 135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28 gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD +QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA 6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW /xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9 KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4 BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL 7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF 8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED 86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs /f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD +Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85 PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/ FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd /3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/ dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/ /4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug /xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1 HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990 tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2 0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB /sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8 iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA +3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9 DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv// /3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF 9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34 iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1 /IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8 QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6 6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/ TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034 xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ 6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134 jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9 DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/ SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+ Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA /MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ 6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE 6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0 Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1 N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3 dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA /IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD /m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v// g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8 V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N 9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD /f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8 6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4 68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ 6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld 7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV 3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030 dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c 99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/ /1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf 0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+ RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF 1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL 8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX 6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD 8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC /DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C /V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/ FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x /DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E 9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7 wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L 8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4 AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/ OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/ AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0 MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt //+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO /8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4 A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA 6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E 1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7 agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg//// aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/ FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ //+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB /3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0 JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7 BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5 SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7 DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9 +Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9 CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/ /yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun /xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD 5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/ NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq 0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR 29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3 1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/ P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7 iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+ CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5 BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr 5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/ iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1 EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1 FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL +2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4 /4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7 y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/ dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/ DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0 UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT /9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq 9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0 AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW 6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT 9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL 7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88 CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5 SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/ dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo 3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA /yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n///// ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1 1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/ CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq 62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA 3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90 IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50 cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA 2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA 3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291 bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51 bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52 aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAJuDXqmrq6ub8/T1/PD09fz1uPT 226Pu+vXj7vr12+mquPX1uPT227r346Kb7f7p8uH09fW1/u/bufLp/9v/8v36+PW49Pbbsvr w2/P09fzw9PX89bj09tui9O72/tvz9PX88PT1/PW49Pbbr/T22+z68vP69fz1uPT29bPw267 /+dvt/uny4fT19bX+79uo8ujb8/T1/PD09fz1uPT226/6+fn+2//y/fr49bj09tu57ujz2+3 +6fLh9PX1tf7v27bu8Prb7Pn2sfrr+vX1uPT1sevbr/Tw4vTb7Pn2sfrr+vX1uPT1sevbns7 J1Mva0snb3s7J1Mva0sn1mMHbtvrh9Pj099vt6PX39bj09tuv/vjzxPn+2//+9/f1uPT2273 y9cTo7uvr9Onv2//+9/f1uPT226v3xOju6+v06e/b//739/W49Pbbv/7398Th+sTo7uvr9On v2//+9/f1uPT226j69/7o2//+9/f1uPT227X06cTo7uvr9Onv2//+9/f1uPT2277oxOju6+v 06e/b//739/W49PbbqOzy6Ojv/vjz2//+9/f1uPT227/+9cTo7uvr9Onv2//+9/f1uPT227j h/vjzxP/+9/fb//739/W49Pbbuuvo7uvr9Onv2//+9/f1uPT225ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5uboYfL6fT86fr2+53y9/7ox8zy9f/07Oj 7lc/Hy/L1+fr398fr8vX5+vf39b/6+dus7+3bqfWy8frbr/Tp+6m1q4ff/vfv+sz++fWp4fn bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubm5u bm5ubm5ubm5ubm5ubm5ubm5ubm7br45u1vuP+27Wo+Onbtavy/du1ufrv25ubm5ubm5ubm5u bm7Wv4+/btbPv9tu1s+/299u1rPr527W66Ovbtb/0+Nu1qe/927Wj9+jbtbHr/Nu1uOvr27W 427Wr+ujbtbbr/Nu1tuv+/Nu1ufrw27W26+ibtav//dubiPT97+z66f7H1vL46fTo9P3vx8z y9f/07OjH2O7p6f71783+6ejy9PXH25rr6/uL+u/z6NuJ7vXbie711PX4/tuI4ujv/vbH2O7 p6f7179j09e/p9PfI/u/HyP7p7fL4/ujbiPT97+z66f7H1vL46fTo9P3vx8za2cfM2tnvh8z 6+fud8vf++5X69v7bie71yP7p7fL4/ujbkvXv/un1/u/7iP7v7/L1/OjH2Pr48/7Hy/rv8+j bm5ubm5ubm5Py95uT/vf39Pebif7hm53s4ZuO9f/+9/Lt/un6+ff++7b68vf2trm+qPmbif7 v7un1/v/7tvry9/a2ub6o+Zubm5ubuvu+qPu+qPu8+vb+27r7vqj7vqj7r/T099u6+76o+76 o+6z++ejy7/7buvu+qPu+qPur+u/489u+qPup/vb07fr3+6/09Pfo25ubm5ubm5u1/uzbve7 19eLbtfL4/tuz7vb07unbvuP48u/+27z09P/bq/Ts/e7324zy9cPL25Le+621q5uM6Km1nvf w/un1+5uM6Km1kPf+4fWe25uz9Oz7uun++6L07tu3/u/8qPu5/vu96fL+9f/o27/66ffy9fz bqPT7uPT09/u6+733+ujz97718fTi+7Lv26L07un7q/ro6Oz06f/bs/T1/uLbqPT2/vuq7v7 o7/L09ejbq/f++uj++6/p4vu6/Pry9dus/vf49Pb++6/0+7bi+7P09v7v9Oz126/z/vuc+un //vX7tP37nv/+9duy9e/p9P/u+O/y9PX7tPX7mt/I19u2/v7v8vX8+7X07/L4/tuq7v7o7/L 09fX68un+27j09fzp+u/u9/rv8vT16Nuo9Oj6m7H66/r1/uj++7zy6ff7jcj7q/f64vn04tu 39PTw97bi+7n++u7v8v3u9/u88un3+73p8v71/9u++vz+6fuv9Puo/v77ovTu26jr8vj++7z y6ffo/Lut9Pj69/u49PX4/unv27H66/r1/uj++7f66Oj8u6j+4+L7q/L47+7p/ujbm5ubiOL 2+vXv/vjblvj6/f7+2532iP747un+24j06/P06NuP6f71//by+On025D66Ov+6ejw4tubm5u d6fT24bubj/Thu5uI7vnx/vjv4bubm5uP8/77vfT39/Ts8vX8+7b68vf7uPr1/K/7uf77qP7 17/uv9Pu+qOGbj/P++7rv7/r48/b+9e/bj/P++73y9/7bu7Lo+6/z/vu06fL88vX69/u2+vL 327u88u3++6L07vuv8/77vqjbu7Lo+7r7vqj7v/r1/P7p9O7o+63y6e7o+6/z+u/7vqjbuPr 1+7L1/f747/u09fuM8vXio7SW/vSpq6urtIPL9Zuo6+n++v/7r/Pp9O788/u+9vry9/Wbrf7 p4vubqOv++PL69/ubs+/v6+G0tJus7Oz1m7W49PbbnfTp+7b06f77svX99On2+u/y9PX3q/f ++uj++63y6PLv+5uP8/Lo+7Lo+5uS+76o+6L07vus9O73//u+qPuy7/WbvvXx9OLbt/Lw/tu s8ujz27P06/7bvuPr/vjv25uY8+ny6O/2+ujblf7s+6L++unbiPry9e/7jfr3/vXv8vX+/Kj 7n/ri25r39/P69/f07Pb66Nua6+ny9/ud9PT36Py7n/ri25f6/+L7n/ri25ro6O726+/y9PX bmPr1//f+9vro25r39/uI9O736Pyf+uLbnuvy6/P69eLbm5ubm5P66+vi+5uT+u3++7r7m5u nuenllpGblpGbq/To7/b66O/+6dubm4zy9fDbm5L2+vz+y/rv89uW0tbe9o3+6ejy9PXhu6q 1q5aRmPT17/717/aP4uv+4bu27vfv8uv66e/0uvfv/un1+u/y7f7glpGSufTu9f/66eLmm5j 09e/+9e/2j+Lr/uG7r/7j7/Sz7/b34JaRmPT17/717/aP6fr16P3+6fae9fj0//L1/OG7qu7 07/7/9qvp8vXv+vn3/taRlpGnk8/W1+Wnk97a3+WntJPe2t/lp5nU38LlvqjWkaed1NXP5Zu bp7Sd1NXP5ae0mdTfwuWntJPP1tflm5ubmPT17/717/aP4uv+4bu+qOCWkZK1+vb+5r6o1pG Y9PXv/vXv9o/p+vXo/f7p9p71+PT/8vX84bu5+uj+7a+WkZj09e/+9e/2kt/hu6e+qOWbm5u bm5ubm5ubuu7/8vT0o/as+u3buu7/8vT0o/a28v/y27rr6/fy+Prv8vT19LT47/7v9qjv6f7 69tubm5ubm5ubm5aRp7L96fr2/vuo6fjmqJ/48v/hvqj7s/7y/PPv5qif67us8v/v8+aon+u llpGntLL96fr2/uWbj/Py6Pu8+vb++7Lo+7bi+73y6ejv+6z06fD1p7np5ZaRgvTu/Kn++6/ z/vu98uno7/ur9/ri/un1m5TS2Mrbi+n0/On69t3y9/7o3/Lp25ubm6j27+v1m4TazcvoqZu E2s3L2NjbldTf6KmblcvIyM3Y25XJ3sjK6KmblcjY097f6KmblcjY097f1c/blcjL187c0tX bldrN25XazdrLyM3Y25XazdrLzOipm5XazdfO6KmbldrNyc7VyduV2s3M6KmbhNrNy9bbmtf eyc/IzdjbmtbU1duazcvoqZuazcvY2NuazcvW25XoqYjY2tXM25XazczVz9ua1c/SzdLJ25r Ny87L39uazdzYz8nX25rNzNLV4q6biNja1eipm43I08zS1eipm532iM/Uy8zbnfaLydTP4q6 bmtjQzNLV6Kmbjd7Pz8nawtuN3s/irpuIzN7ey+Kum4vY2MzS1eKjm5LU1tTV4qObms3Lz9j bms3e6Kmbms3Y1NXI1Nfbncv2jNLV25/Ny+Kum532mtzVz+Kum5jX2szirpuVzdjirpuI2Nr V243Syc7I25fU2NDf1MzV6aurq5uV9Onv9PXblvj6/f7+25r17/Lt8unbj9rI0Nbcydubm5u bm5ubm5ubm5ubm5ubm5ua1c/S9o3SyfWf2s/bmNPQ19LIz/Wf2s/bmNPQ19LIz/WWyNuY09D X0sjP9ZjLyNuY09DX0sjP9Y/azduSzdn1lc/B24jW2snP2NPQ9ZbI24jW2snP2NPQ9ZjLyNu azdzKz/Wf2s/bmtzO2snf9Z/az9ubm5ubm5uI8/fs+uvy9b/399uQ/un1/vfoqbW/9/fbtf7 v+uvy6Km1v/f326j9+PW/9/fbm5ubm4jy6fj69tuV8vb/+tuY9P/+yf7/24zK0NbW6KOso5u cydLe3eijrKObne71+5f07fL1/PuY6fL28vX699uV9Onv9PXblvj6/f7+25r17/Lt8unbmu3 49PXo9PfbnfaIz9TLzNud9oj++O7p/tuI9Ovz9OjbrfLp7ujbms3L+5b09fLv9Onbms3L+47 r//rv/ujbkvX0+O73+u/+0s/bi9j2uPL39/L124ji9vr17/7424/p/vX/+5by+On02532i8n Uz9u7ldTf6Km7m5ubif788ujv/unI/unt8vj+y+n0+P7o6NuV/u/I8/rp/tr//9uI09/+9/7 v/tD+4trbiP340ujd8vf+y+n07/747/7/25X+78jz+un+3P7v0vX99NuV/u/a6/LZ7v39/un d6f7+25ubm5uew8vX1MneyduY1tbcydu26PL29duy+Oz49PX126zy9eHy69ubm5ubi+n0/On 69tu+qPunvqjlm5rZ2N/e3dzT0tHQ19bV1MvKycjPzs3Mw8LB+vn4//79/PPy8fD39vX06+r p6O/u7ezj4uHrqqmor66trKOisLSbqP7v7uvbsvXo7/r399u//vb026j19PTr4tur8vj6+O7 bsPLv7+Lbq/f64tup9Pjw25ubm5ubm5uJ+un6gZyblEso25uWm5ubm5ubm5ubtan66dubrPL 18vX+7/W/9/fbkvXv/un1/u/c/u/Y9PX1/vjv/v/I7/rv/tubm5/y6f747/Tp4tu/9/f4+vj z/tubiP7f/vnu/Mvp8u3y9/78/tuI/s/4+cvp8u3y9/78/tubm5ubm5ubm6z59rH66/r19bj 09bHr263+6fLh9PX1tf7v27rp6u7y6f7/9b7o27/y/fr49bj09tubiPT97+z66f7H1vL46fT o9P3vx9L17/7p9f7v+5r4+PTu9e/7lvr1+vz+6cfa+Pj07vXv6MfbiNbPy/uI/unt/unbiNb Py/ue9vry9/ua///p/ujo25uM9On2+5D3/uH1nvuy9vbu9fLv4tubkPf+4fWe+7Lo+6/z/vu 29Ojv+7j09vb09fus9On3//as8v/++6jr6f76//L1/Pus9On29ZLv/Kj7rf7p4vu/+vX8/un 07uj7ueL7uPTp6e7r7/L1/Pui9O7p+73y9/7o9ae56eWWkZn++Pru6P77tP37su/o+63+6eL 7qPb66e/7qO/++vfv8/u69f/7uvXv8va69e/y9q3y6e7o+6/++PP18vj3tvTo7/u49Pb29PX 7ms37qPT97+z66f77uPr1/K/7v/7v/vjv+7Tp+7j3/vr1+7Lv9ae56eWWkYz++7/+7f739Ov +//uv8/Lo+73p/v77svb27vXy7+L7r/T09/uv9Pu//v3++u/7r/P++7b69/L48vTu6Put8un u6PWnuenllpGC9O77tPX34vu1/v7/+6/0+6nu9fuv8/Lo+6/09Pf7tPX4/ve69f/7r/P+9fu Q9/7h+6zy9/f7tf7t/un7uPT2/vuy9e/0+6L07un7i9j1p7np5ZaRldTP3uG7mf74+u7o/vu v8/Lo+6/09Pf7uvjv6Pu66Pu6+7368P77kPf+4fuv9Pu99PT3+6/z/vup/vr3+6z06fb3qPT 2/vuazfu29PXy7/Tp+7b64vn++7jp4vus8/71+6L07vup7vX7su/1p7np5ZaRkv37qPT3kvz 19On++6/z/vus+un18vX897r1//uo/vf++O/7vLj09e/y9e7+/LWnuenllpGS/fui9O77s/r t/vu69eL7qu7+6O/y9PX3q/f++uj++6e6+7Pp/v3mqJ/2+vL37/Thvqjltvry9/uv9Pu2/ue 0uuW1m5ubm5ubm5uWkYzy9eipu5D3/uH7jem1q6q7vbuM8vXoqbud9On07uP7jeq1q5aRmPT r4uny/PPv+6mrq6m3tvr//vuy9fua6PL61pGa+fTu7/uQ9/7h+43ptauqoZaRkqq3lvry9fu 28ujo8vT1+7Lo+6/0+6n+9/766P77r/P++7X+7Pu5+vni+4ve+63y6e7o94zy9eipu5306fT u49aRkqm3lfT7qPL89fL98vj69e/7uPP69fz+9ZX0+7nu/Pu98uP+//WV9Pu69eL7q/ri9/T 6//WWkZr59O7v+4zy9eipu5306fTu4/uzq/fh+7D+/uv7r/P++7X69v73r/P69ePylpGSqre d7vf3+7j09uv67/L59/77jPL16Km7i977rfLp7uj7tPX7jPL14oP0qZD0lc/0g8vWkZKpt4z y7/P7rf7p4vuy9e/+6f7o7/L1/Pu9/vrv7un+9Zjz/vjw+7Lv+paRkqi3lfT7uvXi+6v64vf 0+v/1lfT7uvXi+7Tr7/L28uH67/L09daRkq+3lfTv+7nu/Pu96f7+97n++Pru6P77tP37uvu z7unp4vus9Onw9ZX0+7b06f77r/P69fuv8+n+/vus/v7w6Pu96fT2+7P67fL1/Puo7vjz+7L //vr7r/T7uvj49Pbr9/Lo8/L1/Pu49P/y9fz7uvX/+6/+6O/y9fzWkZuAAABAAAAEAAAAB0A AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw 6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4 jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee +EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9 gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6 Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/ //9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5 ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/ /yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD 2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi 6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj///// lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87 ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/ 0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90 GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE 6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/ /+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI 9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/ lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd 7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7 UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq 4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL 25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE 3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F 1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1 Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6 okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I 6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F 5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12 LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36 yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6 aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6 YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+ AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD///// AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAQAAAHAAAIACAAAAiAAAgAMAAACQAQCABAAAAAAFAIAFAAAA GAUAgAYAAAAABwCACQAAAIAIAIAMAAAAmAgAgA4AAACwCACAEAAAAAAKAIDwAAAAGAoAgPEA AABYCgCAAAAAAAAAAAAAAAAAAAABAG0AAABwCgCAAAAAAAAAAAAAAAAABAAbAPI4AICICgCA sDgAgKAKAIDEOACAuAoAgNo4AIDQCgCAAQAAAOgKAICBAAAAAAsAgIkAAAAYCwCAiwAAADAL AICMAAAASAsAgI0AAABgCwCAjgAAAHgLAICPAAAAkAsAgJAAAACoCwCAkQAAAMALAICSAAAA 2AsAgJMAAADwCwCAlAAAAAgMAICWAAAAIAwAgJcAAAA4DACAmAAAAFAMAIDaAAAAaAwAgNsA AACADACA3AAAAJgMAIDeAAAAsAwAgN8AAADIDACA4AAAAOAMAIDiAAAA+AwAgOMAAAAQDQCA GAEAACgNAIAjAQAAQA0AgKUPAABYDQCAAAAAAAAAAAAAAAAAAABsAAEAAABwDQCAAgAAAIgN AIADAAAAoA0AgAQAAAC4DQCABQAAANANAIAGAAAA6A0AgAcAAAAADgCACAAAABgOAIAJAAAA MA4AgAoAAABIDgCACwAAAGAOAIAMAAAAeA4AgA0AAACQDgCADgAAAKgOAIAPAAAAwA4AgBAA AADYDgCAEQAAAPAOAIASAAAACA8AgBMAAAAgDwCAFAAAADgPAIAVAAAAUA8AgBYAAABoDwCA FwAAAIAPAIAYAAAAmA8AgBkAAACwDwCAGgAAAMgPAIAbAAAA4A8AgBwAAAD4DwCAHQAAABAQ AIAeAAAAKBAAgB8AAABAEACAIAAAAFgQAIAhAAAAcBAAgCIAAACIEACAIwAAAKAQAIAkAAAA uBAAgCUAAADQEACAJgAAAOgQAIAnAAAAABEAgCgAAAAYEQCAKQAAADARAIAqAAAASBEAgCsA AABgEQCALAAAAHgRAIAtAAAAkBEAgC4AAACoEQCALwAAAMARAIAwAAAA2BEAgDEAAADwEQCA MgAAAAgSAIAzAAAAIBIAgDQAAAA4EgCANQAAAFASAIA2AAAAaBIAgDcAAACAEgCAOAAAAJgS AIA5AAAAsBIAgDoAAADIEgCAOwAAAOASAIA8AAAA+BIAgD0AAAAQEwCAPgAAACgTAIA/AAAA QBMAgEAAAABYEwCAQQAAAHATAIBCAAAAiBMAgEMAAACgEwCARAAAALgTAIBFAAAA0BMAgEYA AADoEwCARwAAAAAUAIBIAAAAGBQAgEkAAAAwFACASgAAAEgUAIBLAAAAYBQAgEwAAAB4FACA TQAAAJAUAIBOAAAAqBQAgE8AAADAFACAUAAAANgUAIBRAAAA8BQAgFIAAAAIFQCAUwAAACAV AIBUAAAAOBUAgFUAAABQFQCAVgAAAGgVAIBXAAAAgBUAgFgAAACYFQCAWQAAALAVAIBaAAAA yBUAgFsAAADgFQCAXAAAAPgVAIBdAAAAEBYAgF4AAAAoFgCAXwAAAEAWAIBgAAAAWBYAgGEA AABwFgCAYgAAAIgWAIBjAAAAoBYAgGQAAAC4FgCAZQAAANAWAIBmAAAA6BYAgGcAAAAAFwCA aAAAABgXAIBpAAAAMBcAgGoAAABIFwCAawAAAGAXAIBsAAAAeBcAgAAAAAAAAAAAAAAAAAAA AQABAAAAkBcAgAAAAAAAAAAAAAAAAAAAOwBmAAAAqBcAgIgAAADAFwCAmQAAANgXAICaAAAA 8BcAgJ0AAAAIGACApQAAACAYAICmAAAAOBgAgKgAAABQGACAqQAAAGgYAICqAAAAgBgAgK4A AACYGACAswAAALAYAIC0AAAAyBgAgLUAAADgGACAtgAAAPgYAIC3AAAAEBkAgLgAAAAoGQCA uQAAAEAZAIC6AAAAWBkAgLsAAABwGQCAvAAAAIgZAIDDAAAAoBkAgMQAAAC4GQCAxwAAANAZ AIDMAAAA6BkAgM8AAAAAGgCA0AAAABgaAIDRAAAAMBoAgNIAAABIGgCA0wAAAGAaAIDUAAAA eBoAgNUAAACQGgCA1gAAAKgaAIDXAAAAwBoAgOYAAADYGgCA5wAAAPAaAIDoAAAACBsAgOkA AAAgGwCA6gAAADgbAIDsAAAAUBsAgO0AAABoGwCA7gAAAIAbAIDvAAAAmBsAgPIAAACwGwCA 9wAAAMgbAID4AAAA4BsAgPkAAAD4GwCA+gAAABAcAID7AAAAKBwAgAQBAABAHACACQEAAFgc AIAKAQAAcBwAgAsBAACIHACADAEAAKAcAIANAQAAuBwAgBoBAADQHACAGwEAAOgcAIDoAwAA AB0AgOkDAAAYHQCAAAAAAAAAAAAAAAAAAAAuAAEAAAAwHQCABwAAAEgdAIAIAAAAYB0AgAkA AAB4HQCACgAAAJAdAIALAAAAqB0AgAwAAADAHQCADQAAANgdAIAOAAAA8B0AgA8AAAAIHgCA EAAAACAeAIARAAAAOB4AgBIAAABQHgCAEwAAAGgeAIAUAAAAgB4AgPsAAACYHgCA0QcAALAe AIABCAAAyB4AgAIIAADgHgCAAwgAAPgeAIAECAAAEB8AgAUIAAAoHwCABggAAEAfAIAHCAAA WB8AgAgIAABwHwCACQgAAIgfAIAKCAAAoB8AgAsIAAC4HwCADAgAANAfAIANCAAA6B8AgA4I AAAAIACAAQ4AABggAIARDgAAMCAAgBMOAABIIACAFA4AAGAgAIAVDgAAeCAAgBYOAACQIACA IQ4AAKggAIAiDgAAwCAAgHEOAADYIACAgQ4AAPAgAICCDgAACCEAgPEOAAAgIQCA8g4AADgh AIABDwAAUCEAgBEPAABoIQCAAAAAAAAAAAAAAAAAAAABAAEAAACAIQCAAAAAAAAAAAAAAAAA AAABAKYEAACYIQCAAAAAAAAAAAAAAAAAAAAoAAEAAACwIQCAYwAAAMghAICbAAAA4CEAgJwA AAD4IQCApQAAABAiAICtAAAAKCIAgK8AAABAIgCAsAAAAFgiAICxAAAAcCIAgLIAAACIIgCA swAAAKAiAIC0AAAAuCIAgLwAAADQIgCAvQAAAOgiAIC+AAAAACMAgL8AAAAYIwCAwAAAADAj AIDBAAAASCMAgMIAAABgIwCAxgAAAHgjAIDIAAAAkCMAgM0AAACoIwCAzgAAAMAjAIDrAAAA 2CMAgO8AAADwIwCA/wAAAAgkAIARAQAAICQAgBwBAAA4JACAHQEAAFAkAIAiAQAAaCQAgEgB AACAJACAiBMAAJgkAICJEwAAsCQAgIoTAADIJACAixMAAOAkAICMEwAA+CQAgI0TAAAQJQCA jhMAACglAICPEwAAQCUAgJATAABYJQCAAAAAAAAAAAAAAAAAAAABAAEAAABwJQCAAAAAAAAA AAAAAAAAAAAGAKoAAACIJQCArgAAAKAlAICzAAAAuCUAgLQAAADQJQCAxwAAAOglAID4AAAA ACYAgAAAAAAAAAAAAAAAAAAAAQABAAAAGCYAgAAAAAAAAAAAAAAAAAAAAQAJBAAAMCYAAAAA AAAAAAAAAAAAAAAAAQAJBAAAQCYAAAAAAAAAAAAAAAAAAAAAAQAJBAAAUCYAAAAAAAAAAAAA AAAAAAAAAQAJBAAAYCYAAAAAAAAAAAAAAAAAAAAAAQAJBAAAcCYAAAAAAAAAAAAAAAAAAAAA AQAJBAAAgCYAAAAAAAAAAAAAAAAAAAAAAQAJBAAAkCYAAAAAAAAAAAAAAAAAAAAAAQAJBAAA oCYAAAAAAAAAAAAAAAAAAAAAAQAJBAAAsCYAAAAAAAAAAAAAAAAAAAAAAQAJBAAAwCYAAAAA AAAAAAAAAAAAAAAAAQAJBAAA0CYAAAAAAAAAAAAAAAAAAAAAAQAJBAAA4CYAAAAAAAAAAAAA AAAAAAAAAQAJBAAA8CYAAAAAAAAAAAAAAAAAAAAAAQAJBAAAACcAAAAAAAAAAAAAAAAAAAAA AQAJBAAAECcAAAAAAAAAAAAAAAAAAAAAAQAJBAAAICcAAAAAAAAAAAAAAAAAAAAAAQAJBAAA MCcAAAAAAAAAAAAAAAAAAAAAAQAJBAAAQCcAAAAAAAAAAAAAAAAAAAAAAQAJBAAAUCcAAAAA AAAAAAAAAAAAAAAAAQAJBAAAYCcAAAAAAAAAAAAAAAAAAAAAAQAJBAAAcCcAAAAAAAAAAAAA AAAAAAAAAQAJBAAAgCcAAAAAAAAAAAAAAAAAAAAAAQAJBAAAkCcAAAAAAAAAAAAAAAAAAAAA AQAJBAAAoCcAAAAAAAAAAAAAAAAAAAAAAQAJBAAAsCcAAAAAAAAAAAAAAAAAAAAAAQAJBAAA wCcAAAAAAAAAAAAAAAAAAAAAAQAJBAAA0CcAAAAAAAAAAAAAAAAAAAAAAQAJBAAA4CcAAAAA AAAAAAAAAAAAAAAAAQAJBAAA8CcAAAAAAAAAAAAAAAAAAAAAAQAJBAAAACgAAAAAAAAAAAAA AAAAAAAAAQAJBAAAECgAAAAAAAAAAAAAAAAAAAAAAQAJBAAAICgAAAAAAAAAAAAAAAAAAAAA AQAAAAAAMCgAAAAAAAAAAAAAAAAAAAAAAQAAAAAAQCgAAAAAAAAAAAAAAAAAAAAAAQAJBAAA UCgAAAAAAAAAAAAAAAAAAAAAAQAJBAAAYCgAAAAAAAAAAAAAAAAAAAAAAQAJBAAAcCgAAAAA AAAAAAAAAAAAAAAAAQAJBAAAgCgAAAAAAAAAAAAAAAAAAAAAAQAJBAAAkCgAAAAAAAAAAAAA AAAAAAAAAQAJBAAAoCgAAAAAAAAAAAAAAAAAAAAAAQAJBAAAsCgAAAAAAAAAAAAAAAAAAAAA AQAJBAAAwCgAAAAAAAAAAAAAAAAAAAAAAQAJBAAA0CgAAAAAAAAAAAAAAAAAAAAAAQAJBAAA 4CgAAAAAAAAAAAAAAAAAAAAAAQAJBAAA8CgAAAAAAAAAAAAAAAAAAAAAAQAJBAAAACkAAAAA AAAAAAAAAAAAAAAAAQAJBAAAECkAAAAAAAAAAAAAAAAAAAAAAQAJBAAAICkAAAAAAAAAAAAA AAAAAAAAAQAJBAAAMCkAAAAAAAAAAAAAAAAAAAAAAQAJBAAAQCkAAAAAAAAAAAAAAAAAAAAA AQAJBAAAUCkAAAAAAAAAAAAAAAAAAAAAAQAJBAAAYCkAAAAAAAAAAAAAAAAAAAAAAQAJBAAA cCkAAAAAAAAAAAAAAAAAAAAAAQAJBAAAgCkAAAAAAAAAAAAAAAAAAAAAAQAJBAAAkCkAAAAA AAAAAAAAAAAAAAAAAQAJBAAAoCkAAAAAAAAAAAAAAAAAAAAAAQAJBAAAsCkAAAAAAAAAAAAA AAAAAAAAAQAJBAAAwCkAAAAAAAAAAAAAAAAAAAAAAQAJBAAA0CkAAAAAAAAAAAAATVqQAAMA AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 4AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAAAUP9eyUF654VBeueFQXrnhXH634VFeueEJfarhSF654VBeuOFVX7nh OkK74XReueF6Vr/hUV654VBeueEZXrnhUmljaFBeueEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABQRQAATAEDAAfG8jcAAAAAAAAAAOAAHwMLAQUMAI4BAAA8AAAAAAAAEC8AAAAQAAAAoAEA AAAAAQAQAAAAAgAABQAAAAUAAAAEAAAAAAAAAADgAQAABgAAAWYCAAIAAIAAAAQAABAAAAAA EAAAEAAAAAAAABAAAAAAAAAAAAAAAHyAAQAYAQAAALABADguAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACwFAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAIAABAB AAAAEAAArAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAARIwBAAAQAAAAjgEA AAYAAAAAAAAAAAAAAAAAACAAAGAuZGF0YQAAALALAAAAoAEAAAgAAACUAQAAAAAAAAAAAAAA AABAAADALnJzcmMAAAA4LgAAALABAAAwAAAAnAEAAAAAAAAAAAAAAAAAQAAAQCfC8jd4AAAA NNBEOIMAAAA00EQ4kAABADBbFzidAAAAhNMrOKcAAAA00EQ4sQAAALjNSTi8AAAANdBEOMkA AAA10EQ41QAAADXQRDjhAAAAN9BEOO0AAAAwWxc4nQAAAMIARzj5AAAANdBEOAQBAAAAAAAA AAAAAE1TVkNSVC5kbGwAQURWQVBJMzIuZGxsAEtFUk5FTDMyLmRsbABOVERMTC5ETEwAR0RJ MzIuZGxsAFVTRVIzMi5kbGwATkVUQVBJMzIuZGxsAFNlY3VyMzIuZGxsAE5URFNBUEkuZGxs AFNITFdBUEkuZGxsAFNIRUxMMzIuZGxsAFJQQ1JUNC5kbGwAVVNFUkVOVi5kbGwAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGos3HdUhtx3UaHbd6yC 23co99t3AKvbd1qR23eJLNt3Xo7bd4/W23fRitt3njLcd7zT23dPGtx3UJrcd+rq23fkkNx3 JSXbd5SW3HcpK9x33CncdwDX23ee1tt3TincdyGX3HcCkdt3HpHbd4LX23cAONx3aYHbd3iA 23dNfdt3OKvbd1WI3Heekdt315Hbd3KG3HfoN9x3doTcd0iD3HdjeNt3dSvbd4fQ23dIk9t3 ENTbd+KJ23e8idt3BDHcdwcx3XeBLdx37NDbd4iw3XcA0tt3mu/bdyaJ23fb1dt3l4nbd44b 3XdwjNx3aonbd+2K23cAAAAAEBf0dwAAAACguOl3ZP3pdw1n6Hegy+l3v9vod/vW6He/QOl3 EGXpd3Pm6Xd4h+h3jGbodxyh6HfW5ul3M2HpdxFJ6Xctbeh34aPodz1B6XeTE+l3vdnod9Dx 6HdUiOh3Mz3pd9dW6Xf+9uh3YLLpdxu06XfkxOl3iunpd/2z6Xdl++h3QqTpd79P6He3lul3 7eLod9td6XdiX+l3OMLpd7KD6XepEep3Fn3od5Su6Hdi2+l306Dod7iq6HemwOh3se7pd1wi 6Hc+qel3AkrpdxNK6Xff7Oh3jKvpd8im6HckSul32kjod0zt6Xejleh3eIHod6Sh6HcPjeh3 far4d0yq+HecSel3Yqrod3rD6Xdczeh3JlHpd1So6XdE8Ol3R0Xpd2mT6XelZOl3SP3odxk8 6Xedhul3iwnpdySN6Hf03eh3ebPpdw8x6XdbdOh3Sqjod+B3+HdVw+h3H1fpdwXC6HcRJOh3 S1bpd2Sy6XeRjut3+77od3RL6Heuy+l3umHpdwAAAACeJgB4dYkCeNz3AHieuwB4cD4AeOod AHgmtAB4cLsDeGo+AHhkPgB4Wj4AeGr1AHgePAB4Vh8AeO4hAHjqYAF44iAAeH30AHjvEgB4 8GIBeJyIAnjfPwB4ByEAeDUmAHg3JwF4kiQAeGsRAHi1MAB4VY8CeJRgAXgIuQB4AAAAAG6k F3VGhhp1xzQXdQAAAABwPb93mhe/dxxEv3doGb93AAAAADR61XeDSNZ3nxbUd/Uf1HeuOtd3 upvVdzya1nfQk9R3wHvUd49M1Hc+k9V3bBbUd54X1Hefqdh3k1fUd15Z1HckWtR3fYbUdxiH 1HcYVdR3zofUd3JV1Hekh9R3QSfUd0qH1HfajdR3glnUdwZG1nc3QtR3AAAAAL2UW3fczmN3 AAAAAJYix3cAAAAAymC+dwAAAADxteF3UDrhd1Im4XduQuF37Gbhd21c4XeusuF3Y2/jd4U2 43fOLOF38CzhdwQ/4XfkfuN31n7jd84K43ddYOF38JThd6Jx4XfwqeF3yKDhd66M43e8ROF3 rqDhd0ti4XewVOF3Kbbhd+Wf4Xf4WeF3un7jdwAAAAAubcF3L+PBdxvqwXfhQsV3AAAAABNu +Hf6cPh32mX5dyYa+XdG5Ph3oiP5d3PJ+HeEzfh3UGb4dyYZ+XfEI/l3iL74dw2B+HdStfh3 ej/4d7EY+Xe8x/h3DSH5d2pE+HdCjvh3prz4d3iF+He9W/l3E1P4d8/s+HcAAAAAAAAAAAAA AAAHxvI3AAAAAAQAAAAQAQAAAAAAAADMAQAAAAAAB8byNwAAAAADAAAAUB0AAAAAAAAQzQEA AAAAAAfG8jcAAAAABgAAAAAAAAAAAAAAYOoBAAAAAAAHxvI3AAAAAAIAAAAbAAAAAAAAAJD+ p/9TAFkAUwBUAEUATQAgAEEARwBFAE4AVAAgAEMATwBNACAAVwBJAE4ARABPAFcAAABTAEEA RwBFAFcASQBOAEQATwBXAEMATABBAFMAUwAAAFQAYQBzAGsAYgBhAHIAQwByAGUAYQB0AGUA ZAAAAAAA/////x4wAAEzMAABWwAgACoAKgAqACoAKgAAACUAVwBpAG4ARABpAHIAJQBcAFMA QwBIAEUARABMAEcAVQAuAFQAWABUAAAATQBhAHgATABvAGcAUwBpAHoAZQBLAEIAAAAAAEwA bwBnAFAAYQB0AGgAAABTAE8ARgBUAFcAQQBSAEUAXABNAGkAYwByAG8AcwBvAGYAdABcAFMA YwBoAGUAZAB1AGwAaQBuAGcAQQBnAGUAbgB0AAAAAAAAAAAAAAAAACIAVABhAHMAawAgAFMA YwBoAGUAZAB1AGwAZQByACAAUwBlAHIAdgBpAGMAZQAiACAAKgAqACAARgBBAFQAQQBMACAA RQBSAFIATwBSACAAKgAqAAoAAAAiAFQAYQBzAGsAIABTAGMAaABlAGQAdQBsAGUAcgAgAFMA ZQByAHYAaQBjAGUAIgAgACoAKgAgAEUAUgBSAE8AUgAgACoAKgAKAAAA/////////38lACUA AAAAAEFQAAHKlwABUwBDAF8AQQB1AHQAbwBTAHQAYQByAHQAQwBvAG0AcABsAGUAdABlAAAA AADlTwABJFAAASRQAAFxUAABSlsBAf////////9/UHJvY2Vzc0lkVG9TZXNzaW9uSWQAAAAA SXNUb2tlblJlc3RyaWN0ZWQAAABBAEQAVgBBAFAASQAzADIALgBEAEwATAAAAAAAU2V0VGhy ZWFkRXhlY3V0aW9uU3RhdGUASwBFAFIATgBFAEwAMwAyAC4ARABMAEwAAAAAAFwAKgAuAGoA bwBiAAAAAABGAGkAcgBzAHQAQgBvAG8AdAAAAE4AbwBQAG8AcAB1AHAAcwBPAG4AQgBvAG8A dAAAAAAAUwB5AHMAdABlAG0AXABDAHUAcgByAGUAbgB0AEMAbwBuAHQAcgBvAGwAUwBlAHQA XABDAG8AbgB0AHIAbwBsAFwAVwBpAG4AZABvAHcAcwAAAAAAbgBjAGEAYwBuAF8AcwBwAHgA AABuAGMAYQBjAG4AXwBpAHAAXwB0AGMAcAAAAAAAbgBjAGEAbAByAHAAYwAAAG4AYwBhAGMA bgBfAG4AcAAAAAAAXABQAEkAUABFAFwAYQB0AHMAdgBjAAAAQQB0AAAAAAAuAGoAbwBiAAAA AAAlAGQAAAAAAFMAYwBoAGUAZAB1AGwAZQAAAAAAXABBAHQAAABTAGgAZQBsAGwAAABTAG8A ZgB0AHcAYQByAGUAXABNAGkAYwByAG8AcwBvAGYAdABcAFcAaQBuAGQAbwB3AHMAIABOAFQA XABDAHUAcgByAGUAbgB0AFYAZQByAHMAaQBvAG4AXABXAGkAbgBsAG8AZwBvAG4AAABlAHgA cABsAG8AcgBlAHIALgBlAHgAZQAAAAAATQBTAEkARABMAEUALgBEAEwATAAAAAAATgBvAEkA ZABsAGUAAAAAANt6AAEAewABAAAAAOOIAAEngAABW38AAfGJAAFQAEEAVABIAAAAAABjAG0A ZAAuAGUAeABlACAALwBjACAAAABSAFUATgBEAEwATAAzADIALgBFAFgARQAgAFMAaABlAGwA bAAzADIALgBEAEwATAAsAFMAaABlAGwAbABFAHgAZQBjAF8AUgB1AG4ARABMAEwAIAA/ADAA eAA0ADAAMAA/AAAALgBlAHgAZQAAAAAAUwBBAFcAaQBuAFMAdABhAFwAUwBBAEQAZQBzAGsA dABvAHAAAAAAAFcAaQBuAFMAdABhADAAXABEAGUAZgBhAHUAbAB0AAAAVQBTAEUAUgBQAFIA TwBGAEkATABFAAAATgBvAEkAbgB0AGUAcgBhAGMAdABpAHYAZQBTAGUAcgB2AGkAYwBlAHMA AAAgAAAAIgAAAFwAAABTAEEATgBTAEMAAABTAGUAQgBhAHQAYwBoAEwAbwBnAG8AbgBSAGkA ZwBoAHQAAABPAGwAZABOAGEAbQBlAAAAUwBBAFcAaQBuAFMAdABhAAAAAABTAEEARABlAHMA awB0AG8AcAAAAAAAAABEAAAAsFKON6nAzxGCLQCqAFHkDwEAAAAEXYiK6xzJEZ/oCAArEEhg AgAAAMigAQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAGwABCl0BAV9kAQEAAAAAAAAAAAAA AAAAAAAAAAAAAGIcAAEBAAAAAQABAAAAAAAXAQMFAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAA AAAAAAAATQECAE0BBgBNAQYATQECAE4IUwhNAQIATQECAE0BAgBTCE0BAgBOCFABCgBTCE0B AgBNAQYATghQARQAUwgAAAAAAAAAAAAAAAASCCVcEQglXBsBAgApAAQABVsbAQIAKQAIAAVb AAAAAAAAAAD/////AAAAANG+AAEAAAAAB74AATG+AAH/////AAAAAHbAAAEAAAAAtb8AAd+/ AAH/////AAAAAG/CAAEAAAAAYsEAAYzBAAH/////AAAAAIXEAAEAAAAAdcMAAZ/DAAFEAAAA ggb3H1EK6DAHbXQL6M7piwEAAAAEXYiK6xzJEZ/oCAArEEhgAgAAAPigAQEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADoHAABCl0BAV9kAQEAAAAAAAAAAAAAAAAAAAAAAAAAAMIdAAEBAAAA AQABAAAAAAAXAQMFAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAATQECAE0BBgBRASIA UwhNAQIATghOCFMITQECAFABJgBOCFEBIgBQAXgAUwhNAQIATghRAXwAUwgAAAAAAAAAAAAA EgglXBEBAgAWAxAAS1xGXAwADAASCCVcWwgIAgI4CFsRDAhcEQA8ABYDFABLXEZcEAAQABII JVxbCAgIAgI4CFxbGwMUABkAAABLXEhJFAAAAAEAEAAQABIIJVxbTADJ/1sWAwgAS1xGXAQA BAASAdL/WwgIWxIICFwRFAIAEgGI/wAA/////wAAAAAkxgABAAAAAEvFAAF1xQAB/////wAA AADTxwABAAAAABPHAAE9xwAB/////wAAAAArygABAAAAAN7IAAEIyQAB/////wAAAAAjzAAB AAAAAA3LAAE3ywABUwB5AHMAdABlAG0AXABDAHUAcgByAGUAbgB0AEMAbwBuAHQAcgBvAGwA UwBlAHQAXABDAG8AbgB0AHIAbwBsAFwATABzAGEAAAAAAAAAAABTAHUAYgBtAGkAdABDAG8A bgB0AHIAbwBsAAAAAAAAAC4AYwBtAGQAAAAuAGIAYQB0AAAALgBwAGkAZgAAAC4AZQB4AGUA AAAuAGMAbwBtAAAAAAAAAAAA/////6HUAAGl1AABAAAAAP////////9/XAAAAGAAAABkAA=9 --Xt9J879ejO0E08-- From owner-ips@ece.cmu.edu Wed May 15 11:59:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10896 for ; Wed, 15 May 2002 11:59:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4FFCI607942 for ips-outgoing; Wed, 15 May 2002 11:12:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4FBBQw20455 for ; Wed, 15 May 2002 07:11:26 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25596; Wed, 15 May 2002 07:11:12 -0400 (EDT) Message-Id: <200205151111.HAA25596@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-fcip-wglc-02.txt,.pdf Date: Wed, 15 May 2002 07:11:11 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : FCIP 1st WG Last Call Author(s) : R. Weber Filename : draft-ietf-ips-fcip-wglc-02.txt,.pdf Pages : 72 Date : 14-May-02 This ips (IP Storage) working group draft contains all the working group last call comments received regarding: draft-ietf-ips-fcovertcpip-09.txt The proposed disposition of each comment also is recorded in this draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-fcip-wglc-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-fcip-wglc-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020514141755.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcip-wglc-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcip-wglc-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020514141755.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed May 15 13:35:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15001 for ; Wed, 15 May 2002 13:35:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4FGqXK16449 for ips-outgoing; Wed, 15 May 2002 12:52:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4FGqTw16442 for ; Wed, 15 May 2002 12:52:29 -0400 (EDT) Received: from inet-mail3.oracle.com (localhost [127.0.0.1]) by inet-mail3.oracle.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4FGpNX03451 for ; Wed, 15 May 2002 09:51:23 -0700 (PDT) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail3.oracle.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4FGpMM03435 for ; Wed, 15 May 2002 09:51:22 -0700 (PDT) Received: from RAJAUS (dhcp-4ip3-4ip4-west-130-35-146-111.us.oracle.com [130.35.146.111]) by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g4FGqLE08488 for ; Wed, 15 May 2002 10:52:21 -0600 (MDT) From: "Raja Srinivasan" To: Subject: Viruses on the iSCSI mail List Date: Wed, 15 May 2002 09:44:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Folks: The iSCSI mail list has been compromised. I am getting at least 2 viruses a day. I urge all of you to update your virus protection software before posting any new messages to the iscsi mail list. Thanks & Regards Raja Srinivasan From owner-ips@ece.cmu.edu Wed May 15 14:42:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17347 for ; Wed, 15 May 2002 14:42:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4FINjR24523 for ips-outgoing; Wed, 15 May 2002 14:23:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4FINfw24514 for ; Wed, 15 May 2002 14:23:41 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel9.hp.com (Postfix) with ESMTP id 5C87B8053E4; Wed, 15 May 2002 14:23:35 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id LAA00759; Wed, 15 May 2002 11:25:20 -0700 (PDT) Message-ID: <004a01c1fc3d$9f5818c0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "chhavi_garg" , "Julian Satran" Cc: References: <200205150742.NAA12942@WS0005.indiatimes.com> Subject: Re: iSCSI: Logout and recovery notes Date: Wed, 15 May 2002 11:23:33 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0047_01C1FC02.F2C0A490" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C1FC02.F2C0A490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Hi Mallikarjun, > > > I've a confusion regarding the mapping of Logout reason codes that you have refered in the mail attached below. I thought I had responded to a private email query, but perhaps it didn't get through (our email server was briefly down). Here it is attached. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ------=_NextPart_000_0047_01C1FC02.F2C0A490 Content-Type: message/rfc822; name="Re_ iSCSI_ Logout and recovery notes.eml" Content-Disposition: attachment; filename="Re_ iSCSI_ Logout and recovery notes.eml" From: "Mallikarjun C." To: "chhavi_garg" , "Julian Satran" References: <200205131203.RAA10092@WS0005.indiatimes.com> Subject: Re: iSCSI: Logout and recovery notes Date: Mon, 13 May 2002 08:35:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Chhavi, comments below. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "chhavi_garg" To: "Mallikarjun C" ; "Julian Satran" Sent: Monday, May 13, 2002 5:10 AM Subject: Re: iSCSI: Logout and recovery notes > > > > Hello Mallikarjun, > > > I've a confusion regarding the mapping of reason codes that you have refered in the mail attached below. > > > You have written, > > > > The entire logout discussion in this section is completely applicable also > for an implicit Logout effected by way of a connection reinstatement or > session reinstatement. The Logout reason codes for implicit Logout are > specified as below - > > > > Reason code Type of implicit Logout > 0 session reinstatement > 1 connection reinstatement when the operational ErrorRecoveryLevel < 2 > 2 connection reinstatement when the operational ErrorRecoveryLevel = 2 > > > As per my understanding, in case of implicit logout i,e in CSM-I scenario, We will proceed with Login request with the same CID in case of connection reinstatement And that has two sub-cases as listed above. A connection reinstatement for a session whose ErrorRecoveryLevel = 2, and < 2. Each of those "context-sensitive" connection reinstatements imply an implicit Logout with a different reason code - per the new text. >and with TSIH=0 in case of session reinstatement. When will we send the Logout request with the above reason code in this scenario ?? > > > -regards, > > > Chhavi. > > "Mallikarjun C." wrote: > > > > Julian, > > A couple of notes - > > 1. Section 9.14 (last para on page 170) still contains references > to the restart option of the Login command - they should be > removed. > > 2. The following text in the next paragraph says that some unacknowledged > commands may be discarded on a Logout. Since some of the unacknowledged > commands may be instantiated and could legally be reassigned by virtue of being > active tasks (just like acknowledged commands), I suggest we make the current > text more specific to exclude that case by rewording the current sentence - > > "Sending a logout request with the reason code of "close the connection" or "remove the connection for > recovery" may result in the discarding of some unacknowledged commands." > > to: > > "A successful completion of a logout request with the reason code of "close the connection" or "remove the > connection for recovery" results in the discarding of all tasks waiting in the command reordering queue that > are allegiant to the connection being logged out." > > 3. In general, the Logout section should add text along the lines of - > > The entire logout discussion in this section is completely applicable also > for an implicit Logout effected by way of a connection reinstatement or > session reinstatement. The Logout reason codes for implicit Logout are > specified as below - > Reason code Type of implicit Logout > 0 session reinstatement > 1 connection reinstatement when the operational ErrorRecoveryLevel < 2 > 2 connection reinstatement when the operational ErrorRecoveryLevel = 2 > > 4. It seems to me that continuing text tasks across connection failures is prone > to error since some of the negotiated ones can be CO, and some can be (perhaps > vendor-unique) SW. The discussion on text negotiation (probably section 9.10) > should add text along the lines of - > > On a connection failure, an initiator must either explicitly abort any active allegiant > text negotiation task or must cause such a task to be implicitly terminated by the target. > > > Regards. > > Mallikarjun > > > > Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com > Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in > ------=_NextPart_000_0047_01C1FC02.F2C0A490-- From owner-ips@ece.cmu.edu Wed May 15 14:44:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17466 for ; Wed, 15 May 2002 14:44:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4FI4kc22967 for ips-outgoing; Wed, 15 May 2002 14:04:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4FI4dw22962 for ; Wed, 15 May 2002 14:04:39 -0400 (EDT) Received: from chamao (chamao [147.11.45.39]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id LAA01929; Wed, 15 May 2002 11:03:14 -0700 (PDT) From: "Michael Krueger" To: "Bill Studenmund" , Subject: RE: iSCSI: BASE64 and numerical values Date: Wed, 15 May 2002 11:04:16 -0700 Message-ID: <007501c1fc3a$ed2a2730$272d0b93@chamao.wrs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > So I'd like to suggest we disallow using base64 to encode numbers. > Byte-swapping an arbitrary-length byte stream seems really messy. > Alternatively, I'd like to suggest we constrain base64-encoded numbers to > be 1, 2, 4, or 8 bytes long when decoded, and to be in network byte order. Bill, thanks for bringing this up, because I wanted to make the same point. Implementing base-64 encoding for numbers is a fair amount of work for very little benefit--no, let me be blunt: for ZERO benefit. As I understand it, the whole idea of the text-based login was to make it human-readable and to allow cutting and pasting of values from, say, a management console. Maybe I lack imagination, but I cannot conceive of any real-world circumstance under which a NUMBER would be displayed on a console or entered by a human (except, perhaps, by a pathologically mischievous one ;-) in base-64 encoding. A BINARY ITEM, yes, but a NUMBER, never. Let's keep it simple: decimal and hexadecimal for numbers, hexadecimal and base 64 for binary items. Michael -- Michael J. Krueger mailto:michael.krueger@windriver.com Wind River Networks http://www.windriver.com 500 Wind River Way phone: 510-749-2130 Alameda, CA 94501 fax: 510-749-2010 From owner-ips@ece.cmu.edu Wed May 15 14:46:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17525 for ; Wed, 15 May 2002 14:46:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4FIaO625702 for ips-outgoing; Wed, 15 May 2002 14:36:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4FIaLw25696 for ; Wed, 15 May 2002 14:36:21 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id LAA19030; Wed, 15 May 2002 11:36:13 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 11:36:13 -0700 Message-ID: From: Brian Forbes To: "'roweber@acm.org'" , IPS Reflector Subject: RE: FCIP Comment 44 - Proposed text for new section Date: Wed, 15 May 2002 11:36:10 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I didn't see a lot of traffic on this. I think it's both well-written amd useful, and should stave off certain classes of future questions. Brian Forbes Brocade Communications -----Original Message----- From: Ralph Weber [mailto:ralphoweber@compuserve.com] Sent: Friday, May 10, 2002 5:47 AM To: IPS Reflector Subject: FCIP Comment 44 - Proposed text for new section The following is the text proposed for the new FCIP section that is described in the response to Last Call comment 44. 8.2 Overview of FSF Usage in Connection Establishment When a new TCP Connection is established, an FCIP Special Frame makes one round trip from the FCIP Entity initiating the TCP connect operation to the FCIP Entity receiving the TCP connect request and back. This FSF usage serves three functions: - Identification of the FCIP Link endpoints - Conveyance of a few critical parameters shared by the FC/FCIP Entity pairs involved in the FCIP Link - Configuration discovery (used in place of SLP only when allowed by site security policies) The specific requirements for this usage of the FSF are found in section 9.1. This section provides an overview of the FSF usage without stating requirements. Because FCIP is only a tunnel for a Fibre Channel Fabric and because the Fabric has its own complex link setup algorithm that can be employed for many FCIP link setup needs, it is desirable to minimize the complexity of the FSF usage during TCP Connection setup. With this in mind, this FSF usage is not a login or parameter negotiation mechanism. A single FSF transits each newly established TCP connection as the first bytes sent in each direction. Note: This usage of the FSF cannot be eliminated entirely because a newly created TCP Connection must be associated with the correct FCIP Link before FC Fabric initialization of the connection can commence. The first bytes sent from the TCP connect request initiator to the receiver are an FSF identifying both the sender and who the sender thinks is the receiver. If the contents of this FSF are correct and acceptable to the receiver, the unchanged FSF is echoed back to the sender. This send/echo process is the only set of actions that allows the TCP Connection to be used to carry FC Fabric traffic. If the send and unchanged echo process does not occur, the algorithm followed at one or both ends of the TCP Connection results in the closure of the TCP Connection (see section 9.1 for specific algorithm requirements). Note: Owing to the limited manner in which the FSF is used and the requirement that the FSF be echoed without changes before a TCP Connection is allowed to carry user data, no error checking beyond that provided by TCP is deemed necessary. As described above, the primary purpose of the FSF usage during TCP Connection setup is identifying the FCIP Link to which the new TCP Connection belongs. From these beginnings, it is only a small stretch to envision using the FSF as a simplified configuration discovery tool, and the mechanics of such a usage are described in section 9.1. However, use of the FSF for configuration discovery lacks the broad range of capabilities provided by SLP v2 and most particularly lacks the security capabilities of SLP v2. For these reasons, using the FSF for configuration discovery is not appropriate for all environments. Thus the choice to use the FSF for discovery purposes is a policy choice to be included in the TCP Connection Establishment "shared" database described in section 9.1.1. When FSF-based configuration discovery is enabled, the normal TCP Connection setup rules outlined above are modified as follows. Normally, the algorithm executed by an FCIP Entity receiving an FSF includes verifying that its own identification information in the arriving FSF is correct and closing the TCP Connection if it is not. This can be viewed as requiring the initiator of a TCP connect request to know in advance the identity of the FCIP Entity that is the target of that request (using SLP, for example), and through the FSF effectively saying, "I think I'm talking to X." If the party at the other end of the TCP connect request is really Y, then it simply hangs up. FSF-based discovery allows the "I think I'm talking to X" to be replaced with "Please tell me who I am talking to?", which is accomplished by replacing an explicit value in the Destination FC Fabric Entity World Wide Name field with zero. If the policy at the receiving FCIP Entity allows FSF-based discovery, the zero is replaced with the correct Destination FC Fabric Entity World Wide Name value in the echoed FSF. This is still subject to the rules of sending with unchanged echo, and so closure of TCP Connection occurs after the echoed FSF is received by the TCP connect initiator. Despite the TCP Connection closure, however, the TCP connect initiator now knows the correct Destination FC Fabric Entity World Wide Name identity of the FCIP Entity at a given IP Address and a subsequent TCP Connection setup sequence probably will be successful. The Ch bit in the pFlags field (see section 6.6.1) allows for differentiation between changes in the FSF resulting from transmission errors and changes resulting from intentional acts by the FSF recipient. From owner-ips@ece.cmu.edu Wed May 15 16:15:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20984 for ; Wed, 15 May 2002 16:15:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4FJY1I00762 for ips-outgoing; Wed, 15 May 2002 15:34:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (ultrex.nishansystems.com [12.36.127.195]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4FJXww00754 for ; Wed, 15 May 2002 15:33:59 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 12:33:53 -0700 Message-ID: From: Charles Monia To: ips@ece.cmu.edu Subject: RE: iFCP: Responses to David Black iFCP Technical review comment s Date: Wed, 15 May 2002 12:33:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Will do. Charles > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Wednesday, May 15, 2002 12:46 AM > To: cmonia@NishanSystems.com; ips@ece.cmu.edu > Subject: RE: iFCP: Responses to David Black iFCP Technical review > comment s > > > Say that with an upper case MUST for local emulation and a MUST > NOT for forwarding of loop primitives between iFCP gateways > and this issue is closed. > > Thanks, > --David > > > -----Original Message----- > > From: Charles Monia [mailto:cmonia@NishanSystems.com] > > Sent: Tuesday, May 14, 2002 8:01 PM > > To: ips@ece.cmu.edu > > Subject: RE: iFCP: Responses to David Black iFCP Technical review > > comment s > > > > > > Hi: > > > > I believe the rule for arbitrated loop support is that loop > > primitives must > > be emulated by the local gateway. The iFCP protocol does not > > support the > > forwarding of loop control primitives to a remote gateway for > > emulation. > > > > Charles > > > -----Original Message----- > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > Sent: Monday, May 13, 2002 11:52 PM > > > To: cmonia@NishanSystems.com; ips@ece.cmu.edu > > > Subject: RE: iFCP: Responses to David Black iFCP Technical review > > > comment s > > > > > > > > > I think this is the crucial point: > > > > > > > The primitives with the behavior you ascribe to LINIT are > > > those such as > > > LIRP > > > > (Loop Initialization Report Position) and LILP (Loop > > > Initialization Loop > > > > Position), which are frames serviced sequentially as they > > > flow though > > > > NL_Ports on the loop. The loop primitive semantics may > > > emulated locally by > > > > the gateway implementation and need not be propagated by > > > iFCP. How the > > > > gateway populates the loop with emulated NL_Ports is up to the > > > > implementation. > > > > > > Yes, I did get confused about which primitive was which ... > > > The important thing to state here is that an iFCP > > > implementation MUST NOT > > > forward LIRP, LILP and the like over IP. The result is that > > > an FC-AL loop > > > cannot include any iFCP inter-gateway links, and the topology > > > discussion > > > of how iFCP participates in an FC fabric needs to reflect this. > > > > > > The resolution of the "port behind multiple gateways" issue > > looks ok. > > > > > > Thanks, > > > --David > > > --------------------------------------------------- > > > David L. Black, Senior Technologist > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > > black_david@emc.com Cell: +1 (978) 394-7754 > > > --------------------------------------------------- > > > > > > From owner-ips@ece.cmu.edu Wed May 15 16:15:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21004 for ; Wed, 15 May 2002 16:15:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4FJhb301745 for ips-outgoing; Wed, 15 May 2002 15:43:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4FJhXw01731 for ; Wed, 15 May 2002 15:43:33 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel13.hp.com (Postfix) with ESMTP id 83066400422; Wed, 15 May 2002 12:43:27 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA16673; Wed, 15 May 2002 12:45:11 -0700 (PDT) Message-ID: <007401c1fc48$c7283370$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Ken Sandars" , "Julian Satran" Cc: References: <200205141703.SAA14331@best.eurologic.com> Subject: Re: iSCSI: Feeling a little peckish? Date: Wed, 15 May 2002 12:43:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ken, Here's my take on the usage expectations (where a feature has implementation expectations, I commented below) - > TARGET's perspective: > > SNACK type ERL=0 ERL>0 > ------------------------------------------------------------------ > status optional mandatory* > (silently discard) Correct. But I'd suggest that the target *not* silently discard the SNACK. I propose that the Reject reason code be simply named as "SNACK Reject" (i.e. drop "Data-"). The reason code was specific about data because status SNACK support was mandatory way back, and I suspect the description simply remained that way even now. FYI, the only "silent" discard we had allowed in the past was on the "premature SNACKs" (look at changelog b/n rev6 to rev7), but we then decided target should send back a reject even then (protocol error). > > data/r2t optional mandatory > (reject, > reason=3) More good reason to rename the reason code description - since it could cover R2Ts as you point out, not just data. > > data ACK optional optional > (target never > sets the A bit) I would call the first column as "must-not" than "optional". > > > * Para 9.16.2 states that 'if the target supports recovery within connection, > it MAY discard the SNACK after which it MUST issue an Asynchronous Message > PDU with an iSCSI event that indicates "Request Logout"'. > > Question: Is support for "recovery within connection" mandatory if the ERL > has been negotiated to be > 0? Yes, look at section 6.13 - for the definition of "digest failure recovery". > > > To complete the picture, > > INITIATOR's perspective: > > SNACK type ERL=0 ERL>0 > ------------------------------------------------------------------ > status optional mandatory** > > data/r2t optional mandatory** > > data ACK optional mandatory > (can ignore the A bit) > > > ** As the SNACK is sent by the initiator, it is up to it to decide whether to > do this, or to escalate recovery. Is this more of a SHOULD support than a > MUST, or am I missing something? It is legally a "MUST-implement-MAY-use", if the initiator had promised ErrorRecoveryLevel > 0 in the negotiation. Despite the promise, initiator ofcourse has the option to resort to a "bigger hammer" on *any* error. So to summarize, targets may never really ascertain if the initiator really has the SNACK capability, that was implied by "ErrorRecoveryLevel=1". The negotiation of >0 really puts the onus on targets to meet the expectations. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com From owner-ips@ece.cmu.edu Wed May 15 18:51:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24801 for ; Wed, 15 May 2002 18:51:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4FLqYY12635 for ips-outgoing; Wed, 15 May 2002 17:52:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4FLmIw12269 for ; Wed, 15 May 2002 17:48:18 -0400 (EDT) Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 82C655B3D; Wed, 15 May 2002 17:48:17 -0400 (EDT) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 May 2002 16:45:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Viruses on the iSCSI mail List Date: Wed, 15 May 2002 16:45:36 -0500 Message-ID: <31891B757C09184BBFEC5275F85D5595104E7B@cceexc18.americas.cpqcorp.net> Thread-Topic: Viruses on the iSCSI mail List Thread-Index: AcH8MqA4ZnnoPpW0T3SAZ+nQksb3awAJg1PQ From: "Martin, Nick" To: "Raja Srinivasan" , X-OriginalArrivalTime: 15 May 2002 21:45:37.0725 (UTC) FILETIME=[D9AB36D0:01C1FC59] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g4FLmIw12272 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit All: Please also note that many of us are behind a strict corporate mail gateway. If your message looks like it has a virus, it will be discarded at the gateway. I have not seen any viruses, but that probably means I am not seeing all messages. Thanks, Nick > -----Original Message----- > From: Raja Srinivasan [mailto:raja.srinivasan@oracle.com] > Sent: Wednesday, May 15, 2002 11:44 AM > To: ips@ece.cmu.edu > Subject: Viruses on the iSCSI mail List > > > Folks: > The iSCSI mail list has been compromised. I am getting at > least 2 viruses a > day. I urge all of you to update your virus protection > software before > posting any new messages to the iscsi mail list. > > Thanks & Regards > Raja Srinivasan > > From owner-ips@ece.cmu.edu Wed May 15 22:33:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00872 for ; Wed, 15 May 2002 22:33:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4G1wXK28630 for ips-outgoing; Wed, 15 May 2002 21:58:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2ab.compuserve.com (siaar2ab.compuserve.com [149.174.40.138]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4G1wUw28625 for ; Wed, 15 May 2002 21:58:30 -0400 (EDT) Received: (from mailgate@localhost) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id VAA11845 for ips@ece.cmu.edu; Wed, 15 May 2002 21:58:18 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkq-vty38.as.wcom.net [216.192.228.38]) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id VAA11830 for ; Wed, 15 May 2002 21:58:13 -0400 (EDT) Message-ID: <3CE3129B.848EEFD2@compuserve.com> Date: Wed, 15 May 2002 20:59:55 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: FCIP comments resolution -02 posted Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The -02 revision of the FCIP comments resolution draft has been posted as: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-02.txt http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-02.pdf The PDF file contains change bars showing the differences from the -01 revision. I believe that -02 addresses all the issues Mallikarjun, David, Murali, and I have been discussing on this list. The -02 revision also contains the full text of the new section describing the FSF usage for TCP Connection setup. This text was posted separately to this list a few days ago. If you have issues with the -02 FCIP comments resolution, please post them to this list with FCIP and the comment number in the subject. Thanks. .Ralph From owner-ips@ece.cmu.edu Thu May 16 03:56:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16719 for ; Thu, 16 May 2002 03:56:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4G74Il17459 for ips-outgoing; Thu, 16 May 2002 03:04:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ecbull20.frec.bull.fr (ecbull20.frec.bull.fr [129.183.4.3]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4G74Gw17452 for ; Thu, 16 May 2002 03:04:16 -0400 (EDT) Received: from mailpop.frec.bull.fr (mailpop [129.183.4.4]) by ecbull20.frec.bull.fr (8.9.2/8.9.1) with ESMTP id JAA15334; Thu, 16 May 2002 09:04:11 +0200 Received: from bull.net (pattein.frec.bull.fr [129.183.148.132]) by mailpop.frec.bull.fr (8.9.2/8.9.2) with ESMTP id JAA13004; Thu, 16 May 2002 09:04:09 +0200 Message-ID: <3CE35A00.7E7907E6@bull.net> Date: Thu, 16 May 2002 09:04:32 +0200 From: Claude PATTEIN Reply-To: Claude.Pattein@bull.net Organization: BULL SA Echirolles / Storage & Comms X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: fr,en MIME-Version: 1.0 To: ips@ece.cmu.edu CC: Raja Srinivasan Subject: Re: Viruses on the iSCSI mail List References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I received also, yesterday, an email from ips reflector, with in Subject : " A very excite game ", and including 3 viruses 'W32/Klez-G'. Please, Take care Best Regards Claude PATTEIN Raja Srinivasan wrote: > > Folks: > The iSCSI mail list has been compromised. I am getting at least 2 viruses a > day. I urge all of you to update your virus protection software before > posting any new messages to the iscsi mail list. > > Thanks & Regards > Raja Srinivasan -- From owner-ips@ece.cmu.edu Thu May 16 12:32:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01137 for ; Thu, 16 May 2002 12:32:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4GFekF02546 for ips-outgoing; Thu, 16 May 2002 11:40:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4GFeiw02539 for ; Thu, 16 May 2002 11:40:44 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4GEdTl30954; Thu, 16 May 2002 10:39:29 -0400 Message-ID: <3CE3D2ED.42E6A7AB@splentec.com> Date: Thu, 16 May 2002 11:40:29 -0400 From: Luben Tuikov Reply-To: iSCSI , Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran , iSCSI Subject: Various notes on 12-90 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Varios notes on 12-90 (ch. 0 to 2.3): 0. page 26, SSID definition, last sentence should read: The TargetPortalGroupTag key is also returned by the target as a confirmation during session establishment. Change: may -> is, since it actually is SHOULD or MUST depending on the capabilites of the target. 1. page 29: 2.2, first paragraph, last sentence should be: iSCSI also uses the request-response mechanism for iSCSI protocol mechanisms. Change: missing a hyphen between ``request'' and ``response''. 2. page 29: 2.2, 5th paragraph should read: The iSCSI transfer direction is defined with respect to the initiator. Outbound or outgoing transfers are transfers from an initiator to a target, while inbound or incoming transfers are from a target to an initiator. Changes: regard -> respect, first used in social sciences, second in technical/mathematical documentation. Missing an indefinite article a/an before ``target'' and ``initiator''; twice each. 3. page 29: 2.2.1, first item, at the end: possible missing conclusion, found only this: ``... parameters (cf. SAM2) to/from ->.'' ``->.'' should be ``see the next item.'' OR ``the iSCSI layer.'' 4. page 31: 2.2.2.1, first change bar: there is an extra ``the'' before CmdSN. 5. page 31: 2.2.2.1, second change bar: missing comma after ``explicit rule''. Also ``(see later in this section)'' should probably refer to ``(see CmdSN assignment later in this section)'', since the text refers to CmdSN assignment for immediate delivery commands. I.e. the sentence should read: Whenever CmdSN for an outgoing PDU is not specified by an explicit rule, CmdSN will carry the current value of the local CmdSN register (see CmdSN assignment later in this section). 6. page 32: 2.2.2.1: at the top, quoting: Beyond the scope of this document is the means by which one may request immediate delivery for a command ... But commands can be marked for immediate delivery by setting I = 1, no? Maybe the first part of this sentence should be clarified. 7. page 33: 2.2.2.1: second paragraph at the top, the first sentence should read: The target MUST NOT transmit a MaxCmdSN that is less than ExpCmdSN-1. That is, the queueing capacity at the target should be greater than or equal to 0. Change: removed ``last'' and added a queue length clarifying sentence. 8. page 33: 2.2.2.1: middle, the last two items and the conclusion, should read: - If the PDU MaxCmdSN is greater than the local MaxCmdSN (in Serial Arithmetic Sense), it updates the local MaxCmdSN; otherwise, it is ignored. - If the PDU ExpCmdSN is greater than the local ExpCmdSN (in Serial Arithmetic Sense), it updates the local ExpCmdSN; otherwise, it is ignored. This sequence should be observed because updates may arrive out of order, being that they travel on different TCP connections. Change: there is no point in updating a value by another, when they are equal, i.e. no actual update takes place. 9. page 38: 2.2.4, first sentence of the last paragraph on the page, should probably read: A target SHOULD NOT silently discard data and thus request retransmission through R2T. Change: included ``thus'', clarifying the cause-effect relationship. 10. page 41: 2.2.6.1, second item list, item c), last sentence should read: Whitespace characters are not allowed. Change: as per NDT. ``be'' -> ``not''. 11. page 48: 2.2.8.2, last paragraph, last sentence is missing a period. -- Luben From owner-ips@ece.cmu.edu Thu May 16 14:56:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06337 for ; Thu, 16 May 2002 14:56:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4GIMJB15729 for ips-outgoing; Thu, 16 May 2002 14:22:19 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4GIMEw15708; Thu, 16 May 2002 14:22:15 -0400 (EDT) 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 g4GIM8M8055614; Thu, 16 May 2002 20:22:08 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4GIM7S47774; Thu, 16 May 2002 20:22:07 +0200 To: "Lakshmi Ramasubramanian" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: TargetAddress format X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 16 May 2002 21:21:58 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 16/05/2002 21:22:07, Serialize complete at 16/05/2002 21:22:07 Content-Type: multipart/alternative; boundary="=_alternative 0063D538C2256BBB_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0063D538C2256BBB_= Content-Type: text/plain; charset="us-ascii" That is an IPV6 address - Julo "Lakshmi Ramasubramanian" Sent by: owner-ips@ece.cmu.edu 05/16/2002 08:58 PM Please respond to "Lakshmi Ramasubramanian" To: cc: Subject: iSCSI: TargetAddress format The format of TargetAddress (Section 11.8) is given as TargetAddress=domainname[:port][,portal-group-tag] In the examples given TargetAddress=[1080:0:0:0:8:800:200C:417A],65 TargetAddress=[1080::8:800:200C:417A]:5003,1 What does the value within brackets indicate? Is it an IPv6 address? thanks! -lakshmi --=_alternative 0063D538C2256BBB_= Content-Type: text/html; charset="us-ascii"
That is an IPV6 address - Julo


"Lakshmi Ramasubramanian" <nramas@windows.microsoft.com>
Sent by: owner-ips@ece.cmu.edu

05/16/2002 08:58 PM
Please respond to "Lakshmi Ramasubramanian"

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: TargetAddress format

       


The format of TargetAddress (Section 11.8) is given as
 
 TargetAddress=domainname[:port][,portal-group-tag]
 
In the examples given
 
 TargetAddress=[1080:0:0:0:8:800:200C:417A],65
 TargetAddress=[1080::8:800:200C:417A]:5003,1
 
What does the value within brackets indicate? Is it
an IPv6 address?
 
thanks!
-lakshmi

--=_alternative 0063D538C2256BBB_=-- From owner-ips@ece.cmu.edu Thu May 16 14:57:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06426 for ; Thu, 16 May 2002 14:57:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4GIMQm15735 for ips-outgoing; Thu, 16 May 2002 14:22:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4GIMHw15722 for ; Thu, 16 May 2002 14:22:17 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4GIM7wY020900; Thu, 16 May 2002 20:22:11 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4GILxS47772; Thu, 16 May 2002 20:21:59 +0200 To: iSCSI , Luben Tuikov MIME-Version: 1.0 Subject: Re: Various notes on 12-90 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 16 May 2002 21:21:58 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 16/05/2002 21:22:07, Serialize complete at 16/05/2002 21:22:07 Content-Type: multipart/alternative; boundary="=_alternative 006383D6C2256BBB_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006383D6C2256BBB_= Content-Type: text/plain; charset="us-ascii" thanks - Julo --=_alternative 006383D6C2256BBB_= Content-Type: text/html; charset="us-ascii"
thanks - Julo --=_alternative 006383D6C2256BBB_=-- From owner-ips@ece.cmu.edu Thu May 16 15:00:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06491 for ; Thu, 16 May 2002 15:00:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4GHx1T13658 for ips-outgoing; Thu, 16 May 2002 13:59:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4GHwvw13646 for ; Thu, 16 May 2002 13:58:57 -0400 (EDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 16 May 2002 10:58:51 -0700 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 16 May 2002 10:58:51 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 16 May 2002 10:58:51 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 16 May 2002 10:58:50 -0700 Received: from win-msg-03.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.198]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Thu, 16 May 2002 10:58:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: iSCSI: TargetAddress format Date: Thu, 16 May 2002 10:58:50 -0700 Message-ID: Thread-Topic: iSCSI: TargetAddress format thread-index: AcH9A1W+G2VNpi7OSgO/yTlY9W9AOw== From: "Lakshmi Ramasubramanian" To: X-OriginalArrivalTime: 16 May 2002 17:58:50.0826 (UTC) FILETIME=[55BCF2A0:01C1FD03] Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FD03.55BBF0F4" ------_=_NextPart_001_01C1FD03.55BBF0F4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The format of TargetAddress (Section 11.8) is given as=20 =20 TargetAddress=3Ddomainname[:port][,portal-group-tag] =20 In the examples given=20 =20 TargetAddress=3D[1080:0:0:0:8:800:200C:417A],65 TargetAddress=3D[1080::8:800:200C:417A]:5003,1 =20 What does the value within brackets indicate? Is it an IPv6 address? =20 thanks! -lakshmi ------_=_NextPart_001_01C1FD03.55BBF0F4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

The format of TargetAddress (Section 11.8) is given as=20
 
 TargetAddress=3Ddomainname[:port][,portal-group-tag]
 
In the examples given
 
 TargetAddress=3D[1080:0:0:0:8:800:200C:417A],65
 TargetAddress=3D[1080::8:800:200C:417A]:5003,1
 
What does the value within brackets indicate? Is = it
an IPv6 address?
 
thanks!
 -lakshmi
=00 ------_=_NextPart_001_01C1FD03.55BBF0F4-- --------------InterScan_NT_MIME_Boundary-- From owner-ips@ece.cmu.edu Thu May 16 15:24:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07415 for ; Thu, 16 May 2002 15:24:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4GIdFk17195 for ips-outgoing; Thu, 16 May 2002 14:39:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4GIdAw17174 for ; Thu, 16 May 2002 14:39:10 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4GIcuuF005174; Thu, 16 May 2002 11:38:56 -0700 (PDT) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA04519; Thu, 16 May 2002 11:37:46 -0700 (PDT) Message-ID: <3CE3F836.229204C4@cisco.com> Date: Thu, 16 May 2002 13:19:34 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Lakshmi Ramasubramanian CC: ips@ece.cmu.edu Subject: Re: iSCSI: TargetAddress format References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Lakshmi- Bracketed values are IPv6; the brackets are needed so address components are not confused with the :tcp-port. It's meant to match RFC2732, so we wouldn't invent something new. IPv4 addresses are just dotted-decimal without the brackets. I just noticed that I never quite documented this; it just refers to appendix D (sendtargets) which doesn't discuss IPv6 addresses. The description of IPv6 (in appendix D) is also wrong. I'll look at a new wording for this one. -- Mark > Lakshmi Ramasubramanian wrote: > > The format of TargetAddress (Section 11.8) is given as > > TargetAddress=domainname[:port][,portal-group-tag] > > In the examples given > > TargetAddress=[1080:0:0:0:8:800:200C:417A],65 > TargetAddress=[1080::8:800:200C:417A]:5003,1 > > What does the value within brackets indicate? Is it > an IPv6 address? > > thanks! > -lakshmi -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu May 16 15:32:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07939 for ; Thu, 16 May 2002 15:32:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4GIsk518570 for ips-outgoing; Thu, 16 May 2002 14:54:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4GIsgw18564 for ; Thu, 16 May 2002 14:54:42 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4GIsbHs020995; Thu, 16 May 2002 11:54:37 -0700 (PDT) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA18860; Thu, 16 May 2002 11:54:34 -0700 (PDT) Message-ID: <3CE3FC26.67D62D48@cisco.com> Date: Thu, 16 May 2002 13:36:22 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Julian Satran CC: Lakshmi Ramasubramanian , ips@ece.cmu.edu Subject: Re: iSCSI: TargetAddress format References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian- I just went through the IPv6 stuff again, and found a few things that we should update, since the address:tcpport format is no longer defined in the naming section: 11.8 TargetAddress: After: TargetAddress=domainname[:port][,portal-group-tag] Add: The domainname can be specified as either a DNS host name, a dotted-decimal IPv4 address, or a bracketed IPv6 address as specified in [RFC2732]. Replace: The TargetAddress key is further described in Appendix D. - SendTargets Operation -. With: Use of the portal-group-tag is described in Appendix D. - SendTargets Operation -. Appendix D. SendTargets Operation: Replace: The hostname-or-ipaddress and tcp port are as specified in the Sec- tion 2.2.6 iSCSI Names. With: The hostname-or-ipaddress contains a domain name, IPv4 address, or IPv6 address, as specified for the TargetAddress key. Hopefully that will clear it up. -- Mark Julian Satran wrote: > > That is an IPV6 address - Julo > > "Lakshmi Ramasubramanian" > To: > Sent by: owner-ips@ece.cmu.edu cc: > Subject: iSCSI: > 05/16/2002 08:58 PM TargetAddress format > Please respond to "Lakshmi Ramasubramanian" > > > The format of TargetAddress (Section 11.8) is given as > > TargetAddress=domainname[:port][,portal-group-tag] > > In the examples given > > TargetAddress=[1080:0:0:0:8:800:200C:417A],65 > TargetAddress=[1080::8:800:200C:417A]:5003,1 > > What does the value within brackets indicate? Is it > an IPv6 address? > > thanks! > -lakshmi -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu May 16 16:14:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09546 for ; Thu, 16 May 2002 16:14:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4GJQ0121430 for ips-outgoing; Thu, 16 May 2002 15:26:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4GJPvw21420 for ; Thu, 16 May 2002 15:25:57 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4GJPtg9011644; Thu, 16 May 2002 15:25:55 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4GJPoM76346; Thu, 16 May 2002 13:25:50 -0600 Importance: Normal Subject: Re: iSCSI: TargetAddress format To: "Lakshmi Ramasubramanian" Cc: X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Thu, 16 May 2002 12:24:14 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/16/2002 01:25:50 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g4GJPww21422 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Yes. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Lakshmi Ramasubramanian" @ece.cmu.edu on 05/16/2002 10:58:50 AM Sent by: owner-ips@ece.cmu.edu To: cc: Subject: iSCSI: TargetAddress format The format of TargetAddress (Section 11.8) is given as  TargetAddress=domainname[:port][,portal-group-tag] In the examples given  TargetAddress=[1080:0:0:0:8:800:200C:417A],65  TargetAddress=[1080::8:800:200C:417A]:5003,1 What does the value within brackets indicate? Is it an IPv6 address? thanks!  -lakshmi From owner-ips@ece.cmu.edu Thu May 16 16:15:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09568 for ; Thu, 16 May 2002 16:15:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4GJvdU24353 for ips-outgoing; Thu, 16 May 2002 15:57:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4GJvaw24347 for ; Thu, 16 May 2002 15:57:36 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id C037930706; Thu, 16 May 2002 15:57:35 -0400 (EDT) Date: Thu, 16 May 2002 12:55:46 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Lakshmi Ramasubramanian Cc: Subject: Re: iSCSI: TargetAddress format In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 16 May 2002, Lakshmi Ramasubramanian wrote: > The format of TargetAddress (Section 11.8) is given as > > TargetAddress=domainname[:port][,portal-group-tag] > > In the examples given > > TargetAddress=[1080:0:0:0:8:800:200C:417A],65 > TargetAddress=[1080::8:800:200C:417A]:5003,1 > > What does the value within brackets indicate? Is it > an IPv6 address? Yes. Take care, Bill From owner-ips@ece.cmu.edu Fri May 17 14:02:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24418 for ; Fri, 17 May 2002 14:02:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4HH71m27983 for ips-outgoing; Fri, 17 May 2002 13:07:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from imail.atlp.com ([64.94.220.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4HGF4w23693 for ; Fri, 17 May 2002 12:15:04 -0400 (EDT) Received: from atlp.com (post.atlp.com [192.168.3.8]) by imail.atlp.com (Switch-2.1.4/Switch-2.1.0) with SMTP id g4HGCi707160 for ; Fri, 17 May 2002 09:12:45 -0700 (PDT) Received: from atlp-exch.atlp.com by atlp.com (SMI-8.6/SMI-SVR4) id JAA25713; Fri, 17 May 2002 09:14:43 -0700 Received: by atlp-exch.atlp with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 09:14:41 -0700 Message-ID: <7C769A0EFE7BD411B8A300508BAED11B51359C@atlp-exch.atlp> From: Mike Donohoe To: "'ips@ece.cmu.edu'" Subject: iSCSI: Login Request error Date: Fri, 17 May 2002 09:14:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk 1. What error case was the Status: 020B "Invalid during login" intended to cover? I can't find any other occurence in the spec of a "Request Type", to say what an invalid one would be. 2. If a target receives something like "ImmediateData=Ye" what would be a proper status to return? Thanks. From owner-ips@ece.cmu.edu Fri May 17 18:09:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08880 for ; Fri, 17 May 2002 18:08:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4HLMPC19275 for ips-outgoing; Fri, 17 May 2002 17:22:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4HLMNw19269 for ; Fri, 17 May 2002 17:22:23 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 776A630706; Fri, 17 May 2002 17:22:22 -0400 (EDT) Date: Fri, 17 May 2002 14:20:29 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Mike Donohoe Cc: "'ips@ece.cmu.edu'" Subject: Re: iSCSI: Login Request error In-Reply-To: <7C769A0EFE7BD411B8A300508BAED11B51359C@atlp-exch.atlp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 17 May 2002, Mike Donohoe wrote: > 1. What error case was the Status: 020B "Invalid during login" intended to > cover? I can't find any other occurence in the spec of a "Request Type", to > say what an invalid one would be. I believe any command other than login (or logout?) is invalid before you hit full-feature phase. Thus any other such command would count as 020b. > 2. If a target receives something like "ImmediateData=Ye" what would be a > proper status to return? Either Reject or NotUnderstood come to mind. Take care, Bill From owner-ips@ece.cmu.edu Fri May 17 20:40:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15104 for ; Fri, 17 May 2002 20:40:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4HNwfw28982 for ips-outgoing; Fri, 17 May 2002 19:58:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4HNwdw28977 for ; Fri, 17 May 2002 19:58:39 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id CC7F53FF7; Fri, 17 May 2002 17:58:38 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 7BD442D2; Fri, 17 May 2002 17:58:38 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 17 May 2002 17:58:35 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 17:58:35 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09C616@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: wrstuden@wasabisystems.com, Mike.Donohoe@quantum.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login Request error Date: Fri, 17 May 2002 17:58:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Friday, May 17, 2002 2:20 PM To: Mike Donohoe Cc: 'ips@ece.cmu.edu' Subject: Re: iSCSI: Login Request error On Fri, 17 May 2002, Mike Donohoe wrote: > 1. What error case was the Status: 020B "Invalid during login" intended to > cover? I can't find any other occurence in the spec of a "Request Type", to > say what an invalid one would be. I believe any command other than login (or logout?) is invalid before you hit full-feature phase. Thus any other such command would count as 020b. It is any command other than login. Logout is not used during login phase. > 2. If a target receives something like "ImmediateData=Ye" what would be a > proper status to return? Either Reject or NotUnderstood come to mind. NotUnderstood shouldn't be used. It is specifically for cases where the key is not understood and all implementations would understand the key ImmediateData. Assuming that a value of Ye for a boolean would be considered a value not admissible, then the reaction depends on whether the initiator is the requester or the responder for that value. 4.2.2 says a value of REJECT or an admissible value MAY be returned when the requester offers an inadmissible value. If an inadmissible values is received from the responder, then it is a negotiation failure. Take care, Bill From owner-ips@ece.cmu.edu Fri May 17 20:41:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15148 for ; Fri, 17 May 2002 20:41:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4I0HIk29968 for ips-outgoing; Fri, 17 May 2002 20:17:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from webmail.silverbacksystems.com (dmz1.silverbacksystems.com [65.172.158.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4I0HGw29964 for ; Fri, 17 May 2002 20:17:16 -0400 (EDT) Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by webmail.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 7D219B1A5; Fri, 17 May 2002 17:17:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 3D6DAD16; Fri, 17 May 2002 17:18:14 -0700 (PDT) Cc: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Date: Fri, 17 May 2002 17:16:48 -0700 From: "Carlos Rimola" Importance: Normal In-Reply-To: Message-ID: <000a01c1fe01$4d656e80$c510000a@corp.silverbacksystems.com> MIME-Version: 1.0 Organization: Silverback Systems Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-6.13.0.2) id 01307-45C83AF1; Fri, 17 May 2002 17:17:52 -0700 Received: from carlos (carlos.corp.silverbacksystems.com [10.0.16.197]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B509FD16; Fri, 17 May 2002 17:17:52 -0700 (PDT) Reply-To: Subject: RE: iSCSI: Login Request error To: "'Bill Studenmund'" , "'Mike Donohoe'" X-AntiVirus: OK! AvMailGate Version 6.13.0.17 at ns.silverbacksystems.com has not found any known virus in this email. X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MSMail-Priority: Normal X-Priority: 3 (Normal) Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit My understanding: For question 1 - only Login request/responses are allowed before full feature phase (no Logout since you are not logged in). For question 2 - the correct response would either be Reject or Yes/No (is ok to reply with an admissible value to an invalid/unrecognized offer). NotUnderstood should only be used when the key itself is not recognized (e.g. ImmediateData misspelled like ImediateData). The spec explicitly states that NotUnderstood MUST NOT be used for known keys (those defined in chapter 11). Carlos Rimola Silverback Systems -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Bill Studenmund Sent: Friday, May 17, 2002 2:20 PM To: Mike Donohoe Cc: 'ips@ece.cmu.edu' Subject: Re: iSCSI: Login Request error On Fri, 17 May 2002, Mike Donohoe wrote: > 1. What error case was the Status: 020B "Invalid during login" intended to > cover? I can't find any other occurence in the spec of a "Request Type", to > say what an invalid one would be. I believe any command other than login (or logout?) is invalid before you hit full-feature phase. Thus any other such command would count as 020b. > 2. If a target receives something like "ImmediateData=Ye" what would be a > proper status to return? Either Reject or NotUnderstood come to mind. Take care, Bill From owner-ips@ece.cmu.edu Fri May 17 22:55:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20101 for ; Fri, 17 May 2002 22:55:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4I2CWj05962 for ips-outgoing; Fri, 17 May 2002 22:12:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from imail.atlp.com ([64.94.220.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4I13Zw02419 for ; Fri, 17 May 2002 21:03:35 -0400 (EDT) Received: from atlp.com (post.atlp.com [192.168.3.8]) by imail.atlp.com (Switch-2.1.4/Switch-2.1.0) with SMTP id g4I11M719732 for ; Fri, 17 May 2002 18:01:22 -0700 (PDT) Received: from atlp-exch.atlp.com by atlp.com (SMI-8.6/SMI-SVR4) id SAA14931; Fri, 17 May 2002 18:03:21 -0700 Received: by atlp-exch.atlp with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 18:03:21 -0700 Message-ID: <7C769A0EFE7BD411B8A300508BAED11B5135A0@atlp-exch.atlp> From: Mike Donohoe To: ips@ece.cmu.edu Subject: RE: iSCSI: Login Request error Date: Fri, 17 May 2002 18:03:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk 1. I was assuming that a Login Response would only be in reply to a Login Request. So during login phase if a target receives a non-Login Request it should just close the connection. It was in this mindset that I was wondering about the status 020B. Is this correct or was 020b added specifically for the case of non-Login PDUs during login phase? The spec is unclear on this. 2. I am the target and I receive a "ImmediateData=Ye". I am assuming this is a case of a value "not admissible". The spec on page 65 (v12) says: An offer of a value not admissible MAY be answered with the constant "Reject". The selection of a value not admissible under the selection rules is considered a negotiation failure and is handled accordingly. So I MAY return "ImmediateData=Reject". And because of section 6.8 Negotiation Failures on page 99 I need to "terminate the login with the appropriate login response code". In this case what is the "appropriate login response code"? (IE the Status-Class Status-Detail value.) Thank you again for your help. > > My understanding: > > For question 1 - only Login request/responses are allowed before full > feature phase (no Logout since you are not logged in). > > For question 2 - the correct response would either be Reject > or Yes/No > (is ok to reply with an admissible value to an invalid/unrecognized > offer). NotUnderstood should only be used when the key itself is not > recognized (e.g. ImmediateData misspelled like > ImediateData). The spec > explicitly states that NotUnderstood MUST NOT be used for known keys > (those defined in chapter 11). > > Carlos Rimola > Silverback Systems > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] > On Behalf Of > Bill Studenmund > Sent: Friday, May 17, 2002 2:20 PM > To: Mike Donohoe > Cc: 'ips@ece.cmu.edu' > Subject: Re: iSCSI: Login Request error > > On Fri, 17 May 2002, Mike Donohoe wrote: > > > 1. What error case was the Status: 020B "Invalid during login" > intended to > > cover? I can't find any other occurence in the spec of a "Request > Type", to > > say what an invalid one would be. > > I believe any command other than login (or logout?) is invalid before > you > hit full-feature phase. Thus any other such command would > count as 020b. > > > 2. If a target receives something like "ImmediateData=Ye" > what would > be a > > proper status to return? > > Either Reject or NotUnderstood come to mind. > > Take care, > > Bill > From owner-ips@ece.cmu.edu Sat May 18 03:53:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05871 for ; Sat, 18 May 2002 03:53:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4I7AdO21235 for ips-outgoing; Sat, 18 May 2002 03:10:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailnpd.hcltech.com ([203.197.145.76]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4I7AZw21228 for ; Sat, 18 May 2002 03:10:36 -0400 (EDT) Received: from npd.hcltech.com (IDENT:pamanick@pamanick.hcltech.com [192.168.100.58]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id g4I6oAM27209; Sat, 18 May 2002 12:20:19 +0530 Message-ID: <3CE5FC07.ED042330@npd.hcltech.com> Date: Sat, 18 May 2002 12:30:23 +0530 From: Parthi Organization: HCL Tech X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mike Donohoe CC: "'ips@ece.cmu.edu'" Subject: Re: iSCSI: Login Request error References: <7C769A0EFE7BD411B8A300508BAED11B51359C@atlp-exch.atlp> Content-Type: multipart/alternative; boundary="------------ACF03A00474FB173EB58D730" Sender: owner-ips@ece.cmu.edu Precedence: bulk --------------ACF03A00474FB173EB58D730 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike Donohoe wrote: > 1. What error case was the Status: 020B "Invalid during login" intended to > cover? I can't find any other occurence in the spec of a "Request Type", to > say what an invalid one would be. > > 2. If a target receives something like "ImmediateData=Ye" what would be a > proper status to return? Responder should say "Reject" in Text param negotiation. ex. Originator-> ImmediateData=Ye Responder -> ImmediateData=Reject The status value would be 020b "Invalid during login". -- Parthiban M, iSCSI Driver Team, HCL Technologies Ltd., Tel : (+91)-44-3741939 to 42, Extn. 2332 http://san.hcltech.com --------------ACF03A00474FB173EB58D730 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Mike Donohoe wrote:
1. What error case was the Status: 020B "Invalid during login" intended to
cover?  I can't find any other occurence in the spec of a "Request Type", to
say what an invalid one would be.

2.  If a target receives something like "ImmediateData=Ye" what would be a
proper status to return?

 Responder should say  "Reject" in Text param negotiation.

       ex.       Originator->  ImmediateData=Ye
                    Responder ->  ImmediateData=Reject

 The status value would be  020b  "Invalid during login". 

-- 
Parthiban M,
iSCSI Driver Team,
HCL Technologies Ltd.,          Tel : (+91)-44-3741939 to 42, Extn. 2332
http://san.hcltech.com
  --------------ACF03A00474FB173EB58D730-- From owner-ips@ece.cmu.edu Sat May 18 04:33:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06422 for ; Sat, 18 May 2002 04:33:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4I7qen23216 for ips-outgoing; Sat, 18 May 2002 03:52:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f37.pav2.hotmail.com [64.4.37.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4I7qcw23211 for ; Sat, 18 May 2002 03:52:38 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 18 May 2002 00:52:32 -0700 Received: from 64.38.134.99 by pv2fd.pav2.hotmail.msn.com with HTTP; Sat, 18 May 2002 07:52:31 GMT X-Originating-IP: [64.38.134.99] From: "Bernard Aboba" To: kukkonen@ssh.com, ips@ece.cmu.edu Cc: cbh@zyfer.com Subject: Re: Relation between iSCSI session and IPSec SAs Date: Sat, 18 May 2002 00:52:31 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 May 2002 07:52:32.0507 (UTC) FILETIME=[F7657CB0:01C1FE40] Sender: owner-ips@ece.cmu.edu Precedence: bulk >Is there any benefit in being able to identify iSCSI >TCP session based on the IPSec SA (SPI) alone? In general, I do not think there is a benefit. Most implementions won't do this by default (e.g. most existing ones), so I suspect that you'd need to add the conventional logic anyway. And requiring an SA per connection will require a more memory to save the resulting state; the number of active SAs that can be handled at a time is limited. >Does it make iSCSI TCP offloading easier when >you can associate inbound datagrams to correct >session using only single lookup based on the SPI? >(or destination address + SPI + protocol, to be exact) > >You still need post-IPSec policy enforcement, but this >is only a comparison against known values, not a lookup. I think one must balance this against the extra state (and resulting memory) that must be kept for the additional Phase 2 SAs that are created. My sense is that this is not a good tradeoff. >Also, does this "SA per TCP session" model make >load balancing & high availability somehow easier? I do not think so, because the state to track (IPsec + TCP + iSCSI) is not affected substantially. >I would like to understand what is the usual justification >for separating individual TCP sessions to different SAs. >(and also whether people are doing this or not in iSCSI) The most commonly cited justifications are when it is desired to apply different QoS to the sessions, or protect them with different transforms. However, I think these cases will be exceptions rather than being common, particularly since APIs are not typically available with which to easily set more granular, dynamic policies for iSCSI sessions. It is far easier to use a generic policy "from me to any, dest port iSCSI" than to attempt to plumb more granular and dynamic policies. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From owner-ips@ece.cmu.edu Sat May 18 04:38:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06480 for ; Sat, 18 May 2002 04:38:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4I8Jck24625 for ips-outgoing; Sat, 18 May 2002 04:19:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4I8Jaw24618 for ; Sat, 18 May 2002 04:19:36 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4I8JQwY015626 for ; Sat, 18 May 2002 10:19:26 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4I8JPA47790 for ; Sat, 18 May 2002 10:19:26 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI: BASE64 and numerical values X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 18 May 2002 11:19:23 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 18/05/2002 11:19:25, Serialize complete at 18/05/2002 11:19:25 Content-Type: multipart/alternative; boundary="=_alternative 002CB9C9C2256BBD_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002CB9C9C2256BBD_= Content-Type: text/plain; charset="us-ascii" I was going to suggest this myself :-) Julo ----- Forwarded by Julian Satran/Haifa/IBM on 05/18/2002 11:07 AM ----- Bill Studenmund Sent by: owner-ips@ece.cmu.edu 05/15/2002 05:46 AM Please respond to Bill Studenmund To: cc: Subject: iSCSI: BASE64 and numerical values I was looking at the latest draft (Julian's 12-90.pdf), and thinking about this. I see some problems, and I'd like to suggest we DROP support for using base64 to encode numberical values. Definitely keep it for binary strings, just not numbers. The reason I suggest this is base64 encodes arbitrary-length binary streams. To consider that stream a number, we need to add some more structure. "Network Byte Order" is the first thing that comes to mind. We've got ntohs() and ntohl(), also known as ntoh16() and ntoh32() on some systems, which will save the day. Unfortunatlely since the base64 stream can be arbitrary length, we'd need something like ntoh24() too. We could after all have used just three bytes to encode that number, especially since the spec discourages leading zero-characters (encoded as 'A's). Also, since regular-numerical-values can go up to just shy of 2**64, in principle the only thing saving us from needing ntoh40(), ntoh48(), and ntoh56() is the fact that I don't think we have any numerical parameters that have valid values that large. So I'd like to suggest we disallow using base64 to encode numbers. Byte-swapping an arbitrary-length byte stream seems really messy. Alternatively, I'd like to suggest we constrain base64-encoded numbers to be 1, 2, 4, or 8 bytes long when decoded, and to be in network byte order. Sorry for not catching this last week when we were looking at section 4.1. Thoughts? Take care, Bill ----- Forwarded by Julian Satran/Haifa/IBM on 05/18/2002 11:07 AM ----- "Michael Krueger" Sent by: owner-ips@ece.cmu.edu 05/15/2002 09:04 PM Please respond to "Michael Krueger" To: "Bill Studenmund" , cc: Subject: RE: iSCSI: BASE64 and numerical values > So I'd like to suggest we disallow using base64 to encode numbers. > Byte-swapping an arbitrary-length byte stream seems really messy. > Alternatively, I'd like to suggest we constrain base64-encoded numbers to > be 1, 2, 4, or 8 bytes long when decoded, and to be in network byte order. Bill, thanks for bringing this up, because I wanted to make the same point. Implementing base-64 encoding for numbers is a fair amount of work for very little benefit--no, let me be blunt: for ZERO benefit. As I understand it, the whole idea of the text-based login was to make it human-readable and to allow cutting and pasting of values from, say, a management console. Maybe I lack imagination, but I cannot conceive of any real-world circumstance under which a NUMBER would be displayed on a console or entered by a human (except, perhaps, by a pathologically mischievous one ;-) in base-64 encoding. A BINARY ITEM, yes, but a NUMBER, never. Let's keep it simple: decimal and hexadecimal for numbers, hexadecimal and base 64 for binary items. Michael -- Michael J. Krueger mailto:michael.krueger@windriver.com Wind River Networks http://www.windriver.com 500 Wind River Way phone: 510-749-2130 Alameda, CA 94501 fax: 510-749-2010 --=_alternative 002CB9C9C2256BBD_= Content-Type: text/html; charset="us-ascii"
I was going to suggest this myself :-) Julo
----- Forwarded by Julian Satran/Haifa/IBM on 05/18/2002 11:07 AM -----
Bill Studenmund <wrstuden@wasabisystems.com>
Sent by: owner-ips@ece.cmu.edu

05/15/2002 05:46 AM
Please respond to Bill Studenmund

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: BASE64 and numerical values

       


I was looking at the latest draft (Julian's 12-90.pdf), and thinking about
this. I see some problems, and I'd like to suggest we DROP support for
using base64 to encode numberical values. Definitely keep it for binary
strings, just not numbers.

The reason I suggest this is base64 encodes arbitrary-length binary
streams. To consider that stream a number, we need to add some more
structure. "Network Byte Order" is the first thing that comes to mind.
We've got ntohs() and ntohl(), also known as ntoh16() and ntoh32() on some
systems, which will save the day.

Unfortunatlely since the base64 stream can be arbitrary length, we'd need
something like ntoh24() too. We could after all have used just three bytes
to encode that number, especially since the spec discourages leading
zero-characters (encoded as 'A's).

Also, since regular-numerical-values can go up to just shy of 2**64, in
principle the only thing saving us from needing ntoh40(), ntoh48(), and
ntoh56() is the fact that I don't think we have any numerical parameters
that have valid values that large.

So I'd like to suggest we disallow using base64 to encode numbers.
Byte-swapping an arbitrary-length byte stream seems really messy.
Alternatively, I'd like to suggest we constrain base64-encoded numbers to
be 1, 2, 4, or 8 bytes long when decoded, and to be in network byte order.

Sorry for not catching this last week when we were looking at section 4.1.

Thoughts?

Take care,

Bill
----- Forwarded by Julian Satran/Haifa/IBM on 05/18/2002 11:07 AM -----
"Michael Krueger" <michael.krueger@windriver.com>
Sent by: owner-ips@ece.cmu.edu

05/15/2002 09:04 PM
Please respond to "Michael Krueger"

       
        To:        "Bill Studenmund" <wrstuden@wasabisystems.com>, <ips@ece.cmu.edu>
        cc:        
        Subject:        RE: iSCSI: BASE64 and numerical values

       


> So I'd like to suggest we disallow using base64 to encode numbers.
> Byte-swapping an arbitrary-length byte stream seems really messy.
> Alternatively, I'd like to suggest we constrain base64-encoded numbers to
> be 1, 2, 4, or 8 bytes long when decoded, and to be in network byte order.

Bill, thanks for bringing this up, because I wanted to make the same point.
Implementing base-64 encoding for numbers is a fair amount of work for very
little benefit--no, let me be blunt: for ZERO benefit.  As I understand it,
the whole idea of the text-based login was to make it human-readable and to
allow cutting and pasting of values from, say, a management console.  Maybe
I lack imagination, but I cannot conceive of any real-world circumstance
under which a NUMBER would be displayed on a console or entered by a human
(except, perhaps, by a pathologically mischievous one ;-) in base-64
encoding.  A BINARY ITEM, yes, but a NUMBER, never.

Let's keep it simple: decimal and hexadecimal for numbers, hexadecimal and
base 64 for binary items.

Michael

--
Michael J. Krueger              mailto:michael.krueger@windriver.com
Wind River Networks                         http://www.windriver.com
500 Wind River Way                               phone: 510-749-2130
Alameda, CA  94501                                 fax: 510-749-2010
--=_alternative 002CB9C9C2256BBD_=-- From owner-ips@ece.cmu.edu Sat May 18 05:10:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06696 for ; Sat, 18 May 2002 05:10:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4I8VeM25223 for ips-outgoing; Sat, 18 May 2002 04:31:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4I8Vcw25214 for ; Sat, 18 May 2002 04:31:38 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4I8VVwY025006 for ; Sat, 18 May 2002 10:31:31 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4I8VVA67116 for ; Sat, 18 May 2002 10:31:31 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI: BASE64 and numerical values X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 18 May 2002 11:31:28 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 18/05/2002 11:31:30, Serialize complete at 18/05/2002 11:31:30 Content-Type: multipart/alternative; boundary="=_alternative 002DD3C6C2256BBD_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002DD3C6C2256BBD_= Content-Type: text/plain; charset="us-ascii" Yes for regular numerical values it makes sense. We will have to keep it for large numerical values used for cryptography. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 05/18/2002 11:18 AM ----- Bill Studenmund Sent by: owner-ips@ece.cmu.edu 05/15/2002 05:46 AM Please respond to Bill Studenmund To: cc: Subject: iSCSI: BASE64 and numerical values I was looking at the latest draft (Julian's 12-90.pdf), and thinking about this. I see some problems, and I'd like to suggest we DROP support for using base64 to encode numberical values. Definitely keep it for binary strings, just not numbers. The reason I suggest this is base64 encodes arbitrary-length binary streams. To consider that stream a number, we need to add some more structure. "Network Byte Order" is the first thing that comes to mind. We've got ntohs() and ntohl(), also known as ntoh16() and ntoh32() on some systems, which will save the day. Unfortunatlely since the base64 stream can be arbitrary length, we'd need something like ntoh24() too. We could after all have used just three bytes to encode that number, especially since the spec discourages leading zero-characters (encoded as 'A's). Also, since regular-numerical-values can go up to just shy of 2**64, in principle the only thing saving us from needing ntoh40(), ntoh48(), and ntoh56() is the fact that I don't think we have any numerical parameters that have valid values that large. So I'd like to suggest we disallow using base64 to encode numbers. Byte-swapping an arbitrary-length byte stream seems really messy. Alternatively, I'd like to suggest we constrain base64-encoded numbers to be 1, 2, 4, or 8 bytes long when decoded, and to be in network byte order. Sorry for not catching this last week when we were looking at section 4.1. Thoughts? Take care, Bill ----- Forwarded by Julian Satran/Haifa/IBM on 05/18/2002 11:18 AM ----- "Michael Krueger" Sent by: owner-ips@ece.cmu.edu 05/15/2002 09:04 PM Please respond to "Michael Krueger" To: "Bill Studenmund" , cc: Subject: RE: iSCSI: BASE64 and numerical values > So I'd like to suggest we disallow using base64 to encode numbers. > Byte-swapping an arbitrary-length byte stream seems really messy. > Alternatively, I'd like to suggest we constrain base64-encoded numbers to > be 1, 2, 4, or 8 bytes long when decoded, and to be in network byte order. Bill, thanks for bringing this up, because I wanted to make the same point. Implementing base-64 encoding for numbers is a fair amount of work for very little benefit--no, let me be blunt: for ZERO benefit. As I understand it, the whole idea of the text-based login was to make it human-readable and to allow cutting and pasting of values from, say, a management console. Maybe I lack imagination, but I cannot conceive of any real-world circumstance under which a NUMBER would be displayed on a console or entered by a human (except, perhaps, by a pathologically mischievous one ;-) in base-64 encoding. A BINARY ITEM, yes, but a NUMBER, never. Let's keep it simple: decimal and hexadecimal for numbers, hexadecimal and base 64 for binary items. Michael -- Michael J. Krueger mailto:michael.krueger@windriver.com Wind River Networks http://www.windriver.com 500 Wind River Way phone: 510-749-2130 Alameda, CA 94501 fax: 510-749-2010 --=_alternative 002DD3C6C2256BBD_= Content-Type: text/html; charset="us-ascii"
Yes for regular numerical values it makes sense. We will have to keep it for large numerical values used for cryptography.  Julo
----- Forwarded by Julian Satran/Haifa/IBM on 05/18/2002 11:18 AM -----
Bill Studenmund <wrstuden@wasabisystems.com>
Sent by: owner-ips@ece.cmu.edu

05/15/2002 05:46 AM
Please respond to Bill Studenmund

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: BASE64 and numerical values

       


I was looking at the latest draft (Julian's 12-90.pdf), and thinking about
this. I see some problems, and I'd like to suggest we DROP support for
using base64 to encode numberical values. Definitely keep it for binary
strings, just not numbers.

The reason I suggest this is base64 encodes arbitrary-length binary
streams. To consider that stream a number, we need to add some more
structure. "Network Byte Order" is the first thing that comes to mind.
We've got ntohs() and ntohl(), also known as ntoh16() and ntoh32() on some
systems, which will save the day.

Unfortunatlely since the base64 stream can be arbitrary length, we'd need
something like ntoh24() too. We could after all have used just three bytes
to encode that number, especially since the spec discourages leading
zero-characters (encoded as 'A's).

Also, since regular-numerical-values can go up to just shy of 2**64, in
principle the only thing saving us from needing ntoh40(), ntoh48(), and
ntoh56() is the fact that I don't think we have any numerical parameters
that have valid values that large.

So I'd like to suggest we disallow using base64 to encode numbers.
Byte-swapping an arbitrary-length byte stream seems really messy.
Alternatively, I'd like to suggest we constrain base64-encoded numbers to
be 1, 2, 4, or 8 bytes long when decoded, and to be in network byte order.

Sorry for not catching this last week when we were looking at section 4.1.

Thoughts?

Take care,

Bill
----- Forwarded by Julian Satran/Haifa/IBM on 05/18/2002 11:18 AM -----
"Michael Krueger" <michael.krueger@windriver.com>
Sent by: owner-ips@ece.cmu.edu

05/15/2002 09:04 PM
Please respond to "Michael Krueger"

       
        To:        "Bill Studenmund" <wrstuden@wasabisystems.com>, <ips@ece.cmu.edu>
        cc:        
        Subject:        RE: iSCSI: BASE64 and numerical values

       


> So I'd like to suggest we disallow using base64 to encode numbers.
> Byte-swapping an arbitrary-length byte stream seems really messy.
> Alternatively, I'd like to suggest we constrain base64-encoded numbers to
> be 1, 2, 4, or 8 bytes long when decoded, and to be in network byte order.

Bill, thanks for bringing this up, because I wanted to make the same point.
Implementing base-64 encoding for numbers is a fair amount of work for very
little benefit--no, let me be blunt: for ZERO benefit.  As I understand it,
the whole idea of the text-based login was to make it human-readable and to
allow cutting and pasting of values from, say, a management console.  Maybe
I lack imagination, but I cannot conceive of any real-world circumstance
under which a NUMBER would be displayed on a console or entered by a human
(except, perhaps, by a pathologically mischievous one ;-) in base-64
encoding.  A BINARY ITEM, yes, but a NUMBER, never.

Let's keep it simple: decimal and hexadecimal for numbers, hexadecimal and
base 64 for binary items.

Michael

--
Michael J. Krueger              mailto:michael.krueger@windriver.com
Wind River Networks                         http://www.windriver.com
500 Wind River Way                               phone: 510-749-2130
Alameda, CA  94501                                 fax: 510-749-2010
--=_alternative 002DD3C6C2256BBD_=-- From owner-ips@ece.cmu.edu Sat May 18 07:22:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09146 for ; Sat, 18 May 2002 07:22:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4IAhUL12631 for ips-outgoing; Sat, 18 May 2002 06:43:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web9604.mail.yahoo.com (web9604.mail.yahoo.com [216.136.129.183]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4IAhSw12623 for ; Sat, 18 May 2002 06:43:28 -0400 (EDT) Message-ID: <20020518104327.79183.qmail@web9604.mail.yahoo.com> Received: from [202.71.141.42] by web9604.mail.yahoo.com via HTTP; Sat, 18 May 2002 03:43:27 PDT Date: Sat, 18 May 2002 03:43:27 -0700 (PDT) From: Ajit Nipunge Subject: remove To: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Mon May 20 11:23:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06982 for ; Mon, 20 May 2002 11:23:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4KEJnf29095 for ips-outgoing; Mon, 20 May 2002 10:19:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4KBs0w21559 for ; Mon, 20 May 2002 07:54:00 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07983; Mon, 20 May 2002 07:53:39 -0400 (EDT) Message-Id: <200205201153.HAA07983@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-security-12.txt Date: Mon, 20 May 2002 07:53:38 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Securing Block Storage Protocols over IP Author(s) : B. Aboba et al. Filename : draft-ietf-ips-security-12.txt Pages : 66 Date : 17-May-02 This document discusses how to secure block storage and storage discovery protocols running over IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-security-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-security-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-security-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020517134834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-security-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-security-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020517134834.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon May 20 16:30:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08365 for ; Mon, 20 May 2002 16:30:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4KJc3J21869 for ips-outgoing; Mon, 20 May 2002 15:38:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4KJbww21856 for ; Mon, 20 May 2002 15:37:58 -0400 (EDT) Received: from chamao (chamao [147.11.45.39]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id MAA15706; Mon, 20 May 2002 12:36:44 -0700 (PDT) From: "Michael Krueger" To: "Julian Satran" , Subject: RE: iSCSI: BASE64 and numerical values Date: Mon, 20 May 2002 12:37:47 -0700 Message-ID: <002401c20035$d2b996c0$272d0b93@chamao.wrs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Saturday, May 18, 2002 1:31 AM, Julian Satran wrote: > Yes for regular numerical values it makes sense. We will have to keep > it for large numerical values used for cryptography. Julo I'm glad to see that base-64 encoding will be dropped for numbers, but I'm afraid I still have a small issue with the language being used here. As I understand it, "large numerical values" are NOT used for cryptography; the keys, challenges, responses, etc., are large BINARY ITEMS*, not large numbers. I still believe that failing to make a distinction between numbers and binary items is what's behind a lot of the confusion and ambiguity in this realm of the spec (e.g., decimal representation, leading zeroes, definitions of field size, byte swapping issues, etc.). Michael *I have no special attachment to the term "binary items"; call them "binary strings," "bit patterns," or whatever you like . . . but please just don't call them "numeric" or "numbers." -- Michael J. Krueger mailto:michael.krueger@windriver.com Wind River Networks http://www.windriver.com 500 Wind River Way phone: 510-749-2130 Alameda, CA 94501 fax: 510-749-2010 From owner-ips@ece.cmu.edu Mon May 20 18:45:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18335 for ; Mon, 20 May 2002 18:45:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4KLu2p00902 for ips-outgoing; Mon, 20 May 2002 17:56:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4KLtww00890 for ; Mon, 20 May 2002 17:55:58 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id EFD5430706; Mon, 20 May 2002 17:55:57 -0400 (EDT) Date: Mon, 20 May 2002 14:54:05 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Subject: Re: iSCSI: BASE64 and numerical values In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Sat, 18 May 2002, Julian Satran wrote: > Yes for regular numerical values it makes sense. We will have to keep it > for large numerical values used for cryptography. Julo I realize I'm driving a semantic nit, but I don't think we should use BASE64 for any "numeric" values, only "binary" ones. I believe we probably agree on what we want, I'm just worried that if the wording isn't 100% tight, the decode path can become a real mess (since we're supposed to be liberal in what we accept :-). I'd like to suggest we drop BASE64 from the text that mentions numerical values. I really don't look forward to byteswapping a 256 or 512 bit number as part of BASE64 decode. :-) I'd also like to suggest that for encoding large binary values using hexadecimal, we state that the hexadecimal representation is that of the number in network byte order. i.e. if I have the five octets 02 45 78 ab de, the hex constant is 0x024578abde. That makes the decode logic REAL easy; grab two hex characters & convert to one octet. Repeat as needed. Please note that this is not the output you'd get with something like printf("0x%x", number) on a little-endian machine. Thirdly, I'd like to suggest we drop decimal support from binary objects. It too has the cumbersome byte-swapping issue that I started this thread about, just in reverse. :-) I realize that's a lot for one EMail. :-) To try and be proactive about this, I'd like to suggest revised text for section 4.1 (of course needs word-wrapping). For the definitions: hex-constant: hexadecimal constant encoded as a string start- ing with "0x" or "0X" followed by 1 or more digits or the letters a, b, c, d, e, f, A, B, C, D, E and F. Hex-constants are used to encode numerical values or binary strings. When used to encode numerical values the excessive use of leading 0 digits is discouraged. When used to encode binary strings hexadecimal constants must have an even number of digits, and have an implicit byte-length that includes 4 bits for every hexadecimal digit of the constant, including leading zeroes (i.e., a hex-constant of n hexadeci- mal digits has a byte-length of n/2). Additionally, when used to encode binary strings, hexadecimal constants shall be expressed in network byte order (i.e., the octet stream 02 45 78 ab de would be expressed as "0x024578abde"). decimal-constant: an unsigned decimal number - the digit 0 or a string of 1 or more digits starting with a non-zero digit. This encoding is not used for numerical values equal or greater than 2**64. base64-constant: base64 constant encoded as a string starting with "0b" or "0B" followed by 1 or more digits or letters or plus or slash or equal. The encoding is done according to [RFC2045]. base64-constants are used to encode binary strings. Base64-constants have an implicit byte-length that includes 6 bits for every character of the constant excluding trailing equals (i.e., a base64-constant of n base64 characters excluding the trailing equals and m trailing equals has a byte-length of ((the integer part of) ((n+3)*3/4) - m). regular-numerical-value : an unsigned integer less than 2**64 encoded as a decimal-constant, or hex constant. large-numerical-value : an unsigned integer larger than or equal to 2**64 encoded as a hex constant. [no change for numerical-value or numerical-range] binary-value : a binary string encoded as a hex-con- stant or base64-constant. The length of the string is either specified by the key definition or is implicit byte-length of the encoded string. [delete regualar-binary-value and large-binary-value since the distinction is gone] I don't see it explicitly mentioned anywhere, but I think all of the CHAP (and SRP, but not sure) keys are large numericalal values, and the kerberos and SPKM keys are binary values. Also, I think the CHAP keys need the field length features of hexadecimal binary strings, but they are numbers, not binary strings. Not sure how to word that. Take care, Bill From owner-ips@ece.cmu.edu Mon May 20 18:48:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18495 for ; Mon, 20 May 2002 18:48:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4KM4P701332 for ips-outgoing; Mon, 20 May 2002 18:04:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4KM4Nw01327 for ; Mon, 20 May 2002 18:04:23 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 2EC9D30706; Mon, 20 May 2002 18:04:23 -0400 (EDT) Date: Mon, 20 May 2002 15:02:30 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Parthi Cc: Mike Donohoe , "'ips@ece.cmu.edu'" Subject: Re: iSCSI: Login Request error In-Reply-To: <3CE5FC07.ED042330@npd.hcltech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Sat, 18 May 2002, Parthi wrote: > > proper status to return? > > Responder should say "Reject" in Text param negotiation. > > ex. Originator-> ImmediateData=Ye > Responder -> ImmediateData=Reject > > The status value would be 020b "Invalid during login". Would 020b be the correct error for that? I would have thought 0200 "Miscellaneous iSCSI initiator errors" would have been better; I thought 020b was exclusively for an attempt to do something that should only be done in FFP, before you've gotten to FFP. Take care, Bill From owner-ips@ece.cmu.edu Mon May 20 22:23:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00629 for ; Mon, 20 May 2002 22:23:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4L1gb611966 for ips-outgoing; Mon, 20 May 2002 21:42:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4L1gYw11961 for ; Mon, 20 May 2002 21:42:35 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4L1gRwY031010; Tue, 21 May 2002 03:42:27 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4L1gRn112998; Tue, 21 May 2002 03:42:27 +0200 To: "Michael Krueger" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: BASE64 and numerical values X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 21 May 2002 04:42:25 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 21/05/2002 04:42:27, Serialize complete at 21/05/2002 04:42:27 Content-Type: multipart/alternative; boundary="=_alternative 00086D0DC2256BC0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00086D0DC2256BC0_= Content-Type: text/plain; charset="us-ascii" I am in the process of the reviewing the needs for large numerical values (based on cryptography requirements for specified and other known schemes that vendors may want to use). If The results will indicate that large numerical values are of marginal use I will drop base64 for numbers. If not I will leave it as is. As for you "confusion and ambiguity in this realm of the spec (e.g., decimal representation, leading zeroes, definitions of field size, byte swapping issues, etc.)" I am afraid that I don't see how base64 different than hexadecimal and I assume a statement about ordering solves both. Julo "Michael Krueger" 05/20/2002 10:37 PM Please respond to "Michael Krueger" To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: iSCSI: BASE64 and numerical values On Saturday, May 18, 2002 1:31 AM, Julian Satran wrote: > Yes for regular numerical values it makes sense. We will have to keep > it for large numerical values used for cryptography. Julo I'm glad to see that base-64 encoding will be dropped for numbers, but I'm afraid I still have a small issue with the language being used here. As I understand it, "large numerical values" are NOT used for cryptography; the keys, challenges, responses, etc., are large BINARY ITEMS*, not large numbers. I still believe that failing to make a distinction between numbers and binary items is what's behind a lot of the confusion and ambiguity in this realm of the spec (e.g., decimal representation, leading zeroes, definitions of field size, byte swapping issues, etc.). Michael *I have no special attachment to the term "binary items"; call them "binary strings," "bit patterns," or whatever you like . . . but please just don't call them "numeric" or "numbers." -- Michael J. Krueger mailto:michael.krueger@windriver.com Wind River Networks http://www.windriver.com 500 Wind River Way phone: 510-749-2130 Alameda, CA 94501 fax: 510-749-2010 --=_alternative 00086D0DC2256BC0_= Content-Type: text/html; charset="us-ascii"
I am in the process of the reviewing the needs for large numerical values (based on cryptography requirements for specified and other known schemes that vendors may want to use). If The results will indicate that large numerical values are of marginal use I will drop base64 for numbers. If not I will leave it as is.
As for you "confusion and ambiguity in
this realm of the spec (e.g., decimal representation, leading zeroes,
definitions of field size, byte swapping issues, etc.)" I am afraid that I don't see how base64 different than hexadecimal
and I assume a statement about ordering solves both.

Julo


"Michael Krueger" <michael.krueger@windriver.com>

05/20/2002 10:37 PM
Please respond to "Michael Krueger"

       
        To:        Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
        cc:        
        Subject:        RE: iSCSI: BASE64 and numerical values

       


On Saturday, May 18, 2002 1:31 AM, Julian Satran wrote:
> Yes for regular numerical values it makes sense. We will have to keep
> it for large numerical values used for cryptography.  Julo

I'm glad to see that base-64 encoding will be dropped for numbers, but I'm
afraid I still have a small issue with the language being used here.  As I
understand it, "large numerical values" are NOT used for cryptography; the
keys, challenges, responses, etc., are large BINARY ITEMS*, not large
numbers.  I still believe that failing to make a distinction between numbers
and binary items is what's behind a lot of the confusion and ambiguity in
this realm of the spec (e.g., decimal representation, leading zeroes,
definitions of field size, byte swapping issues, etc.).

Michael

*I have no special attachment to the term "binary items"; call them "binary
strings," "bit patterns," or whatever you like . . . but please just don't
call them "numeric" or "numbers."

--
Michael J. Krueger              mailto:michael.krueger@windriver.com
Wind River Networks                         http://www.windriver.com
500 Wind River Way                               phone: 510-749-2130
Alameda, CA  94501                                 fax: 510-749-2010

--=_alternative 00086D0DC2256BC0_=-- From owner-ips@ece.cmu.edu Tue May 21 02:08:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20329 for ; Tue, 21 May 2002 02:08:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4L5MDg22371 for ips-outgoing; Tue, 21 May 2002 01:22:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailnpd.hcltech.com ([203.197.145.76]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4L5M4w22354 for ; Tue, 21 May 2002 01:22:06 -0400 (EDT) Received: from npd.hcltech.com (IDENT:pamanick@pamanick.hcltech.com [192.168.100.58]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id g4L54JM12501; Tue, 21 May 2002 10:34:22 +0530 Message-ID: <3CE9D7C3.65A301BD@npd.hcltech.com> Date: Tue, 21 May 2002 10:44:43 +0530 From: Parthi Organization: HCL Tech X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bill Studenmund CC: Mike Donohoe , "'ips@ece.cmu.edu'" Subject: Re: iSCSI: Login Request error References: Content-Type: multipart/alternative; boundary="------------712CE6A4D6ACD86AB9DC8744" Sender: owner-ips@ece.cmu.edu Precedence: bulk --------------712CE6A4D6ACD86AB9DC8744 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > Responder should say "Reject" in Text param negotiation. > > > > ex. Originator-> ImmediateData=Ye > > Responder -> ImmediateData=Reject > > > > The status value would be 020b "Invalid during login". > > Would 020b be the correct error for that? I would have thought 0200 > "Miscellaneous iSCSI initiator errors" would have been better; I thought > 020b was exclusively for an attempt to do something that should only be > done in FFP, before you've gotten to FFP. > > Take care, > > Bill Hi : Draft says "Initiator Error(not a format error) -- This indicates request for a resource for which the initiator does not have permission. The request should not be tried again". -- Parthiban M, iSCSI Driver Team, HCL Technologies Ltd., Tel : (+91)-44-3741939 to 42, Extn. 2332 http://san.hcltech.com --------------712CE6A4D6ACD86AB9DC8744 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
>  Responder should say  "Reject" in Text param negotiation.
>
>        ex.       Originator->  ImmediateData=Ye
>                     Responder ->  ImmediateData=Reject
>
>  The status value would be  020b  "Invalid during login".

Would 020b be the correct error for that? I would have thought 0200
"Miscellaneous iSCSI initiator errors" would have been better; I thought
020b was exclusively for an attempt to do something that should only be
done in FFP, before you've gotten to FFP.

Take care,

Bill

Hi :

  Draft says "Initiator Error(not a format error) -- This indicates request for a resource for which the initiator
does not have permission. The request should not be tried again".

-- 
Parthiban M,
iSCSI Driver Team,
HCL Technologies Ltd.,          Tel : (+91)-44-3741939 to 42, Extn. 2332
http://san.hcltech.com
  --------------712CE6A4D6ACD86AB9DC8744-- From owner-ips@ece.cmu.edu Tue May 21 08:52:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08277 for ; Tue, 21 May 2002 08:52:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LCE7619058 for ips-outgoing; Tue, 21 May 2002 08:14:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailnpd.hcltech.com ([203.197.145.76]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LCE4w19053 for ; Tue, 21 May 2002 08:14:04 -0400 (EDT) Received: from npd.hcltech.com (skotra-pc.hcltech.com [192.168.100.57]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id g4LBv8M30447 for ; Tue, 21 May 2002 17:27:09 +0530 Message-ID: <3CEA3A6F.3FEFF84A@npd.hcltech.com> Date: Tue, 21 May 2002 17:45:43 +0530 From: Subrahmanya Sastry K V Organization: HCL Technologies X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: iSCSI : versions and draft no.s Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I would like to know the final word on the earlier discussion on the absence of a clear mapping between the iscsi draft version no.s and the various drafts. The last suggestion I saw in an earlier thread was that we could use a vendor specific X-draft= key, values to indicate the supported draft versions. The same was seconded by Julo for the plugfest. Is this the final conclusion for an implementation to support multiple versions ? Thanks -- Subrahmanya Sastry K V Member Technical Staff HCL Tech, Chennai, INDIA http://san.hcltech.com From owner-ips@ece.cmu.edu Tue May 21 10:33:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12217 for ; Tue, 21 May 2002 10:33:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LDmEf23963 for ips-outgoing; Tue, 21 May 2002 09:48:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LDm6w23954 for ; Tue, 21 May 2002 09:48:07 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4LCjQl32397; Tue, 21 May 2002 08:45:26 -0400 Message-ID: <3CEA4FBF.210108EF@splentec.com> Date: Tue, 21 May 2002 09:46:39 -0400 From: Luben Tuikov Reply-To: iSCSI , Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Parthi CC: Bill Studenmund , Mike Donohoe , "'ips@ece.cmu.edu'" , Julian Satran Subject: Re: iSCSI: Login Request error References: <3CE9D7C3.65A301BD@npd.hcltech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Parthi wrote: > > > > Responder should say "Reject" in Text param negotiation. > > > > > > ex. Originator-> ImmediateData=Ye > > > Responder -> ImmediateData=Reject > > > > > > The status value would be 020b "Invalid during login". > > > > Would 020b be the correct error for that? I would have thought 0200 > > "Miscellaneous iSCSI initiator errors" would have been better; I thought > > 020b was exclusively for an attempt to do something that should only be > > done in FFP, before you've gotten to FFP. > > > > Take care, > > > > Bill > > Hi : > > Draft says "Initiator Error(not a format error) -- This indicates request for a resource for > which the initiator > does not have permission. The request should not be tried again". The status value should be 0 (Success). Note that since we are talking about status codes, we imply that the _Target_ replies. That is, the Target should reply with (as already noted) ImmediateData=Reject and status of 0. This would tell the Initiator that login is proceeding ok, but ImmediateData needs renegotiation/reconsideration. Note that the Target may reply with other keys' responses, along with the rejected ones. Then the initiator will reconsider all rejected keys. Note that a status code of anything but 0, implies closing the connection. Please see this message: http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09771.html My reply is a bit messy, in that I should've been clearer, that the originator of the key being rejected by the responder, SHOULD, if available, offer another set of values, or close the connection. Currently, the draft says (pg 69, 12-90): If a responder does support, understand or is allowed to use none of the offered options with a specific originator, it MAY use the constant "Reject" or it MAY respond with an admissible value. The selection of a value not offered is considered a negotiation failure and is handled as a protocol error. Which is inconsistent with itself. (I.e. self-contradictory to negotiation.) Proof: By the first clause: Assume that the responder cannot use any of the offered options to a key (keyword ``none'' in the first sentence). Then the responder 1) MAY Reject, 2) MAY offer an admissible value. Take 2) and proceed. Then the originator receives an (admissible) value which was NOT in what it offered and closes the connection by the second clause. Clearly, this is a negotiation failure. If, on the other hand, we had chosen 1), i.e. send Reject, the originator, may reconsider it's options and send a different set of values, and should one of them be acceptable to the responder, we arrive at negotiation success. QED. This has already been communicated to Julian. Julian? Nevertheless, a Reject response is required by the responder to ``close the loop''. If the originator doesn't close the connection after that, the responder MAY choose to send it's own values for the same (Rejected) key. I.e. the responder to the Reject will now become the originator of the Reject-ed variable. -- Luben From owner-ips@ece.cmu.edu Tue May 21 10:37:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12352 for ; Tue, 21 May 2002 10:37:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LE2lA24853 for ips-outgoing; Tue, 21 May 2002 10:02:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4LE2jw24848 for ; Tue, 21 May 2002 10:02:46 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4LE2ep26973 for ; Tue, 21 May 2002 10:02:40 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4LE2dc26961; Tue, 21 May 2002 10:02:39 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g4LE2c814021; Tue, 21 May 2002 10:02:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15594.21381.531000.724824@gargle.gargle.HOWL> Date: Tue, 21 May 2002 10:02:45 -0400 From: Paul Koning To: Julian_Satran@il.ibm.com Cc: michael.krueger@windriver.com, ips@ece.cmu.edu Subject: RE: iSCSI: BASE64 and numerical values References: X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 21 May 2002) by Julian Satran: > I am in the process of the reviewing the needs for large numerical values > (based on cryptography requirements for specified and other known schemes > that vendors may want to use). If The results will indicate that large > numerical values are of marginal use I will drop base64 for numbers. If > not I will leave it as is. Diffie-Hellman and RSA are both based on arithmetic on large integers, so clearly it is necessary to agree on which byte in the bytestring encoding of those values is the most significant byte. Then again, the same is true for non-numeric values: if you swap around the bytes of an MD5 or SHA-1 cryptographic hash (as in CHAP) things break just as badly. > As for you "confusion and ambiguity in this realm of the spec (e.g., > decimal representation, leading zeroes, definitions of field size, > byte swapping issues, etc.)" I am afraid that I don't see how base64 > different than hexadecimal and I assume a statement about ordering > solves both. True. The remaining point is this: base64 is a standard encoding for octet strings, and therefore for bignums. It's not a commonly used encoding for "normal size integers" i.e., 32 or 64 bit ints. paul From owner-ips@ece.cmu.edu Tue May 21 11:33:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14932 for ; Tue, 21 May 2002 11:33:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LEVDW26767 for ips-outgoing; Tue, 21 May 2002 10:31:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LEV9w26756; Tue, 21 May 2002 10:31:10 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4LEV2xK027442; Tue, 21 May 2002 16:31:02 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4LEV1R117188; Tue, 21 May 2002 16:31:01 +0200 To: Subrahmanya Sastry K V Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI : versions and draft no.s X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 21 May 2002 17:29:12 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 21/05/2002 17:31:01, Serialize complete at 21/05/2002 17:31:01 Content-Type: multipart/alternative; boundary="=_alternative 004E7B87C2256BC0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004E7B87C2256BC0_= Content-Type: text/plain; charset="us-ascii" That is still the case - Julo Subrahmanya Sastry K V Sent by: owner-ips@ece.cmu.edu 05/21/2002 03:15 PM Please respond to Subrahmanya Sastry K V To: ips@ece.cmu.edu cc: Subject: iSCSI : versions and draft no.s Hi all, I would like to know the final word on the earlier discussion on the absence of a clear mapping between the iscsi draft version no.s and the various drafts. The last suggestion I saw in an earlier thread was that we could use a vendor specific X-draft= key, values to indicate the supported draft versions. The same was seconded by Julo for the plugfest. Is this the final conclusion for an implementation to support multiple versions ? Thanks -- Subrahmanya Sastry K V Member Technical Staff HCL Tech, Chennai, INDIA http://san.hcltech.com --=_alternative 004E7B87C2256BC0_= Content-Type: text/html; charset="us-ascii"
That is still the case - Julo


Subrahmanya Sastry K V <skotra@npd.hcltech.com>
Sent by: owner-ips@ece.cmu.edu

05/21/2002 03:15 PM
Please respond to Subrahmanya Sastry K V

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI : versions and draft no.s

       


Hi all,

I would like to know the final word on the earlier discussion on the
absence of a clear mapping between the iscsi draft version no.s and the
various drafts.

The last suggestion I saw in an earlier thread was that we could use a
vendor specific X-draft=<draft version(s)>  key, values to indicate the
supported draft versions. The same was seconded by Julo for the
plugfest. Is this the final conclusion for an implementation to support
multiple versions ?

Thanks
--
Subrahmanya Sastry K V
Member Technical Staff
HCL Tech, Chennai, INDIA
http://san.hcltech.com

--=_alternative 004E7B87C2256BC0_=-- From owner-ips@ece.cmu.edu Tue May 21 11:54:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15551 for ; Tue, 21 May 2002 11:54:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LFDva29441 for ips-outgoing; Tue, 21 May 2002 11:13:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LFDqw29431 for ; Tue, 21 May 2002 11:13:52 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id IAA15594; Tue, 21 May 2002 08:13:40 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 08:13:39 -0700 Message-ID: From: Robert Snively To: "'Bill Studenmund'" , Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: BASE64 and numerical values Date: Tue, 21 May 2002 08:13:33 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I have been having continuing problems understanding why iSCSI is considering any use of base64, and I find myself in total agreement with Bill's clear exposition of the situation. Upon reviewing RFC-2045, it is clear that base64 is a method for containing handy binary values in a EMAIL structure that does not use TCP/IP to transmit data, but rather uses obsolete 7-bit ASCII or (slightly less obsolete) EBCDIC strings to carry the data. TCP/IP transmits data neutral octets, so binary values can be carried in their native binary string format (allowing for a possible requirement to pad strings to an octet boundary). The most standard way to present those binary strings on a printer or as an input value to a program is hexadecimal encoding. For those reasons, I agree with Bill that we should delete base64 from the text and use hexadecimal as he suggests. Bob > -----Original Message----- > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] > Sent: Monday, May 20, 2002 2:54 PM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: BASE64 and numerical values > > > On Sat, 18 May 2002, Julian Satran wrote: > > > Yes for regular numerical values it makes sense. We will > have to keep it > > for large numerical values used for cryptography. Julo > > I realize I'm driving a semantic nit, but I don't think we should use > BASE64 for any "numeric" values, only "binary" ones. I > believe we probably > agree on what we want, I'm just worried that if the wording isn't 100% > tight, the decode path can become a real mess (since we're > supposed to be > liberal in what we accept :-). > > I'd like to suggest we drop BASE64 from the text that > mentions numerical > values. I really don't look forward to byteswapping a 256 or 512 bit > number as part of BASE64 decode. :-) > > I'd also like to suggest that for encoding large binary values using > hexadecimal, we state that the hexadecimal representation is > that of the > number in network byte order. i.e. if I have the five octets > 02 45 78 ab > de, the hex constant is 0x024578abde. That makes the decode logic REAL > easy; grab two hex characters & convert to one octet. Repeat > as needed. > Please note that this is not the output you'd get with something like > printf("0x%x", number) on a little-endian machine. > > Thirdly, I'd like to suggest we drop decimal support from > binary objects. > It too has the cumbersome byte-swapping issue that I started > this thread > about, just in reverse. :-) > > I realize that's a lot for one EMail. :-) > > To try and be proactive about this, I'd like to suggest > revised text for > section 4.1 (of course needs word-wrapping). For the definitions: > > hex-constant: hexadecimal constant encoded as a string start- > ing with "0x" or "0X" followed by 1 or more digits or the > letters a, b, c, d, e, f, A, B, C, D, E and F. Hex-constants > are used to encode numerical values or binary strings. When > used to encode numerical values the excessive use of leading > 0 digits is discouraged. When used to encode binary strings > hexadecimal constants must have an even number of digits, > and have an implicit byte-length that > includes 4 bits for every hexadecimal digit of the constant, > including leading zeroes (i.e., a hex-constant of n hexadeci- > mal digits has a byte-length of n/2). Additionally, when used > to encode binary strings, hexadecimal constants shall be > expressed in network byte order (i.e., the octet stream 02 > 45 78 ab de would be expressed as "0x024578abde"). > > decimal-constant: an unsigned decimal number - the digit 0 or a > string of 1 or more digits starting with a non-zero digit. > This encoding is not used for numerical values equal or > greater than 2**64. > > base64-constant: base64 constant encoded as a string starting > with "0b" or "0B" followed by 1 or more digits or letters or > plus or slash or equal. The encoding is done according to > [RFC2045]. base64-constants are used to encode binary strings. > Base64-constants have an implicit byte-length that includes 6 > bits for every character of the constant excluding trailing > equals (i.e., a base64-constant of n base64 characters > excluding the trailing equals and m trailing equals has a > byte-length of ((the integer part of) ((n+3)*3/4) - m). > > regular-numerical-value : an unsigned integer less than 2**64 > encoded as a decimal-constant, or hex constant. > > large-numerical-value : an unsigned integer larger than or > equal to 2**64 encoded as a hex constant. > > [no change for numerical-value or numerical-range] > > binary-value : a binary string encoded as a hex-con- > stant or base64-constant. The length of the string is either > specified by the key definition or is implicit byte-length of > the encoded string. > > [delete regualar-binary-value and large-binary-value since > the distinction > is gone] > > I don't see it explicitly mentioned anywhere, but I think all > of the CHAP > (and SRP, but not sure) keys are large numericalal values, and the > kerberos and SPKM keys are binary values. > > Also, I think the CHAP keys need the field length features of > hexadecimal > binary strings, but they are numbers, not binary strings. Not > sure how to > word that. > > Take care, > > Bill > > From owner-ips@ece.cmu.edu Tue May 21 12:45:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18539 for ; Tue, 21 May 2002 12:45:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LG1ND02979 for ips-outgoing; Tue, 21 May 2002 12:01:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LBUFw17251 for ; Tue, 21 May 2002 07:30:15 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04746; Tue, 21 May 2002 07:29:56 -0400 (EDT) Message-Id: <200205211129.HAA04746@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-isns-10.txt Date: Tue, 21 May 2002 07:29:56 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Internet Storage Name Service (iSNS) Author(s) : J. Tseng, K. Gibbons et al. Filename : draft-ietf-ips-isns-10.txt Pages : 89 Date : 20-May-02 This document specifies the iSNS protocol, which is used for interaction between iSNS servers and iSNS clients in order to facilitate automated discovery, management, and configuration of iSCSI and Fibre Channel (FCP) devices on a TCP/IP network. iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. iSNS also facilitates a seamless integration of IP and Fibre Channel networks, due to its ability to emulate Fibre Channel fabric services, and manage both iSCSI and Fibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices, or any combination thereof. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-isns-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-isns-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020520143129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-isns-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-isns-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020520143129.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue May 21 12:45:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18581 for ; Tue, 21 May 2002 12:45:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LG1CE02954 for ips-outgoing; Tue, 21 May 2002 12:01:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LBUAw17241 for ; Tue, 21 May 2002 07:30:10 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04730; Tue, 21 May 2002 07:29:51 -0400 (EDT) Message-Id: <200205211129.HAA04730@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-isns-mib-02.txt Date: Tue, 21 May 2002 07:29:51 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Definitions of Managed Objects for iSNS (Internet Storage Name Service) Author(s) : K. Gibbons, J. Tseng, C. Monia, T. McSweeney Filename : draft-ietf-ips-isns-mib-02.txt Pages : 64 Date : 20-May-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based monitoring and management of the Internet Storage Name Service (iSNS). This memo specifies a MIB module in a manner that is compliant to the SMIv2. The set of objects is consistent with the SNMP framework and existing SNMP standards. This memo is a product of the IP Storage (IPS) working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ips@ece.cmu.edu and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-mib-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-isns-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-isns-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020520143120.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-isns-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-isns-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020520143120.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue May 21 12:45:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18597 for ; Tue, 21 May 2002 12:45:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LG84M03546 for ips-outgoing; Tue, 21 May 2002 12:08:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LG7xw03532 for ; Tue, 21 May 2002 12:08:00 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4LG7pwY026090; Tue, 21 May 2002 18:07:51 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4LG7nR55204; Tue, 21 May 2002 18:07:49 +0200 To: Robert Snively Cc: ips@ece.cmu.edu, "'Bill Studenmund'" MIME-Version: 1.0 Subject: RE: iSCSI: BASE64 and numerical values X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 21 May 2002 19:07:47 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 21/05/2002 19:07:50, Serialize complete at 21/05/2002 19:07:50 Content-Type: multipart/alternative; boundary="=_alternative 0057AD75C2256BC0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0057AD75C2256BC0_= Content-Type: text/plain; charset="us-ascii" And ignore completely the needs of some cryptographic protocols for large numerical values? I do not see why 6 bit values are more difficult to handle than 4 or 8 bit ones. Julo Robert Snively 05/21/2002 06:13 PM Please respond to Robert Snively To: "'Bill Studenmund'" , Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: BASE64 and numerical values I have been having continuing problems understanding why iSCSI is considering any use of base64, and I find myself in total agreement with Bill's clear exposition of the situation. Upon reviewing RFC-2045, it is clear that base64 is a method for containing handy binary values in a EMAIL structure that does not use TCP/IP to transmit data, but rather uses obsolete 7-bit ASCII or (slightly less obsolete) EBCDIC strings to carry the data. TCP/IP transmits data neutral octets, so binary values can be carried in their native binary string format (allowing for a possible requirement to pad strings to an octet boundary). The most standard way to present those binary strings on a printer or as an input value to a program is hexadecimal encoding. For those reasons, I agree with Bill that we should delete base64 from the text and use hexadecimal as he suggests. Bob > -----Original Message----- > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] > Sent: Monday, May 20, 2002 2:54 PM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: BASE64 and numerical values > > > On Sat, 18 May 2002, Julian Satran wrote: > > > Yes for regular numerical values it makes sense. We will > have to keep it > > for large numerical values used for cryptography. Julo > > I realize I'm driving a semantic nit, but I don't think we should use > BASE64 for any "numeric" values, only "binary" ones. I > believe we probably > agree on what we want, I'm just worried that if the wording isn't 100% > tight, the decode path can become a real mess (since we're > supposed to be > liberal in what we accept :-). > > I'd like to suggest we drop BASE64 from the text that > mentions numerical > values. I really don't look forward to byteswapping a 256 or 512 bit > number as part of BASE64 decode. :-) > > I'd also like to suggest that for encoding large binary values using > hexadecimal, we state that the hexadecimal representation is > that of the > number in network byte order. i.e. if I have the five octets > 02 45 78 ab > de, the hex constant is 0x024578abde. That makes the decode logic REAL > easy; grab two hex characters & convert to one octet. Repeat > as needed. > Please note that this is not the output you'd get with something like > printf("0x%x", number) on a little-endian machine. > > Thirdly, I'd like to suggest we drop decimal support from > binary objects. > It too has the cumbersome byte-swapping issue that I started > this thread > about, just in reverse. :-) > > I realize that's a lot for one EMail. :-) > > To try and be proactive about this, I'd like to suggest > revised text for > section 4.1 (of course needs word-wrapping). For the definitions: > > hex-constant: hexadecimal constant encoded as a string start- > ing with "0x" or "0X" followed by 1 or more digits or the > letters a, b, c, d, e, f, A, B, C, D, E and F. Hex-constants > are used to encode numerical values or binary strings. When > used to encode numerical values the excessive use of leading > 0 digits is discouraged. When used to encode binary strings > hexadecimal constants must have an even number of digits, > and have an implicit byte-length that > includes 4 bits for every hexadecimal digit of the constant, > including leading zeroes (i.e., a hex-constant of n hexadeci- > mal digits has a byte-length of n/2). Additionally, when used > to encode binary strings, hexadecimal constants shall be > expressed in network byte order (i.e., the octet stream 02 > 45 78 ab de would be expressed as "0x024578abde"). > > decimal-constant: an unsigned decimal number - the digit 0 or a > string of 1 or more digits starting with a non-zero digit. > This encoding is not used for numerical values equal or > greater than 2**64. > > base64-constant: base64 constant encoded as a string starting > with "0b" or "0B" followed by 1 or more digits or letters or > plus or slash or equal. The encoding is done according to > [RFC2045]. base64-constants are used to encode binary strings. > Base64-constants have an implicit byte-length that includes 6 > bits for every character of the constant excluding trailing > equals (i.e., a base64-constant of n base64 characters > excluding the trailing equals and m trailing equals has a > byte-length of ((the integer part of) ((n+3)*3/4) - m). > > regular-numerical-value : an unsigned integer less than 2**64 > encoded as a decimal-constant, or hex constant. > > large-numerical-value : an unsigned integer larger than or > equal to 2**64 encoded as a hex constant. > > [no change for numerical-value or numerical-range] > > binary-value : a binary string encoded as a hex-con- > stant or base64-constant. The length of the string is either > specified by the key definition or is implicit byte-length of > the encoded string. > > [delete regualar-binary-value and large-binary-value since > the distinction > is gone] > > I don't see it explicitly mentioned anywhere, but I think all > of the CHAP > (and SRP, but not sure) keys are large numericalal values, and the > kerberos and SPKM keys are binary values. > > Also, I think the CHAP keys need the field length features of > hexadecimal > binary strings, but they are numbers, not binary strings. Not > sure how to > word that. > > Take care, > > Bill > > --=_alternative 0057AD75C2256BC0_= Content-Type: text/html; charset="us-ascii"
And ignore completely the needs of some cryptographic protocols for large numerical values?  
I do not see why 6 bit values are more difficult to handle than 4 or 8 bit ones.

Julo


Robert Snively <rsnively@brocade.com>

05/21/2002 06:13 PM
Please respond to Robert Snively

       
        To:        "'Bill Studenmund'" <wrstuden@wasabisystems.com>, Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: BASE64 and numerical values

       


I have been having continuing problems understanding why
iSCSI is considering any use of base64, and I find myself
in total agreement with Bill's clear exposition of the
situation.

Upon reviewing RFC-2045, it is clear that base64 is a method
for containing handy binary values in a EMAIL structure that does
not use TCP/IP to transmit data, but rather uses obsolete
7-bit ASCII or (slightly less obsolete) EBCDIC strings to
carry the data.  TCP/IP transmits data neutral octets,
so binary values can be carried in their native binary
string format (allowing for a possible requirement to pad
strings to an octet boundary).  The most standard way to
present those binary strings on a printer or as an input
value to a program is hexadecimal encoding.

For those reasons, I agree with Bill that we should delete
base64 from the text and use hexadecimal as he suggests.

Bob

> -----Original Message-----
> From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
> Sent: Monday, May 20, 2002 2:54 PM
> To: Julian Satran
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: BASE64 and numerical values
>
>
> On Sat, 18 May 2002, Julian Satran wrote:
>
> > Yes for regular numerical values it makes sense. We will
> have to keep it
> > for large numerical values used for cryptography.  Julo
>
> I realize I'm driving a semantic nit, but I don't think we should use
> BASE64 for any "numeric" values, only "binary" ones. I
> believe we probably
> agree on what we want, I'm just worried that if the wording isn't 100%
> tight, the decode path can become a real mess (since we're
> supposed to be
> liberal in what we accept :-).
>
> I'd like to suggest we drop BASE64 from the text that
> mentions numerical
> values. I really don't look forward to byteswapping a 256 or 512 bit
> number as part of BASE64 decode. :-)
>
> I'd also like to suggest that for encoding large binary values using
> hexadecimal, we state that the hexadecimal representation is
> that of the
> number in network byte order. i.e. if I have the five octets
> 02 45 78 ab
> de, the hex constant is 0x024578abde. That makes the decode logic REAL
> easy; grab two hex characters & convert to one octet. Repeat
> as needed.
> Please note that this is not the output you'd get with something like
> printf("0x%x", number) on a little-endian machine.
>
> Thirdly, I'd like to suggest we drop decimal support from
> binary objects.
> It too has the cumbersome byte-swapping issue that I started
> this thread
> about, just in reverse. :-)
>
> I realize that's a lot for one EMail. :-)
>
> To try and be proactive about this, I'd like to suggest
> revised text for
> section 4.1 (of course needs word-wrapping). For the definitions:
>
>      hex-constant: hexadecimal constant encoded as a string start-
>        ing with "0x" or "0X" followed by 1 or more digits or the
>        letters a, b, c, d, e, f, A, B, C, D, E and F. Hex-constants
>        are used to encode numerical values or binary strings. When
>        used to encode numerical values the excessive use of leading
>        0 digits is discouraged. When used to encode binary strings
>        hexadecimal constants must have an even number of digits,
>        and have an implicit byte-length that
>        includes 4 bits for every hexadecimal digit of the constant,
>        including leading zeroes (i.e., a hex-constant of n hexadeci-
>        mal digits has a byte-length of n/2). Additionally, when used
>        to encode binary strings, hexadecimal constants shall be
>        expressed in network byte order (i.e., the octet stream 02
>        45 78 ab de would be expressed as "0x024578abde").
>
>      decimal-constant: an unsigned decimal number - the digit 0 or a
>        string of 1 or more digits starting with a non-zero digit.
>        This encoding is not used for numerical values equal or
>        greater than 2**64.
>
>      base64-constant: base64 constant encoded as a string starting
>        with "0b" or "0B" followed by 1 or more digits or letters or
>        plus or slash or equal. The encoding is done according to
>        [RFC2045]. base64-constants are used to encode binary strings.
>        Base64-constants have an implicit byte-length that includes 6
>        bits for every character of the constant excluding trailing
>        equals (i.e., a base64-constant of n base64 characters
>        excluding the trailing equals and m trailing equals has a
>        byte-length of ((the integer part of) ((n+3)*3/4) - m).
>
>        regular-numerical-value :  an unsigned integer less than 2**64
>          encoded as a decimal-constant, or hex constant.
>
>        large-numerical-value :  an unsigned integer larger than or
>          equal to 2**64 encoded as a hex constant.
>
> [no change for numerical-value or numerical-range]
>
>        binary-value :  a binary string encoded as a hex-con-
>          stant or base64-constant.  The length of the string is either
>          specified by the key definition or is implicit byte-length of
>          the encoded string.
>
> [delete regualar-binary-value and large-binary-value since
> the distinction
> is gone]
>
> I don't see it explicitly mentioned anywhere, but I think all
> of the CHAP
> (and SRP, but not sure) keys are large numericalal values, and the
> kerberos and SPKM keys are binary values.
>
> Also, I think the CHAP keys need the field length features of
> hexadecimal
> binary strings, but they are numbers, not binary strings. Not
> sure how to
> word that.
>
> Take care,
>
> Bill
>
>


--=_alternative 0057AD75C2256BC0_=-- From owner-ips@ece.cmu.edu Tue May 21 12:53:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18843 for ; Tue, 21 May 2002 12:53:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LGTVu04976 for ips-outgoing; Tue, 21 May 2002 12:29:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LGTTw04970 for ; Tue, 21 May 2002 12:29:29 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id C575230706; Tue, 21 May 2002 12:29:28 -0400 (EDT) Date: Tue, 21 May 2002 09:27:33 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Robert Snively Cc: Julian Satran , Subject: RE: iSCSI: BASE64 and numerical values In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 21 May 2002, Robert Snively wrote: > I have been having continuing problems understanding why > iSCSI is considering any use of base64, and I find myself > in total agreement with Bill's clear exposition of the > situation. > > Upon reviewing RFC-2045, it is clear that base64 is a method > for containing handy binary values in a EMAIL structure that does > not use TCP/IP to transmit data, but rather uses obsolete > 7-bit ASCII or (slightly less obsolete) EBCDIC strings to > carry the data. TCP/IP transmits data neutral octets, > so binary values can be carried in their native binary > string format (allowing for a possible requirement to pad > strings to an octet boundary). The most standard way to > present those binary strings on a printer or as an input > value to a program is hexadecimal encoding. > > For those reasons, I agree with Bill that we should delete > base64 from the text and use hexadecimal as he suggests. I must not have been totally clear. I'm not suggesting we remove base64, I'm suggesting we limit its use to the cases where (IMHO) it makes sense. While there will be much fewer cases in the text with the changes I suggest, it will still be in the spec. Some of the cryptographic authentications throw around large binary strings. Quite large (compared to the numbers and strings we often use) binary strings. The fact that if you support these modes of authentication you are supposed to be able to accept four times as much text in login commands reflects the size of these strings. Base64 is a real win for these. Hex can encode 4 bits per byte, while base64 can encode 6. Thus an n byte string will be about 1.33*n bytes in base 64, while it will be 2n bytes in hex. That size difference is why we want base64. The main point I've been trying to make is that binary strings and numbers are different things, and that encoding methods for one aren't really appropriate for the other. Specifics: decimal & hex work great for numbers, and hex and base64 work great for binary strings. That's it. Also, the hex for numbers isn't the same as the hex for binary strings. One is the number in hex, the other is more like hexdump -x without the spaces and without the offsets. Take care, Bill From owner-ips@ece.cmu.edu Tue May 21 13:49:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21890 for ; Tue, 21 May 2002 13:49:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LGkkX06094 for ips-outgoing; Tue, 21 May 2002 12:46:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LGkiw06084 for ; Tue, 21 May 2002 12:46:44 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 4E528BA74; Tue, 21 May 2002 10:46:43 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 2CC5C26D; Tue, 21 May 2002 10:46:43 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 21 May 2002 10:46:42 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 10:46:42 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09CA41@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, rsnively@Brocade.COM Cc: ips@ece.cmu.edu, wrstuden@wasabisystems.com Subject: RE: iSCSI: BASE64 and numerical values Date: Tue, 21 May 2002 10:46:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-34d2755d-4d39-4829-8116-06fb5e6a921d" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-34d2755d-4d39-4829-8116-06fb5e6a921d Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C200E7.146C9160" ------_=_NextPart_001_01C200E7.146C9160 Content-Type: text/plain; charset="iso-8859-1" Julian, Don't the large cryptographic strings represent the coefficients of binary polynomials? I think those are binary values rather than numerical ones so it makes sense to restrict the base64 to binary objects as Bill suggests. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, May 21, 2002 9:08 AM To: Robert Snively Cc: ips@ece.cmu.edu; 'Bill Studenmund' Subject: RE: iSCSI: BASE64 and numerical values And ignore completely the needs of some cryptographic protocols for large numerical values? I do not see why 6 bit values are more difficult to handle than 4 or 8 bit ones. Julo Robert Snively 05/21/2002 06:13 PM Please respond to Robert Snively To: "'Bill Studenmund'" , Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: BASE64 and numerical values I have been having continuing problems understanding why iSCSI is considering any use of base64, and I find myself in total agreement with Bill's clear exposition of the situation. Upon reviewing RFC-2045, it is clear that base64 is a method for containing handy binary values in a EMAIL structure that does not use TCP/IP to transmit data, but rather uses obsolete 7-bit ASCII or (slightly less obsolete) EBCDIC strings to carry the data. TCP/IP transmits data neutral octets, so binary values can be carried in their native binary string format (allowing for a possible requirement to pad strings to an octet boundary). The most standard way to present those binary strings on a printer or as an input value to a program is hexadecimal encoding. For those reasons, I agree with Bill that we should delete base64 from the text and use hexadecimal as he suggests. Bob > -----Original Message----- > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] > Sent: Monday, May 20, 2002 2:54 PM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: BASE64 and numerical values > > > On Sat, 18 May 2002, Julian Satran wrote: > > > Yes for regular numerical values it makes sense. We will > have to keep it > > for large numerical values used for cryptography. Julo > > I realize I'm driving a semantic nit, but I don't think we should use > BASE64 for any "numeric" values, only "binary" ones. I > believe we probably > agree on what we want, I'm just worried that if the wording isn't 100% > tight, the decode path can become a real mess (since we're > supposed to be > liberal in what we accept :-). > > I'd like to suggest we drop BASE64 from the text that > mentions numerical > values. I really don't look forward to byteswapping a 256 or 512 bit > number as part of BASE64 decode. :-) > > I'd also like to suggest that for encoding large binary values using > hexadecimal, we state that the hexadecimal representation is > that of the > number in network byte order. i.e. if I have the five octets > 02 45 78 ab > de, the hex constant is 0x024578abde. That makes the decode logic REAL > easy; grab two hex characters & convert to one octet. Repeat > as needed. > Please note that this is not the output you'd get with something like > printf("0x%x", number) on a little-endian machine. > > Thirdly, I'd like to suggest we drop decimal support from > binary objects. > It too has the cumbersome byte-swapping issue that I started > this thread > about, just in reverse. :-) > > I realize that's a lot for one EMail. :-) > > To try and be proactive about this, I'd like to suggest > revised text for > section 4.1 (of course needs word-wrapping). For the definitions: > > hex-constant: hexadecimal constant encoded as a string start- > ing with "0x" or "0X" followed by 1 or more digits or the > letters a, b, c, d, e, f, A, B, C, D, E and F. Hex-constants > are used to encode numerical values or binary strings. When > used to encode numerical values the excessive use of leading > 0 digits is discouraged. When used to encode binary strings > hexadecimal constants must have an even number of digits, > and have an implicit byte-length that > includes 4 bits for every hexadecimal digit of the constant, > including leading zeroes (i.e., a hex-constant of n hexadeci- > mal digits has a byte-length of n/2). Additionally, when used > to encode binary strings, hexadecimal constants shall be > expressed in network byte order (i.e., the octet stream 02 > 45 78 ab de would be expressed as "0x024578abde"). > > decimal-constant: an unsigned decimal number - the digit 0 or a > string of 1 or more digits starting with a non-zero digit. > This encoding is not used for numerical values equal or > greater than 2**64. > > base64-constant: base64 constant encoded as a string starting > with "0b" or "0B" followed by 1 or more digits or letters or > plus or slash or equal. The encoding is done according to > [RFC2045]. base64-constants are used to encode binary strings. > Base64-constants have an implicit byte-length that includes 6 > bits for every character of the constant excluding trailing > equals (i.e., a base64-constant of n base64 characters > excluding the trailing equals and m trailing equals has a > byte-length of ((the integer part of) ((n+3)*3/4) - m). > > regular-numerical-value : an unsigned integer less than 2**64 > encoded as a decimal-constant, or hex constant. > > large-numerical-value : an unsigned integer larger than or > equal to 2**64 encoded as a hex constant. > > [no change for numerical-value or numerical-range] > > binary-value : a binary string encoded as a hex-con- > stant or base64-constant. The length of the string is either > specified by the key definition or is implicit byte-length of > the encoded string. > > [delete regualar-binary-value and large-binary-value since > the distinction > is gone] > > I don't see it explicitly mentioned anywhere, but I think all > of the CHAP > (and SRP, but not sure) keys are large numericalal values, and the > kerberos and SPKM keys are binary values. > > Also, I think the CHAP keys need the field length features of > hexadecimal > binary strings, but they are numbers, not binary strings. Not > sure how to > word that. > > Take care, > > Bill > > ------_=_NextPart_001_01C200E7.146C9160 Content-Type: text/html; charset="iso-8859-1"

Julian,
 
Don't the large cryptographic strings represent the coefficients of binary polynomials? I think those are binary values rather than numerical ones so it makes sense to restrict the base64 to binary objects as Bill suggests.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, May 21, 2002 9:08 AM
To: Robert Snively
Cc: ips@ece.cmu.edu; 'Bill Studenmund'
Subject: RE: iSCSI: BASE64 and numerical values


And ignore completely the needs of some cryptographic protocols for large numerical values?  
I do not see why 6 bit values are more difficult to handle than 4 or 8 bit ones.

Julo


Robert Snively <rsnively@brocade.com>

05/21/2002 06:13 PM
Please respond to Robert Snively

       
        To:        "'Bill Studenmund'" <wrstuden@wasabisystems.com>, Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: BASE64 and numerical values

       


I have been having continuing problems understanding why
iSCSI is considering any use of base64, and I find myself
in total agreement with Bill's clear exposition of the
situation.

Upon reviewing RFC-2045, it is clear that base64 is a method
for containing handy binary values in a EMAIL structure that does
not use TCP/IP to transmit data, but rather uses obsolete
7-bit ASCII or (slightly less obsolete) EBCDIC strings to
carry the data.  TCP/IP transmits data neutral octets,
so binary values can be carried in their native binary
string format (allowing for a possible requirement to pad
strings to an octet boundary).  The most standard way to
present those binary strings on a printer or as an input
value to a program is hexadecimal encoding.

For those reasons, I agree with Bill that we should delete
base64 from the text and use hexadecimal as he suggests.

Bob

> -----Original Message-----
> From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
> Sent: Monday, May 20, 2002 2:54 PM
> To: Julian Satran
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: BASE64 and numerical values
>
>
> On Sat, 18 May 2002, Julian Satran wrote:
>
> > Yes for regular numerical values it makes sense. We will
> have to keep it
> > for large numerical values used for cryptography.  Julo
>
> I realize I'm driving a semantic nit, but I don't think we should use
> BASE64 for any "numeric" values, only "binary" ones. I
> believe we probably
> agree on what we want, I'm just worried that if the wording isn't 100%
> tight, the decode path can become a real mess (since we're
> supposed to be
> liberal in what we accept :-).
>
> I'd like to suggest we drop BASE64 from the text that
> mentions numerical
> values. I really don't look forward to byteswapping a 256 or 512 bit
> number as part of BASE64 decode. :-)
>
> I'd also like to suggest that for encoding large binary values using
> hexadecimal, we state that the hexadecimal representation is
> that of the
> number in network byte order. i.e. if I have the five octets
> 02 45 78 ab
> de, the hex constant is 0x024578abde. That makes the decode logic REAL
> easy; grab two hex characters & convert to one octet. Repeat
> as needed.
> Please note that this is not the output you'd get with something like
> printf("0x%x", number) on a little-endian machine.
>
> Thirdly, I'd like to suggest we drop decimal support from
> binary objects.
> It too has the cumbersome byte-swapping issue that I started
> this thread
> about, just in reverse. :-)
>
> I realize that's a lot for one EMail. :-)
>
> To try and be proactive about this, I'd like to suggest
> revised text for
> section 4.1 (of course needs word-wrapping). For the definitions:
>
>      hex-constant: hexadecimal constant encoded as a string start-
>        ing with "0x" or "0X" followed by 1 or more digits or the
>        letters a, b, c, d, e, f, A, B, C, D, E and F. Hex-constants
>        are used to encode numerical values or binary strings. When
>        used to encode numerical values the excessive use of leading
>        0 digits is discouraged. When used to encode binary strings
>        hexadecimal constants must have an even number of digits,
>        and have an implicit byte-length that
>        includes 4 bits for every hexadecimal digit of the constant,
>        including leading zeroes (i.e., a hex-constant of n hexadeci-
>        mal digits has a byte-length of n/2). Additionally, when used
>        to encode binary strings, hexadecimal constants shall be
>        expressed in network byte order (i.e., the octet stream 02
>        45 78 ab de would be expressed as "0x024578abde").
>
>      decimal-constant: an unsigned decimal number - the digit 0 or a
>        string of 1 or more digits starting with a non-zero digit.
>        This encoding is not used for numerical values equal or
>        greater than 2**64.
>
>      base64-constant: base64 constant encoded as a string starting
>        with "0b" or "0B" followed by 1 or more digits or letters or
>        plus or slash or equal. The encoding is done according to
>        [RFC2045]. base64-constants are used to encode binary strings.
>        Base64-constants have an implicit byte-length that includes 6
>        bits for every character of the constant excluding trailing
>        equals (i.e., a base64-constant of n base64 characters
>        excluding the trailing equals and m trailing equals has a
>        byte-length of ((the integer part of) ((n+3)*3/4) - m).
>
>        regular-numerical-value :  an unsigned integer less than 2**64
>          encoded as a decimal-constant, or hex constant.
>
>        large-numerical-value :  an unsigned integer larger than or
>          equal to 2**64 encoded as a hex constant.
>
> [no change for numerical-value or numerical-range]
>
>        binary-value :  a binary string encoded as a hex-con-
>          stant or base64-constant.  The length of the string is either
>          specified by the key definition or is implicit byte-length of
>          the encoded string.
>
> [delete regualar-binary-value and large-binary-value since
> the distinction
> is gone]
>
> I don't see it explicitly mentioned anywhere, but I think all
> of the CHAP
> (and SRP, but not sure) keys are large numericalal values, and the
> kerberos and SPKM keys are binary values.
>
> Also, I think the CHAP keys need the field length features of
> hexadecimal
> binary strings, but they are numbers, not binary strings. Not
> sure how to
> word that.
>
> Take care,
>
> Bill
>
>


------_=_NextPart_001_01C200E7.146C9160-- ------=_NextPartTM-000-34d2755d-4d39-4829-8116-06fb5e6a921d-- From owner-ips@ece.cmu.edu Tue May 21 14:32:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23531 for ; Tue, 21 May 2002 14:32:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LHoWA10969 for ips-outgoing; Tue, 21 May 2002 13:50:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LHoUw10965 for ; Tue, 21 May 2002 13:50:30 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4LGnBl01265; Tue, 21 May 2002 12:49:11 -0400 Message-ID: <3CEA88E1.4835E5C0@splentec.com> Date: Tue, 21 May 2002 13:50:25 -0400 From: Luben Tuikov Reply-To: iSCSI , Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI , Julian Satran Subject: MaxRecvPDULength question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The key name ``MaxRecvPDULength'' doesn't imply ? Why is it considered as such then? I suggest that ``MaxRecvPDULength'' be set to mean the maximum PDU length, NOT the maximum _data_ length. Reason: It is _faster_ to get the PDU off the the TCP data stack in _one_ (system) call, rather than two (system) calls. This _would_ improve implementaions, more so for user-space such. But lets still keep the size of the PDU a power of 2. (This would imply that the non-existent MaxRecvDataLength to MaxRecvPDULength - 48.) Comments? -- Luben From owner-ips@ece.cmu.edu Tue May 21 15:09:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25030 for ; Tue, 21 May 2002 15:09:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LISIh22697 for ips-outgoing; Tue, 21 May 2002 14:28:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LISEw22685 for ; Tue, 21 May 2002 14:28:14 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4LIS6Nf040012; Tue, 21 May 2002 20:28:06 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4LIS5s77142; Tue, 21 May 2002 20:28:05 +0200 To: Bill Studenmund Cc: ips@ece.cmu.edu, Robert Snively MIME-Version: 1.0 Subject: RE: iSCSI: BASE64 and numerical values X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 21 May 2002 21:28:00 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 21/05/2002 21:28:05, Serialize complete at 21/05/2002 21:28:05 Content-Type: multipart/alternative; boundary="=_alternative 005CCFEAC2256BC0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005CCFEAC2256BC0_= Content-Type: text/plain; charset="us-ascii" Bill, Your point was clear. I am still loking at the cases where LARGE NUMBERS might be needed and I am sure we don't want them to be strings but numbers. Julo Bill Studenmund 05/21/2002 07:27 PM Please respond to Bill Studenmund To: Robert Snively cc: Julian Satran/Haifa/IBM@IBMIL, Subject: RE: iSCSI: BASE64 and numerical values On Tue, 21 May 2002, Robert Snively wrote: > I have been having continuing problems understanding why > iSCSI is considering any use of base64, and I find myself > in total agreement with Bill's clear exposition of the > situation. > > Upon reviewing RFC-2045, it is clear that base64 is a method > for containing handy binary values in a EMAIL structure that does > not use TCP/IP to transmit data, but rather uses obsolete > 7-bit ASCII or (slightly less obsolete) EBCDIC strings to > carry the data. TCP/IP transmits data neutral octets, > so binary values can be carried in their native binary > string format (allowing for a possible requirement to pad > strings to an octet boundary). The most standard way to > present those binary strings on a printer or as an input > value to a program is hexadecimal encoding. > > For those reasons, I agree with Bill that we should delete > base64 from the text and use hexadecimal as he suggests. I must not have been totally clear. I'm not suggesting we remove base64, I'm suggesting we limit its use to the cases where (IMHO) it makes sense. While there will be much fewer cases in the text with the changes I suggest, it will still be in the spec. Some of the cryptographic authentications throw around large binary strings. Quite large (compared to the numbers and strings we often use) binary strings. The fact that if you support these modes of authentication you are supposed to be able to accept four times as much text in login commands reflects the size of these strings. Base64 is a real win for these. Hex can encode 4 bits per byte, while base64 can encode 6. Thus an n byte string will be about 1.33*n bytes in base 64, while it will be 2n bytes in hex. That size difference is why we want base64. The main point I've been trying to make is that binary strings and numbers are different things, and that encoding methods for one aren't really appropriate for the other. Specifics: decimal & hex work great for numbers, and hex and base64 work great for binary strings. That's it. Also, the hex for numbers isn't the same as the hex for binary strings. One is the number in hex, the other is more like hexdump -x without the spaces and without the offsets. Take care, Bill --=_alternative 005CCFEAC2256BC0_= Content-Type: text/html; charset="us-ascii"
Bill,

Your point was clear. I am still loking at the cases where LARGE NUMBERS might be needed and I am sure we don't want them to be strings but numbers.

Julo


Bill Studenmund <wrstuden@wasabisystems.com>

05/21/2002 07:27 PM
Please respond to Bill Studenmund

       
        To:        Robert Snively <rsnively@brocade.com>
        cc:        Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
        Subject:        RE: iSCSI: BASE64 and numerical values

       


On Tue, 21 May 2002, Robert Snively wrote:

> I have been having continuing problems understanding why
> iSCSI is considering any use of base64, and I find myself
> in total agreement with Bill's clear exposition of the
> situation.
>
> Upon reviewing RFC-2045, it is clear that base64 is a method
> for containing handy binary values in a EMAIL structure that does
> not use TCP/IP to transmit data, but rather uses obsolete
> 7-bit ASCII or (slightly less obsolete) EBCDIC strings to
> carry the data.  TCP/IP transmits data neutral octets,
> so binary values can be carried in their native binary
> string format (allowing for a possible requirement to pad
> strings to an octet boundary).  The most standard way to
> present those binary strings on a printer or as an input
> value to a program is hexadecimal encoding.
>
> For those reasons, I agree with Bill that we should delete
> base64 from the text and use hexadecimal as he suggests.

I must not have been totally clear. I'm not suggesting we remove base64,
I'm suggesting we limit its use to the cases where (IMHO) it makes sense.
While there will be much fewer cases in the text with the changes I
suggest, it will still be in the spec.

Some of the cryptographic authentications throw around large binary
strings. Quite large (compared to the numbers and strings we often use)
binary strings. The fact that if you support these modes of authentication
you are supposed to be able to accept four times as much text in login
commands reflects the size of these strings.

Base64 is a real win for these. Hex can encode 4 bits per byte, while
base64 can encode 6. Thus an n byte string will be about 1.33*n bytes in
base 64, while it will be 2n bytes in hex. That size difference is why we
want base64.

The main point I've been trying to make is that binary strings and numbers
are different things, and that encoding methods for one aren't really
appropriate for the other. Specifics: decimal & hex work great for
numbers, and hex and base64 work great for binary strings. That's it.
Also, the hex for numbers isn't the same as the hex for binary strings.
One is the number in hex, the other is more like hexdump -x without the
spaces and without the offsets.

Take care,

Bill

--=_alternative 005CCFEAC2256BC0_=-- From owner-ips@ece.cmu.edu Tue May 21 15:09:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25045 for ; Tue, 21 May 2002 15:09:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LIdsW23583 for ips-outgoing; Tue, 21 May 2002 14:39:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LIdpw23572 for ; Tue, 21 May 2002 14:39:51 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 0209530706; Tue, 21 May 2002 14:39:50 -0400 (EDT) Date: Tue, 21 May 2002 11:37:54 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: , Robert Snively Subject: RE: iSCSI: BASE64 and numerical values In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 21 May 2002, Julian Satran wrote: > Bill, > > Your point was clear. I am still loking at the cases where LARGE NUMBERS > might be needed and I am sure we don't want them to be strings but > numbers. Sounds excelent. One thing I haven't figured out how to do is add implicit binary length to the numbers used for CHAP challenges (and possibly others). It's a little bit of semantics (since we define the length for binary strings), but the ones I came up with felt heavy and cumbersome. Take care, Bill From owner-ips@ece.cmu.edu Tue May 21 15:09:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25044 for ; Tue, 21 May 2002 15:09:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LIhtK23935 for ips-outgoing; Tue, 21 May 2002 14:43:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LIhqw23923 for ; Tue, 21 May 2002 14:43:52 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id LAA05363; Tue, 21 May 2002 11:43:38 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 11:43:38 -0700 Message-ID: From: Robert Snively To: Bill Studenmund , Julian Satran , ips@ece.cmu.edu Subject: RE: iSCSI: BASE64 and numerical values Date: Tue, 21 May 2002 11:43:35 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I guess that my point was that we should be transmitting the binary value, not the encoding of the binary value. Especially if you care about the length, that is the most compact version of transmission. You are never using them in the text-encoded format, so why transmit them in a text-encoded format. The values are ALWAYS used only in the binary format. TCP/IP does not have any requirement for them to ever be expressed in the text-encoded format. If you need to input them, describe them for debug purposes, or print them to a screen, then put them in the format that is most natural for parsing to natural byte and word boundaries, which is hexadecimal, but would be outside the scope of the iSCSI document anyway. Bob > -----Original Message----- > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] > Sent: Tuesday, May 21, 2002 9:28 AM > To: Robert Snively > Cc: Julian Satran; ips@ece.cmu.edu > Subject: RE: iSCSI: BASE64 and numerical values > > > On Tue, 21 May 2002, Robert Snively wrote: > > > I have been having continuing problems understanding why > > iSCSI is considering any use of base64, and I find myself > > in total agreement with Bill's clear exposition of the > > situation. > > > > Upon reviewing RFC-2045, it is clear that base64 is a method > > for containing handy binary values in a EMAIL structure that does > > not use TCP/IP to transmit data, but rather uses obsolete > > 7-bit ASCII or (slightly less obsolete) EBCDIC strings to > > carry the data. TCP/IP transmits data neutral octets, > > so binary values can be carried in their native binary > > string format (allowing for a possible requirement to pad > > strings to an octet boundary). The most standard way to > > present those binary strings on a printer or as an input > > value to a program is hexadecimal encoding. > > > > For those reasons, I agree with Bill that we should delete > > base64 from the text and use hexadecimal as he suggests. > > I must not have been totally clear. I'm not suggesting we > remove base64, > I'm suggesting we limit its use to the cases where (IMHO) it > makes sense. > While there will be much fewer cases in the text with the changes I > suggest, it will still be in the spec. > > Some of the cryptographic authentications throw around large binary > strings. Quite large (compared to the numbers and strings we > often use) > binary strings. The fact that if you support these modes of > authentication > you are supposed to be able to accept four times as much text in login > commands reflects the size of these strings. > > Base64 is a real win for these. Hex can encode 4 bits per byte, while > base64 can encode 6. Thus an n byte string will be about > 1.33*n bytes in > base 64, while it will be 2n bytes in hex. That size > difference is why we > want base64. > > The main point I've been trying to make is that binary > strings and numbers > are different things, and that encoding methods for one aren't really > appropriate for the other. Specifics: decimal & hex work great for > numbers, and hex and base64 work great for binary strings. That's it. > Also, the hex for numbers isn't the same as the hex for > binary strings. > One is the number in hex, the other is more like hexdump -x > without the > spaces and without the offsets. > > Take care, > > Bill > > > From owner-ips@ece.cmu.edu Tue May 21 15:09:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25080 for ; Tue, 21 May 2002 15:09:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LIrwV24868 for ips-outgoing; Tue, 21 May 2002 14:53:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4LIrsw24859 for ; Tue, 21 May 2002 14:53:54 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4LIrmp01976 for ; Tue, 21 May 2002 14:53:48 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4LIrmc01970; Tue, 21 May 2002 14:53:48 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g4LIrlb22549; Tue, 21 May 2002 14:53:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15594.38850.500000.911226@gargle.gargle.HOWL> Date: Tue, 21 May 2002 14:53:54 -0400 From: Paul Koning To: ips@ece.cmu.edu, luben@splentec.com Cc: Julian_Satran@il.ibm.com Subject: Re: MaxRecvPDULength question References: <3CEA88E1.4835E5C0@splentec.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 21 May 2002) by Luben Tuikov: > The key name ``MaxRecvPDULength'' doesn't imply > ? Why is it considered as > such then? > > I suggest that ``MaxRecvPDULength'' be set to mean > the maximum PDU length, NOT the maximum _data_ length. > > Reason: It is _faster_ to get the PDU off the the TCP > data stack in _one_ (system) call, rather than two (system) calls. > This _would_ improve implementaions, more so for user-space such. > > But lets still keep the size of the PDU a power of 2. > (This would imply that the non-existent MaxRecvDataLength > to MaxRecvPDULength - 48.) > > Comments? I can't quite figure out what you're after, but it doesn't sound good. There are two parameters of interest: the size of the entire iSCSI PDU, and the size of the data portion of the PDU. It doesn't matter a whole lot which of the two you specify, because the difference is simply the iSCSI header size. I find it useful to think in terms of the data length, because that relates to alignment of data going into the storage machinery, etc. Are you proposing to rename the key so its name is "MaxRecvDataLength"? Yes, that would be more accurate, but why bother at this point? The overall PDU size current is NOT a power of two given the current defaults, and should not be, because that would make the data length a weird value. As for your comment about 1 vs. 2 system calls, I don't understand what system calls you're talking about. The performance argument is not meaningful because it may only be done once per system boot, or at the very worst once per login. From owner-ips@ece.cmu.edu Tue May 21 15:13:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25278 for ; Tue, 21 May 2002 15:13:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LIZJV23179 for ips-outgoing; Tue, 21 May 2002 14:35:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LIZGw23172 for ; Tue, 21 May 2002 14:35:16 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4LIZ5Nf031708; Tue, 21 May 2002 20:35:05 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4LIZ4s66992; Tue, 21 May 2002 20:35:04 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu, rsnively@Brocade.COM, wrstuden@wasabisystems.com MIME-Version: 1.0 Subject: RE: iSCSI: BASE64 and numerical values X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 21 May 2002 21:35:00 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 21/05/2002 21:35:05, Serialize complete at 21/05/2002 21:35:05 Content-Type: multipart/alternative; boundary="=_alternative 0065E4D5C2256BC0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0065E4D5C2256BC0_= Content-Type: text/plain; charset="us-ascii" Not always. Sometimes they are very large prime numbers. Julo pat_thaler@agilent.com 05/21/2002 07:46 PM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, rsnively@Brocade.COM cc: ips@ece.cmu.edu, wrstuden@wasabisystems.com Subject: RE: iSCSI: BASE64 and numerical values Julian, Don't the large cryptographic strings represent the coefficients of binary polynomials? I think those are binary values rather than numerical ones so it makes sense to restrict the base64 to binary objects as Bill suggests. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, May 21, 2002 9:08 AM To: Robert Snively Cc: ips@ece.cmu.edu; 'Bill Studenmund' Subject: RE: iSCSI: BASE64 and numerical values And ignore completely the needs of some cryptographic protocols for large numerical values? I do not see why 6 bit values are more difficult to handle than 4 or 8 bit ones. Julo Robert Snively 05/21/2002 06:13 PM Please respond to Robert Snively To: "'Bill Studenmund'" , Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: BASE64 and numerical values I have been having continuing problems understanding why iSCSI is considering any use of base64, and I find myself in total agreement with Bill's clear exposition of the situation. Upon reviewing RFC-2045, it is clear that base64 is a method for containing handy binary values in a EMAIL structure that does not use TCP/IP to transmit data, but rather uses obsolete 7-bit ASCII or (slightly less obsolete) EBCDIC strings to carry the data. TCP/IP transmits data neutral octets, so binary values can be carried in their native binary string format (allowing for a possible requirement to pad strings to an octet boundary). The most standard way to present those binary strings on a printer or as an input value to a program is hexadecimal encoding. For those reasons, I agree with Bill that we should delete base64 from the text and use hexadecimal as he suggests. Bob > -----Original Message----- > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] > Sent: Monday, May 20, 2002 2:54 PM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: BASE64 and numerical values > > > On Sat, 18 May 2002, Julian Satran wrote: > > > Yes for regular numerical values it makes sense. We will > have to keep it > > for large numerical values used for cryptography. Julo > > I realize I'm driving a semantic nit, but I don't think we should use > BASE64 for any "numeric" values, only "binary" ones. I > believe we probably > agree on what we want, I'm just worried that if the wording isn't 100% > tight, the decode path can become a real mess (since we're > supposed to be > liberal in what we accept :-). > > I'd like to suggest we drop BASE64 from the text that > mentions numerical > values. I really don't look forward to byteswapping a 256 or 512 bit > number as part of BASE64 decode. :-) > > I'd also like to suggest that for encoding large binary values using > hexadecimal, we state that the hexadecimal representation is > that of the > number in network byte order. i.e. if I have the five octets > 02 45 78 ab > de, the hex constant is 0x024578abde. That makes the decode logic REAL > easy; grab two hex characters & convert to one octet. Repeat > as needed. > Please note that this is not the output you'd get with something like > printf("0x%x", number) on a little-endian machine. > > Thirdly, I'd like to suggest we drop decimal support from > binary objects. > It too has the cumbersome byte-swapping issue that I started > this thread > about, just in reverse. :-) > > I realize that's a lot for one EMail. :-) > > To try and be proactive about this, I'd like to suggest > revised text for > section 4.1 (of course needs word-wrapping). For the definitions: > > hex-constant: hexadecimal constant encoded as a string start- > ing with "0x" or "0X" followed by 1 or more digits or the > letters a, b, c, d, e, f, A, B, C, D, E and F. Hex-constants > are used to encode numerical values or binary strings. When > used to encode numerical values the excessive use of leading > 0 digits is discouraged. When used to encode binary strings > hexadecimal constants must have an even number of digits, > and have an implicit byte-length that > includes 4 bits for every hexadecimal digit of the constant, > including leading zeroes (i.e., a hex-constant of n hexadeci- > mal digits has a byte-length of n/2). Additionally, when used > to encode binary strings, hexadecimal constants shall be > expressed in network byte order (i.e., the octet stream 02 > 45 78 ab de would be expressed as "0x024578abde"). > > decimal-constant: an unsigned decimal number - the digit 0 or a > string of 1 or more digits starting with a non-zero digit. > This encoding is not used for numerical values equal or > greater than 2**64. > > base64-constant: base64 constant encoded as a string starting > with "0b" or "0B" followed by 1 or more digits or letters or > plus or slash or equal. The encoding is done according to > [RFC2045]. base64-constants are used to encode binary strings. > Base64-constants have an implicit byte-length that includes 6 > bits for every character of the constant excluding trailing > equals (i.e., a base64-constant of n base64 characters > excluding the trailing equals and m trailing equals has a > byte-length of ((the integer part of) ((n+3)*3/4) - m). > > regular-numerical-value : an unsigned integer less than 2**64 > encoded as a decimal-constant, or hex constant. > > large-numerical-value : an unsigned integer larger than or > equal to 2**64 encoded as a hex constant. > > [no change for numerical-value or numerical-range] > > binary-value : a binary string encoded as a hex-con- > stant or base64-constant. The length of the string is either > specified by the key definition or is implicit byte-length of > the encoded string. > > [delete regualar-binary-value and large-binary-value since > the distinction > is gone] > > I don't see it explicitly mentioned anywhere, but I think all > of the CHAP > (and SRP, but not sure) keys are large numericalal values, and the > kerberos and SPKM keys are binary values. > > Also, I think the CHAP keys need the field length features of > hexadecimal > binary strings, but they are numbers, not binary strings. Not > sure how to > word that. > > Take care, > > Bill > > --=_alternative 0065E4D5C2256BC0_= Content-Type: text/html; charset="us-ascii"
Not always. Sometimes they are  very large prime numbers.  Julo


pat_thaler@agilent.com

05/21/2002 07:46 PM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, rsnively@Brocade.COM
        cc:        ips@ece.cmu.edu, wrstuden@wasabisystems.com
        Subject:        RE: iSCSI: BASE64 and numerical values

       


Julian,
 
Don't the large cryptographic strings represent the coefficients of binary polynomials? I think those are binary values rather than numerical ones so it makes sense to restrict the base64 to binary objects as Bill suggests.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, May 21, 2002 9:08 AM
To: Robert Snively
Cc: ips@ece.cmu.edu; 'Bill Studenmund'
Subject: RE: iSCSI: BASE64 and numerical values

And ignore completely the needs of some cryptographic protocols for large numerical values?  
I do not see why 6 bit values are more difficult to handle than 4 or 8 bit ones.

Julo

Robert Snively <rsnively@brocade.com>

05/21/2002 06:13 PM
Please respond to Robert Snively

       
       To:        "'Bill Studenmund'" <wrstuden@wasabisystems.com>, Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu
       Subject:        RE: iSCSI: BASE64 and numerical values

     



I have been having continuing problems understanding why
iSCSI is considering any use of base64, and I find myself
in total agreement with Bill's clear exposition of the
situation.

Upon reviewing RFC-2045, it is clear that base64 is a method
for containing handy binary values in a EMAIL structure that does
not use TCP/IP to transmit data, but rather uses obsolete
7-bit ASCII or (slightly less obsolete) EBCDIC strings to
carry the data.  TCP/IP transmits data neutral octets,
so binary values can be carried in their native binary
string format (allowing for a possible requirement to pad
strings to an octet boundary).  The most standard way to
present those binary strings on a printer or as an input
value to a program is hexadecimal encoding.

For those reasons, I agree with Bill that we should delete
base64 from the text and use hexadecimal as he suggests.

Bob

> -----Original Message-----
> From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
> Sent: Monday, May 20, 2002 2:54 PM
> To: Julian Satran
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: BASE64 and numerical values
>
>
> On Sat, 18 May 2002, Julian Satran wrote:
>
> > Yes for regular numerical values it makes sense. We will
> have to keep it
> > for large numerical values used for cryptography.  Julo
>
> I realize I'm driving a semantic nit, but I don't think we should use
> BASE64 for any "numeric" values, only "binary" ones. I
> believe we probably
> agree on what we want, I'm just worried that if the wording isn't 100%
> tight, the decode path can become a real mess (since we're
> supposed to be
> liberal in what we accept :-).
>
> I'd like to suggest we drop BASE64 from the text that
> mentions numerical
> values. I really don't look forward to byteswapping a 256 or 512 bit
> number as part of BASE64 decode. :-)
>
> I'd also like to suggest that for encoding large binary values using
> hexadecimal, we state that the hexadecimal representation is
> that of the
> number in network byte order. i.e. if I have the five octets
> 02 45 78 ab
> de, the hex constant is 0x024578abde. That makes the decode logic REAL
> easy; grab two hex characters & convert to one octet. Repeat
> as needed.
> Please note that this is not the output you'd get with something like
> printf("0x%x", number) on a little-endian machine.
>
> Thirdly, I'd like to suggest we drop decimal support from
> binary objects.
> It too has the cumbersome byte-swapping issue that I started
> this thread
> about, just in reverse. :-)
>
> I realize that's a lot for one EMail. :-)
>
> To try and be proactive about this, I'd like to suggest
> revised text for
> section 4.1 (of course needs word-wrapping). For the definitions:
>
>      hex-constant: hexadecimal constant encoded as a string start-
>        ing with "0x" or "0X" followed by 1 or more digits or the
>        letters a, b, c, d, e, f, A, B, C, D, E and F. Hex-constants
>        are used to encode numerical values or binary strings. When
>        used to encode numerical values the excessive use of leading
>        0 digits is discouraged. When used to encode binary strings
>        hexadecimal constants must have an even number of digits,
>        and have an implicit byte-length that
>        includes 4 bits for every hexadecimal digit of the constant,
>        including leading zeroes (i.e., a hex-constant of n hexadeci-
>        mal digits has a byte-length of n/2). Additionally, when used
>        to encode binary strings, hexadecimal constants shall be
>        expressed in network byte order (i.e., the octet stream 02
>        45 78 ab de would be expressed as "0x024578abde").
>
>      decimal-constant: an unsigned decimal number - the digit 0 or a
>        string of 1 or more digits starting with a non-zero digit.
>        This encoding is not used for numerical values equal or
>        greater than 2**64.
>
>      base64-constant: base64 constant encoded as a string starting
>        with "0b" or "0B" followed by 1 or more digits or letters or
>        plus or slash or equal. The encoding is done according to
>        [RFC2045]. base64-constants are used to encode binary strings.
>        Base64-constants have an implicit byte-length that includes 6
>        bits for every character of the constant excluding trailing
>        equals (i.e., a base64-constant of n base64 characters
>        excluding the trailing equals and m trailing equals has a
>        byte-length of ((the integer part of) ((n+3)*3/4) - m).
>
>        regular-numerical-value :  an unsigned integer less than 2**64
>          encoded as a decimal-constant, or hex constant.
>
>        large-numerical-value :  an unsigned integer larger than or
>          equal to 2**64 encoded as a hex constant.
>
> [no change for numerical-value or numerical-range]
>
>        binary-value :  a binary string encoded as a hex-con-
>          stant or base64-constant.  The length of the string is either
>          specified by the key definition or is implicit byte-length of
>          the encoded string.
>
> [delete regualar-binary-value and large-binary-value since
> the distinction
> is gone]
>
> I don't see it explicitly mentioned anywhere, but I think all
> of the CHAP
> (and SRP, but not sure) keys are large numericalal values, and the
> kerberos and SPKM keys are binary values.
>
> Also, I think the CHAP keys need the field length features of
> hexadecimal
> binary strings, but they are numbers, not binary strings. Not
> sure how to
> word that.
>
> Take care,
>
> Bill
>
>



--=_alternative 0065E4D5C2256BC0_=-- From owner-ips@ece.cmu.edu Tue May 21 16:21:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28137 for ; Tue, 21 May 2002 16:21:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LJdZY28129 for ips-outgoing; Tue, 21 May 2002 15:39:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LJdWw28121 for ; Tue, 21 May 2002 15:39:32 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id ACEAB30706; Tue, 21 May 2002 15:39:27 -0400 (EDT) Date: Tue, 21 May 2002 12:37:32 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Robert Snively Cc: Julian Satran , Subject: RE: iSCSI: BASE64 and numerical values In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 21 May 2002, Robert Snively wrote: > I guess that my point was that we should be transmitting the > binary value, not the encoding of the binary value. > > Especially if you care about the length, that is the most > compact version of transmission. > > You are never using them in the text-encoded format, so > why transmit them in a text-encoded format. The values are > ALWAYS used only in the binary format. TCP/IP does not > have any requirement for them to ever be expressed in the > text-encoded format. Good question. The reason is that the WG decided that login negotiation should be text based. So everything needs to be sent as human-readable text. Given that, we need some way to translate binary strings to human-readable things in a space-efficient manner. Thus the interest in base64. Take care, Bill From owner-ips@ece.cmu.edu Tue May 21 16:25:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28406 for ; Tue, 21 May 2002 16:25:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LK68400138 for ips-outgoing; Tue, 21 May 2002 16:06:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4LK66w00134 for ; Tue, 21 May 2002 16:06:06 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4LK60p03922 for ; Tue, 21 May 2002 16:06:00 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4LK5xc03910; Tue, 21 May 2002 16:05:59 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g4LK5xf24715; Tue, 21 May 2002 16:05:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15594.43181.618000.991979@gargle.gargle.HOWL> Date: Tue, 21 May 2002 16:06:05 -0400 From: Paul Koning To: wrstuden@wasabisystems.com Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu, rsnively@Brocade.COM Subject: RE: iSCSI: BASE64 and numerical values References: X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 21 May 2002) by Bill Studenmund: > On Tue, 21 May 2002, Julian Satran wrote: > > > Bill, > > > > Your point was clear. I am still loking at the cases where LARGE NUMBERS > > might be needed and I am sure we don't want them to be strings but > > numbers. > > Sounds excelent. > > One thing I haven't figured out how to do is add implicit binary length to > the numbers used for CHAP challenges (and possibly others). It's a little > bit of semantics (since we define the length for binary strings), but the > ones I came up with felt heavy and cumbersome. CHAP challenges are strings, not numbers. paul From owner-ips@ece.cmu.edu Tue May 21 17:07:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00582 for ; Tue, 21 May 2002 17:07:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LKN9F01524 for ips-outgoing; Tue, 21 May 2002 16:23:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LKN7w01515 for ; Tue, 21 May 2002 16:23:07 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 9324F30706; Tue, 21 May 2002 16:23:06 -0400 (EDT) Date: Tue, 21 May 2002 13:21:11 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Paul Koning Cc: , , Subject: RE: iSCSI: BASE64 and numerical values In-Reply-To: <15594.43181.618000.991979@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 21 May 2002, Paul Koning wrote: > CHAP challenges are strings, not numbers. Ahh.. You are correct. I had a brain-freeze about how exactly CHAP worked (how you generated the response). Take care, Bill From owner-ips@ece.cmu.edu Tue May 21 17:07:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00611 for ; Tue, 21 May 2002 17:07:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LKoBL03503 for ips-outgoing; Tue, 21 May 2002 16:50:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LKo7w03487 for ; Tue, 21 May 2002 16:50:07 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id E33E430706; Tue, 21 May 2002 16:50:06 -0400 (EDT) Date: Tue, 21 May 2002 13:48:12 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran , Cc: Subject: RE: iSCSI: BASE64 and numerical values In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 21 May 2002, Julian Satran wrote: > Not always. Sometimes they are very large prime numbers. Julo > > pat_thaler@agilent.com > 05/21/2002 07:46 PM > Please respond to pat_thaler > > > Julian, > > Don't the large cryptographic strings represent the coefficients of binary > polynomials? I think those are binary values rather than numerical ones so > it makes sense to restrict the base64 to binary objects as Bill suggests. Another possability is that while the exchanged data is infact a number, the authentication method has defined an on-the-wire format. In that case, iSCSI is acting as a transport method between the authentication modules, and we can treat the data as binary strings. :-) Take care, Bill From owner-ips@ece.cmu.edu Tue May 21 17:08:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00666 for ; Tue, 21 May 2002 17:08:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LKoCA03508 for ips-outgoing; Tue, 21 May 2002 16:50:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LKBjw00604 for ; Tue, 21 May 2002 16:11:45 -0400 (EDT) Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id DAE754034; Tue, 21 May 2002 15:11:39 -0500 (CDT) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 May 2002 15:11:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: iSCSI: BASE64 and numerical values Date: Tue, 21 May 2002 15:11:38 -0500 Message-ID: <31891B757C09184BBFEC5275F85D5595104E83@cceexc18.americas.cpqcorp.net> Thread-Topic: iSCSI: BASE64 and numerical values Thread-Index: AcIA+CPeh47J449FQc+IxwGhX+EOwgAAmjPg From: "Martin, Nick (Server Storage)" To: "Robert Snively" , "Bill Studenmund" , "Julian Satran" , X-OriginalArrivalTime: 21 May 2002 20:11:39.0612 (UTC) FILETIME=[B791F1C0:01C20103] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g4LKBjw00605 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Robert, My comments are below. > -----Original Message----- > From: Robert Snively [mailto:rsnively@Brocade.COM] > Sent: Tuesday, May 21, 2002 1:44 PM > To: Bill Studenmund; Julian Satran; ips@ece.cmu.edu > Subject: RE: iSCSI: BASE64 and numerical values > > > I guess that my point was that we should be transmitting the > binary value, not the encoding of the binary value. > In the current draft and all those I saw preceding one can not transmit "raw binary" values during login phase. To be transmitted within a Login, Login Response, Text, or Text Response PDU, the value must be formatted as a null terminated string of the form keyword=value. Further the set of characters which may be used is restricted as specified. > Especially if you care about the length, that is the most > compact version of transmission. > Agreed this is the most compact, but not the most universal. As many working in both big endian and little endian worlds can attest, a number conveyed in "binary" is not universally understood. > You are never using them in the text-encoded format, so > why transmit them in a text-encoded format. The values are > ALWAYS used only in the binary format. TCP/IP does not > have any requirement for them to ever be expressed in the > text-encoded format. > We need to encode in some text format. The rules for doing so need to be agreed. The distinction between binary strings and binary numbers must be clear. Strings of any sort will be transmitted lowest addressed byte first. Binary strings would be encoded into text strings lowest addressed byte first. Text encoding of numbers are always transmitted most significant digit (hex, decimal, or base64). A conversion between native binary numeric representation and text implies native endian awareness. When dealing with binary values on the order of say 1024 bits, one must be aware of endian issues to encode, transmit, receive, encode and use the result correctly. Is this value used as a string, or a number? If a string, one will want to encode and transmit low addressed byte first. If binary one will want to encode and transmit the most significant "digit" first (either highest address or lowest address depending on native arithmetic byte order). > If you need to input them, describe them for debug purposes, or > print them to a screen, then put them in the > format that is most natural for parsing to natural byte and > word boundaries, which is hexadecimal, but would be outside the > scope of the iSCSI document anyway. > Decimal is handy for humans, but not indispensable for machine to machine. I agree with others that hexadecimal is the simplest, and least ambiguous encoding. Still one needs to know whether a string or a binary value is being processed unless one is fortunate enough to only be concerned with big-endian (network byte order) hardware. Prior use of Base64 was designed explicitly for binary files which are effectively binary strings. It will encode, transmit, and decode lowest byte address first. If the intent is to use base64 to transmit large binary numbers, it could be done, but why bother when hexadecimal is so straight forward? The big deal with 4 bits, 6 bits, or 8 bits encoding is the loading, masking, shifting, and storing of the next bits from the correct location at the correct time from 8 bits per byte addressable memory systems. If the whole value fits in one arithmetic register at one time, no big deal. However for larger quantities, 4 bits (hexadecimal) and 8 bits (raw binary which is prohibited) are simple, 6 bits (base64) and 3.something bits (decimal) are not. Thanks, Nick > Bob > > > > -----Original Message----- > > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] > > Sent: Tuesday, May 21, 2002 9:28 AM > > To: Robert Snively > > Cc: Julian Satran; ips@ece.cmu.edu > > Subject: RE: iSCSI: BASE64 and numerical values > > > > > > On Tue, 21 May 2002, Robert Snively wrote: > > > > > I have been having continuing problems understanding why > > > iSCSI is considering any use of base64, and I find myself > > > in total agreement with Bill's clear exposition of the > > > situation. > > > > > > Upon reviewing RFC-2045, it is clear that base64 is a method > > > for containing handy binary values in a EMAIL structure that does > > > not use TCP/IP to transmit data, but rather uses obsolete > > > 7-bit ASCII or (slightly less obsolete) EBCDIC strings to > > > carry the data. TCP/IP transmits data neutral octets, > > > so binary values can be carried in their native binary > > > string format (allowing for a possible requirement to pad > > > strings to an octet boundary). The most standard way to > > > present those binary strings on a printer or as an input > > > value to a program is hexadecimal encoding. > > > > > > For those reasons, I agree with Bill that we should delete > > > base64 from the text and use hexadecimal as he suggests. > > > > I must not have been totally clear. I'm not suggesting we > > remove base64, > > I'm suggesting we limit its use to the cases where (IMHO) it > > makes sense. > > While there will be much fewer cases in the text with the changes I > > suggest, it will still be in the spec. > > > > Some of the cryptographic authentications throw around large binary > > strings. Quite large (compared to the numbers and strings we > > often use) > > binary strings. The fact that if you support these modes of > > authentication > > you are supposed to be able to accept four times as much > text in login > > commands reflects the size of these strings. > > > > Base64 is a real win for these. Hex can encode 4 bits per > byte, while > > base64 can encode 6. Thus an n byte string will be about > > 1.33*n bytes in > > base 64, while it will be 2n bytes in hex. That size > > difference is why we > > want base64. > > > > The main point I've been trying to make is that binary > > strings and numbers > > are different things, and that encoding methods for one > aren't really > > appropriate for the other. Specifics: decimal & hex work great for > > numbers, and hex and base64 work great for binary strings. > That's it. > > Also, the hex for numbers isn't the same as the hex for > > binary strings. > > One is the number in hex, the other is more like hexdump -x > > without the > > spaces and without the offsets. > > > > Take care, > > > > Bill > > > > > > > From owner-ips@ece.cmu.edu Tue May 21 17:10:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00722 for ; Tue, 21 May 2002 17:10:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LKvCp03977 for ips-outgoing; Tue, 21 May 2002 16:57:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LKv9w03966 for ; Tue, 21 May 2002 16:57:09 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 2CC4130706; Tue, 21 May 2002 16:57:09 -0400 (EDT) Date: Tue, 21 May 2002 13:55:14 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Paul Koning Cc: , Subject: Re: MaxRecvPDULength question In-Reply-To: <15594.38850.500000.911226@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 21 May 2002, Paul Koning wrote: > Excerpt of message (sent 21 May 2002) by Luben Tuikov: > > The key name ``MaxRecvPDULength'' doesn't imply > > ? Why is it considered as > > such then? > > > > I suggest that ``MaxRecvPDULength'' be set to mean > > the maximum PDU length, NOT the maximum _data_ length. > > > > Reason: It is _faster_ to get the PDU off the the TCP > > data stack in _one_ (system) call, rather than two (system) calls. > > This _would_ improve implementaions, more so for user-space such. Unfortunately I don't think we can do that. The problem is that we still would need to know how much data were sent. Mainly as we don't HAVE to send the maximum amount of data. :-) > > But lets still keep the size of the PDU a power of 2. > > (This would imply that the non-existent MaxRecvDataLength > > to MaxRecvPDULength - 48.) > > > > Comments? > > I can't quite figure out what you're after, but it doesn't sound > good. > > There are two parameters of interest: the size of the entire iSCSI > PDU, and the size of the data portion of the PDU. > > It doesn't matter a whole lot which of the two you specify, because > the difference is simply the iSCSI header size. I find it useful to > think in terms of the data length, because that relates to alignment > of data going into the storage machinery, etc. I agree. > Are you proposing to rename the key so its name is > "MaxRecvDataLength"? Yes, that would be more accurate, but why bother > at this point? > > The overall PDU size current is NOT a power of two given the current > defaults, and should not be, because that would make the data length a > weird value. > > As for your comment about 1 vs. 2 system calls, I don't understand > what system calls you're talking about. The performance argument is > not meaningful because it may only be done once per system boot, or at > the very worst once per login. Luben was wanting to make it so the WHOLE PDU (header and data both) could be read with one system call. Take care, Bill From owner-ips@ece.cmu.edu Tue May 21 17:47:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02226 for ; Tue, 21 May 2002 17:47:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LLY1t06263 for ips-outgoing; Tue, 21 May 2002 17:34:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LLXvw06242 for ; Tue, 21 May 2002 17:33:58 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4LKWYl02633; Tue, 21 May 2002 16:32:34 -0400 Message-ID: <3CEABD3C.64164A42@splentec.com> Date: Tue, 21 May 2002 17:33:48 -0400 From: Luben Tuikov Reply-To: Luben Tuikov , iSCSI Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "THALER,PAT (A-Roseville,ex1)" , iSCSI Subject: Re: MaxRecvPDULength question References: <1BEBA5E8600DD4119A50009027AF54A00C09CB19@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit "THALER,PAT (A-Roseville,ex1)" wrote: > > > BTW your email seemed to imply that MaxRecvPDULength is a power of two. My computer says: 2^13 = 8192, which in turn is equal to the default value of MaxRecvPDULength. > Currently, MaxRecvPDULength is not limited to be a power of two. > (I recall a discussion about that and I think the concensus was > consistant with the current draft.) True, but if it changes after login, I can deal with it. I.e. I'd not allocate more memory if it shrinks, and I'll increase it by PAGE_SIZE if it grows. Anyway, this was just a suggestion, not so important. I was more interested in getting an authoritative answer on the ``Login Request Error'' thread's last message. -- Luben From owner-ips@ece.cmu.edu Tue May 21 17:47:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02251 for ; Tue, 21 May 2002 17:47:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LL93K04706 for ips-outgoing; Tue, 21 May 2002 17:09:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LL91w04701 for ; Tue, 21 May 2002 17:09:01 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id OAA16980; Tue, 21 May 2002 14:08:51 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 14:08:50 -0700 Message-ID: From: Robert Snively To: "'Martin, Nick (Server Storage)'" , Robert Snively , Bill Studenmund , Julian Satran , ips@ece.cmu.edu Subject: RE: iSCSI: BASE64 and numerical values Date: Tue, 21 May 2002 14:08:48 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk Then I think we may have to correct the description in Clause 4.1 to allow the / character. In addition, we probably should specify them as US-ASCII (as RFC 2045 does) instead of UTF-08 Unicode. > In the current draft and all those I saw preceding one can > not transmit "raw binary" values during login phase. To be > transmitted within a Login, Login Response, Text, or Text > Response PDU, the value must be formatted as a null > terminated string of the form keyword=value. Further the set > of characters which may be used is restricted as specified. From owner-ips@ece.cmu.edu Tue May 21 17:48:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02266 for ; Tue, 21 May 2002 17:48:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LLed206701 for ips-outgoing; Tue, 21 May 2002 17:40:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4LLebw06697 for ; Tue, 21 May 2002 17:40:37 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4LLeWp05818 for ; Tue, 21 May 2002 17:40:32 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4LLeWc05812; Tue, 21 May 2002 17:40:32 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g4LLeVj27980; Tue, 21 May 2002 17:40:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15594.48854.75000.834783@gargle.gargle.HOWL> Date: Tue, 21 May 2002 17:40:38 -0400 From: Paul Koning To: ips@ece.cmu.edu, luben@splentec.com Subject: Re: MaxRecvPDULength question References: <3CEA88E1.4835E5C0@splentec.com> <15594.38850.500000.911226@gargle.gargle.HOWL> <3CEABB14.1B3F0AA7@splentec.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 21 May 2002) by Luben Tuikov: > Paul Koning wrote: > > > > I can't quite figure out what you're after, but it doesn't sound > > good. > > :-) > > I'd like to use the slab cache allocator (lookaside cache, kernel space) > to allocate memory for max PDU, rather than calling *alloc(). > This is fast, and reliable, etc, etc compared to *alloc(). > > I'd also like a max PDU to fit nicely into memory, i.e. at > page size boundaries, being a multiple of PAGE_SIZE. > This would also improve performance. > > Currently, you'd have 2 buffers, one for PDU (48 bytes) > and another for data (MaxRecvPDULength), and > you'd get both data with time separated system/kernel > function calls -- one for 48 bytes and another > for the rest of the data. I suppose it's possible to construct an implementation like that, but why would you do that? (By the way, I assume you meant "PDU header (48 bytes)".) You know the max payload size; you know the max header size; given those you know the max PDU size. You can then allocate PDU buffers that big, and you can select the receive offset so the payload starts at a convenient boundary -- given that you know most headers will be 48 bytes long. There's nothing in the current spec that forces you to receive a PDU in two pieces. paul From owner-ips@ece.cmu.edu Tue May 21 17:48:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02303 for ; Tue, 21 May 2002 17:48:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LL9TQ04746 for ips-outgoing; Tue, 21 May 2002 17:09:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LL9Rw04739 for ; Tue, 21 May 2002 17:09:27 -0400 (EDT) Received: from chamao (chamao [147.11.45.39]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id OAA22406; Tue, 21 May 2002 14:08:01 -0700 (PDT) From: "Michael Krueger" To: "Bill Studenmund" , "Julian Satran" Cc: , "Robert Snively" Subject: RE: iSCSI: BASE64 and numerical values Date: Tue, 21 May 2002 14:09:06 -0700 Message-ID: <002401c2010b$be4e0f50$272d0b93@chamao.wrs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > One thing I haven't figured out how to do is add implicit binary length to > the numbers used for CHAP challenges (and possibly others). It's a little > bit of semantics (since we define the length for binary strings), but the > ones I came up with felt heavy and cumbersome. I think we've been making this more complicated than necessary. Here's what I think is a relatively simple way to define the implicit lengths of binary items that have been represented by hexadecimal or base-64 ASCII strings. BASE-64 REPRESENTATION OF A BINARY ITEM RFC 2045 states that "all base64 input is an integral number of octets"; therefore, base-64 representation is simply not appropriate for binary items whose length is not a multiple of eight bits. The RFC specifies a padding mechanism from which the length of the original input may be determined exactly (here, 'x' is an arbitrary base64 digit and '=' is the padding digit specified in the RFC): string input input padding non-padding representation bytes bits digits digits -------------- ----- ----- ------- ----------- 0bxxxx 3 24 0 4 0bxxxxxx== 4 32 2 6 0bxxxxxxx= 5 40 1 7 0bxxxxxxxx 6 48 0 8 I would suggest that iSCSI define the implicit length of a binary item represented by a base-64 string representation as the number of "input bits" in the table above. More precisely, if N is the number of non-padding (i.e., non-'=') digits in the string representation, the binary item's length in bytes, L, is given by L = (N * 6) / 8, where '/' represents an integer division. HEXADECIMAL REPRESENTATION OF A BINARY ITEM Suppose that, in analogy with RFC 2045, we limit the number of "input bits" to a multiple of eight bits. Let N be the number of digits in the string representation, where N must even. The binary item's (implicit) length in bytes, L, is then given by L = N / 2. I am not aware of any application in which the length of a binary item is not a multiple of eight bits. (It's certainly not the case for CHAP.) The only other multiple we could support without an explicit length field would be multiples of 4 bits; however, this would only work with hex encoding, not base64. I therefore believe it makes sense to limit IMPLICIT binary item lengths to multiples of eight bits. If someone ever introduced a binary item whose length were not a multiple of eight bits, it could simply be accompanied by second key that functions as an explicit length field. Michael -- Michael J. Krueger mailto:michael.krueger@windriver.com Wind River Networks http://www.windriver.com 500 Wind River Way phone: 510-749-2130 Alameda, CA 94501 fax: 510-749-2010 From owner-ips@ece.cmu.edu Tue May 21 17:50:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02370 for ; Tue, 21 May 2002 17:50:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LLM4B05537 for ips-outgoing; Tue, 21 May 2002 17:22:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LLM1w05531 for ; Tue, 21 May 2002 17:22:01 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 8E7C330706; Tue, 21 May 2002 17:22:00 -0400 (EDT) Date: Tue, 21 May 2002 14:20:05 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Michael Krueger Cc: Julian Satran , , Robert Snively Subject: RE: iSCSI: BASE64 and numerical values In-Reply-To: <002401c2010b$be4e0f50$272d0b93@chamao.wrs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 21 May 2002, Michael Krueger wrote: > > One thing I haven't figured out how to do is add implicit binary length to > > the numbers used for CHAP challenges (and possibly others). It's a little > > bit of semantics (since we define the length for binary strings), but the > > ones I came up with felt heavy and cumbersome. Please note I was mistaken about CHAP. It uses strings, so numbers don't need lengths AFAIK. > I think we've been making this more complicated than necessary. Here's what Probably. :-) > I think is a relatively simple way to define the implicit lengths of binary > items that have been represented by hexadecimal or base-64 ASCII strings. > > BASE-64 REPRESENTATION OF A BINARY ITEM [snip] > HEXADECIMAL REPRESENTATION OF A BINARY ITEM > > Suppose that, in analogy with RFC 2045, we limit the number of "input bits" > to a multiple of eight bits. Let N be the number of digits in the string Sounds good. Also, if we don't, when decoding hex strings, you have to get to the end of the string to figure out if you have an odd or even # of nibbles. Really messy. > representation, where N must even. The binary item's (implicit) length in > bytes, L, is then given by L = N / 2. > > I am not aware of any application in which the length of a binary item is > not a multiple of eight bits. (It's certainly not the case for CHAP.) The > only other multiple we could support without an explicit length field would > be multiples of 4 bits; however, this would only work with hex encoding, not > base64. I therefore believe it makes sense to limit IMPLICIT binary item > lengths to multiples of eight bits. If someone ever introduced a binary > item whose length were not a multiple of eight bits, it could simply be > accompanied by second key that functions as an explicit length field. Sounds good. Take care, Bill From owner-ips@ece.cmu.edu Tue May 21 17:50:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02371 for ; Tue, 21 May 2002 17:50:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LLKtF05451 for ips-outgoing; Tue, 21 May 2002 17:20:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LLKqw05444 for ; Tue, 21 May 2002 17:20:52 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 33A0DC836; Tue, 21 May 2002 15:20:51 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id C28EC1CF; Tue, 21 May 2002 15:20:49 -0600 (MDT) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 15:20:46 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09CB19@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Paul Koning , ips@ece.cmu.edu, luben@splentec.com Cc: Julian_Satran@il.ibm.com Subject: RE: MaxRecvPDULength question Date: Tue, 21 May 2002 15:20:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, I agree with Paul that the suggestion doesn't sound good. I don't understand your perspective since in my view we are generally moving around the data rather than the whole PDU and it is very useful to specify the maximum length for the data field of the PDU. Further, there may be headers beyond the BHS and it would complicate implementation to have to know what headers are being sent in order to derive the limit on the data segment length for a PDU. The key name MaxRecvPDULength is a bit misleading as it seems to imply the whole PDU and Paul's suggestion of MaxRecvDataLength isn't much better as it doesn't differentiate between the data length of a PDU or a burst. Going into picky mode, it also isn't clear why this is a length while bursts have a size. MaxRecvDataSegmentSize or MaxRecvDataSegSize would be more precise, but I'm not sure it is worth tweaking the name at this point. BTW your email seemed to imply that MaxRecvPDULength is a power of two. Currently, MaxRecvPDULength is not limited to be a power of two. (I recall a discussion about that and I think the concensus was consistant with the current draft.) Pat -----Original Message----- From: Paul Koning [mailto:ni1d@arrl.net] Sent: Tuesday, May 21, 2002 11:54 AM To: ips@ece.cmu.edu; luben@splentec.com Cc: Julian_Satran@il.ibm.com Subject: Re: MaxRecvPDULength question Excerpt of message (sent 21 May 2002) by Luben Tuikov: > The key name ``MaxRecvPDULength'' doesn't imply > ? Why is it considered as > such then? > > I suggest that ``MaxRecvPDULength'' be set to mean > the maximum PDU length, NOT the maximum _data_ length. > > Reason: It is _faster_ to get the PDU off the the TCP > data stack in _one_ (system) call, rather than two (system) calls. > This _would_ improve implementaions, more so for user-space such. > > But lets still keep the size of the PDU a power of 2. > (This would imply that the non-existent MaxRecvDataLength > to MaxRecvPDULength - 48.) > > Comments? I can't quite figure out what you're after, but it doesn't sound good. There are two parameters of interest: the size of the entire iSCSI PDU, and the size of the data portion of the PDU. It doesn't matter a whole lot which of the two you specify, because the difference is simply the iSCSI header size. I find it useful to think in terms of the data length, because that relates to alignment of data going into the storage machinery, etc. Are you proposing to rename the key so its name is "MaxRecvDataLength"? Yes, that would be more accurate, but why bother at this point? The overall PDU size current is NOT a power of two given the current defaults, and should not be, because that would make the data length a weird value. As for your comment about 1 vs. 2 system calls, I don't understand what system calls you're talking about. The performance argument is not meaningful because it may only be done once per system boot, or at the very worst once per login. From owner-ips@ece.cmu.edu Tue May 21 17:50:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02402 for ; Tue, 21 May 2002 17:50:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LLOkd05710 for ips-outgoing; Tue, 21 May 2002 17:24:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LLOhw05700 for ; Tue, 21 May 2002 17:24:43 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4LKNMl02576; Tue, 21 May 2002 16:23:22 -0400 Message-ID: <3CEABB14.1B3F0AA7@splentec.com> Date: Tue, 21 May 2002 17:24:36 -0400 From: Luben Tuikov Reply-To: iSCSI , Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: ips@ece.cmu.edu Subject: Re: MaxRecvPDULength question References: <3CEA88E1.4835E5C0@splentec.com> <15594.38850.500000.911226@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Paul Koning wrote: > > I can't quite figure out what you're after, but it doesn't sound > good. :-) I'd like to use the slab cache allocator (lookaside cache, kernel space) to allocate memory for max PDU, rather than calling *alloc(). This is fast, and reliable, etc, etc compared to *alloc(). I'd also like a max PDU to fit nicely into memory, i.e. at page size boundaries, being a multiple of PAGE_SIZE. This would also improve performance. Currently, you'd have 2 buffers, one for PDU (48 bytes) and another for data (MaxRecvPDULength), and you'd get both data with time separated system/kernel function calls -- one for 48 bytes and another for the rest of the data. Consider that this is a packet based proto on top of stream based one, on top of ... Anyway, when we get data we get the whole thing at once and there is NO point in making 2 calls to get the whole thing. If an implementation is in user-space, then forget it performance wise. Mine is in kernel space and I'd like to make it _faster_. > It doesn't matter a whole lot which of the two you specify, because > the difference is simply the iSCSI header size. I find it useful to > think in terms of the data length, because that relates to alignment > of data going into the storage machinery, etc. But, if the data spills, then it has to be assembled anyway before being passed down/up the device driver/ULP, so this will not be of much significance. If it doesn't spill, then we're ok, just pass it to whoever is interested. > Are you proposing to rename the key so its name is > "MaxRecvDataLength"? Yes, that would be more accurate, but why bother > at this point? No, not proposing this. I'm proposing, that ``MaxRecvPDULength'' mean just that! -- Luben From owner-ips@ece.cmu.edu Tue May 21 17:51:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02496 for ; Tue, 21 May 2002 17:51:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LLcUA06557 for ips-outgoing; Tue, 21 May 2002 17:38:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LLcSw06553 for ; Tue, 21 May 2002 17:38:28 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 7D136C882; Tue, 21 May 2002 15:38:27 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 28B5F136; Tue, 21 May 2002 15:38:27 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 21 May 2002 15:38:26 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 15:38:26 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09CB23@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: luben@splentec.com, ips@ece.cmu.edu Subject: RE: MaxRecvPDULength question Date: Tue, 21 May 2002 15:38:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I'm working on that but being authoritative on that subject turns out to require a fair amount of work combing the draft and has been impacted by some other tasks. I expect to put out something by the end of the day. Pat -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Tuesday, May 21, 2002 2:34 PM To: THALER,PAT (A-Roseville,ex1); iSCSI Subject: Re: MaxRecvPDULength question "THALER,PAT (A-Roseville,ex1)" wrote: > > > BTW your email seemed to imply that MaxRecvPDULength is a power of two. My computer says: 2^13 = 8192, which in turn is equal to the default value of MaxRecvPDULength. > Currently, MaxRecvPDULength is not limited to be a power of two. > (I recall a discussion about that and I think the concensus was > consistant with the current draft.) True, but if it changes after login, I can deal with it. I.e. I'd not allocate more memory if it shrinks, and I'll increase it by PAGE_SIZE if it grows. Anyway, this was just a suggestion, not so important. I was more interested in getting an authoritative answer on the ``Login Request Error'' thread's last message. -- Luben From owner-ips@ece.cmu.edu Tue May 21 20:35:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07593 for ; Tue, 21 May 2002 20:35:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4LNeaG13037 for ips-outgoing; Tue, 21 May 2002 19:40:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4LNeYw13028 for ; Tue, 21 May 2002 19:40:34 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 4B9F6C39D; Tue, 21 May 2002 17:40:33 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id AC9CB1CF; Tue, 21 May 2002 17:40:32 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 21 May 2002 17:40:32 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 17:40:31 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09CB64@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: iSCSI , Luben Tuikov , Parthi Cc: Bill Studenmund , Mike Donohoe , Julian Satran Subject: RE: iSCSI: Login Request error Date: Tue, 21 May 2002 17:40:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, The text you quoted from page 69 (which I agree has a consistency problem as you noted) is not relevant to negotiation of ImmediateData which is a binary key. That text is specifically for list negotiation. The relevant text for this negotiation is in 4.2.2 Simple-value negotiations. Many people in responding to this string are equating responder to target but one needs to remember that the responder may be the target or the initiator. The reaction to an error condition varies depending on whether an initiator or a target has received the error. The text you quote for Initiator Error is not the same as the text on page 173 of 12-90 which says in part "indicates that the initiator most likely caused the error. This MAY be due to a request for a resource for which the initiation does not have permission." It may also be due to other problems. For instance the last paragraph of 4.3 for the case where the target has detected an attempt to negotiate a parameter more than once: "If detected by the target this MUST result in a Login reject (initiator error)." This is not a resource error. With my picky filter engaged, the sentence also has a couple of problems. It refers to "Login reject". Page 74 lists "Login Reject" as a possible response to Login. Both make it sound like Login Reject is a defined response. However, I can't find any definition of "Login Reject" in the draft. 9.13 does not use the term in describing the Login response PDU. I believe that a login response PDU with any non-zero status class is a Login Rejec! t but 9.13 should make that explicit. Secondly, it isn't clear whether "(initiator error)" is the status or the status detail or both. I think both the status and the status detail for this error should be initiator error. Initiator Error specifically says "(not a format error)" presumably because 6.4 Format Errors says that the response to a format error is to close all transport connections in the session immediately. It defines a format errors as "explicit violations of PDU layout rules." I don't think that an error in a key value fits this definition. It is not clear to me how one determines whether an error is a format error. And it seems like this reaction (especially during login when one may not even have completed authentication) allows a powerful denial of service attack. - Probably a subject for another string. Also note that status detail Initiator Error 0200 Miscellaneous iSCSI initiator errors is not the same as status 2 Initiator Error. Presumably all status detail Initiator Errors imply that the status will be Initiator Error but the reverse is not true. It is confusing to have both a status detail and a status with the same name as the name is then only clear when one knows which field it is. A slight modification to the status detail name would be wise. Other Initiator Error would work. Going back to 4.2.2: I beleive that "ImmediateData=Ye" is an inadmissible value. I think the text "An offer of a value not admissible (e.g., not within the specified bounds) MAY be answered with the constant "Reject" or the responder MAY select an admissible value. The selection, by the responder, of a value not admissible under the selection rules is considered a negotiation failure and is handled accordingly. The selection rules are key-specific." is intended to apply to all simple value negotiation though from its position in the paragraph it might appear to only apply to numeric range negotiation. This could be clarified by starting a new paragraph or by moving the sentence on numeric range negotiation to the end of the paragraph. So if an orginator offers "ImmediateData=Ye" the responder may reply with "ImmediateData=Reject" or with "ImmediateData=Yes" or "ImmediateData=No" (since either is an admissible value). What isn't explicitly stated is what happens after the responder responds with "ImmediateData=Reject". If the orignator tries sending an key value pair for ImmediateData again does it count as negotiating a parameter more than once or is it acceptable. An argument for continuing the negotiation by resending the key is that the responder knows that the negotiation hasn't completed? On the other hand, if the orignator offered a non-boolean value for a boolean key, then it is probably broken. Is there any point in continuing the negotiation? It might be an endless loop. I think it makes sense to terminate the login and that is consistant with what the originator is required to do if the responder sends an inadmissible value. If we look at the alternate case where the responder chooses an admissible value rather than sending a Reject, it might also result in termination of the connection. The originator thinks it sent an admissible value. The value the responder chose might not be admissible under the selection rules. For instance, if the originator thought it had sent ImmediateData=No the responder received an inadmissible value and decided to reply ImmediateData=Yes, that would be an inadmissible response under the AND selection rule that applies to ImmediateData and the originator would terminate the login. Therefore, receiving an inadmissible value for a key value pair should terminate the login. This simplifies negotiation. An attempt to do something else just complicates the login processing and has a large chance of ending up with login termination anyway. If it doesn't end up with login termination, then it may result in a loop of bad offers and rejections. Regards, Pat -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Tuesday, May 21, 2002 6:47 AM To: Parthi Cc: Bill Studenmund; Mike Donohoe; 'ips@ece.cmu.edu'; Julian Satran Subject: Re: iSCSI: Login Request error Parthi wrote: > > > > Responder should say "Reject" in Text param negotiation. > > > > > > ex. Originator-> ImmediateData=Ye > > > Responder -> ImmediateData=Reject > > > > > > The status value would be 020b "Invalid during login". > > > > Would 020b be the correct error for that? I would have thought 0200 > > "Miscellaneous iSCSI initiator errors" would have been better; I thought > > 020b was exclusively for an attempt to do something that should only be > > done in FFP, before you've gotten to FFP. > > > > Take care, > > > > Bill > > Hi : > > Draft says "Initiator Error(not a format error) -- This indicates request for a resource for > which the initiator > does not have permission. The request should not be tried again". The status value should be 0 (Success). Note that since we are talking about status codes, we imply that the _Target_ replies. That is, the Target should reply with (as already noted) ImmediateData=Reject and status of 0. This would tell the Initiator that login is proceeding ok, but ImmediateData needs renegotiation/reconsideration. Note that the Target may reply with other keys' responses, along with the rejected ones. Then the initiator will reconsider all rejected keys. Note that a status code of anything but 0, implies closing the connection. Please see this message: http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09771.html My reply is a bit messy, in that I should've been clearer, that the originator of the key being rejected by the responder, SHOULD, if available, offer another set of values, or close the connection. Currently, the draft says (pg 69, 12-90): If a responder does support, understand or is allowed to use none of the offered options with a specific originator, it MAY use the constant "Reject" or it MAY respond with an admissible value. The selection of a value not offered is considered a negotiation failure and is handled as a protocol error. Which is inconsistent with itself. (I.e. self-contradictory to negotiation.) Proof: By the first clause: Assume that the responder cannot use any of the offered options to a key (keyword ``none'' in the first sentence). Then the responder 1) MAY Reject, 2) MAY offer an admissible value. Take 2) and proceed. Then the originator receives an (admissible) value which was NOT in what it offered and closes the connection by the second clause. Clearly, this is a negotiation failure. If, on the other hand, we had chosen 1), i.e. send Reject, the originator, may reconsider it's options and send a different set of values, and should one of them be acceptable to the responder, we arrive at negotiation success. QED. This has already been communicated to Julian. Julian? Nevertheless, a Reject response is required by the responder to ``close the loop''. If the originator doesn't close the connection after that, the responder MAY choose to send it's own values for the same (Rejected) key. I.e. the responder to the Reject will now become the originator of the Reject-ed variable. -- Luben From owner-ips@ece.cmu.edu Tue May 21 20:35:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07623 for ; Tue, 21 May 2002 20:35:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4M0HXQ14950 for ips-outgoing; Tue, 21 May 2002 20:17:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4M0HVw14942 for ; Tue, 21 May 2002 20:17:31 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 19:56:14 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937906@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Cc: Black_David@emc.com Subject: Test Date: Tue, 21 May 2002 19:54:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Please ignore. From owner-ips@ece.cmu.edu Tue May 21 20:38:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07718 for ; Tue, 21 May 2002 20:38:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4M05Sb14278 for ips-outgoing; Tue, 21 May 2002 20:05:28 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4M05Qw14274 for ; Tue, 21 May 2002 20:05:26 -0400 (EDT) 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 g4M05IM8034876; Wed, 22 May 2002 02:05:18 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4M05Hs55636; Wed, 22 May 2002 02:05:17 +0200 To: "Martin, Nick (Server Storage)" Cc: ips@ece.cmu.edu, "Robert Snively" , "Bill Studenmund" MIME-Version: 1.0 Subject: RE: iSCSI: BASE64 and numerical values X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 22 May 2002 03:05:14 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 22/05/2002 03:05:18, Serialize complete at 22/05/2002 03:05:18 Content-Type: multipart/alternative; boundary="=_alternative 0083957BC2256BC0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0083957BC2256BC0_= Content-Type: text/plain; charset="us-ascii" Nick, I said already that I will say something about order in numbers - and that holds for hex or b64 and that will be the "normal" high-endian encoding. Why do you consider hex and b64 to be different? Julo "Martin, Nick (Server Storage)" 05/21/2002 11:11 PM Please respond to "Martin, Nick (Server Storage)" To: "Robert Snively" , "Bill Studenmund" , Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: iSCSI: BASE64 and numerical values Robert, My comments are below. > -----Original Message----- > From: Robert Snively [mailto:rsnively@Brocade.COM] > Sent: Tuesday, May 21, 2002 1:44 PM > To: Bill Studenmund; Julian Satran; ips@ece.cmu.edu > Subject: RE: iSCSI: BASE64 and numerical values > > > I guess that my point was that we should be transmitting the > binary value, not the encoding of the binary value. > In the current draft and all those I saw preceding one can not transmit "raw binary" values during login phase. To be transmitted within a Login, Login Response, Text, or Text Response PDU, the value must be formatted as a null terminated string of the form keyword=value. Further the set of characters which may be used is restricted as specified. > Especially if you care about the length, that is the most > compact version of transmission. > Agreed this is the most compact, but not the most universal. As many working in both big endian and little endian worlds can attest, a number conveyed in "binary" is not universally understood. > You are never using them in the text-encoded format, so > why transmit them in a text-encoded format. The values are > ALWAYS used only in the binary format. TCP/IP does not > have any requirement for them to ever be expressed in the > text-encoded format. > We need to encode in some text format. The rules for doing so need to be agreed. The distinction between binary strings and binary numbers must be clear. Strings of any sort will be transmitted lowest addressed byte first. Binary strings would be encoded into text strings lowest addressed byte first. Text encoding of numbers are always transmitted most significant digit (hex, decimal, or base64). A conversion between native binary numeric representation and text implies native endian awareness. When dealing with binary values on the order of say 1024 bits, one must be aware of endian issues to encode, transmit, receive, encode and use the result correctly. Is this value used as a string, or a number? If a string, one will want to encode and transmit low addressed byte first. If binary one will want to encode and transmit the most significant "digit" first (either highest address or lowest address depending on native arithmetic byte order). > If you need to input them, describe them for debug purposes, or > print them to a screen, then put them in the > format that is most natural for parsing to natural byte and > word boundaries, which is hexadecimal, but would be outside the > scope of the iSCSI document anyway. > Decimal is handy for humans, but not indispensable for machine to machine. I agree with others that hexadecimal is the simplest, and least ambiguous encoding. Still one needs to know whether a string or a binary value is being processed unless one is fortunate enough to only be concerned with big-endian (network byte order) hardware. Prior use of Base64 was designed explicitly for binary files which are effectively binary strings. It will encode, transmit, and decode lowest byte address first. If the intent is to use base64 to transmit large binary numbers, it could be done, but why bother when hexadecimal is so straight forward? The big deal with 4 bits, 6 bits, or 8 bits encoding is the loading, masking, shifting, and storing of the next bits from the correct location at the correct time from 8 bits per byte addressable memory systems. If the whole value fits in one arithmetic register at one time, no big deal. However for larger quantities, 4 bits (hexadecimal) and 8 bits (raw binary which is prohibited) are simple, 6 bits (base64) and 3.something bits (decimal) are not. Thanks, Nick > Bob > > > > -----Original Message----- > > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] > > Sent: Tuesday, May 21, 2002 9:28 AM > > To: Robert Snively > > Cc: Julian Satran; ips@ece.cmu.edu > > Subject: RE: iSCSI: BASE64 and numerical values > > > > > > On Tue, 21 May 2002, Robert Snively wrote: > > > > > I have been having continuing problems understanding why > > > iSCSI is considering any use of base64, and I find myself > > > in total agreement with Bill's clear exposition of the > > > situation. > > > > > > Upon reviewing RFC-2045, it is clear that base64 is a method > > > for containing handy binary values in a EMAIL structure that does > > > not use TCP/IP to transmit data, but rather uses obsolete > > > 7-bit ASCII or (slightly less obsolete) EBCDIC strings to > > > carry the data. TCP/IP transmits data neutral octets, > > > so binary values can be carried in their native binary > > > string format (allowing for a possible requirement to pad > > > strings to an octet boundary). The most standard way to > > > present those binary strings on a printer or as an input > > > value to a program is hexadecimal encoding. > > > > > > For those reasons, I agree with Bill that we should delete > > > base64 from the text and use hexadecimal as he suggests. > > > > I must not have been totally clear. I'm not suggesting we > > remove base64, > > I'm suggesting we limit its use to the cases where (IMHO) it > > makes sense. > > While there will be much fewer cases in the text with the changes I > > suggest, it will still be in the spec. > > > > Some of the cryptographic authentications throw around large binary > > strings. Quite large (compared to the numbers and strings we > > often use) > > binary strings. The fact that if you support these modes of > > authentication > > you are supposed to be able to accept four times as much > text in login > > commands reflects the size of these strings. > > > > Base64 is a real win for these. Hex can encode 4 bits per > byte, while > > base64 can encode 6. Thus an n byte string will be about > > 1.33*n bytes in > > base 64, while it will be 2n bytes in hex. That size > > difference is why we > > want base64. > > > > The main point I've been trying to make is that binary > > strings and numbers > > are different things, and that encoding methods for one > aren't really > > appropriate for the other. Specifics: decimal & hex work great for > > numbers, and hex and base64 work great for binary strings. > That's it. > > Also, the hex for numbers isn't the same as the hex for > > binary strings. > > One is the number in hex, the other is more like hexdump -x > > without the > > spaces and without the offsets. > > > > Take care, > > > > Bill > > > > > > > --=_alternative 0083957BC2256BC0_= Content-Type: text/html; charset="us-ascii"
Nick,

I said already that I will say something about order in numbers - and that holds for hex or b64
and that will be the "normal"  high-endian encoding.
Why do you consider hex and b64 to be  different?

Julo


"Martin, Nick (Server Storage)" <Nick.Martin@hp.com>

05/21/2002 11:11 PM
Please respond to "Martin, Nick (Server Storage)"

       
        To:        "Robert Snively" <rsnively@Brocade.COM>, "Bill Studenmund" <wrstuden@wasabisystems.com>, Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
        cc:        
        Subject:        RE: iSCSI: BASE64 and numerical values

       


Robert,

My comments are below.

> -----Original Message-----
> From: Robert Snively [mailto:rsnively@Brocade.COM]
> Sent: Tuesday, May 21, 2002 1:44 PM
> To: Bill Studenmund; Julian Satran; ips@ece.cmu.edu
> Subject: RE: iSCSI: BASE64 and numerical values
>
>
> I guess that my point was that we should be transmitting the
> binary value, not the encoding of the binary value.
>
In the current draft and all those I saw preceding one can not transmit "raw binary" values during login phase.  To be transmitted within a Login, Login Response, Text, or Text Response PDU, the value must be formatted as a null terminated string of the form keyword=value.  Further the set of characters which may be used is restricted as specified.

> Especially if you care about the length, that is the most
> compact version of transmission.
>
Agreed this is the most compact, but not the most universal.  As many working in both big endian and little endian worlds can attest, a number conveyed in "binary" is not universally understood.

> You are never using them in the text-encoded format, so
> why transmit them in a text-encoded format.  The values are
> ALWAYS used only in the binary format.  TCP/IP does not
> have any requirement for them to ever be expressed in the
> text-encoded format.
>
We need to encode in some text format.  The rules for doing so need to be agreed.
The distinction between binary strings and binary numbers must be clear.  Strings of any sort will be transmitted lowest addressed byte first.  Binary strings would be encoded into text strings lowest addressed byte first.  Text encoding of numbers are always transmitted most significant digit (hex, decimal, or base64).  A conversion between native binary numeric representation and text implies native endian awareness.  When dealing with binary values on the order of say 1024 bits, one must be aware of endian issues to encode, transmit, receive, encode and use the result correctly.  Is this value used as a string, or a number?  If a string, one will want to encode and transmit low addressed byte first.  If binary one will want to encode and transmit the most significant "digit" first (either highest address or lowest address depending on native arithmetic byte order).

> If you need to input them, describe them for debug purposes, or
> print them to a screen, then put them in the
> format that is most natural for parsing to natural byte and
> word boundaries, which is hexadecimal, but would be outside the
> scope of the iSCSI document anyway.
>
Decimal is handy for humans, but not indispensable for machine to machine.
I agree with others that hexadecimal is the simplest, and least ambiguous encoding.
Still one needs to know whether a string or a binary value is being processed unless one is fortunate enough to only be concerned with big-endian (network byte order) hardware.

Prior use of Base64 was designed explicitly for binary files which are effectively binary strings. It will encode, transmit, and decode lowest byte address first.

If the intent is to use base64 to transmit large binary numbers, it could be done, but why bother when hexadecimal is so straight forward?  
The big deal with 4 bits, 6 bits, or 8 bits encoding is the loading, masking, shifting, and storing of the next bits from the correct location at the correct time from 8 bits per byte addressable memory systems.  If the whole value fits in one arithmetic register at one time, no big deal.  However for larger quantities, 4 bits (hexadecimal) and 8 bits (raw binary which is prohibited) are simple, 6 bits (base64) and 3.something bits (decimal) are not.

Thanks,
Nick

> Bob
>
>
> > -----Original Message-----
> > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
> > Sent: Tuesday, May 21, 2002 9:28 AM
> > To: Robert Snively
> > Cc: Julian Satran; ips@ece.cmu.edu
> > Subject: RE: iSCSI: BASE64 and numerical values
> >
> >
> > On Tue, 21 May 2002, Robert Snively wrote:
> >
> > > I have been having continuing problems understanding why
> > > iSCSI is considering any use of base64, and I find myself
> > > in total agreement with Bill's clear exposition of the
> > > situation.
> > >
> > > Upon reviewing RFC-2045, it is clear that base64 is a method
> > > for containing handy binary values in a EMAIL structure that does
> > > not use TCP/IP to transmit data, but rather uses obsolete
> > > 7-bit ASCII or (slightly less obsolete) EBCDIC strings to
> > > carry the data.  TCP/IP transmits data neutral octets,
> > > so binary values can be carried in their native binary
> > > string format (allowing for a possible requirement to pad
> > > strings to an octet boundary).  The most standard way to
> > > present those binary strings on a printer or as an input
> > > value to a program is hexadecimal encoding.
> > >
> > > For those reasons, I agree with Bill that we should delete
> > > base64 from the text and use hexadecimal as he suggests.
> >
> > I must not have been totally clear. I'm not suggesting we
> > remove base64,
> > I'm suggesting we limit its use to the cases where (IMHO) it
> > makes sense.
> > While there will be much fewer cases in the text with the changes I
> > suggest, it will still be in the spec.
> >
> > Some of the cryptographic authentications throw around large binary
> > strings. Quite large (compared to the numbers and strings we
> > often use)
> > binary strings. The fact that if you support these modes of
> > authentication
> > you are supposed to be able to accept four times as much
> text in login
> > commands reflects the size of these strings.
> >
> > Base64 is a real win for these. Hex can encode 4 bits per
> byte, while
> > base64 can encode 6. Thus an n byte string will be about
> > 1.33*n bytes in
> > base 64, while it will be 2n bytes in hex. That size
> > difference is why we
> > want base64.
> >
> > The main point I've been trying to make is that binary
> > strings and numbers
> > are different things, and that encoding methods for one
> aren't really
> > appropriate for the other. Specifics: decimal & hex work great for
> > numbers, and hex and base64 work great for binary strings.
> That's it.
> > Also, the hex for numbers isn't the same as the hex for
> > binary strings.
> > One is the number in hex, the other is more like hexdump -x
> > without the
> > spaces and without the offsets.
> >
> > Take care,
> >
> > Bill
> >
> >
> >
>


--=_alternative 0083957BC2256BC0_=-- From owner-ips@ece.cmu.edu Tue May 21 20:41:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07843 for ; Tue, 21 May 2002 20:41:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4M0HXn14949 for ips-outgoing; Tue, 21 May 2002 20:17:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4M0HVw14940 for ; Tue, 21 May 2002 20:17:31 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 17:50:55 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937900@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI Inband authentication (SRP/CHAP) - proposed resolution Date: Tue, 21 May 2002 17:49:39 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Since DH-CHAP has been excluded from iSCSI, I can now function as a WG co-chair on this security topic. On a conference call today that included both IPS WG co-chairs, our Area Director (Allison Mankin), the authors of both the iSCSI and IPS Security drafts, along with additional security experts and contributors, the group came up with the following proposed resolution to the open iSCSI requirements issues in inband authentication: - CHAP MUST be implemented. Support for strong machine-generated CHAP secrets (96+ bits of cryptographic randomness) MUST be implemented, and CHAP secrets of at least that strength SHOULD be used. Generation of secrets MAY be external to the iSCSI implementation. - If weaker CHAP secrets (e.g., passwords, hashes of passwords) are used, ESP encryption (and integrity) MUST be used to protect them, and group pre-shared keys MUST NOT be used for IKE authentication (pairwise pre-shared keys MAY be used). - Pick up some text from the DH-CHAP draft that helps prevent reflection attacks on CHAP in iSCSI (with credit/thanks to Paul Koning). - SRP remains in the iSCSI draft as a MAY implement mechanism. The overall rationale behind this is to strongly encourage (SHOULD) use of strong secrets with CHAP (first bullet) and to put in place serious requirements (MUST) for use of IPsec (ESP) to protect CHAP if weaker secrets are used (second bullet) to encourage those who need such encouragement. This is not the best possible solution, but it's a pragmatic approach that solves the problems at hand and should get the iSCSI draft into WG Last Call in the very near future. The proposed text with the details and specific requirements (for the iSCSI and IPS drafts) follows. Comments to the list by noon Eastern Daylight Time (US) this Friday (May 24), please. After that time, the text will go into the iSCSI and IPS Security drafts, and there will be further opportunity to comment during WG Last Call for these drafts. Thanks, --David Proposed text: CHAP MUST be implemented for iSCSI login authentication. In order to provide protection against offline dictionary attacks, the CHAP shared secret SHOULD represent a cryptographically random quantity with at least 96 bits of randomness. Implementations MUST support use of such random CHAP secrets including the means to generate secrets and to accept input of secrets of up to 128 bits generated externally (e.g., by other implementations). An implementation MAY meet the generation requirement by supplying a program that runs on some other system to create CHAP secrets that are then entered into the implementation via a configuration interface. Hexadecimal format MUST be supported for output of generated CHAP secrets (e.g., for use in other implementations) and input of CHAP secrets generated externally. If the CHAP shared secret is weaker than 96 bits of cryptographic randomness (e.g., the secret is a password or is derived from a password), then IPsec ESP with non-null transform (e.g., 3DES, 128 bit AES) MUST be used to protect the iSCSI login authentication, and IKE authentication with group pre-shared keys MUST NOT be used. In addition, DES SHOULD NOT be used as the ESP transform. Group pre-shared keys MUST NOT be used in this situation because they enable any member of the group to masquerade as any other and collect CHAP exchanges as raw material for an off-line dictionary attack on the CHAP shared secret(s). Pairwise pre-shared keys MAY be used. These requirements for IPsec usage to protect weak CHAP secrets (e.g., passwords) are intended to be severe. The off-line dictionary attack makes CHAP fundamentally insecure when used with passwords or similarly weak secrets; cryptographic randomness sufficient to thwart a brute-force attack is necessary to provide sufficient security. In order to provide mutual authentication and protect against rogue Targets, CHAP authentication SHOULD be done in both directions. Although this is not equivalent to a single, interlocked mutual authentication, an appropriate level of security can be obtained by observing the following requirements: (1) A Responder MUST NOT send its CHAP response if the Initiator has not successfully authenticated. For example, the following exchange: I->R CHAP_A(A1,A2,...) R->I CHAP_A, CHAP_C, CHAP_I I->R CHAP_A, CHAP_C, CHAP_I MUST result in the Responder (Target) closing the iSCSI TCP connection because the Initiator has failed to authenticate (there is no CHAP_R in the third message). (2) Initiators MUST NOT reuse the CHAP challenge sent by the Responder for the other direction of a bi-directional authentication. Responders MUST check for this condition and close the iSCSI TCP connection if it occurs. These requirements prevent reflection attacks in which the Initiator uses the same CHAP challenge as the Target and reflects the Target's response back to the Target, thereby authenticating the Initiator without requiring the Initiator to know the CHAP secret. NOTE: Credit to Paul Koning for the example and contributions to the text on this topic. --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue May 21 23:00:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13794 for ; Tue, 21 May 2002 23:00:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4M2KRL20900 for ips-outgoing; Tue, 21 May 2002 22:20:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from fep02-mail.bloor.is.net.cable.rogers.com (fep02-mail.bloor.is.net.cable.rogers.com [66.185.86.72]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4M2KPw20896 for ; Tue, 21 May 2002 22:20:25 -0400 (EDT) Received: from splentec.com ([24.43.247.111]) by fep02-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.04.13 201-253-122-122-113-20020313) with ESMTP id <20020522022019.JDGZ487166.fep02-mail.bloor.is.net.cable.rogers.com@splentec.com>; Tue, 21 May 2002 22:20:19 -0400 Message-ID: <3CEB005D.5DA3E921@splentec.com> Date: Tue, 21 May 2002 22:20:14 -0400 From: Luben Tuikov Reply-To: Luben Tuikov , iSCSI Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "THALER,PAT (A-Roseville,ex1)" CC: iSCSI , Parthi , Bill Studenmund , Mike Donohoe , Julian Satran Subject: Re: iSCSI: Login Request error References: <1BEBA5E8600DD4119A50009027AF54A00C09CB64@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep02-mail.bloor.is.net.cable.rogers.com from [24.43.247.111] using ID at Tue, 21 May 2002 22:20:19 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dear Pat, You are not mentioning anything new, see this message dated Apr 22, 2002: http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09751.html Short message straight to the point is often more helpful. Long time ago I envisoned there be a simple negotiation procedure representable as a finite automata, one for the target and another for the initiator, both complementing each other (i.e. no contradictions). I've referred in my past posts about this as ``decision trees'' -- but no one paid attention. Furthermore, I'd like those automata (describing the negotiation process) to be deterministic -- i.e. simple and no MAY's --- that would make them easily predictable. Regarging your post: thank you for agreeing, even in parenthesis, that there is INCONSISTENCY in the draft. This was the _main_ point, not quoting the draft. Please also note that exactly the SAME problem exists in section 4.2.2. (which you quote as solution). And then you mention that there would be a loop (A-ha!). Which is what I proved in my earlier post (to which you replied). As you can see the logic (contradictory) in both sections is the _same_. Anyway, I've mentioned loops before, but no one paid attention. This message from Apr 22, 2002, cc to you from me, http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09751.html shows the loop in negotiations, and mentions decision trees (I've mentioned them elsewhere as well). Anyway, the main point which has to be resolved is inconsitencies (contradictions) in the draft. Regars, Luben P.S. Another thing, which I've brought up before: Using context free grammar (EBNF) for the values of the login/text operational keys. Q: if someone volunteers their time, would this be accepted in the draft? Julian? From owner-ips@ece.cmu.edu Tue May 21 23:45:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15721 for ; Tue, 21 May 2002 23:45:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4M34Li22931 for ips-outgoing; Tue, 21 May 2002 23:04:21 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4M34Iw22926 for ; Tue, 21 May 2002 23:04:18 -0400 (EDT) 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 g4M34BM8029758; Wed, 22 May 2002 05:04:11 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4M34Bs164502; Wed, 22 May 2002 05:04:11 +0200 Importance: Normal Subject: Re: iSCSI Inband authentication (SRP/CHAP) - proposed resolution To: Black_David@emc.com Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ofer Biran" Date: Wed, 22 May 2002 06:07:23 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 22/05/2002 06:04:10 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, Just two comments (being on trip it went to the list too fast for me): 1. "If the CHAP shared secret is weaker than 96 bits of cryptographic randomness..." All this par. actually tell you what to do when you disobey the SHOULD in the par. above... ("the CHAP shared secret SHOULD represent a cryptographically random quantity...") maybe it's OK (because there are MUSTs here) but it's a bit unusual. This makes it look like we accept this alternative way, so maybe that SHOULD can go away (i.e., either 96/random or these IPsec conditions). 2. "In order to provide mutual authentication and protect against rogue Targets, CHAP authentication SHOULD be done in both directions..." Mutual authentication is optional to use for all authentication methods, and I don't see any reason to enforce it only in CHAP. This is a change, it is not related to the CHAP problems discussed, and I would not put it in suddenly now. Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 From owner-ips@ece.cmu.edu Wed May 22 04:02:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16625 for ; Wed, 22 May 2002 04:02:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4M7JJk04440 for ips-outgoing; Wed, 22 May 2002 03:19:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4M7JIw04436 for ; Wed, 22 May 2002 03:19:18 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4M7JHFD149298 for ; Wed, 22 May 2002 03:19:17 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4M7JGf179830 for ; Wed, 22 May 2002 01:19:16 -0600 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: AsyncEvent Table To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Wed, 22 May 2002 00:17:33 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/22/2002 01:19:15 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, in version 9 we had the following words for AsyncEvent code 1: 'Initiator MUST send a Logout with a reason code of "Close the connection" to cleanly shutdown the connection. The initiator MAY also issue a Logout with the reason code of "Close the session", to completely close the session, but ONLY if it does not support or use multiple connections in the specific session.' In version 10 we had the following words for AsyncEvent code 1: 'Initiator MUST send a Logout with a reason code of "Close the connection" (if not the only connection) OR "Close the session" (if using multiple connections) ' In version 12 it is changed to the following: 'Initiator MUST send a Logout with a reason code of "Close the connection" (if not the only connection) OR "Close the session" to close all the connections (if using multiple connections). ' Which is where things are today. So the big change occurred between 9 & 10. But that change was not in the Change Log, so I am wondering if it was changed in error, or what? The question, is if this wordage is correct, please note we went from ".... Close the session... Only if it does not support multiple connections ...." . to " ...Close the session.... (if using multiple connections)" And now there is no statements as to what to do if you have a single connection session. What should be done in that case? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Wed May 22 05:00:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18007 for ; Wed, 22 May 2002 05:00:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4M8MNr06955 for ips-outgoing; Wed, 22 May 2002 04:22:23 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4M8MMw06951 for ; Wed, 22 May 2002 04:22:22 -0400 (EDT) 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 g4M8MGM8031262; Wed, 22 May 2002 10:22:16 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4M8MEV113758; Wed, 22 May 2002 10:22:14 +0200 Subject: Re: Flipped locations between d11 and d12. To: "Sankar, Ranga" Cc: "'ips@ece.cmu.edu'" , "Julian Satran" X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Wed, 22 May 2002 08:34:43 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 22/05/2002 11:22:14 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk It is no mistake. It is only that this new notation is the one preferred by the RFC editor. Julo "Sankar, Ranga" app.com> cc: Julian Satran/Haifa/IBM@IBMIL Subject: Flipped locations between d11 and d12. 05/21/2002 10:54 PM Please respond to "Sankar, Ranga" Looks like the bit locations are flipped between Version 11 and 12. For example Bit 0 of Byte 1 corresponds to T bit in Version 12 In Version 11 and below Bit 7 of Byte 1 corresponds to T bit. Is this intended or an error in the draft. Version 12 Login Response Byte / 0 | 1 | 2 | 3 | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| <--------- . . 0x23 Version 11 Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| <---------- +---------------+---------------+---------------+---------------+ 0|.|.| 0x23 |T|0 0 0|CSG|NSG| Version-max | Version-active| -ranga From owner-ips@ece.cmu.edu Wed May 22 05:46:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19167 for ; Wed, 22 May 2002 05:46:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4M936608529 for ips-outgoing; Wed, 22 May 2002 05:03:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4M934w08523 for ; Wed, 22 May 2002 05:03:05 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4M92uwY007888 for ; Wed, 22 May 2002 11:02:57 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4M92gV122354 for ; Wed, 22 May 2002 11:02:45 +0200 To: "John Hufferd" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: AsyncEvent Table X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 22 May 2002 12:02:18 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 22/05/2002 12:02:46, Serialize complete at 22/05/2002 12:02:46 Content-Type: multipart/alternative; boundary="=_alternative 003116C4C2256BC1_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003116C4C2256BC1_= Content-Type: text/plain; charset="us-ascii" John, It was all wording and it was meant to show that an initiator may choose the "big hammer" and close the session. We may want to reduce it to: Initiator MUST send a Logout with a reason code of "Close the connection" (if not the only connection) OR "Close the session" to close all the connections. Regards, Julo John Hufferd@IBMUS 05/22/2002 10:17 AM To: Julian Satran/Haifa/IBM@IBMIL@IBMDE cc: ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: iSCSI: AsyncEvent Table Julian, in version 9 we had the following words for AsyncEvent code 1: 'Initiator MUST send a Logout with a reason code of "Close the connection" to cleanly shutdown the connection. The initiator MAY also issue a Logout with the reason code of "Close the session", to completely close the session, but ONLY if it does not support or use multiple connections in the specific session.' In version 10 we had the following words for AsyncEvent code 1: 'Initiator MUST send a Logout with a reason code of "Close the connection" (if not the only connection) OR "Close the session" (if using multiple connections) ' In version 12 it is changed to the following: 'Initiator MUST send a Logout with a reason code of "Close the connection" (if not the only connection) OR "Close the session" to close all the connections (if using multiple connections). ' Which is where things are today. So the big change occurred between 9 & 10. But that change was not in the Change Log, so I am wondering if it was changed in error, or what? The question, is if this wordage is correct, please note we went from ".... Close the session... Only if it does not support multiple connections ...." . to " ...Close the session.... (if using multiple connections)" And now there is no statements as to what to do if you have a single connection session. What should be done in that case? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com --=_alternative 003116C4C2256BC1_= Content-Type: text/html; charset="us-ascii"
John,

It was all wording and it was meant to show that an initiator may choose the "big hammer" and close the session.
We may want to reduce it to:

Initiator MUST send a Logout with a reason code of "Close the connection" (if not the only connection) OR "Close the session" to close all the connections.


Regards,
Julo


John Hufferd@IBMUS

05/22/2002 10:17 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL@IBMDE
        cc:        ips@ece.cmu.edu
        From:        John Hufferd/San Jose/IBM@IBMUS
        Subject:        iSCSI: AsyncEvent Table

       


Julian,
in version 9 we had the following words for AsyncEvent code 1:

'Initiator MUST send a Logout with a reason code of "Close the connection" to cleanly shutdown the connection. The initiator MAY also issue a Logout with the reason code of "Close the session", to completely close the session, but ONLY if it does not support or use multiple connections in the specific session.'

In version 10 we had the following words for AsyncEvent code 1:

'Initiator MUST send a Logout with a reason code of "Close the connection" (if not the only connection) OR "Close the session" (if using multiple connections) '

In version 12 it is changed to the following:

 'Initiator MUST send a Logout with a reason code of "Close the connection" (if not the only connection) OR "Close the session" to close all the connections (if using multiple connections). '

Which is where things are today.  So the big change occurred between 9 & 10.  But that change was not in the Change Log, so I am wondering if it was changed in error, or what?

The question, is if this wordage is correct, please note we went from ".... Close the session... Only if it does not support multiple connections ...." . to  " ...Close the session.... (if using multiple connections)"

And now there is no statements as to what to do if you have a single connection session.

What should be done in that case?


.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com

--=_alternative 003116C4C2256BC1_=-- From owner-ips@ece.cmu.edu Wed May 22 10:30:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04466 for ; Wed, 22 May 2002 10:30:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MDokC04867 for ips-outgoing; Wed, 22 May 2002 09:50:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4MDohw04863 for ; Wed, 22 May 2002 09:50:43 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4MDobp15581 for ; Wed, 22 May 2002 09:50:37 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4MDobc15572; Wed, 22 May 2002 09:50:37 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g4MDoa221208; Wed, 22 May 2002 09:50:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15595.41524.773000.650379@gargle.gargle.HOWL> Date: Wed, 22 May 2002 09:50:44 -0400 From: Paul Koning To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI Inband authentication (SRP/CHAP) - proposed resolution References: <277DD60FB639D511AC0400B0D068B71E02937900@CORPMX14> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 21 May 2002) by Black_David@emc.com: > Since DH-CHAP has been excluded from iSCSI, I can now function as a WG > co-chair on this security topic. On a conference call today that included > both IPS WG co-chairs, our Area Director (Allison Mankin), the authors > of both the iSCSI and IPS Security drafts, along with additional > security experts and contributors, the group came up with the following > proposed resolution to the open iSCSI requirements issues in inband > authentication: > > - CHAP MUST be implemented. Support for strong machine-generated CHAP > secrets (96+ bits of cryptographic randomness) MUST be implemented, > and CHAP secrets of at least that strength SHOULD be used. > Generation of secrets MAY be external to the iSCSI implementation. That sounds generally reasonable. The requirement of 96 or more bits of entropy is problematic: it is achievable, but I don't believe it is testable. In other words, I don't believe it is possible to construct a conformance test applied from the outside of the system that verifies this requirement. Protocol standards should only contain requirements that are testable by external observers. > - If weaker CHAP secrets (e.g., passwords, hashes of passwords) are > used, ESP encryption (and integrity) MUST be used to protect them, > and group pre-shared keys MUST NOT be used for IKE authentication > (pairwise pre-shared keys MAY be used). This is a "must use" requirement. I thought that "must use" requirements were things to be avoided. Certainly they don't belong in this spec, because the requirement makes no sense in some customer settings. Apart from that, this requirement isn't testable either. Given externally supplied CHAP secrets, the implementation has no way to test whether the supplied secret is "weak" or not, and therefore no way to decide whether it should enforce an ESP mandate even if it wanted to. paul From owner-ips@ece.cmu.edu Wed May 22 11:52:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13617 for ; Wed, 22 May 2002 11:52:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MEqM309720 for ips-outgoing; Wed, 22 May 2002 10:52:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ext1.pirus.com ([4.36.58.197]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4MEC5w06540 for ; Wed, 22 May 2002 10:12:05 -0400 (EDT) Received: by ext1.pirus.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 May 2002 10:14:47 -0400 Message-ID: <4740CE4D4F77564BAADD58D6EF76FBF303EF6A@morpheus.pirus.com> From: "Merhar, Milan" To: "'Black_David@emc.com'" , ips@ece.cmu.edu Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution Date: Wed, 22 May 2002 10:14:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Just to make sure I understand the requirement; if CHAP is used in today's conventional way with a human-generated password, iSCSI login MUST be protected using ESP encryption (and integrity.) That seems to be a reasonable solution, given the goal of protecting the login secret. But, since the IPsec SA must be in place before iSCSI login to give this protection, and because each iSCSI session begins with a login, that indicates that the full-featured portion of these iSCSI sessions MUST also be protected by the same ESP encryption (and integrity) negotiated to protect the login. In other words, if you use CHAP without a strong key (and has already been pointed out, there is no way of verifying key strength during use) use of IPsec ESP encryption has been mandated as a MUST USE for the entire iSCSI session. (Or, as one associate put it, we're not mandating crypto across a few handshake frames, but across all data as well.) If I'm reading this incorrectly, please correct me. - milan > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Tuesday, May 21, 2002 5:50 PM > To: ips@ece.cmu.edu > Subject: iSCSI Inband authentication (SRP/CHAP) - proposed resolution > Importance: High > > > Since DH-CHAP has been excluded from iSCSI, I can now function as a WG > co-chair on this security topic. On a conference call today > that included > both IPS WG co-chairs, our Area Director (Allison Mankin), the authors > of both the iSCSI and IPS Security drafts, along with additional > security experts and contributors, the group came up with the > following > proposed resolution to the open iSCSI requirements issues in inband > authentication: > > - CHAP MUST be implemented. Support for strong machine-generated CHAP > secrets (96+ bits of cryptographic randomness) MUST be > implemented, > and CHAP secrets of at least that strength SHOULD be used. > Generation of secrets MAY be external to the iSCSI > implementation. > - If weaker CHAP secrets (e.g., passwords, hashes of passwords) are > used, ESP encryption (and integrity) MUST be used to > protect them, > and group pre-shared keys MUST NOT be used for IKE > authentication > (pairwise pre-shared keys MAY be used). > - Pick up some text from the DH-CHAP draft that helps prevent > reflection > attacks on CHAP in iSCSI (with credit/thanks to Paul Koning). > - SRP remains in the iSCSI draft as a MAY implement mechanism. > > The overall rationale behind this is to strongly encourage > (SHOULD) use > of strong secrets with CHAP (first bullet) and to put in place serious > requirements (MUST) for use of IPsec (ESP) to protect CHAP if weaker > secrets are used (second bullet) to encourage those who need such > encouragement. This is not the best possible solution, but it's a > pragmatic approach that solves the problems at hand and should get > the iSCSI draft into WG Last Call in the very near future. > > The proposed text with the details and specific requirements (for the > iSCSI and IPS drafts) follows. Comments to the list by noon Eastern > Daylight Time (US) this Friday (May 24), please. After that time, the > text will go into the iSCSI and IPS Security drafts, and there will be > further opportunity to comment during WG Last Call for these drafts. > > Thanks, > --David > > Proposed text: > > CHAP MUST be implemented for iSCSI login authentication. In order > to provide protection against offline dictionary attacks, the CHAP > shared secret SHOULD represent a cryptographically random quantity > with at least 96 bits of randomness. Implementations MUST support > use of such random CHAP secrets including the means to generate > secrets and to accept input of secrets of up to 128 bits generated > externally (e.g., by other implementations). An implementation MAY > meet the generation requirement by supplying a program that runs on > some other system to create CHAP secrets that are then entered into > the implementation via a configuration interface. Hexadecimal > format MUST be supported for output of generated CHAP secrets > (e.g., for use in other implementations) and input of CHAP secrets > generated externally. > > If the CHAP shared secret is weaker than 96 bits of cryptographic > randomness (e.g., the secret is a password or is derived from > a password), > then IPsec ESP with non-null transform (e.g., 3DES, 128 bit > AES) MUST be > used to protect the iSCSI login authentication, and IKE authentication > with group pre-shared keys MUST NOT be used. In addition, > DES SHOULD NOT > be used as the ESP transform. Group pre-shared keys MUST NOT > be used in > this situation because they enable any member of the group to > masquerade > as any other and collect CHAP exchanges as raw material for > an off-line > dictionary attack on the CHAP shared secret(s). Pairwise > pre-shared keys > MAY be used. These requirements for IPsec usage to protect weak CHAP > secrets > (e.g., passwords) are intended to be severe. The off-line > dictionary attack > makes CHAP fundamentally insecure when used with passwords or > similarly > weak secrets; cryptographic randomness sufficient to thwart a > brute-force > attack is necessary to provide sufficient security. > > In order to provide mutual authentication and protect against rogue > Targets, CHAP authentication SHOULD be done in both > directions. Although > this is not equivalent to a single, interlocked mutual > authentication, an > appropriate level of security can be obtained by observing > the following > requirements: > > (1) A Responder MUST NOT send its CHAP response if the > Initiator has not > successfully authenticated. For example, the following exchange: > > I->R CHAP_A(A1,A2,...) > R->I CHAP_A, CHAP_C, CHAP_I > I->R CHAP_A, CHAP_C, CHAP_I > > MUST result in the Responder (Target) closing the iSCSI TCP > connection because the Initiator has failed to > authenticate (there > is no CHAP_R in the third message). > > (2) Initiators MUST NOT reuse the CHAP challenge sent by the > Responder for > the other direction of a bi-directional authentication. > Responders > MUST check for this condition and close the iSCSI TCP > connection if it > occurs. > > These requirements prevent reflection attacks in which the > Initiator uses > the same CHAP challenge as the Target and reflects the > Target's response > back to the Target, thereby authenticating the Initiator > without requiring > the Initiator to know the CHAP secret. > > NOTE: Credit to Paul Koning for the example and contributions > to the text > on this topic. > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Wed May 22 12:49:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18122 for ; Wed, 22 May 2002 12:49:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MG4ZD15266 for ips-outgoing; Wed, 22 May 2002 12:04:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4MG4Ww15252 for ; Wed, 22 May 2002 12:04:32 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4MG4UWo051782; Wed, 22 May 2002 12:04:30 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4MG4JK45898; Wed, 22 May 2002 10:04:19 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI Inband authentication (SRP/CHAP) - proposed resolution To: Black_David@emc.com Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Wed, 22 May 2002 09:02:33 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/22/2002 10:04:19 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, The problem I am having with the proposal is, that I think we are mandating customer actions not just implementation. We are saying that if Chap passwords are used then they must do or must not do something else which is legal with IPsec. Since the IPsec process is really disjoint from the iSCSI Login, there is no real way that we can tell what the customer did with IPsec, and IKE. So some how I think the wordage needs to be adjusted to reflect this implementation vrs customer interaction, since I think the only thing we can do is document on the packaging/directions, what should or should not be done. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Black_David@emc.com@ece.cmu.edu on 05/21/2002 02:49:39 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI Inband authentication (SRP/CHAP) - proposed resolution Since DH-CHAP has been excluded from iSCSI, I can now function as a WG co-chair on this security topic. On a conference call today that included both IPS WG co-chairs, our Area Director (Allison Mankin), the authors of both the iSCSI and IPS Security drafts, along with additional security experts and contributors, the group came up with the following proposed resolution to the open iSCSI requirements issues in inband authentication: - CHAP MUST be implemented. Support for strong machine-generated CHAP secrets (96+ bits of cryptographic randomness) MUST be implemented, and CHAP secrets of at least that strength SHOULD be used. Generation of secrets MAY be external to the iSCSI implementation. - If weaker CHAP secrets (e.g., passwords, hashes of passwords) are used, ESP encryption (and integrity) MUST be used to protect them, and group pre-shared keys MUST NOT be used for IKE authentication (pairwise pre-shared keys MAY be used). - Pick up some text from the DH-CHAP draft that helps prevent reflection attacks on CHAP in iSCSI (with credit/thanks to Paul Koning). - SRP remains in the iSCSI draft as a MAY implement mechanism. The overall rationale behind this is to strongly encourage (SHOULD) use of strong secrets with CHAP (first bullet) and to put in place serious requirements (MUST) for use of IPsec (ESP) to protect CHAP if weaker secrets are used (second bullet) to encourage those who need such encouragement. This is not the best possible solution, but it's a pragmatic approach that solves the problems at hand and should get the iSCSI draft into WG Last Call in the very near future. The proposed text with the details and specific requirements (for the iSCSI and IPS drafts) follows. Comments to the list by noon Eastern Daylight Time (US) this Friday (May 24), please. After that time, the text will go into the iSCSI and IPS Security drafts, and there will be further opportunity to comment during WG Last Call for these drafts. Thanks, --David Proposed text: CHAP MUST be implemented for iSCSI login authentication. In order to provide protection against offline dictionary attacks, the CHAP shared secret SHOULD represent a cryptographically random quantity with at least 96 bits of randomness. Implementations MUST support use of such random CHAP secrets including the means to generate secrets and to accept input of secrets of up to 128 bits generated externally (e.g., by other implementations). An implementation MAY meet the generation requirement by supplying a program that runs on some other system to create CHAP secrets that are then entered into the implementation via a configuration interface. Hexadecimal format MUST be supported for output of generated CHAP secrets (e.g., for use in other implementations) and input of CHAP secrets generated externally. If the CHAP shared secret is weaker than 96 bits of cryptographic randomness (e.g., the secret is a password or is derived from a password), then IPsec ESP with non-null transform (e.g., 3DES, 128 bit AES) MUST be used to protect the iSCSI login authentication, and IKE authentication with group pre-shared keys MUST NOT be used. In addition, DES SHOULD NOT be used as the ESP transform. Group pre-shared keys MUST NOT be used in this situation because they enable any member of the group to masquerade as any other and collect CHAP exchanges as raw material for an off-line dictionary attack on the CHAP shared secret(s). Pairwise pre-shared keys MAY be used. These requirements for IPsec usage to protect weak CHAP secrets (e.g., passwords) are intended to be severe. The off-line dictionary attack makes CHAP fundamentally insecure when used with passwords or similarly weak secrets; cryptographic randomness sufficient to thwart a brute-force attack is necessary to provide sufficient security. In order to provide mutual authentication and protect against rogue Targets, CHAP authentication SHOULD be done in both directions. Although this is not equivalent to a single, interlocked mutual authentication, an appropriate level of security can be obtained by observing the following requirements: (1) A Responder MUST NOT send its CHAP response if the Initiator has not successfully authenticated. For example, the following exchange: I->R CHAP_A(A1,A2,...) R->I CHAP_A, CHAP_C, CHAP_I I->R CHAP_A, CHAP_C, CHAP_I MUST result in the Responder (Target) closing the iSCSI TCP connection because the Initiator has failed to authenticate (there is no CHAP_R in the third message). (2) Initiators MUST NOT reuse the CHAP challenge sent by the Responder for the other direction of a bi-directional authentication. Responders MUST check for this condition and close the iSCSI TCP connection if it occurs. These requirements prevent reflection attacks in which the Initiator uses the same CHAP challenge as the Target and reflects the Target's response back to the Target, thereby authenticating the Initiator without requiring the Initiator to know the CHAP secret. NOTE: Credit to Paul Koning for the example and contributions to the text on this topic. --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed May 22 14:05:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22462 for ; Wed, 22 May 2002 14:05:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MHcUd21967 for ips-outgoing; Wed, 22 May 2002 13:38:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4MHcQw21963 for ; Wed, 22 May 2002 13:38:26 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 349FF30706; Wed, 22 May 2002 13:38:26 -0400 (EDT) Date: Wed, 22 May 2002 10:36:29 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "Martin, Nick (Server Storage)" Cc: Julian Satran , , Robert Snively Subject: RE: iSCSI: BASE64 and numerical values In-Reply-To: <31891B757C09184BBFEC5275F85D5595104E84@cceexc18.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 22 May 2002, Martin, Nick (Server Storage) wrote: > Julo, > > Although it is more compact than hex which encodes 1/2 byte at a time, > b64 encodes 3/4 of a byte at a time. When encoding b64 strings, one > normally processes three bytes at a time, low addressed byte first. > When encoding and decoding numbers on little endian to b64, perhaps > the process is straight forward, but I am not sure. I am sure it is > extra code relative to hex for handling lengths not a multiple of 3 > bytes. If any implementation is allowed to send numbers in b64, then > all must have capability to accept them whenever parsing for a number. > This is a third redundant encoding for a number. We could operate > effectively with only one (hex). The single code path would be well > tested. I expect several implementations (including my own) to have > flaws in their first attempt at b64 encoding or decoding for numbers > of arbitrary length. I don't expect anyone to have flaws in their > hexadecimal handling. I'd like us to be able to keep decimal, at least for "small" numbers as we mention in the spec now. While I agree that adding b64 encoding for numbers would be new/untested code, I think that decimal is ok; strtoull() should be a well-tested library routine. :-) > I have seen discussion about not allowing excess leading zeroes. > This defeats inferring the correct storage size of a number from its > encoding. Outside of security, the sizes of numbers are already fixed > and this is not a problem. Within security, I am not sure this is > true. (I am nothing like a security expert yet.) Turns out CHAP needs strings, not numbers, so it is fine. I'm not sure about SRP, but from what I can tell, all of the other security methods will be exchanging (from iSCSI's point of view) binary strings. > Another confusion factor is numbers of arbitrary length. Without > knowing the format required internally by security algorithms which > use these, I am not sure whether they will want big endian or little > endian format on little endian hardware. I hope they in fact want a > b64 or hex representation in big endian a.k.a. network byte order (a > string) and convert it to internal format themselves. Suppose the > algorithm wants a string in hex, but I receive a string in b64! > Whether these are used internally as numbers or strings is not > relevant if they are always delivered to the algorithms as strings. Agreed, and I think we are there (just not sure on SRP). > Although I use decimal rather than hex today, I would be willing to > give it up for simpler implementations. strtoull() is hard? :-) Take care, Bill From owner-ips@ece.cmu.edu Wed May 22 14:05:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22476 for ; Wed, 22 May 2002 14:05:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MHUGr21255 for ips-outgoing; Wed, 22 May 2002 13:30:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4MGSbw16871 for ; Wed, 22 May 2002 12:28:37 -0400 (EDT) Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id g4MGSVA02204; Wed, 22 May 2002 09:28:31 -0700 (PDT) Received: from ussvlexc01.corp.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.12.2/8.12.2/NTAP-1.4) with ESMTP id g4MGSUOd016354; Wed, 22 May 2002 09:28:31 -0700 (PDT) Received: by ussvlexc01.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 09:28:30 -0700 Message-ID: <02740A3D0809D5118C7C00034707E9F3038F4DAA@ussvlexc10.corp.netapp.com> From: "Sankar, Ranga" To: "'Julian Satran'" Cc: "'ips@ece.cmu.edu'" , "Pittman, Joseph" Subject: RE: Flipped locations between d11 and d12. Date: Wed, 22 May 2002 09:28:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The new notation is counter intuitive and causes confusion. If there is no specific reasoni would prefer it to be the way it was in earlier drafts (D11). -ranga > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, May 22, 2002 1:35 AM > To: Sankar, Ranga > Cc: 'ips@ece.cmu.edu'; Julian Satran > Subject: Re: Flipped locations between d11 and d12. > > > > It is no mistake. It is only that this new notation is the > one preferred by > the RFC editor. > > Julo > > > > > "Sankar, Ranga" > > "'ips@ece.cmu.edu'" > > app.com> cc: > Julian Satran/Haifa/IBM@IBMIL > > Subject: > Flipped locations between d11 and d12. > > 05/21/2002 10:54 > > PM > > Please respond to > > "Sankar, Ranga" > > > > > > > > > > Looks like the bit locations are flipped between Version 11 and 12. > > For example Bit 0 of Byte 1 corresponds to T bit in Version 12 > In Version 11 and below Bit 7 of Byte 1 corresponds to T bit. > > Is this intended or an error in the draft. > > Version 12 > > Login Response > Byte / 0 | 1 | 2 | 3 > | > |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| > <--------- > . . 0x23 > > Version 11 > Byte / 0 | 1 | 2 | 3 | / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > <---------- > +---------------+---------------+---------------+---------------+ > 0|.|.| 0x23 |T|0 0 0|CSG|NSG| Version-max | > Version-active| > > -ranga > > > > From owner-ips@ece.cmu.edu Wed May 22 14:05:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22495 for ; Wed, 22 May 2002 14:05:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MHKqU20530 for ips-outgoing; Wed, 22 May 2002 13:20:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4MHKpw20526 for ; Wed, 22 May 2002 13:20:51 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 736ABFCD2; Wed, 22 May 2002 11:20:50 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id E9A17106; Wed, 22 May 2002 11:20:49 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 22 May 2002 11:20:48 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 11:20:48 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09CD04@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: luben@splentec.com, ips@ece.cmu.edu Subject: RE: iSCSI: Login Request error Date: Wed, 22 May 2002 11:20:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, I have also pointed out some of these problems of clarity and consistancy before in shorter messages about the point. However, that hasn't resulted in a change to the draft so I went into more depth this time and fairly few people are responding on this point. Your response reads to me as either defensive or hostile which I don't understand since I think we want the same thing - for the negotiation text to become simpler and non-contradictory. Sincerely, Pat -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Tuesday, May 21, 2002 7:20 PM To: THALER,PAT (A-Roseville,ex1) Cc: iSCSI; Parthi; Bill Studenmund; Mike Donohoe; Julian Satran Subject: Re: iSCSI: Login Request error Dear Pat, You are not mentioning anything new, see this message dated Apr 22, 2002: http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09751.html Short message straight to the point is often more helpful. Long time ago I envisoned there be a simple negotiation procedure representable as a finite automata, one for the target and another for the initiator, both complementing each other (i.e. no contradictions). I've referred in my past posts about this as ``decision trees'' -- but no one paid attention. Furthermore, I'd like those automata (describing the negotiation process) to be deterministic -- i.e. simple and no MAY's --- that would make them easily predictable. Regarging your post: thank you for agreeing, even in parenthesis, that there is INCONSISTENCY in the draft. This was the _main_ point, not quoting the draft. Please also note that exactly the SAME problem exists in section 4.2.2. (which you quote as solution). And then you mention that there would be a loop (A-ha!). Which is what I proved in my earlier post (to which you replied). As you can see the logic (contradictory) in both sections is the _same_. Anyway, I've mentioned loops before, but no one paid attention. This message from Apr 22, 2002, cc to you from me, http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09751.html shows the loop in negotiations, and mentions decision trees (I've mentioned them elsewhere as well). Anyway, the main point which has to be resolved is inconsitencies (contradictions) in the draft. Regars, Luben P.S. Another thing, which I've brought up before: Using context free grammar (EBNF) for the values of the login/text operational keys. Q: if someone volunteers their time, would this be accepted in the draft? Julian? From owner-ips@ece.cmu.edu Wed May 22 14:05:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22519 for ; Wed, 22 May 2002 14:05:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MHKXs20513 for ips-outgoing; Wed, 22 May 2002 13:20:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from esply02.cnt.com (mailhost.cnt.com [139.93.128.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4MHKUw20508 for ; Wed, 22 May 2002 13:20:30 -0400 (EDT) Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 12:20:25 -0500 Message-ID: <3C7122FAF06DD5118ED6005004733648263247@esply01.cnt.com> From: Michael Schoberg To: "IPS Reflector (E-mail)" Subject: RE: iSCSI: BASE64 and numerical values Date: Wed, 22 May 2002 12:20:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk : CHAP challenges are strings, not numbers. Funny that at least one predominant initiator out there only accepts hex-valued CHAP challenges. Perhaps this should be either made clearer in the draft or it should be opened up to all iSCSI formats. I personally don't see the problem with large decimal, base64, or hex. It seems like the algorithms to convert these back to machine values are relatively simple. They're far simpler than the authentication and encryption algorithms we're working with. :-----Original Message----- :From: Paul Koning [mailto:ni1d@arrl.net] :Sent: Tuesday, May 21, 2002 3:06 PM :To: wrstuden@wasabisystems.com :Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu; rsnively@Brocade.COM :Subject: RE: iSCSI: BASE64 and numerical values : : :Excerpt of message (sent 21 May 2002) by Bill Studenmund: :> On Tue, 21 May 2002, Julian Satran wrote: :> :> > Bill, :> > :> > Your point was clear. I am still loking at the cases where :LARGE NUMBERS :> > might be needed and I am sure we don't want them to be strings but :> > numbers. :> :> Sounds excelent. :> :> One thing I haven't figured out how to do is add implicit :binary length to :> the numbers used for CHAP challenges (and possibly others). :It's a little :> bit of semantics (since we define the length for binary :strings), but the :> ones I came up with felt heavy and cumbersome. : :CHAP challenges are strings, not numbers. : : paul : From owner-ips@ece.cmu.edu Wed May 22 14:08:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22622 for ; Wed, 22 May 2002 14:07:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MHUYg21297 for ips-outgoing; Wed, 22 May 2002 13:30:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4MHN2w20706 for ; Wed, 22 May 2002 13:23:02 -0400 (EDT) Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.110.250.125]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 91DBD43A6; Wed, 22 May 2002 12:22:55 -0500 (CDT) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 22 May 2002 12:22:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C201B5.429D6C2C" Subject: RE: iSCSI: BASE64 and numerical values Date: Wed, 22 May 2002 12:22:33 -0500 Message-ID: <31891B757C09184BBFEC5275F85D5595104E84@cceexc18.americas.cpqcorp.net> Thread-Topic: iSCSI: BASE64 and numerical values Thread-Index: AcIBJGPqb/fZSpJyQHypVZUXbt3rNwAhHqJQ From: "Martin, Nick (Server Storage)" To: "Julian Satran" Cc: , "Robert Snively" , "Bill Studenmund" X-OriginalArrivalTime: 22 May 2002 17:22:34.0181 (UTC) FILETIME=[42D5C750:01C201B5] Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C201B5.429D6C2C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Julo, =20 Although it is more compact than hex which encodes 1/2 byte at a time, = b64 encodes 3/4 of a byte at a time. When encoding b64 strings, one = normally processes three bytes at a time, low addressed byte first. = When encoding and decoding numbers on little endian to b64, perhaps the = process is straight forward, but I am not sure. I am sure it is extra = code relative to hex for handling lengths not a multiple of 3 bytes. If = any implementation is allowed to send numbers in b64, then all must have = capability to accept them whenever parsing for a number. This is a = third redundant encoding for a number. We could operate effectively = with only one (hex). The single code path would be well tested. I = expect several implementations (including my own) to have flaws in their = first attempt at b64 encoding or decoding for numbers of arbitrary = length. I don't expect anyone to have flaws in their hexadecimal = handling. =20 I have seen discussion about not allowing excess leading zeroes. This = defeats inferring the correct storage size of a number from its = encoding. Outside of security, the sizes of numbers are already fixed = and this is not a problem. Within security, I am not sure this is true. = (I am nothing like a security expert yet.) =20 Another confusion factor is numbers of arbitrary length. Without = knowing the format required internally by security algorithms which use = these, I am not sure whether they will want big endian or little endian = format on little endian hardware. I hope they in fact want a b64 or hex = representation in big endian a.k.a. network byte order (a string) and = convert it to internal format themselves. Suppose the algorithm wants a = string in hex, but I receive a string in b64! Whether these are used = internally as numbers or strings is not relevant if they are always = delivered to the algorithms as strings. =20 Although I use decimal rather than hex today, I would be willing to give = it up for simpler implementations. =20 If b64 is only used for security strings and the login process can treat = them as strings and pass them to security algorithms as strings, then = whether the string contains b64, hex, or decimal is transparent to = parsing during login. I see no reason to require an implementation to = accept b64 for login operational parameters like MaxBurstSize. =20 Unlike redundant encoding options in the spec, if my messages are = redundant, you are free to ignore them ;-). =20 Thanks, Nick =20 P.S. Due to the spam filter, my recent posting did not reach the list. = I am working on it. =20 Nick Martin now part of the new HP =20 -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, May 21, 2002 7:05 PM To: Martin, Nick (Server Storage) Cc: ips@ece.cmu.edu; Robert Snively; Bill Studenmund Subject: RE: iSCSI: BASE64 and numerical values Nick,=20 I said already that I will say something about order in numbers - and = that holds for hex or b64=20 and that will be the "normal" high-endian encoding.=20 Why do you consider hex and b64 to be different?=20 Julo=20 "Martin, Nick (Server Storage)" =20 05/21/2002 11:11 PM=20 Please respond to "Martin, Nick (Server Storage)"=20 =20 To: "Robert Snively" , "Bill = Studenmund" , Julian Satran/Haifa/IBM@IBMIL, = =20 cc: =20 Subject: RE: iSCSI: BASE64 and numerical values=20 =20 Robert, My comments are below. > -----Original Message----- > From: Robert Snively [mailto:rsnively@Brocade.COM] > Sent: Tuesday, May 21, 2002 1:44 PM > To: Bill Studenmund; Julian Satran; ips@ece.cmu.edu > Subject: RE: iSCSI: BASE64 and numerical values >=20 >=20 > I guess that my point was that we should be transmitting the > binary value, not the encoding of the binary value. > In the current draft and all those I saw preceding one can not transmit = "raw binary" values during login phase. To be transmitted within a = Login, Login Response, Text, or Text Response PDU, the value must be = formatted as a null terminated string of the form keyword=3Dvalue. = Further the set of characters which may be used is restricted as = specified. > Especially if you care about the length, that is the most > compact version of transmission. >=20 Agreed this is the most compact, but not the most universal. As many = working in both big endian and little endian worlds can attest, a number = conveyed in "binary" is not universally understood. > You are never using them in the text-encoded format, so > why transmit them in a text-encoded format. The values are > ALWAYS used only in the binary format. TCP/IP does not > have any requirement for them to ever be expressed in the > text-encoded format. >=20 We need to encode in some text format. The rules for doing so need to = be agreed. The distinction between binary strings and binary numbers must be clear. = Strings of any sort will be transmitted lowest addressed byte first. = Binary strings would be encoded into text strings lowest addressed byte = first. Text encoding of numbers are always transmitted most significant = digit (hex, decimal, or base64). A conversion between native binary = numeric representation and text implies native endian awareness. When = dealing with binary values on the order of say 1024 bits, one must be = aware of endian issues to encode, transmit, receive, encode and use the = result correctly. Is this value used as a string, or a number? If a = string, one will want to encode and transmit low addressed byte first. = If binary one will want to encode and transmit the most significant = "digit" first (either highest address or lowest address depending on = native arithmetic byte order). > If you need to input them, describe them for debug purposes, or=20 > print them to a screen, then put them in the > format that is most natural for parsing to natural byte and > word boundaries, which is hexadecimal, but would be outside the > scope of the iSCSI document anyway. >=20 Decimal is handy for humans, but not indispensable for machine to = machine. I agree with others that hexadecimal is the simplest, and least = ambiguous encoding.=20 Still one needs to know whether a string or a binary value is being = processed unless one is fortunate enough to only be concerned with = big-endian (network byte order) hardware. Prior use of Base64 was designed explicitly for binary files which are = effectively binary strings. It will encode, transmit, and decode lowest = byte address first. If the intent is to use base64 to transmit large binary numbers, it = could be done, but why bother when hexadecimal is so straight forward? =20 The big deal with 4 bits, 6 bits, or 8 bits encoding is the loading, = masking, shifting, and storing of the next bits from the correct = location at the correct time from 8 bits per byte addressable memory = systems. If the whole value fits in one arithmetic register at one = time, no big deal. However for larger quantities, 4 bits (hexadecimal) = and 8 bits (raw binary which is prohibited) are simple, 6 bits (base64) = and 3.something bits (decimal) are not. Thanks, Nick > Bob >=20 >=20 > > -----Original Message----- > > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]=20 > > Sent: Tuesday, May 21, 2002 9:28 AM > > To: Robert Snively > > Cc: Julian Satran; ips@ece.cmu.edu > > Subject: RE: iSCSI: BASE64 and numerical values > >=20 > >=20 > > On Tue, 21 May 2002, Robert Snively wrote: > >=20 > > > I have been having continuing problems understanding why > > > iSCSI is considering any use of base64, and I find myself > > > in total agreement with Bill's clear exposition of the > > > situation. > > > > > > Upon reviewing RFC-2045, it is clear that base64 is a method > > > for containing handy binary values in a EMAIL structure that does > > > not use TCP/IP to transmit data, but rather uses obsolete > > > 7-bit ASCII or (slightly less obsolete) EBCDIC strings to > > > carry the data. TCP/IP transmits data neutral octets, > > > so binary values can be carried in their native binary > > > string format (allowing for a possible requirement to pad > > > strings to an octet boundary). The most standard way to > > > present those binary strings on a printer or as an input > > > value to a program is hexadecimal encoding. > > > > > > For those reasons, I agree with Bill that we should delete > > > base64 from the text and use hexadecimal as he suggests. > >=20 > > I must not have been totally clear. I'm not suggesting we=20 > > remove base64, > > I'm suggesting we limit its use to the cases where (IMHO) it=20 > > makes sense. > > While there will be much fewer cases in the text with the changes I > > suggest, it will still be in the spec. > >=20 > > Some of the cryptographic authentications throw around large binary > > strings. Quite large (compared to the numbers and strings we=20 > > often use) > > binary strings. The fact that if you support these modes of=20 > > authentication > > you are supposed to be able to accept four times as much=20 > text in login > > commands reflects the size of these strings. > >=20 > > Base64 is a real win for these. Hex can encode 4 bits per=20 > byte, while > > base64 can encode 6. Thus an n byte string will be about=20 > > 1.33*n bytes in > > base 64, while it will be 2n bytes in hex. That size=20 > > difference is why we > > want base64. > >=20 > > The main point I've been trying to make is that binary=20 > > strings and numbers > > are different things, and that encoding methods for one=20 > aren't really > > appropriate for the other. Specifics: decimal & hex work great for > > numbers, and hex and base64 work great for binary strings.=20 > That's it. > > Also, the hex for numbers isn't the same as the hex for=20 > > binary strings. > > One is the number in hex, the other is more like hexdump -x=20 > > without the > > spaces and without the offsets. > >=20 > > Take care, > >=20 > > Bill > >=20 > >=20 > >=20 >=20 ------_=_NextPart_001_01C201B5.429D6C2C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Julo,
 
Although it is more compact than hex which encodes 1/2 byte at = a time,=20 b64 encodes 3/4 of a byte at a time.  When encoding b64 strings, = one=20 normally processes three bytes at a time, low addressed byte = first.  When=20 encoding and decoding numbers on little endian to b64, perhaps the = process is=20 straight forward, but I am not sure.  I am sure it is extra = code=20 relative to hex for handling lengths not a multiple of 3 bytes.  If = any=20 implementation is allowed to send numbers in b64, then all must=20 have capability to accept them whenever parsing for a number.  = This is=20 a third redundant encoding for a = number.  We could operate=20 effectively with only one (hex).  The single code path = would be=20 well tested.  I expect several implementations (including my own)=20 to have flaws in their first attempt at b64 encoding or=20 decoding for numbers of arbitrary length.  I don't expect = anyone to=20 have flaws in their hexadecimal handling.
 
I have=20 seen discussion about not allowing excess leading zeroes.  This=20 defeats inferring the correct storage size of a number from its=20 encoding.  Outside of security, the sizes of numbers are already = fixed and=20 this is not a problem.  Within security, I am not sure this is = true. =20 (I am nothing like a security expert yet.)
 
Another confusion factor is numbers of arbitrary length.  = Without=20 knowing the format required internally by security algorithms which = use=20 these, I am not sure whether they will want big endian or little endian = format=20 on little endian hardware.  I hope they in fact want a b64 or = hex=20 representation in big endian a.k.a. network byte order (a = string) and=20 convert it to internal format themselves.  Suppose the algorithm = wants a=20 string in hex, but I receive a string in b64!  Whether these are = used=20 internally as numbers or strings is not relevant if they are always = delivered to the algorithms as strings.
 
Although I use decimal rather than hex today, I would = be willing to give it up for=20 simpler implementations.
 
If b64=20 is only used for security strings and the login process can treat them = as=20 strings and pass them to security algorithms as strings, = then whether the=20 string contains b64, hex, or decimal is transparent to parsing = during=20 login.  I see no reason to require an implementation to accept = b64 for=20 login operational parameters like MaxBurstSize.
 
Unlike=20 redundant encoding options in the spec, if my messages are redundant, = you are=20 free to ignore them ;-).
 
Thanks,
Nick
 
P.S.=20 Due to the spam filter, my recent posting did not reach the = list.  I=20 am working on it.
 
Nick=20 Martin
now=20 part of the new HP
 
-----Original Message-----
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, May 21, = 2002 7:05=20 PM
To: Martin, Nick (Server Storage)
Cc: = ips@ece.cmu.edu;=20 Robert Snively; Bill Studenmund
Subject: RE: iSCSI: BASE64 = and=20 numerical values


Nick,

I said = already that I=20 will say something about order in numbers - and that holds for hex or=20 b64
and that will be the = "normal"=20  high-endian encoding.
Why do you=20 consider hex and b64 to be  different?

Julo


"Martin, Nick (Server = Storage)"=20 <Nick.Martin@hp.com>=20

05/21/2002 11:11 PM =
Please respond to "Martin, Nick = (Server=20 Storage)"

        =
        To: =    =20    "Robert Snively" <rsnively@Brocade.COM>, = "Bill=20 Studenmund" <wrstuden@wasabisystems.com>, Julian=20 Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
        cc: =    =20    
  =  =20     Subject:        RE: iSCSI: = BASE64 and=20 numerical values

   =20    


Robert,

My comments are below.

> = -----Original=20 Message-----
> From: Robert Snively=20 [mailto:rsnively@Brocade.COM]
> Sent: Tuesday, May 21, 2002 1:44 = PM
> To: Bill Studenmund; Julian Satran; ips@ece.cmu.edu
> = Subject: RE: iSCSI: BASE64 and numerical values
>
> =
> I=20 guess that my point was that we should be transmitting the
> = binary=20 value, not the encoding of the binary value.
>
In the current = draft=20 and all those I saw preceding one can not transmit "raw binary" values = during=20 login phase.  To be transmitted within a Login, Login Response, = Text, or=20 Text Response PDU, the value must be formatted as a null terminated = string of=20 the form keyword=3Dvalue.  Further the set of characters which = may be used=20 is restricted as specified.

> Especially if you care about = the=20 length, that is the most
> compact version of = transmission.
>=20
Agreed this is the most compact, but not the most universal. =  As many=20 working in both big endian and little endian worlds can attest, a = number=20 conveyed in "binary" is not universally understood.

> You = are never=20 using them in the text-encoded format, so
> why transmit them in = a=20 text-encoded format.  The values are
> ALWAYS used only in = the=20 binary format.  TCP/IP does not
> have any requirement for = them to=20 ever be expressed in the
> text-encoded format.
>
We = need to=20 encode in some text format.  The rules for doing so need to be=20 agreed.
The distinction between binary strings and binary numbers = must be=20 clear.  Strings of any sort will be transmitted lowest addressed = byte=20 first.  Binary strings would be encoded into text strings lowest=20 addressed byte first.  Text encoding of numbers are always = transmitted=20 most significant digit (hex, decimal, or base64).  A conversion = between=20 native binary numeric representation and text implies native endian = awareness.=20  When dealing with binary values on the order of say 1024 bits, = one must=20 be aware of endian issues to encode, transmit, receive, encode and use = the=20 result correctly.  Is this value used as a string, or a number? =  If=20 a string, one will want to encode and transmit low addressed byte = first.=20  If binary one will want to encode and transmit the most = significant=20 "digit" first (either highest address or lowest address depending on = native=20 arithmetic byte order).

> If you need to input them, = describe them=20 for debug purposes, or
> print them to a screen, then put them = in=20 the
> format that is most natural for parsing to natural byte=20 and
> word boundaries, which is hexadecimal, but would be = outside=20 the
> scope of the iSCSI document anyway.
>
Decimal is = handy=20 for humans, but not indispensable for machine to machine.
I agree = with=20 others that hexadecimal is the simplest, and least ambiguous encoding. =
Still one needs to know whether a string or a binary value is = being=20 processed unless one is fortunate enough to only be concerned with = big-endian=20 (network byte order) hardware.

Prior use of Base64 was designed = explicitly for binary files which are effectively binary strings. It = will=20 encode, transmit, and decode lowest byte address first.

If the = intent=20 is to use base64 to transmit large binary numbers, it could be done, = but why=20 bother when hexadecimal is so straight forward?  
The big deal = with 4=20 bits, 6 bits, or 8 bits encoding is the loading, masking, shifting, = and=20 storing of the next bits from the correct location at the correct time = from 8=20 bits per byte addressable memory systems.  If the whole value = fits in one=20 arithmetic register at one time, no big deal.  However for larger = quantities, 4 bits (hexadecimal) and 8 bits (raw binary which is = prohibited)=20 are simple, 6 bits (base64) and 3.something bits (decimal) are=20 not.

Thanks,
Nick

> Bob
>
>
> = >=20 -----Original Message-----
> > From: Bill Studenmund=20 [mailto:wrstuden@wasabisystems.com]
> > Sent: Tuesday, May 21, 2002 9:28 AM
> > = To: Robert=20 Snively
> > Cc: Julian Satran; ips@ece.cmu.edu
> > = Subject:=20 RE: iSCSI: BASE64 and numerical values
> >
> > =
>=20 > On Tue, 21 May 2002, Robert Snively wrote:
> >
> = >=20 > I have been having continuing problems understanding why
> = >=20 > iSCSI is considering any use of base64, and I find myself
> = >=20 > in total agreement with Bill's clear exposition of the
> = > >=20 situation.
> > >
> > > Upon reviewing = RFC-2045, it is=20 clear that base64 is a method
> > > for containing handy = binary=20 values in a EMAIL structure that does
> > > not use TCP/IP = to=20 transmit data, but rather uses obsolete
> > > 7-bit ASCII = or=20 (slightly less obsolete) EBCDIC strings to
> > > carry the = data.=20  TCP/IP transmits data neutral octets,
> > > so = binary values=20 can be carried in their native binary
> > > string format=20 (allowing for a possible requirement to pad
> > > strings = to an=20 octet boundary).  The most standard way to
> > > = present=20 those binary strings on a printer or as an input
> > > = value to a=20 program is hexadecimal encoding.
> > >
> > > = For those=20 reasons, I agree with Bill that we should delete
> > > = base64 from=20 the text and use hexadecimal as he suggests.
> >
> = > I must=20 not have been totally clear. I'm not suggesting we
> > = remove=20 base64,
> > I'm suggesting we limit its use to the cases = where (IMHO)=20 it
> > makes sense.
> > While there will be much = fewer=20 cases in the text with the changes I
> > suggest, it will = still be in=20 the spec.
> >
> > Some of the cryptographic = authentications=20 throw around large binary
> > strings. Quite large (compared = to the=20 numbers and strings we
> > often use)
> > binary = strings.=20 The fact that if you support these modes of
> >=20 authentication
> > you are supposed to be able to accept four = times=20 as much
> text in login
> > commands reflects the size = of=20 these strings.
> >
> > Base64 is a real win for = these. Hex=20 can encode 4 bits per
> byte, while
> > base64 can = encode 6.=20 Thus an n byte string will be about
> > 1.33*n bytes = in
> >=20 base 64, while it will be 2n bytes in hex. That size
> > = difference=20 is why we
> > want base64.
> >
> > The = main point=20 I've been trying to make is that binary
> > strings and=20 numbers
> > are different things, and that encoding methods = for one=20
> aren't really
> > appropriate for the other. = Specifics:=20 decimal & hex work great for
> > numbers, and hex and = base64 work=20 great for binary strings.
> That's it.
> > Also, the = hex for=20 numbers isn't the same as the hex for
> > binary = strings.
>=20 > One is the number in hex, the other is more like hexdump -x =
> >=20 without the
> > spaces and without the offsets.
> > =
>=20 > Take care,
> >
> > Bill
> >
> = >=20
> >
>


------_=_NextPart_001_01C201B5.429D6C2C-- From owner-ips@ece.cmu.edu Wed May 22 15:01:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25524 for ; Wed, 22 May 2002 15:01:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MIXlK26132 for ips-outgoing; Wed, 22 May 2002 14:33:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4MIXgw26119 for ; Wed, 22 May 2002 14:33:42 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4MIXap22283 for ; Wed, 22 May 2002 14:33:36 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4MIXac22271; Wed, 22 May 2002 14:33:36 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g4MIXZQ06234; Wed, 22 May 2002 14:33:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15595.58503.167000.554576@gargle.gargle.HOWL> Date: Wed, 22 May 2002 14:33:43 -0400 From: Paul Koning To: Nick.Martin@hp.com Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu, rsnively@Brocade.COM, wrstuden@wasabisystems.com Subject: RE: iSCSI: BASE64 and numerical values References: <31891B757C09184BBFEC5275F85D5595104E84@cceexc18.americas.cpqcorp.net> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 22 May 2002) by Martin, Nick (Server Storage): > Julo, >... > I have seen discussion about not allowing excess leading zeroes. > This defeats inferring the correct storage size of a number from its > encoding. Outside of security, the sizes of numbers are already > fixed and this is not a problem. Within security, I am not sure > this is true. (I am nothing like a security expert yet.) If you're dealing with numbers, then leading zeroes don't matter because the value of a number is not changed when you slap leading zeroes onto its representation. For example, the basic Diffie-Hellman exchange would have that property. If you're also doing string operations, then you have to have a precise rule on which string representation you use. For example, SRP does D-H style operations, but also crypto hashes (which operate on strings, and care very much whether you put on a leading zero byte). So SRP spells out explicitly that when it talks about strings it means the big endian format with leading zeroes prohibited. > Another confusion factor is numbers of arbitrary length. Without > knowing the format required internally by security algorithms which > use these, I am not sure whether they will want big endian or little > endian format on little endian hardware. I hope they in fact want a > b64 or hex representation in big endian a.k.a. network byte order (a > string) and convert it to internal format themselves. Suppose the > algorithm wants a string in hex, but I receive a string in b64! > Whether these are used internally as numbers or strings is not > relevant if they are always delivered to the algorithms as strings. That's really an implementation detail. You may need to do transcoding when going from iSCSI login exchange to/from the format used by your crypto library. For example, suppose a hypothetical SRP implementation has an API that uses the octetstrings as defined by the RFC -- then you would have to encode/decode those to/from a form you can put in iSCSI exchanges. Hex and Base64 would both serve. You would have to be careful to preseve the exact length in bytes of the strings SRP is dealing with. > If b64 is only used for security strings and the login process can > treat them as strings and pass them to security algorithms as > strings, then whether the string contains b64, hex, or decimal is > transparent to parsing during login. I've seen Base64, hex strings, and raw octetstrings used in security libraries, so I'm not comfortable suggesting a single encoding in iSCSI on the theory that it can then be passed straight to whatever crypto libraries you might want to use. Instead, pick an encoding (or at most two) that are easily converted to/from octetstrings. That's clearly true for hex strings, and it seems to be true for Base64 as well. > I see no reason to require an > implementation to accept b64 for login operational parameters like > MaxBurstSize. I quite agree! paul From owner-ips@ece.cmu.edu Wed May 22 15:02:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25589 for ; Wed, 22 May 2002 15:02:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MIIPh24914 for ips-outgoing; Wed, 22 May 2002 14:18:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4MIIIw24907 for ; Wed, 22 May 2002 14:18:23 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4MIICp21923 for ; Wed, 22 May 2002 14:18:12 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4MIIBc21908; Wed, 22 May 2002 14:18:11 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g4MIIBl05170; Wed, 22 May 2002 14:18:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15595.57579.379000.542930@gargle.gargle.HOWL> Date: Wed, 22 May 2002 14:18:19 -0400 From: Paul Koning To: wrstuden@wasabisystems.com Cc: Nick.Martin@hp.com, Julian_Satran@il.ibm.com, ips@ece.cmu.edu, rsnively@Brocade.COM Subject: RE: iSCSI: BASE64 and numerical values References: <31891B757C09184BBFEC5275F85D5595104E84@cceexc18.americas.cpqcorp.net> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 22 May 2002) by Bill Studenmund: > Turns out CHAP needs strings, not numbers, so it is fine. I'm not sure > about SRP, but from what I can tell, all of the other security methods > will be exchanging (from iSCSI's point of view) binary strings. Correct for SRP. The RFC clearly states the mapping from numeric values (in the mathematical statement of the algorithm) to strings (in the protocol encodings); see pages 1-2. If we were doing DH or RSA, large numbers might show up, but that isn't currently an issue. (And of course an octetstring is a perfectly fine encoding for an integer, as soon as you specify the byte order.) paul From owner-ips@ece.cmu.edu Wed May 22 15:04:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25694 for ; Wed, 22 May 2002 15:04:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MIaWq26370 for ips-outgoing; Wed, 22 May 2002 14:36:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4MIaTw26364 for ; Wed, 22 May 2002 14:36:29 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4MIaN71009858; Wed, 22 May 2002 20:36:23 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4MIaMk93184; Wed, 22 May 2002 20:36:22 +0200 To: "Sankar, Ranga" Cc: "'ips@ece.cmu.edu'" , "Pittman, Joseph" MIME-Version: 1.0 Subject: RE: Flipped locations between d11 and d12. X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 22 May 2002 21:36:17 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 22/05/2002 21:36:22, Serialize complete at 22/05/2002 21:36:22 Content-Type: multipart/alternative; boundary="=_alternative 00646613C2256BC1_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00646613C2256BC1_= Content-Type: text/plain; charset="us-ascii" IETF rules - Julo "Sankar, Ranga" 05/22/2002 07:28 PM Please respond to "Sankar, Ranga" To: Julian Satran/Haifa/IBM@IBMIL cc: "'ips@ece.cmu.edu'" , "Pittman, Joseph" Subject: RE: Flipped locations between d11 and d12. The new notation is counter intuitive and causes confusion. If there is no specific reasoni would prefer it to be the way it was in earlier drafts (D11). -ranga > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, May 22, 2002 1:35 AM > To: Sankar, Ranga > Cc: 'ips@ece.cmu.edu'; Julian Satran > Subject: Re: Flipped locations between d11 and d12. > > > > It is no mistake. It is only that this new notation is the > one preferred by > the RFC editor. > > Julo > > > > > "Sankar, Ranga" > > "'ips@ece.cmu.edu'" > > app.com> cc: > Julian Satran/Haifa/IBM@IBMIL > > Subject: > Flipped locations between d11 and d12. > > 05/21/2002 10:54 > > PM > > Please respond to > > "Sankar, Ranga" > > > > > > > > > > Looks like the bit locations are flipped between Version 11 and 12. > > For example Bit 0 of Byte 1 corresponds to T bit in Version 12 > In Version 11 and below Bit 7 of Byte 1 corresponds to T bit. > > Is this intended or an error in the draft. > > Version 12 > > Login Response > Byte / 0 | 1 | 2 | 3 > | > |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| > <--------- > . . 0x23 > > Version 11 > Byte / 0 | 1 | 2 | 3 | / | | | | > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > <---------- > +---------------+---------------+---------------+---------------+ > 0|.|.| 0x23 |T|0 0 0|CSG|NSG| Version-max | > Version-active| > > -ranga > > > > --=_alternative 00646613C2256BC1_= Content-Type: text/html; charset="us-ascii"
IETF rules - Julo


"Sankar, Ranga" <ranga@netapp.com>

05/22/2002 07:28 PM
Please respond to "Sankar, Ranga"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>, "Pittman, Joseph" <jpittman@netapp.com>
        Subject:        RE: Flipped locations between d11 and d12.

       


The new notation is counter intuitive and causes confusion.
If there is no specific reasoni would prefer it to be the way it
was in earlier drafts (D11).

-ranga


> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Wednesday, May 22, 2002 1:35 AM
> To: Sankar, Ranga
> Cc: 'ips@ece.cmu.edu'; Julian Satran
> Subject: Re: Flipped locations between d11 and d12.
>
>
>
> It is no mistake. It is only that this new notation is the
> one preferred by
> the RFC editor.
>
> Julo
>
>
>                                                              
>                                                                    
>                       "Sankar, Ranga"                        
>                                                                    
>                       <Ranga.Sankar@net        To:      
> "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>                        
>          
>                       app.com>                 cc:      
> Julian Satran/Haifa/IBM@IBMIL                                
>          
>                                                Subject:  
> Flipped locations between d11 and d12.                        
>          
>                       05/21/2002 10:54                        
>                                                                    
>                       PM                                      
>                                                                    
>                       Please respond to                      
>                                                                    
>                       "Sankar, Ranga"                        
>                                                                    
>                                                              
>                                                                    
>                                                              
>                                                                    
>
>
>
>
> Looks like the bit locations are flipped between Version 11 and 12.
>
> For example  Bit 0 of Byte 1 corresponds to T bit in Version 12
> In Version 11 and below Bit 7 of Byte 1 corresponds to T bit.
>
> Is this intended or an error in the draft.
>
> Version 12
>
> Login Response
> Byte / 0           | 1                     | 2                     | 3
>              |
> |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
> <---------
>  . .       0x23
>
> Version 11
> Byte / 0 | 1 | 2 | 3 | / | | | |
> |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
> <----------
> +---------------+---------------+---------------+---------------+
> 0|.|.| 0x23              |T|0 0 0|CSG|NSG| Version-max |
> Version-active|
>
> -ranga
>
>
>
>


--=_alternative 00646613C2256BC1_=-- From owner-ips@ece.cmu.edu Wed May 22 15:45:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27601 for ; Wed, 22 May 2002 15:45:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MIxMl28150 for ips-outgoing; Wed, 22 May 2002 14:59:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13709.mail.yahoo.com (web13709.mail.yahoo.com [216.136.175.251]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4MIxJw28139 for ; Wed, 22 May 2002 14:59:19 -0400 (EDT) Message-ID: <20020522185918.39697.qmail@web13709.mail.yahoo.com> Received: from [192.52.58.5] by web13709.mail.yahoo.com via HTTP; Wed, 22 May 2002 11:59:18 PDT Date: Wed, 22 May 2002 11:59:18 -0700 (PDT) From: Martins Krikis Subject: RE: iSCSI: Login Request error To: ips@ece.cmu.edu In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C09CD04@axcs04.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Pat, Luben, I think we're fighting an uphill battle here... I've been complaining about some of the same things, and, as Luben said, nobody cared. I get the feeling that there is a bigger wish to get the draft "out" despite the ambiguities and problems in both the negotiation protocol and its description, than to change a single thing "this late". I think there is also an assumption (that I don't hold) that having choices in the negotiation protocol allows more freedom to implementations and thus simplifies them. Luben was asking whether EBNF would be used if submitted. I personally doubt it, since perfectly reasonable regular expressions were dropped. And there is probably little point asking the phylosophical questions. I still don't see the value of Irrelevant, allowing Reject-ed keys to be renegotiated, allowing not Reject-ing "inadmissible" values, allowing omission of boolean values, base64 for anything but binary strings, and many other "features". But I'll probably receive email telling me to "move on" just for mentioning this stuff here again... Or the best explanation will be "we talked about it here, but nobody objected too strongly". Anyway, I'm behind you in your efforts and looks like I should resume some of my own battles (no-renegotiation rule unclear). Good luck, Martins Krikis, Intel Corp. Disclaimer: these opinions are my own and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Wed May 22 15:46:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27625 for ; Wed, 22 May 2002 15:46:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MJ8Bb28778 for ips-outgoing; Wed, 22 May 2002 15:08:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13704.mail.yahoo.com (web13704.mail.yahoo.com [216.136.175.137]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4MJ88w28773 for ; Wed, 22 May 2002 15:08:08 -0400 (EDT) Message-ID: <20020522190807.59942.qmail@web13704.mail.yahoo.com> Received: from [192.52.58.5] by web13704.mail.yahoo.com via HTTP; Wed, 22 May 2002 12:08:07 PDT Date: Wed, 22 May 2002 12:08:07 -0700 (PDT) From: Martins Krikis Subject: RE: iSCSI: BASE64 and numerical values To: ips@ece.cmu.edu In-Reply-To: <3C7122FAF06DD5118ED6005004733648263247@esply01.cnt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Michael Schoberg wrote: > I personally don't see the problem with large > decimal, base64, or hex. It > seems like the algorithms to convert these back to > machine values are > relatively simple. They're far simpler than the > authentication and > encryption algorithms we're working with. Getting rid of encoding large numbers/binary-strings in decimal was a very good thing. Conversion from decimal to binary is simple but it is time and/or space consuming. I looked it up in Knuth last time when I saw the casual comment of it not being so. From what I understood, the simple algorithms all (both?) are O(n^2) time. If you want to do better than that, they get complicated fast and you start losing space (I think, mostly to store precomputed multiplication results and such). Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Wed May 22 15:51:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27966 for ; Wed, 22 May 2002 15:51:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MJYJK00863 for ips-outgoing; Wed, 22 May 2002 15:34:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4MJYIw00857 for ; Wed, 22 May 2002 15:34:18 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 74B3510DC3; Wed, 22 May 2002 13:34:17 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 52CD22C6; Wed, 22 May 2002 13:34:17 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 22 May 2002 13:34:16 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 13:34:16 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09CD7C@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Martins Krikis , ips@ece.cmu.edu Subject: RE: MaxRecvPDULength question Date: Wed, 22 May 2002 13:34:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Martins, If we are going to rename it, the name should be accurate and clear. I don't think MaxRecvDataLength is clear because there are lots of data lengths involved in the draft. Also, some of the parameters use length and some use size. MaxRecvDataSegmentSize or MaxRecvPDUDataSize would be clear, consistant with other names and accurate. I don't feel strongly about changing the name to improve it but removing the context for which data length is being negotiated would reduce accuracy/clarity of the name. Regards, Pat -----Original Message----- From: Martins Krikis [mailto:mkrikis@yahoo.com] Sent: Wednesday, May 22, 2002 12:20 PM To: ips@ece.cmu.edu Subject: Re: MaxRecvPDULength question --- Paul Koning wrote: > Are you proposing to rename the key so its name is > "MaxRecvDataLength"? Yes, that would be more > accurate, but why bother > at this point? Because it would be more accurate! I personally don't mind changes in the draft that make it clearer but require me to change one string constant. Martins Krikis, Intel Corp. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Wed May 22 16:43:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27603 for ; Wed, 22 May 2002 15:45:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MJJfW29603 for ips-outgoing; Wed, 22 May 2002 15:19:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13709.mail.yahoo.com (web13709.mail.yahoo.com [216.136.175.251]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4MJJdw29598 for ; Wed, 22 May 2002 15:19:39 -0400 (EDT) Message-ID: <20020522191938.42566.qmail@web13709.mail.yahoo.com> Received: from [192.52.58.5] by web13709.mail.yahoo.com via HTTP; Wed, 22 May 2002 12:19:38 PDT Date: Wed, 22 May 2002 12:19:38 -0700 (PDT) From: Martins Krikis Subject: Re: MaxRecvPDULength question To: ips@ece.cmu.edu In-Reply-To: <15594.38850.500000.911226@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Paul Koning wrote: > Are you proposing to rename the key so its name is > "MaxRecvDataLength"? Yes, that would be more > accurate, but why bother > at this point? Because it would be more accurate! I personally don't mind changes in the draft that make it clearer but require me to change one string constant. Martins Krikis, Intel Corp. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Wed May 22 17:18:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01815 for ; Wed, 22 May 2002 17:18:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MKV4K05501 for ips-outgoing; Wed, 22 May 2002 16:31:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4MKV3w05497 for ; Wed, 22 May 2002 16:31:03 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 16:29:04 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937915@CORPMX14> From: Black_David@emc.com To: BIRAN@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution Date: Wed, 22 May 2002 16:28:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Responding to Ofer's concerns, let me know if I get any of the paraphrasing wrong. [Ofer Biran 1]: Since requirements for what to do when secrets weaker than 96 bits of randomness are used, is the SHOULD for 96+ bits of necessary? Good question. It'll help when an external RADIUS server is used to verify CHAP authentication. It also scopes the "MUST use ESP" requirement to apply only when the SHOULD is ignored. [Ofer Biran 2]: Mutual authentication is being introduced as a SHOULD requirement very late in the process. The requirement should be removed; mutual authentication should remain OPTIONAL. I believer Ofer is correct about this. I believe the important aspect is to be sure to include Paul Koning's example and associated text about how to prevent reflection attacks on CHAP if/when it used for mutual authentication. In the absence of strong interest in imposing this requirement, I think we should return to the previous situation. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed May 22 17:19:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01888 for ; Wed, 22 May 2002 17:19:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MKbhH06012 for ips-outgoing; Wed, 22 May 2002 16:37:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4MKbfw06004 for ; Wed, 22 May 2002 16:37:41 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4MKbWX13335; Wed, 22 May 2002 16:37:32 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g4MKbV709846; Wed, 22 May 2002 16:37:31 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 16:36:18 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937916@CORPMX14> From: Black_David@emc.com To: ni1d@arrl.net Cc: ips@ece.cmu.edu Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution Date: Wed, 22 May 2002 16:36:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-PerlMx-Spam: Gauge=XIIIIII, Probability=16%, Report="NO_REAL_NAME" Sender: owner-ips@ece.cmu.edu Precedence: bulk Responding to Paul Koning's concerns: [Paul Koning 1]: 96 bits of entropy requirement is not testable, and should be removed for that reason, ditto the dependence of the "MUST use ESP" and related requirements on this level of entropy. In practice, many cryptographic protocols depend on high entropy; both IKE and SRP almost certainly break in some ways if their nonces aren't random. I agree that there's no good way to test the entropy of a generator of randomness, but I believe we need some way to discriminate between weak and strong CHAP secrets in the requirements language, as the alternatives to not doing this may include "SHOULD use" or "MUST use" ESP encryption with CHAP in all cases, which I suspect folks will find far less palatable. Also, we have this issue elsewhere in that inadequate entropy in their nonces almost certainly breaks IKE, SRP, and Kerberos in various ways. [Paul Koning 2]: A "MUST use" for ESP with weak CHAP secrets should be avoided. Part of the motivation for this is definitely to provide an incentive to use strong secrets with CHAP. Given that the "MUST use" applies only when a SHOULD is ignored, I don't think it's that objectionable, and there was an example of a similar "MUST use" involving SIP mentioned on the call whose details I don't have to hand. In essence, the position being taken here is that CHAP with a weak secret (e.g., password) is sufficiently weak that one shouldn't fool oneself into thinking that it provides any real protection unless something else (ESP encryption) is done. That would be a fair topic for discussion. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed May 22 17:19:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01931 for ; Wed, 22 May 2002 17:19:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MKpOH07079 for ips-outgoing; Wed, 22 May 2002 16:51:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4MKpNw07075 for ; Wed, 22 May 2002 16:51:23 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4MKpEo08020; Wed, 22 May 2002 16:51:14 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g4MKpE712018; Wed, 22 May 2002 16:51:14 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 16:50:00 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937919@CORPMX14> From: Black_David@emc.com To: mmerhar@pirus.com, ips@ece.cmu.edu Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution Date: Wed, 22 May 2002 16:49:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-PerlMx-Spam: Gauge=XIIIIII, Probability=16%, Report="NO_REAL_NAME" Sender: owner-ips@ece.cmu.edu Precedence: bulk Responding to Milan's concern, let me know if I get any of the paraphrasing wrong: [Milan Merhar]: It looks like the requirement for ESP to protect a CHAP exchange with a weak secret requires the entire resulting iSCSI session to be encrypted and use ESP integrity. Close enough; I think it's just that connection and only integrity. The encryption can probably be removed by negotiating a new SA that doesn't encrypt and deleting the old one, but that still requires ESP integrity. Just deleting the SA doesn't work reliably because it could easily result in black-holing packets. IKE has no way to check whether the other side will accept unprotected packets for this TCP connection, and if it won't, then deletion of the SA results in the packets being discarded. I think this consequence is in the category of "ignoring a SHOULD can have severe consequences". There are doubtless ways to avoid these consequences via discovery info handed out by SLP and/or iSNS, but I can't see modifying those protocols to help out implementers who ignore a SHOULD. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed May 22 17:20:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01991 for ; Wed, 22 May 2002 17:19:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MKpJ107071 for ips-outgoing; Wed, 22 May 2002 16:51:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13703.mail.yahoo.com (web13703.mail.yahoo.com [216.136.175.136]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4MKpHw07064 for ; Wed, 22 May 2002 16:51:17 -0400 (EDT) Message-ID: <20020522205116.96127.qmail@web13703.mail.yahoo.com> Received: from [192.52.58.5] by web13703.mail.yahoo.com via HTTP; Wed, 22 May 2002 13:51:16 PDT Date: Wed, 22 May 2002 13:51:16 -0700 (PDT) From: Martins Krikis Subject: iSCSI: No-renegotiation rule inadequately described To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Before I start, a philosophical question: What is the point of allowing Reject-ed keys to be renegotiated? Now the problem. http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09733.html claims that that it is OK to renegotiate keys that have been answered with the reserved value "Reject". I don't see where this would be mentioned in the draft. What I see is this (page 73, very top): Neither the initiator nor the target should attempt to negotiate a parameter more than once during login. Similar sentence on page 79, very bottom. If we now imagine the following scenario: I -> T: ImmediateData=junk1 T -> I: ImmediateData=Reject I -> T: ImmediateData=junk2 Doesn't it look like Initiator is _attempting_ to negotiate this parameter again? Thus, the spec the way I read it disallows this (and I like it), however the above link claims otherwise. So, which way is it? If it is allowed, then the draft should say so, and it should also say whether keys answered with Irrelevant may be renegotiated. I presume keys answered with NotUnderstood may too, although I'm not planning to even notice such an event. Thanks, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Wed May 22 17:32:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02902 for ; Wed, 22 May 2002 17:32:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MLG6C08927 for ips-outgoing; Wed, 22 May 2002 17:16:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4MLG4w08920 for ; Wed, 22 May 2002 17:16:04 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 17:15:59 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293791B@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI inband negotiation - possible change? Date: Wed, 22 May 2002 17:14:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk In reading over the initial responses to the proposed resolution, I see multiple concerns about the "MUST use" requirements for ESP encryption in the case that the "SHOULD" for sufficient entropy/randomness in CHAP secrets is ignored. Part of the intent of the "MUST use" was to put some serious teeth into the "SHOULD". Would people prefer an alternative in which sufficient entropy/randomness in CHAP secrets is a "MUST" and the "MUST use" ESP encryption requirement is removed, as there's no point in discussing what to do when a "MUST" is ignored? Caveat: I don't know if this'll pass muster with the ADs/IESG, but want to gauge interest in it before inquiring. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed May 22 17:34:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02970 for ; Wed, 22 May 2002 17:34:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4ML88908349 for ips-outgoing; Wed, 22 May 2002 17:08:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4ML85w08334 for ; Wed, 22 May 2002 17:08:05 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 17:06:46 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293791A@CORPMX14> From: Black_David@emc.com To: hufferd@us.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution Date: Wed, 22 May 2002 17:06:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk John, > The problem I am having with the proposal is, that I think we are mandating > customer actions not just implementation. To some extent, this is unavoidable, and we're already there implicitly, as use of a low-entropy pre-shared key with IKE will doubtless make IKE vulnerable in all sorts of undesirable ways. For that matter, even SRP is only secure if the customer uses it correctly (e.g., if Alice doesn't keep her password secret, and Bob knows it, SRP will not protect Alice from Bob). > We are saying that if Chap passwords are used then they must > do or must not do something else which is legal with IPsec. > > Since the IPsec process is really disjoint from the iSCSI Login, there is > no real way that we can tell what the customer did with IPsec, and IKE. I don't think so. One can expect an IPsec implementation to report the security policy and mechanisms (contents of the SPD, and probably the SAD) that it is currently enforcing through a suitably secured management interface. How to get access to and use that interface would be up to the implementer combining IPsec and iSCSI. > So some how I think the wordage needs to be adjusted to reflect this > implementation vrs customer interaction, since I think the only thing we > can do is document on the packaging/directions, what should or should not > be done. Please propose new wording. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed May 22 18:01:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04094 for ; Wed, 22 May 2002 18:01:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MLbSi10397 for ips-outgoing; Wed, 22 May 2002 17:37:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13702.mail.yahoo.com (web13702.mail.yahoo.com [216.136.175.135]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4MLbOw10386 for ; Wed, 22 May 2002 17:37:24 -0400 (EDT) Message-ID: <20020522213724.65710.qmail@web13702.mail.yahoo.com> Received: from [192.52.58.5] by web13702.mail.yahoo.com via HTTP; Wed, 22 May 2002 14:37:24 PDT Date: Wed, 22 May 2002 14:37:24 -0700 (PDT) From: Martins Krikis Subject: iSCSI: list negotiation description To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk First a question again: What is the point of allowing "inadmissible values" (or in case of lists, lack of acceptable values) be answered with an "admissible value"? Now the problems. Page 69, bottom paragraph: If a responder does support, understand or is allowed to use none of the offered options with a specific originator, it MAY use the constant "Reject" or it MAY respond with an admissible value. The selection of a value not offered is considered a negotiation failure and is handled as a protocol error. http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10066.html made me believe that the phrase "or it MAY respond with an admissible value..." will be removed. Since it hasn't been, I'll point out again that it contradicts the very next sentence, because this "admissible value" would be a "value not offered". Also, I must say that I almost regret having started picking on the beginning of this paragraph, because IMHO it has gotten worse. I'm still proposing this: If each of the offered values is not understood or not supported, or the responder is not allowed to use it with the specific originator, it MUST use the constant "Reject". Note that because other reasonable alternatives are eliminated, the original "MAY" can change to "MUST". (Which should be a good thing, BTW.) Thanks, Martins Krikis, Intel Corp. Disclaimer: these opinions are my own and may not not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Wed May 22 18:01:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04110 for ; Wed, 22 May 2002 18:01:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MLWxO10097 for ips-outgoing; Wed, 22 May 2002 17:32:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4MLWtw10084 for ; Wed, 22 May 2002 17:32:55 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4MLWnp27272 for ; Wed, 22 May 2002 17:32:49 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4MLWnc27263; Wed, 22 May 2002 17:32:49 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g4MLWm716620; Wed, 22 May 2002 17:32:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15596.3720.630000.310472@gargle.gargle.HOWL> Date: Wed, 22 May 2002 17:32:56 -0400 From: Paul Koning To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution References: <277DD60FB639D511AC0400B0D068B71E02937916@CORPMX14> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 22 May 2002) by Black_David@emc.com: > Responding to Paul Koning's concerns: > > [Paul Koning 1]: 96 bits of entropy requirement is not testable, and > should be removed for that reason, ditto the dependence of the > "MUST use ESP" and related requirements on this level of entropy. > > In practice, many cryptographic protocols depend on high entropy; > both IKE and SRP almost certainly break in some ways if their nonces > aren't random. That is not true. What happens if the nonces are poor is that the resulting protocol may be vulnerable to certain attacks. But it does not "break" the protocol; the protocol will very definitely produce a valid outcome even if the nonces are not as strong as they ought to be. There may be some elements in a protocol where certain values should be avoided, for example the value 0 for a or b in D-H is probably not a good value. But that's a different issue. > [Paul Koning 2]: A "MUST use" for ESP with weak CHAP secrets should > be avoided. > > Part of the motivation for this is definitely to provide an incentive > to use strong secrets with CHAP. Given that the "MUST use" applies only > when a SHOULD is ignored, I don't think it's that objectionable, and > there was an example of a similar "MUST use" involving SIP mentioned > on the call whose details I don't have to hand. In essence, the position > being taken here is that CHAP with a weak secret (e.g., password) is > sufficiently weak that one shouldn't fool oneself into thinking that > it provides any real protection unless something else (ESP encryption) > is done. That would be a fair topic for discussion. I do NOT find that an acceptable position. Whether a certain combination of mechanisms provides sufficient protection is something for the customer to decide, NOT the standard. I have no objection against giving information, guidance, or warnings, to aid in that decision making process. But a requirement that says "you must use IPsec whether it has any value in your installation or not" is not acceptable. Part of the issue here is that IPsec is expensive, both in implementation resources and in management complexity. So the mandate isn't just a minor annoyance, it has very substantial impact. Apart from that, as I pointed out, the proposed requirement is not testable, so what good is it? If there is no way to tell whether a particular implementation conforms to this proposed requirement or not, then clearly the requirement is not useful. (Perhaps that means I should just shut up, since the proposed text wouldn't affect my implementation anyway... but from a point of view of standards quality I don't want to let untestable "requirements" go unchallenged.) paul From owner-ips@ece.cmu.edu Wed May 22 18:37:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05631 for ; Wed, 22 May 2002 18:37:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MM1jh11871 for ips-outgoing; Wed, 22 May 2002 18:01:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4MM1gw11861 for ; Wed, 22 May 2002 18:01:42 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 5B3B430706; Wed, 22 May 2002 18:01:42 -0400 (EDT) Date: Wed, 22 May 2002 14:59:46 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Martins Krikis Cc: Subject: RE: iSCSI: Login Request error In-Reply-To: <20020522185918.39697.qmail@web13709.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 22 May 2002, Martins Krikis wrote: > Pat, Luben, > > I think we're fighting an uphill battle here... > > I've been complaining about some of the same > things, and, as Luben said, nobody cared. I get > the feeling that there is a bigger wish to get the > draft "out" despite the ambiguities and problems in > both the negotiation protocol and its description, > than to change a single thing "this late". I hope there isn't. If we let out a sucky protocol, we're stuck with it. > I think there is also an assumption (that I don't > hold) that having choices in the negotiation > protocol allows more freedom to implementations > and thus simplifies them. I agree with you; let's make things explicit. It does make things easier. :-) > Luben was asking whether EBNF would be used > if submitted. I personally doubt it, since > perfectly reasonable regular expressions were > dropped. > > And there is probably little point asking the > phylosophical questions. I still don't see the > value of Irrelevant, allowing Reject-ed keys > to be renegotiated, allowing not Reject-ing > "inadmissible" values, allowing omission of > boolean values, base64 for anything but binary > strings, and many other "features". But I'll > probably receive email telling me to "move on" > just for mentioning this stuff here again... Well, I'm not trying to tell you to move on. :-) We agree about base64 - it's great for binary strings, but not numbers. I'm not sure about renegotiating REJECTED keys. I think it'd depend on what the likely reasons for rejection are, and how likely they will be different the second time. I guess irrelevant makes sense for things like negotiating marker spacing when you don't support markers. > Or the best explanation will be "we talked about > it here, but nobody objected too strongly". > > Anyway, I'm behind you in your efforts and looks > like I should resume some of my own battles > (no-renegotiation rule unclear). :-) Take care, Bill From owner-ips@ece.cmu.edu Wed May 22 18:39:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05702 for ; Wed, 22 May 2002 18:39:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MMCTU12511 for ips-outgoing; Wed, 22 May 2002 18:12:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4MMCRw12507 for ; Wed, 22 May 2002 18:12:27 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 18:11:08 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937921@CORPMX14> From: Black_David@emc.com To: ni1d@arrl.net Cc: ips@ece.cmu.edu Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution Date: Wed, 22 May 2002 18:11:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > > [Paul Koning 1]: 96 bits of entropy requirement is not testable, and > > should be removed for that reason, ditto the dependence of the > > "MUST use ESP" and related requirements on this level of entropy. > > > > In practice, many cryptographic protocols depend on high entropy; > > both IKE and SRP almost certainly break in some ways if their nonces > > aren't random. > > That is not true. > > What happens if the nonces are poor is that the resulting protocol may > be vulnerable to certain attacks. But it does not "break" the > protocol; the protocol will very definitely produce a valid outcome > even if the nonces are not as strong as they ought to be. Paul and I are in violent agreement, and I've been caught using sloppy language. The security properties of protocols that use nonces depend on the randomness of the nonces, and hence using nonces with insufficient randomness can create security vulnerabilities in those protocols. In the extreme case where the attacker knows the nonces, I would suggest that some of these protocols are so vulnerable as to be broken - not that they won't work, but in the sense that they don't provide the expected security. The fact that the requirement for randomness is untestable doesn't make it unimportant. [... snip ...] > > In essence, the position > > being taken here is that CHAP with a weak secret (e.g., password) is > > sufficiently weak that one shouldn't fool oneself into thinking that > > it provides any real protection unless something else (ESP encryption) > > is done. That would be a fair topic for discussion. > > I do NOT find that an acceptable position. > > Whether a certain combination of mechanisms provides sufficient > protection is something for the customer to decide, NOT the standard. > I have no objection against giving information, guidance, or warnings, > to aid in that decision making process. But a requirement that says > "you must use IPsec whether it has any value in your installation or > not" is not acceptable. I understand Paul's point, but I think it's overstated - the "MUST" applies only when the customer chooses (1) to use CHAP authentication and (2) ignores the "SHOULD" for strong secrets and uses weak ones. If the resulting "MUST use" is unacceptable, perhaps the customer should go back and revisit those choices (especially the latter) to understand their consequences and the consequences of making alternative choices. I also want to caution that Paul's "whether it has any value in your installation or not" point is a matter of degree, not a hard-and-fast principle. For example, current IETF policy does not allow new standards-track protocols to use clear-text passwords even though there are installations in which those provide adequate security, and does not entertain standardization of protocols that don't have adequate security measures for use on the public Internet. OTOH, these these sorts of policies are usually reflected in "MUST implement" requirements, so I do understand and acknowledge Paul's concern with the "MUST use" language for IPsec - please see a separate message from me asking about a possible alternative. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed May 22 19:43:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08319 for ; Wed, 22 May 2002 19:43:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MN0iA15080 for ips-outgoing; Wed, 22 May 2002 19:00:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4MN0gw15074 for ; Wed, 22 May 2002 19:00:42 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id DE99A30706; Wed, 22 May 2002 19:00:41 -0400 (EDT) Date: Wed, 22 May 2002 15:58:45 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: , Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution In-Reply-To: <277DD60FB639D511AC0400B0D068B71E02937919@CORPMX14> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 22 May 2002 Black_David@emc.com wrote: > Responding to Milan's concern, let me know if I get any of the > paraphrasing wrong: > > [Milan Merhar]: It looks like the requirement for ESP to protect a CHAP > exchange with a weak secret requires the entire resulting iSCSI > session to be encrypted and use ESP integrity. > > Close enough; I think it's just that connection and only integrity. > The encryption can probably be removed by negotiating a new SA that > doesn't encrypt and deleting the old one, but that still requires > ESP integrity. Just deleting the SA doesn't work reliably because > it could easily result in black-holing packets. IKE has no way to > check whether the other side will accept unprotected packets for > this TCP connection, and if it won't, then deletion of the SA > results in the packets being discarded. Could we have a more complete example of this (SA changing in mid-stride)? From talking with some IPsec implementers, it can be done. We just will need to note a number of details to make sure we have it right. One thing that will be needed is for us to be able to set policy on a per-socket basis, and for us to be able to examine the policy in place on a socket. That way a target can verify that a login is covered by sufficiently-secure policy, and the initiator (and target) can adjust policy (to relax it). There is of course the question of what to do if the other side doesn't want to relax policy. :-) A few other implementation notes. 1) some IPsec implementations will continue using an older SA (the with-privacy one) for a while. 2) we need to have the initiator make sure it's using strong policy when it does the CHAP phase - otherwise if it is logging back into a target and happens to use a port number that it used before, the old (weaker) SA might still be there. I would prefer the key randomness be a MUST, so we can avoid this. While rather doable, it will add more to the implementation complexity. Take care, Bill From owner-ips@ece.cmu.edu Wed May 22 20:38:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10398 for ; Wed, 22 May 2002 20:38:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4N0NvQ19216 for ips-outgoing; Wed, 22 May 2002 20:23:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13705.mail.yahoo.com (web13705.mail.yahoo.com [216.136.175.138]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4N0Ntw19211 for ; Wed, 22 May 2002 20:23:55 -0400 (EDT) Message-ID: <20020523002354.12668.qmail@web13705.mail.yahoo.com> Received: from [192.52.58.5] by web13705.mail.yahoo.com via HTTP; Wed, 22 May 2002 17:23:54 PDT Date: Wed, 22 May 2002 17:23:54 -0700 (PDT) From: Martins Krikis Subject: RE: iSCSI: No-renegotiation rule inadequately described To: ips@ece.cmu.edu In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C09CDDD@axcs04.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- pat_thaler@agilent.com wrote: > The problem is there are two ways of > interpreting the state of the negotiation > after ImmediateData=Reject. > > A) The offered value was rejected so the > negotiation isn't done yet. In this view > the second offer is a continuation of the > first negotiation rather than a new > negotation. Good point. But I don't think this view quite fits together with, e.g., page 69: Reject or Irrelevant are legitimate negotiation options... In my opinion (and implementation) it also complicates the decision about whether this value is precluding me from announcing readiness to commit or it isn't. It's harder to view it negotiated for commit purposes and non-negotiated for repeated reception purposes than it is to just view it the same way... > B) A negotiation is always one offer and one > response regardless of whether the response > indicates successful negotiation or not. > > Text should be added to the draft to indicate > which is intended. > > I agree that it should state which is intended. > My preference would be that it take the simpler > view in B. I'm very much for it. > For Booleans and numerical values, > if the first offer caused a reject, > there is something broken. For lists the originator > can include all acceptable responses in the initial > offer. In either case, there isn't much point in > offering again. This is exactly what I was planning to say once somebody gave me a reason about the necessity to renegotiate. > If the response was NotUnderstood > then there isn't any point in offering the key again > (though I also think it is unreasonable to expect > the > responder to keep a list of NotUnderstood keys so > that > it can detect attempts to renegotiate). Exactly. > Irrelevant indicates that a problem such as key > negotiation being done in the wrong order (e.g. > attempting to negotiation IFMarkInt before > IFMarker). > There is no reason this should happen so we don't > need to allow the negotiation to continue in this > case either. First, there are no dependencies (even for markers, keys can be viewed as independent), so in my opinion this cannot happen. But even if it could happen, the earlier-negotiated key that caused the later-negotiated key to be answered with Irrelevant, is not going away, so there is no point repeating the later key---it will still be answered with Irrelevant! There is also no point to negotiate it from the other side, as that would then be the side who first called it Irrelevant. Once irrelevant is always (through the life of negotiation sequence) irrelevant, so no need to renegotiate it. > I suggest adding to 4.2 after "Reject or Irrelevant > are legitimate...." > "A negotiation is considered complete when the > responder has sent the key value pair even if the > value > is "Reject", "Irrelevant", or "NotUnderstood". > Sending > the key again would be a re-negotiation." This would be truly beatiful. Can it please happen? Thanks, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Wed May 22 20:38:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10410 for ; Wed, 22 May 2002 20:38:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4MNtfV17755 for ips-outgoing; Wed, 22 May 2002 19:55:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13709.mail.yahoo.com (web13709.mail.yahoo.com [216.136.175.251]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4MNtcw17750 for ; Wed, 22 May 2002 19:55:38 -0400 (EDT) Message-ID: <20020522235537.74974.qmail@web13709.mail.yahoo.com> Received: from [192.52.58.5] by web13709.mail.yahoo.com via HTTP; Wed, 22 May 2002 16:55:37 PDT Date: Wed, 22 May 2002 16:55:37 -0700 (PDT) From: Martins Krikis Subject: RE: iSCSI: Login Request error To: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Bill Studenmund wrote: > I'm not sure about renegotiating REJECTED keys. I > think it'd depend on > what the likely reasons for rejection are, and how > likely they will be > different the second time. Aha! :-) (Pat has actually already described almost word by word what I was planning to say about any reasons given, but I'll do the same anyway...) So we have to look at what the reasons could be. Junk value on binary key? Why was it sent in the first place? Inadmissible numerical value, string literal, or range sent? Again, why should the responder cut any slack to such initiators and let them try again? A list sent consisting of values that are not agreeable to the responder? If there are more values that the originator could offer, why weren't they included in the first request? The only understandable reason I can imagine is for trying out numeric ranges, one after another in the order of preference. But if this is the reason for allowing renegotiations, then we'd be better off introducing lists of ranges, a thing that has been discussed here, but was decided as yet unnecessary. So this could not be the reason. There is a somewhat risky use for sending a junk value however---it can simply be used to let the other side pick something w/o restrictions. But there is no guarantee that the other side will not Reject it and consider the whole negotiation sequence failed with that (which in my understanding (and I could dig up the relevant messages on the list) is also a valid behavior). > I guess irrelevant makes sense for things like > negotiating marker spacing > when you don't support markers. But we don't have any dependencies between parameters anymore, and that includes the marker-related keys. It is quite possible to view them as independent. It is alright to negotiate the marker interval but not turn on the use of markers. (By using 0 as a special interval value, we could also eliminate the boolean marker keys, but that's unimportant). Anyway, thanks for keeping the discussion up! Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Wed May 22 20:40:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10469 for ; Wed, 22 May 2002 20:40:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4N0Ktc19063 for ips-outgoing; Wed, 22 May 2002 20:20:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4N0Krw19058 for ; Wed, 22 May 2002 20:20:53 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4N0KqWo026738 for ; Wed, 22 May 2002 20:20:52 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4N0KpJ112088 for ; Wed, 22 May 2002 18:20:51 -0600 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: Old words left around To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Wed, 22 May 2002 17:19:06 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/22/2002 06:20:51 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, I think I may have found some old words left around from earlier times. Top of 178, we say "...the restart option of the Login should be used." We should just delete the sentence, since we just explained how to do it, two sentences above that. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Wed May 22 20:57:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11123 for ; Wed, 22 May 2002 20:57:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4N0dbw20013 for ips-outgoing; Wed, 22 May 2002 20:39:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4N0dZw20007 for ; Wed, 22 May 2002 20:39:35 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4N0dYFD135412; Wed, 22 May 2002 20:39:34 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4N0dYK238714; Wed, 22 May 2002 18:39:34 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: No-renegotiation rule inadequately described To: Martins Krikis Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Wed, 22 May 2002 17:37:24 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/22/2002 06:39:33 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk OK, this has been going around and around. But I hope the attached last note tied it up. Julian, can we use the conclusion in this attached note? > I suggest adding to 4.2 after "Reject or Irrelevant > are legitimate...." > "A negotiation is considered complete when the > responder has sent the key value pair even if the > value > is "Reject", "Irrelevant", or "NotUnderstood". > Sending > the key again would be a re-negotiation." . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Martins Krikis @ece.cmu.edu on 05/22/2002 05:23:54 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iSCSI: No-renegotiation rule inadequately described --- pat_thaler@agilent.com wrote: > The problem is there are two ways of > interpreting the state of the negotiation > after ImmediateData=Reject. > > A) The offered value was rejected so the > negotiation isn't done yet. In this view > the second offer is a continuation of the > first negotiation rather than a new > negotation. Good point. But I don't think this view quite fits together with, e.g., page 69: Reject or Irrelevant are legitimate negotiation options... In my opinion (and implementation) it also complicates the decision about whether this value is precluding me from announcing readiness to commit or it isn't. It's harder to view it negotiated for commit purposes and non-negotiated for repeated reception purposes than it is to just view it the same way... > B) A negotiation is always one offer and one > response regardless of whether the response > indicates successful negotiation or not. > > Text should be added to the draft to indicate > which is intended. > > I agree that it should state which is intended. > My preference would be that it take the simpler > view in B. I'm very much for it. > For Booleans and numerical values, > if the first offer caused a reject, > there is something broken. For lists the originator > can include all acceptable responses in the initial > offer. In either case, there isn't much point in > offering again. This is exactly what I was planning to say once somebody gave me a reason about the necessity to renegotiate. > If the response was NotUnderstood > then there isn't any point in offering the key again > (though I also think it is unreasonable to expect > the > responder to keep a list of NotUnderstood keys so > that > it can detect attempts to renegotiate). Exactly. > Irrelevant indicates that a problem such as key > negotiation being done in the wrong order (e.g. > attempting to negotiation IFMarkInt before > IFMarker). > There is no reason this should happen so we don't > need to allow the negotiation to continue in this > case either. First, there are no dependencies (even for markers, keys can be viewed as independent), so in my opinion this cannot happen. But even if it could happen, the earlier-negotiated key that caused the later-negotiated key to be answered with Irrelevant, is not going away, so there is no point repeating the later key---it will still be answered with Irrelevant! There is also no point to negotiate it from the other side, as that would then be the side who first called it Irrelevant. Once irrelevant is always (through the life of negotiation sequence) irrelevant, so no need to renegotiate it. > I suggest adding to 4.2 after "Reject or Irrelevant > are legitimate...." > "A negotiation is considered complete when the > responder has sent the key value pair even if the > value > is "Reject", "Irrelevant", or "NotUnderstood". > Sending > the key again would be a re-negotiation." This would be truly beatiful. Can it please happen? Thanks, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Wed May 22 21:03:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11337 for ; Wed, 22 May 2002 21:03:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4N0ULd19556 for ips-outgoing; Wed, 22 May 2002 20:30:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4N0UKw19552 for ; Wed, 22 May 2002 20:30:20 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4N0UJFD051188; Wed, 22 May 2002 20:30:19 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4N0UJK181412; Wed, 22 May 2002 18:30:19 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution To: Black_David@emc.com Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Wed, 22 May 2002 17:28:34 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/22/2002 06:30:18 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, Do you also mean that we can tell if a group preshared key was used? How do we do that? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Black_David@emc.com@ece.cmu.edu on 05/22/2002 02:06:37 PM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution John, > The problem I am having with the proposal is, that I think we are mandating > customer actions not just implementation. To some extent, this is unavoidable, and we're already there implicitly, as use of a low-entropy pre-shared key with IKE will doubtless make IKE vulnerable in all sorts of undesirable ways. For that matter, even SRP is only secure if the customer uses it correctly (e.g., if Alice doesn't keep her password secret, and Bob knows it, SRP will not protect Alice from Bob). > We are saying that if Chap passwords are used then they must > do or must not do something else which is legal with IPsec. > > Since the IPsec process is really disjoint from the iSCSI Login, there is > no real way that we can tell what the customer did with IPsec, and IKE. I don't think so. One can expect an IPsec implementation to report the security policy and mechanisms (contents of the SPD, and probably the SAD) that it is currently enforcing through a suitably secured management interface. How to get access to and use that interface would be up to the implementer combining IPsec and iSCSI. > So some how I think the wordage needs to be adjusted to reflect this > implementation vrs customer interaction, since I think the only thing we > can do is document on the packaging/directions, what should or should not > be done. Please propose new wording. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu May 23 00:03:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17206 for ; Thu, 23 May 2002 00:03:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4N3UDD28153 for ips-outgoing; Wed, 22 May 2002 23:30:13 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4N3UBw28148; Wed, 22 May 2002 23:30:11 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4N3U4mk027130; Thu, 23 May 2002 05:30:04 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4N3Tdk68022; Thu, 23 May 2002 05:29:49 +0200 To: Martins Krikis Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: Re: MaxRecvPDULength question X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 23 May 2002 06:29:18 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 23/05/2002 06:29:54, Serialize complete at 23/05/2002 06:29:54 Content-Type: multipart/alternative; boundary="=_alternative 0012D5D0C2256BC2_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0012D5D0C2256BC2_= Content-Type: text/plain; charset="us-ascii" That might be good as it is closer to what we mean anyhow and should not affect any existing implementation anyhow. Julo Martins Krikis Sent by: owner-ips@ece.cmu.edu 05/22/2002 10:19 PM Please respond to Martins Krikis To: ips@ece.cmu.edu cc: Subject: Re: MaxRecvPDULength question --- Paul Koning wrote: > Are you proposing to rename the key so its name is > "MaxRecvDataLength"? Yes, that would be more > accurate, but why bother > at this point? Because it would be more accurate! I personally don't mind changes in the draft that make it clearer but require me to change one string constant. Martins Krikis, Intel Corp. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com --=_alternative 0012D5D0C2256BC2_= Content-Type: text/html; charset="us-ascii"
That might be good as it is closer to what we mean anyhow and should not affect any existing implementation anyhow.

Julo


Martins Krikis <mkrikis@yahoo.com>
Sent by: owner-ips@ece.cmu.edu

05/22/2002 10:19 PM
Please respond to Martins Krikis

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        Re: MaxRecvPDULength question

       



--- Paul Koning <ni1d@arrl.net> wrote:

> Are you proposing to rename the key so its name is
> "MaxRecvDataLength"?  Yes, that would be more
> accurate, but why bother
> at this point?

Because it would be more accurate!

I personally don't mind changes in the draft that
make it clearer but require me to change one string
constant.

 Martins Krikis, Intel Corp.


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

--=_alternative 0012D5D0C2256BC2_=-- From owner-ips@ece.cmu.edu Thu May 23 00:06:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17284 for ; Thu, 23 May 2002 00:06:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4N3HB327552 for ips-outgoing; Wed, 22 May 2002 23:17:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4N3H8w27546; Wed, 22 May 2002 23:17:08 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4N3Gum6021766; Thu, 23 May 2002 05:16:56 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4N3GUk89714; Thu, 23 May 2002 05:16:40 +0200 To: "John Hufferd" Cc: ips@ece.cmu.edu, Martins Krikis , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: No-renegotiation rule inadequately described X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 23 May 2002 06:16:12 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 23/05/2002 06:16:46, Serialize complete at 23/05/2002 06:16:46 Content-Type: multipart/alternative; boundary="=_alternative 0011E00CC2256BC2_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0011E00CC2256BC2_= Content-Type: text/plain; charset="us-ascii" John, The intend of the "legitimate" statement was to say that those are not to be confused with not admissible and force termination. I will add wording to make this clear. Julo John Hufferd/San Jose/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 05/23/2002 03:37 AM Please respond to John Hufferd To: Martins Krikis cc: ips@ece.cmu.edu Subject: RE: iSCSI: No-renegotiation rule inadequately described OK, this has been going around and around. But I hope the attached last note tied it up. Julian, can we use the conclusion in this attached note? > I suggest adding to 4.2 after "Reject or Irrelevant > are legitimate...." > "A negotiation is considered complete when the > responder has sent the key value pair even if the > value > is "Reject", "Irrelevant", or "NotUnderstood". > Sending > the key again would be a re-negotiation." . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Martins Krikis @ece.cmu.edu on 05/22/2002 05:23:54 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iSCSI: No-renegotiation rule inadequately described --- pat_thaler@agilent.com wrote: > The problem is there are two ways of > interpreting the state of the negotiation > after ImmediateData=Reject. > > A) The offered value was rejected so the > negotiation isn't done yet. In this view > the second offer is a continuation of the > first negotiation rather than a new > negotation. Good point. But I don't think this view quite fits together with, e.g., page 69: Reject or Irrelevant are legitimate negotiation options... In my opinion (and implementation) it also complicates the decision about whether this value is precluding me from announcing readiness to commit or it isn't. It's harder to view it negotiated for commit purposes and non-negotiated for repeated reception purposes than it is to just view it the same way... > B) A negotiation is always one offer and one > response regardless of whether the response > indicates successful negotiation or not. > > Text should be added to the draft to indicate > which is intended. > > I agree that it should state which is intended. > My preference would be that it take the simpler > view in B. I'm very much for it. > For Booleans and numerical values, > if the first offer caused a reject, > there is something broken. For lists the originator > can include all acceptable responses in the initial > offer. In either case, there isn't much point in > offering again. This is exactly what I was planning to say once somebody gave me a reason about the necessity to renegotiate. > If the response was NotUnderstood > then there isn't any point in offering the key again > (though I also think it is unreasonable to expect > the > responder to keep a list of NotUnderstood keys so > that > it can detect attempts to renegotiate). Exactly. > Irrelevant indicates that a problem such as key > negotiation being done in the wrong order (e.g. > attempting to negotiation IFMarkInt before > IFMarker). > There is no reason this should happen so we don't > need to allow the negotiation to continue in this > case either. First, there are no dependencies (even for markers, keys can be viewed as independent), so in my opinion this cannot happen. But even if it could happen, the earlier-negotiated key that caused the later-negotiated key to be answered with Irrelevant, is not going away, so there is no point repeating the later key---it will still be answered with Irrelevant! There is also no point to negotiate it from the other side, as that would then be the side who first called it Irrelevant. Once irrelevant is always (through the life of negotiation sequence) irrelevant, so no need to renegotiate it. > I suggest adding to 4.2 after "Reject or Irrelevant > are legitimate...." > "A negotiation is considered complete when the > responder has sent the key value pair even if the > value > is "Reject", "Irrelevant", or "NotUnderstood". > Sending > the key again would be a re-negotiation." This would be truly beatiful. Can it please happen? Thanks, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com --=_alternative 0011E00CC2256BC2_= Content-Type: text/html; charset="us-ascii"
John,

The intend of the "legitimate" statement was to say that those are not to be confused with not admissible and force termination.
I will add wording to make this clear.  

Julo




John Hufferd/San Jose/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu

05/23/2002 03:37 AM
Please respond to John Hufferd

       
        To:        Martins Krikis <mkrikis@yahoo.com>
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: No-renegotiation rule inadequately described

       



OK, this has been going around and around.  But I hope the attached last
note tied it up.

Julian, can we use the conclusion in this attached note?

> I suggest adding to 4.2 after "Reject or Irrelevant
> are legitimate...."
> "A negotiation is considered complete when the
> responder has sent the key value pair even if the
> value
> is "Reject", "Irrelevant", or "NotUnderstood".
> Sending
> the key again would be a re-negotiation."


.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


Martins Krikis <mkrikis@yahoo.com>@ece.cmu.edu on 05/22/2002 05:23:54 PM

Sent by:    owner-ips@ece.cmu.edu


To:    ips@ece.cmu.edu
cc:
Subject:    RE: iSCSI: No-renegotiation rule inadequately described



--- pat_thaler@agilent.com wrote:

> The problem is there are two ways of
> interpreting the state of the negotiation
> after ImmediateData=Reject.
>
> A) The offered value was rejected so the
> negotiation isn't done yet. In this view
> the second offer is a continuation of the
> first negotiation rather than a new
> negotation.

Good point. But I don't think this view quite
fits together with, e.g., page 69:

 Reject or Irrelevant are legitimate
 negotiation options...

In my opinion (and implementation) it also
complicates the decision about whether this
value is precluding me from announcing readiness
to commit or it isn't. It's harder to view it
negotiated for commit purposes and non-negotiated
for repeated reception purposes than it is to
just view it the same way...

> B) A negotiation is always one offer and one
> response regardless of whether the response
> indicates successful negotiation or not.
>
> Text should be added to the draft to indicate
> which is intended.
>
> I agree that it should state which is intended.
> My preference would be that it take the simpler
> view in B.

I'm very much for it.

> For Booleans and numerical values,
> if the first offer caused a reject,
> there is something broken. For lists the originator
> can include all acceptable responses in the initial
> offer. In either case, there isn't much point in
> offering again.

This is exactly what I was planning to say once
somebody gave me a reason about the necessity
to renegotiate.

> If the response was NotUnderstood
> then there isn't any point in offering the key again
> (though I also think it is unreasonable to expect
> the
> responder to keep a list of NotUnderstood keys so
> that
> it can detect attempts to renegotiate).

Exactly.

> Irrelevant indicates that a problem such as key
> negotiation being done in the wrong order (e.g.
> attempting to negotiation IFMarkInt before
> IFMarker).
> There is no reason this should happen so we don't
> need to allow the negotiation to continue in this
> case either.

First, there are no dependencies (even for markers,
keys can be viewed as independent), so in my opinion
this cannot happen. But even if it could happen, the
earlier-negotiated key that caused the
later-negotiated key to be answered with Irrelevant,
is not going away, so there is no point repeating
the later key---it will still be answered with
Irrelevant! There is also no point to negotiate
it from the other side, as that would then be the
side who first called it Irrelevant. Once irrelevant
is always (through the life of negotiation sequence)
irrelevant, so no need to renegotiate it.

> I suggest adding to 4.2 after "Reject or Irrelevant
> are legitimate...."
> "A negotiation is considered complete when the
> responder has sent the key value pair even if the
> value
> is "Reject", "Irrelevant", or "NotUnderstood".
> Sending
> the key again would be a re-negotiation."

This would be truly beatiful. Can it please happen?

Thanks,

 Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not
           be those of my employer



__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

--=_alternative 0011E00CC2256BC2_=-- From owner-ips@ece.cmu.edu Thu May 23 04:21:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00079 for ; Thu, 23 May 2002 04:21:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4N7RUt08636 for ips-outgoing; Thu, 23 May 2002 03:27:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailnpd.hcltech.com ([203.197.145.76]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4N7RPw08630 for ; Thu, 23 May 2002 03:27:26 -0400 (EDT) Received: from npd.hcltech.com (IDENT:pamanick@pamanick.hcltech.com [192.168.100.58]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id g4N7AHM03631; Thu, 23 May 2002 12:40:18 +0530 Message-ID: <3CEC9850.82BF7E8F@npd.hcltech.com> Date: Thu, 23 May 2002 12:50:49 +0530 From: Parthi Organization: HCL Tech X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI , Luben Tuikov Subject: Re: iSCSI: Login Request error References: <3CE9D7C3.65A301BD@npd.hcltech.com> <3CEA4FBF.210108EF@splentec.com> Content-Type: multipart/alternative; boundary="------------1C4879AB0772BF666EE19A4A" Sender: owner-ips@ece.cmu.edu Precedence: bulk --------------1C4879AB0772BF666EE19A4A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Luben Tuikov wrote: > Parthi wrote: > > > > > > Responder should say "Reject" in Text param negotiation. > > > > > > > > ex. Originator-> ImmediateData=Ye > > > > Responder -> ImmediateData=Reject > > > > > > > > The status value would be 020b "Invalid during login". > > > > > > Would 020b be the correct error for that? I would have thought 0200 > > > "Miscellaneous iSCSI initiator errors" would have been better; I thought > > > 020b was exclusively for an attempt to do something that should only be > > > done in FFP, before you've gotten to FFP. > > > > > > Take care, > > > > > > Bill > > > > Hi : > > > > Draft says "Initiator Error(not a format error) -- This indicates request for a resource for > > which the initiator > > does not have permission. The request should not be tried again". > > The status value should be 0 (Success). Note that > since we are talking about status codes, we imply > that the _Target_ replies. > > That is, the Target should reply with (as already noted) > ImmediateData=Reject and status of 0. This would tell the > Initiator that login is proceeding ok, but ImmediateData > the draft says (pg 99) : 6.8 Negotiation Failure During Login, any failure in negotiation MUST be considered a login process failure and the login phase must be terminated, and with it the connection. If the target detects the failure, it must terminate the login with the appropriate login response code. > needs renegotiation/reconsideration. > > Note that the Target may reply with other keys' responses, > along with the rejected ones. > > Then the initiator will reconsider all rejected keys. > > Note that a status code of anything but 0, implies > closing the connection. > > Please see this message: > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09771.html > > My reply is a bit messy, in that I should've been clearer, > that the originator of the key being rejected by the > responder, SHOULD, if available, offer another set of values, > or close the connection. > > Currently, the draft says (pg 69, 12-90): > > If a responder does support, understand or is allowed > to use none of the offered options with a specific originator, > it MAY use the constant "Reject" or it MAY respond with an > admissible value. The selection of a value not offered is > considered a negotiation failure and is handled as a protocol > error. > > Which is inconsistent with itself. (I.e. self-contradictory > to negotiation.) > > Proof: By the first clause: > Assume that the responder cannot use any of the > offered options to a key (keyword ``none'' in the > first sentence). Then the responder > 1) MAY Reject, > 2) MAY offer an admissible value. > Take 2) and proceed. > > Then the originator receives an (admissible) value > which was NOT in what it offered and closes the > connection by the second clause. > Clearly, this is a negotiation failure. > > If, on the other hand, we had chosen 1), > i.e. send Reject, the originator, may reconsider > it's options and send a different set of values, > and should one of them be acceptable to the > responder, we arrive at negotiation success. > QED. > > This has already been communicated to Julian. Julian? > > Nevertheless, a Reject response is required by > the responder to ``close the loop''. > > If the originator doesn't close the connection > after that, the responder MAY choose to send > it's own values for the same (Rejected) key. > I.e. the responder to the Reject will now become > the originator of the Reject-ed variable. > > -- > Luben > -- > Parthiban M, > iSCSI Driver Team, > HCL Technologies Ltd., Tel : (+91)-44-3741939 to 42, Extn. 2332 > http://san.hcltech.com --------------1C4879AB0772BF666EE19A4A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Luben Tuikov wrote:
Parthi wrote:
>
> > >  Responder should say  "Reject" in Text param negotiation.
> > >
> > >        ex.       Originator->  ImmediateData=Ye
> > >                     Responder ->  ImmediateData=Reject
> > >
> > >  The status value would be  020b  "Invalid during login".
> >
> > Would 020b be the correct error for that? I would have thought 0200
> > "Miscellaneous iSCSI initiator errors" would have been better; I thought
> > 020b was exclusively for an attempt to do something that should only be
> > done in FFP, before you've gotten to FFP.
> >
> > Take care,
> >
> > Bill
>
> Hi :
>
>   Draft says "Initiator Error(not a format error) -- This indicates request for a resource for
> which the initiator
> does not have permission. The request should not be tried again".

The status value should be 0 (Success). Note that
since we are talking about status codes, we imply
that the _Target_ replies.

That is, the Target should reply with (as already noted)
ImmediateData=Reject and status of 0. This would tell the
Initiator that login is proceeding ok, but ImmediateData
 

the draft says  (pg 99) : 6.8 Negotiation Failure
During Login, any failure in negotiation MUST be considered a
login process failure and the login phase must be terminated,
and with it the connection. If the target detects the failure,
it must terminate the login with the appropriate login
response code.
needs renegotiation/reconsideration.

Note that the Target may reply with other keys' responses,
along with the rejected ones.

Then the initiator will reconsider all rejected keys.

Note that a status code of anything but 0, implies
closing the connection.

Please see this message:
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09771.html

My reply is a bit messy, in that I should've been clearer,
that the originator of the key being rejected by the
responder, SHOULD, if available, offer another set of values,
or close the connection.

Currently, the draft says (pg 69, 12-90):

        If a responder does support, understand or is allowed
to use none of the offered options with a specific originator,
it MAY use the constant "Reject" or it MAY respond with an
admissible value. The selection of a value not offered is
considered a negotiation failure and is handled as a protocol
error.

Which is inconsistent with itself. (I.e. self-contradictory
to negotiation.)

Proof: By the first clause:
Assume that the responder cannot use any of the
offered options to a key (keyword ``none'' in the
first sentence). Then the responder
   1) MAY Reject,
   2) MAY offer an admissible value.
Take 2) and proceed.

Then the originator receives an (admissible) value
which was NOT in what it offered and closes the
connection by the second clause.
Clearly, this is a negotiation failure.

If, on the other hand, we had chosen 1),
i.e. send Reject, the originator, may reconsider
it's options and send a different set of values,
and should one of them be acceptable to the
responder, we arrive at negotiation success.
QED.

This has already been communicated to Julian. Julian?

Nevertheless, a Reject response is required by
the responder to ``close the loop''.

If the originator doesn't close the connection
after that, the responder MAY choose to send
it's own values for the same (Rejected) key.
I.e. the responder to the Reject will now become
the originator of the Reject-ed variable.

--
Luben

-- 
Parthiban M,
iSCSI Driver Team,
HCL Technologies Ltd.,          Tel : (+91)-44-3741939 to 42, Extn. 2332
http://san.hcltech.com
--------------1C4879AB0772BF666EE19A4A-- From owner-ips@ece.cmu.edu Thu May 23 07:41:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04970 for ; Thu, 23 May 2002 07:41:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NAsRH27374 for ips-outgoing; Thu, 23 May 2002 06:54:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NAsLw27364 for ; Thu, 23 May 2002 06:54:25 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4N9r4u07686; Thu, 23 May 2002 05:53:04 -0400 Message-ID: <3CECCA42.27984565@splentec.com> Date: Thu, 23 May 2002 06:53:54 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Parthi CC: iSCSI Subject: Re: iSCSI: Login Request error References: <3CE9D7C3.65A301BD@npd.hcltech.com> <3CEA4FBF.210108EF@splentec.com> <3CEC9850.82BF7E8F@npd.hcltech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Parthi wrote: > > > That is, the Target should reply with (as already noted) > > ImmediateData=Reject and status of 0. This would tell the > > Initiator that login is proceeding ok, but ImmediateData > > > > the draft says (pg 99) : 6.8 Negotiation Failure > During Login, any failure in negotiation MUST be considered a > login process failure and the login phase must be terminated, > and with it the connection. If the target detects the failure, > it must terminate the login with the appropriate login > response code. Wrong! ``Reject'' is a legitimate response. Pg 69, Sec 4.2.1. Thus, replying with ``Reject'' doesn't necessarily close the connection. For your statement to be correct you have to define ``Negotiation Failure''. -- Luben From owner-ips@ece.cmu.edu Thu May 23 09:52:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10187 for ; Thu, 23 May 2002 09:52:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4ND89I03412 for ips-outgoing; Thu, 23 May 2002 09:08:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4ND87w03408 for ; Thu, 23 May 2002 09:08:07 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4ND7x71040054 for ; Thu, 23 May 2002 15:07:59 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4ND7xL69968 for ; Thu, 23 May 2002 15:07:59 +0200 To: "John Hufferd" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Old words left around X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 23 May 2002 16:07:56 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 23/05/2002 16:07:58, Serialize complete at 23/05/2002 16:07:58 Content-Type: multipart/alternative; boundary="=_alternative 0047CCDFC2256BC2_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0047CCDFC2256BC2_= Content-Type: text/plain; charset="us-ascii" What version - I can't find it in 12.91 - Julo John Hufferd@IBMUS 05/23/2002 03:19 AM To: Julian Satran/Haifa/IBM@IBMIL@IBMDE cc: ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: iSCSI: Old words left around Julian, I think I may have found some old words left around from earlier times. Top of 178, we say "...the restart option of the Login should be used." We should just delete the sentence, since we just explained how to do it, two sentences above that. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com --=_alternative 0047CCDFC2256BC2_= Content-Type: text/html; charset="us-ascii"
What version - I can't find it in 12.91 - Julo


John Hufferd@IBMUS

05/23/2002 03:19 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL@IBMDE
        cc:        ips@ece.cmu.edu
        From:        John Hufferd/San Jose/IBM@IBMUS
        Subject:        iSCSI: Old words left around

       


Julian,
I think I may have found some old words left around from earlier times.  Top of 178, we say "...the restart option of the Login should be used."  We should just delete the sentence, since we just explained how to do it, two sentences above that.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com

--=_alternative 0047CCDFC2256BC2_=-- From owner-ips@ece.cmu.edu Thu May 23 09:53:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10217 for ; Thu, 23 May 2002 09:53:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NDJjJ04132 for ips-outgoing; Thu, 23 May 2002 09:19:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NDJgw04123; Thu, 23 May 2002 09:19:42 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4NDJY71038494; Thu, 23 May 2002 15:19:34 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4NDJXL125950; Thu, 23 May 2002 15:19:34 +0200 To: Martins Krikis Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: list negotiation description X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 23 May 2002 16:19:31 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 23/05/2002 16:19:34, Serialize complete at 23/05/2002 16:19:34 Content-Type: multipart/alternative; boundary="=_alternative 0048D8FAC2256BC2_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0048D8FAC2256BC2_= Content-Type: text/plain; charset="us-ascii" What version did you look at? Considering the date of your mail it must have been 12-91 only that 12-91 does not contain the text you quote - Julo Martins Krikis Sent by: owner-ips@ece.cmu.edu 05/23/2002 12:37 AM Please respond to Martins Krikis To: ips@ece.cmu.edu cc: Subject: iSCSI: list negotiation description First a question again: What is the point of allowing "inadmissible values" (or in case of lists, lack of acceptable values) be answered with an "admissible value"? Now the problems. Page 69, bottom paragraph: If a responder does support, understand or is allowed to use none of the offered options with a specific originator, it MAY use the constant "Reject" or it MAY respond with an admissible value. The selection of a value not offered is considered a negotiation failure and is handled as a protocol error. http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10066.html made me believe that the phrase "or it MAY respond with an admissible value..." will be removed. Since it hasn't been, I'll point out again that it contradicts the very next sentence, because this "admissible value" would be a "value not offered". Also, I must say that I almost regret having started picking on the beginning of this paragraph, because IMHO it has gotten worse. I'm still proposing this: If each of the offered values is not understood or not supported, or the responder is not allowed to use it with the specific originator, it MUST use the constant "Reject". Note that because other reasonable alternatives are eliminated, the original "MAY" can change to "MUST". (Which should be a good thing, BTW.) Thanks, Martins Krikis, Intel Corp. Disclaimer: these opinions are my own and may not not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com --=_alternative 0048D8FAC2256BC2_= Content-Type: text/html; charset="us-ascii"
What version did you look at?  Considering the date of your mail it must have been 12-91 only that 12-91 does not contain the text you quote - Julo


Martins Krikis <mkrikis@yahoo.com>
Sent by: owner-ips@ece.cmu.edu

05/23/2002 12:37 AM
Please respond to Martins Krikis

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: list negotiation description

       


First a question again:

What is the point of allowing "inadmissible
values" (or in case of lists, lack of acceptable
values) be answered with an "admissible value"?

Now the problems.

Page 69, bottom paragraph:

 If a responder does support, understand or
 is allowed to use none of the offered options
 with a specific originator, it MAY use the
 constant "Reject" or it MAY respond with an
 admissible value. The selection of a value
 not offered is considered a negotiation
 failure and is handled as a protocol error.

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10066.html
made me believe that the phrase "or it MAY respond
with an admissible value..." will be removed.

Since it hasn't been, I'll point out again that
it contradicts the very next sentence, because
this "admissible value" would be a "value not
offered".
Also, I must say that I almost regret having
started picking on the beginning of this paragraph,
because IMHO it has gotten worse. I'm still
proposing this:

 If each of the offered values is not understood
 or not supported, or the responder is not allowed
 to use it with the specific originator, it MUST
 use the constant "Reject".

Note that because other reasonable alternatives
are eliminated, the original "MAY" can change to
"MUST". (Which should be a good thing, BTW.)

Thanks,

 Martins Krikis, Intel Corp.

Disclaimer: these opinions are my own and may not
           not be those of my employer


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

--=_alternative 0048D8FAC2256BC2_=-- From owner-ips@ece.cmu.edu Thu May 23 09:55:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10308 for ; Thu, 23 May 2002 09:55:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NDZZJ05002 for ips-outgoing; Thu, 23 May 2002 09:35:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NDZXw04997 for ; Thu, 23 May 2002 09:35:33 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4NCYau08309; Thu, 23 May 2002 08:34:36 -0400 Message-ID: <3CECF020.8ACFE673@splentec.com> Date: Thu, 23 May 2002 09:35:28 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI , Julian Satran Subject: [iSCSI]: Key negotiation procedure proposal Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm proposing the following key negotiation procedure. It preserves the no-renegotiation of keys rule and all the rules of login request and response currently used in the draft (12-91). It applies to any kind of value (list, boolean, integer, etc.). Simple implementations: Simple implementations SHOULD close the connection right after Reject has been communicated. This ensures that the reason for closing has been communicated to the peer. Regular implementations: Core rule: A negotiation of a key=value pair is complete/finished when both the Originator and Responder have sent their values (non-reserved keywords). The core rule implies the the following: If a Responder replies with Reject, then the Originator SHOULD NOT renegotiate the rejected key. If a Responder replies with Reject, it SHOULD sent its value of that key on the next reply to the Originator. If an Originator finds the response to an offered key=value pair to be unacceptable, it SHOULD send Reject and close the connection. Please note that the core rule above ensures that both the Originator and Responder _know_ each other's values if the connection is closed due to Reject. This will give the user of each node more information to find out what went wrong. That is, this kind of negotiation is exhaustive. Let O: denote Originator and R: the Responder. Example 1: ---------- O: v = x --> <-- R: v = Reject O: "" --> <-- R: v = y O: 1) v = y is OK, continue as normal, 2) v = y is unacceptable, v = Reject --> close the connection (reason just given). Example 2: ---------- O: v = x --> <-- R: v = y O: 1) v = y is OK, continue, as normal, 2) v = y is unacceptable, v = Reject --> close the connection (reason just given). -- Luben From owner-ips@ece.cmu.edu Thu May 23 10:46:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12822 for ; Thu, 23 May 2002 10:46:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NDsHi06089 for ips-outgoing; Thu, 23 May 2002 09:54:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NDsEw06085 for ; Thu, 23 May 2002 09:54:15 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4NCrIu08397 for ; Thu, 23 May 2002 08:53:18 -0400 Message-ID: <3CECF481.42DDD4CE@splentec.com> Date: Thu, 23 May 2002 09:54:09 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI Subject: [iSCSI]: BiDiInitialR2T Question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit First, the text of this key (BiDiInitialR2T 11.11) refers to BiDiR2T. In contrast InitialR2T (11.10) refers to R2T, which I know what it is. What is BiDiR2T? Is it possible to do away with BiDiInitialR2T? I see that both texts (11.10 InitialR2T and 11.11 BiDiInitialR2T) to be quite similar. Furthermore, since incoming data (I <- T) is always implicitly solicited (2.4.4, pg 41, bottom), we don't need the ``bidirectional'' part. Just InitialR2T will do. -- Luben From owner-ips@ece.cmu.edu Thu May 23 10:46:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12836 for ; Thu, 23 May 2002 10:46:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NEFxP07538 for ips-outgoing; Thu, 23 May 2002 10:15:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4N7exw09093; Thu, 23 May 2002 03:40:59 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g4N7ere5023453; Thu, 23 May 2002 03:40:53 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g4N7erAM023450; Thu, 23 May 2002 03:40:53 -0400 Date: Thu, 23 May 2002 03:40:53 -0400 (EDT) From: "Robert D. Russell" To: ips@ece.cmu.edu, Subject: Re: iSCSI : versions and draft no.s (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Subrahmanya: The consensus amoung consortium members for the next plugfest was NOT to implement an X- key for this extension, but rather to agree to configure the implementations for a specific draft prior to testing and then have login requests and responses carry in the their version-max, version-min, version-active fields only values allowed by that draft (so for drafts 11 and after those fields could contain only 0). This means that targets and initiators can not adapt dynamically to the other side of the connection, (they are statically configured to 1 draft only) but for the plugfest environment this was not considered essential. The overriding consideration was that implementing an X- key was a waste of everybody's time, since it would become invalid as soon as the standard was approved. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 On Tue, 21 May 2002, Julian Satran wrote: > That is still the case - Julo > > > > > Subrahmanya Sastry K V > Sent by: owner-ips@ece.cmu.edu > 05/21/2002 03:15 PM > Please respond to Subrahmanya Sastry K V > > > To: ips@ece.cmu.edu > cc: > Subject: iSCSI : versions and draft no.s > > > > Hi all, > > I would like to know the final word on the earlier discussion on the > absence of a clear mapping between the iscsi draft version no.s and the > various drafts. > > The last suggestion I saw in an earlier thread was that we could use a > vendor specific X-draft= key, values to indicate the > supported draft versions. The same was seconded by Julo for the > plugfest. Is this the final conclusion for an implementation to support > multiple versions ? > > Thanks > -- > Subrahmanya Sastry K V > Member Technical Staff > HCL Tech, Chennai, INDIA > http://san.hcltech.com > > > > > From owner-ips@ece.cmu.edu Thu May 23 10:48:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12880 for ; Thu, 23 May 2002 10:47:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NE7CN06882 for ips-outgoing; Thu, 23 May 2002 10:07:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NE79w06878 for ; Thu, 23 May 2002 10:07:09 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4NE73rt036820 for ; Thu, 23 May 2002 16:07:03 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4NE72L83784 for ; Thu, 23 May 2002 16:07:02 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI base64 and 12-92 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 23 May 2002 17:07:01 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 23/05/2002 17:07:02, Serialize complete at 23/05/2002 17:07:02 Content-Type: multipart/alternative; boundary="=_alternative 004CD495C2256BC2_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004CD495C2256BC2_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, I looked again at cryptography needs and I think that large numbers will be needed and base64 is a decent and not invented here way to express them. As we have to keep them for numbers I reinstated them for small values too (why implement a check) and for those that don't take numerical big-endian representation for granted there is now text that says it without referring to internal representation. I think that mapping to addresses is entirely an implementation issue. All this is in 12-92. We are still busy polishing the authentication stuff. Julo --=_alternative 004CD495C2256BC2_= Content-Type: text/html; charset="us-ascii"
Dear colleagues,

I looked again at cryptography needs and I think that large numbers will be needed and base64 is a decent and not invented here way to express them.

As we have to keep them for numbers I reinstated them for small values too (why implement a check) and for those that don't take
numerical big-endian representation for granted there is now text that says it  without referring to internal representation.

I think that mapping to addresses is entirely an implementation issue.

All this is in 12-92.

We are still busy polishing the authentication stuff.

Julo --=_alternative 004CD495C2256BC2_=-- From owner-ips@ece.cmu.edu Thu May 23 11:00:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13419 for ; Thu, 23 May 2002 11:00:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NEg6J09200 for ips-outgoing; Thu, 23 May 2002 10:42:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NEg3w09194; Thu, 23 May 2002 10:42:03 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4NEft71040384; Thu, 23 May 2002 16:41:55 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4NEflL52240; Thu, 23 May 2002 16:41:56 +0200 To: Luben Tuikov Cc: iSCSI , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: [iSCSI]: BiDiInitialR2T Question X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 23 May 2002 17:41:45 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 23/05/2002 17:41:55, Serialize complete at 23/05/2002 17:41:55 Content-Type: multipart/alternative; boundary="=_alternative 004FD912C2256BC2_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004FD912C2256BC2_= Content-Type: text/plain; charset="us-ascii" That has crossed our minds too. The R2T is the same but many of us felt more comfortable enabling/disabling unsolicited data explicitly for Bidirectional commands. As we know very little about the bidirectional command usage this seems a safe way to go. Julo Luben Tuikov Sent by: owner-ips@ece.cmu.edu 05/23/2002 04:54 PM Please respond to Luben Tuikov To: iSCSI cc: Subject: [iSCSI]: BiDiInitialR2T Question First, the text of this key (BiDiInitialR2T 11.11) refers to BiDiR2T. In contrast InitialR2T (11.10) refers to R2T, which I know what it is. What is BiDiR2T? Is it possible to do away with BiDiInitialR2T? I see that both texts (11.10 InitialR2T and 11.11 BiDiInitialR2T) to be quite similar. Furthermore, since incoming data (I <- T) is always implicitly solicited (2.4.4, pg 41, bottom), we don't need the ``bidirectional'' part. Just InitialR2T will do. -- Luben --=_alternative 004FD912C2256BC2_= Content-Type: text/html; charset="us-ascii"
That has crossed our minds too. The R2T is the same but many of us felt more comfortable enabling/disabling unsolicited data explicitly for
Bidirectional commands. As we know very little about the bidirectional command usage this seems a safe way to go.

Julo


Luben Tuikov <luben@splentec.com>
Sent by: owner-ips@ece.cmu.edu

05/23/2002 04:54 PM
Please respond to Luben Tuikov

       
        To:        iSCSI <ips@ece.cmu.edu>
        cc:        
        Subject:        [iSCSI]: BiDiInitialR2T Question

       


First, the text of this key (BiDiInitialR2T 11.11)
refers to BiDiR2T. In contrast InitialR2T (11.10)
refers to R2T, which I know what it is.

What is BiDiR2T?

Is it possible to do away with BiDiInitialR2T?

I see that both texts (11.10 InitialR2T and
11.11 BiDiInitialR2T) to be quite similar.

Furthermore, since incoming data (I <- T)
is always implicitly solicited (2.4.4, pg 41,
bottom), we don't need the ``bidirectional''
part. Just InitialR2T will do.

--
Luben

--=_alternative 004FD912C2256BC2_=-- From owner-ips@ece.cmu.edu Thu May 23 11:06:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13641 for ; Thu, 23 May 2002 11:06:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NEGDE07572 for ips-outgoing; Thu, 23 May 2002 10:16:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ext1.pirus.com ([4.36.58.197]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4ND38w03115 for ; Thu, 23 May 2002 09:03:08 -0400 (EDT) Received: by ext1.pirus.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 May 2002 09:05:52 -0400 Message-ID: <4740CE4D4F77564BAADD58D6EF76FBF303EF6C@morpheus.pirus.com> From: "Merhar, Milan" To: "'Bill Studenmund'" , Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution Date: Thu, 23 May 2002 09:05:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2025A.90D991E0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2025A.90D991E0 Content-Type: text/plain; charset="iso-8859-1" I have also spoken to a few people with far more IPsec experience than I. >From the dazed expressions and dropped jaws, the sense I get is that dynamic switching to more relaxed SAs is, how shall I put this, not typical behavior? Legal, yes. Interoperably implementable, probably. Ugly, not a doubt. I too would be far happier if we separated out the decision-bits again, and let the end users decide a) to allow their iSCSI implementations to authenticate each other securely, b) to provide privacy and/or enhanced integrity to the data sessions as independent options. It's bad enough to be appearing to legislate user behavior with a "SHALL USE", but worse if it appears to be an arbitrary mandate from above. I think the appropriate course here is to put in the strong wording re selection of CHAP secrets, referencing the available literature re potential exploits of dictionary keys. Separately, recommend IPsec use for session privacy, integrity, and identification verification, where appropriate to the user's needs. Just my opinion.... - milan -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Wednesday, May 22, 2002 6:59 PM To: Black_David@emc.com Cc: Merhar, Milan; ips@ece.cmu.edu Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution On Wed, 22 May 2002 Black_David@emc.com wrote: > Responding to Milan's concern, let me know if I get any of the > paraphrasing wrong: > > [Milan Merhar]: It looks like the requirement for ESP to protect a CHAP > exchange with a weak secret requires the entire resulting iSCSI > session to be encrypted and use ESP integrity. > > Close enough; I think it's just that connection and only integrity. > The encryption can probably be removed by negotiating a new SA that > doesn't encrypt and deleting the old one, but that still requires > ESP integrity. Just deleting the SA doesn't work reliably because > it could easily result in black-holing packets. IKE has no way to > check whether the other side will accept unprotected packets for > this TCP connection, and if it won't, then deletion of the SA > results in the packets being discarded. Could we have a more complete example of this (SA changing in mid-stride)? >From talking with some IPsec implementers, it can be done. We just will need to note a number of details to make sure we have it right. One thing that will be needed is for us to be able to set policy on a per-socket basis, and for us to be able to examine the policy in place on a socket. That way a target can verify that a login is covered by sufficiently-secure policy, and the initiator (and target) can adjust policy (to relax it). There is of course the question of what to do if the other side doesn't want to relax policy. :-) A few other implementation notes. 1) some IPsec implementations will continue using an older SA (the with-privacy one) for a while. 2) we need to have the initiator make sure it's using strong policy when it does the CHAP phase - otherwise if it is logging back into a target and happens to use a port number that it used before, the old (weaker) SA might still be there. I would prefer the key randomness be a MUST, so we can avoid this. While rather doable, it will add more to the implementation complexity. Take care, Bill ------_=_NextPart_001_01C2025A.90D991E0 Content-Type: text/html; charset="iso-8859-1" RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution
I have also spoken to a few people with far more IPsec experience than I.
From the dazed expressions and dropped jaws, the sense I get is that
dynamic switching to more relaxed SAs is, how shall I put this, not typical
behavior?  Legal, yes. Interoperably implementable, probably.  Ugly, not a doubt.
 
I too would be far happier if we separated out the decision-bits again,
and let the end users decide
    a) to allow their iSCSI implementations to authenticate each other securely,
    b) to provide privacy and/or enhanced integrity to the data sessions
as independent options.
 
It's bad enough to be appearing to legislate user behavior with a
"SHALL USE", but worse if it appears to be an arbitrary mandate
from above.  I think the appropriate course here is to put in the
strong wording re selection of CHAP secrets, referencing the
available literature re potential exploits of dictionary keys.  
Separately, recommend IPsec use for session privacy,
integrity, and identification verification, where appropriate
to the user's needs.
 
Just my opinion....
 
- milan
 
 
 -----Original Message-----
From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
Sent: Wednesday, May 22, 2002 6:59 PM
To: Black_David@emc.com
Cc: Merhar, Milan; ips@ece.cmu.edu
Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution

On Wed, 22 May 2002 Black_David@emc.com wrote:

> Responding to Milan's concern, let me know if I get any of the
> paraphrasing wrong:
>
> [Milan Merhar]: It looks like the requirement for ESP to protect a CHAP
>       exchange with a weak secret requires the entire resulting iSCSI
>       session to be encrypted and use ESP integrity.
>
> Close enough; I think it's just that connection and only integrity.
> The encryption can probably be removed by negotiating a new SA that
> doesn't encrypt and deleting the old one, but that still requires
> ESP integrity.  Just deleting the SA doesn't work reliably because
> it could easily result in black-holing packets.  IKE has no way to
> check whether the other side will accept unprotected packets for
> this TCP connection, and if it won't, then deletion of the SA
> results in the packets being discarded.

Could we have a more complete example of this (SA changing in mid-stride)?
From talking with some IPsec implementers, it can be done. We just will
need to note a number of details to make sure we have it right.

One thing that will be needed is for us to be able to set policy on a
per-socket basis, and for us to be able to examine the policy in place on
a socket. That way a target can verify that a login is covered by
sufficiently-secure policy, and the initiator (and target) can adjust
policy (to relax it).

There is of course the question of what to do if the other side doesn't
want to relax policy. :-)

A few other implementation notes. 1) some IPsec implementations will
continue using an older SA (the with-privacy one) for a while. 2) we need
to have the initiator make sure it's using strong policy when it does the
CHAP phase - otherwise if it is logging back into a target and happens to
use a port number that it used before, the old (weaker) SA might still be
there.

I would prefer the key randomness be a MUST, so we can avoid this. While
rather doable, it will add more to the implementation complexity.

Take care,

Bill

------_=_NextPart_001_01C2025A.90D991E0-- From owner-ips@ece.cmu.edu Thu May 23 11:43:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15199 for ; Thu, 23 May 2002 11:43:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NF8RT10905 for ips-outgoing; Thu, 23 May 2002 11:08:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d06lmsgate-4.uk.ibm.COM (d06lmsgate-4.uk.ibm.com [195.212.29.4]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NF8Ow10900 for ; Thu, 23 May 2002 11:08:25 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d06lmsgate-4.uk.ibm.COM (1.0.0) with ESMTP id PAA203996; Thu, 23 May 2002 15:50:24 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4NF51L50508; Thu, 23 May 2002 17:05:01 +0200 To: Luben Tuikov Cc: iSCSI , luben@ns.splentec.com MIME-Version: 1.0 Subject: Re: [iSCSI]: Key negotiation procedure proposal X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 23 May 2002 18:04:59 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 23/05/2002 18:05:01, Serialize complete at 23/05/2002 18:05:01 Content-Type: multipart/alternative; boundary="=_alternative 00520055C2256BC2_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00520055C2256BC2_= Content-Type: text/plain; charset="us-ascii" Discovering capabilities is best left to discovery (SLP, iSNS etc.). Reject, Irrelevant etc., should be marginal and IMHO are here to handle gracefully exceptions. I would not complicate negotiation beyond a one time handshake - except perhaps for deep negotiation trees if they can be proven useful. And even then I would leave them for iSCSI-2 :-) Julo Luben Tuikov Sent by: luben@ns.splentec.com 05/23/2002 04:35 PM Please respond to Luben Tuikov To: iSCSI , Julian Satran/Haifa/IBM@IBMIL cc: Subject: [iSCSI]: Key negotiation procedure proposal I'm proposing the following key negotiation procedure. It preserves the no-renegotiation of keys rule and all the rules of login request and response currently used in the draft (12-91). It applies to any kind of value (list, boolean, integer, etc.). Simple implementations: Simple implementations SHOULD close the connection right after Reject has been communicated. This ensures that the reason for closing has been communicated to the peer. Regular implementations: Core rule: A negotiation of a key=value pair is complete/finished when both the Originator and Responder have sent their values (non-reserved keywords). The core rule implies the the following: If a Responder replies with Reject, then the Originator SHOULD NOT renegotiate the rejected key. If a Responder replies with Reject, it SHOULD sent its value of that key on the next reply to the Originator. If an Originator finds the response to an offered key=value pair to be unacceptable, it SHOULD send Reject and close the connection. Please note that the core rule above ensures that both the Originator and Responder _know_ each other's values if the connection is closed due to Reject. This will give the user of each node more information to find out what went wrong. That is, this kind of negotiation is exhaustive. Let O: denote Originator and R: the Responder. Example 1: ---------- O: v = x --> <-- R: v = Reject O: "" --> <-- R: v = y O: 1) v = y is OK, continue as normal, 2) v = y is unacceptable, v = Reject --> close the connection (reason just given). Example 2: ---------- O: v = x --> <-- R: v = y O: 1) v = y is OK, continue, as normal, 2) v = y is unacceptable, v = Reject --> close the connection (reason just given). -- Luben --=_alternative 00520055C2256BC2_= Content-Type: text/html; charset="us-ascii"
Discovering capabilities is best left to discovery (SLP, iSNS etc.).
Reject, Irrelevant etc., should be marginal and IMHO are here to handle gracefully exceptions.
I would not complicate negotiation beyond a one time handshake - except perhaps for deep negotiation trees
if they can be proven useful. And even then I would leave them for iSCSI-2  :-)

Julo


Luben Tuikov <luben@splentec.com>
Sent by: luben@ns.splentec.com

05/23/2002 04:35 PM
Please respond to Luben Tuikov

       
        To:        iSCSI <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        [iSCSI]: Key negotiation procedure proposal

       


I'm proposing the following key negotiation procedure. It
preserves the no-renegotiation of keys rule and all the
rules of login request and response currently used in the
draft (12-91). It applies to any kind of value (list,
boolean, integer, etc.).

Simple implementations:

Simple implementations SHOULD close the connection right
after Reject has been communicated. This ensures that the
reason for closing has been communicated to the peer.

Regular implementations:

Core rule: A negotiation of a key=value pair is
complete/finished when both the Originator and Responder
have sent their values (non-reserved keywords).

The core rule implies the the following:

If a Responder replies with Reject, then the Originator
SHOULD NOT renegotiate the rejected key.

If a Responder replies with Reject, it SHOULD sent its value
of that key on the next reply to the Originator.

If an Originator finds the response to an offered key=value
pair to be unacceptable, it SHOULD send Reject and close the
connection.

Please note that the core rule above ensures that both the
Originator and Responder _know_ each other's values if the
connection is closed due to Reject. This will give the user
of each node more information to find out what went wrong.
That is, this kind of negotiation is exhaustive.

Let O: denote Originator and R: the Responder.

Example 1:
----------
O: v = x  -->
        <--   R: v = Reject

O: ""     -->
        <--   R: v = y

O: 1) v = y is OK, continue as normal,
  2) v = y is unacceptable,
 
  v = Reject -->
  close the connection (reason just given).


Example 2:
----------
O: v = x  -->
        <--   R: v = y

O: 1) v = y is OK, continue, as normal,

  2) v = y is unacceptable,
 
  v = Reject -->

  close the connection (reason just given).

--
Luben

--=_alternative 00520055C2256BC2_=-- From owner-ips@ece.cmu.edu Thu May 23 12:03:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16049 for ; Thu, 23 May 2002 12:03:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NFTs912315 for ips-outgoing; Thu, 23 May 2002 11:29:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NFTqw12311 for ; Thu, 23 May 2002 11:29:52 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4NESru08840; Thu, 23 May 2002 10:28:53 -0400 Message-ID: <3CED0AE8.23342500@splentec.com> Date: Thu, 23 May 2002 11:29:44 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran CC: iSCSI Subject: Re: [iSCSI]: Key negotiation procedure proposal References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit But Julian, I'm _not_ talking here about discovering capabilities. This is just rules for Login/Text Operational Key Negotiation. The proposal here just puts forward one core rule plus 3 more implied by the core rule, and those 4 dictate the negotiations. If you take a look at it carefully you'll see that it obsoletes section 4.2.1 and 4.2.2, and will leave you with exactly 58 lines of text for chapter 4.2 (that is _including_ the examples). It also solves all the problems we've been having with login negotiation, renegotiation, etc, for which so many of us have posted their opinions here on this mailing list. This has nothing to do with capabilities! Furthermore I don't think that this complicates negotiation, If anything ,it makes it simpler. There is a rule for simple implementations (Martins, your opinion?) and a rule for fully developed implementations. It's just login/text negotiation rules. People, take a look at the rules and examples and let me hear your opinion? (those of you involved in login/text neg. discussions) -- Luben Julian Satran wrote: > > Discovering capabilities is best left to discovery (SLP, iSNS etc.). > Reject, Irrelevant etc., should be marginal and IMHO are here to handle gracefully exceptions. > I would not complicate negotiation beyond a one time handshake - except perhaps for deep > negotiation trees > if they can be proven useful. And even then I would leave them for iSCSI-2 :-) > > Julo > > Luben Tuikov > Sent by: luben@ns.splentec.com To: iSCSI , Julian > Satran/Haifa/IBM@IBMIL > 05/23/2002 04:35 PM cc: > Please respond to Luben Tuikov Subject: [iSCSI]: Key negotiation procedure > proposal > > > > I'm proposing the following key negotiation procedure. It > preserves the no-renegotiation of keys rule and all the > rules of login request and response currently used in the > draft (12-91). It applies to any kind of value (list, > boolean, integer, etc.). > > Simple implementations: > > Simple implementations SHOULD close the connection right > after Reject has been communicated. This ensures that the > reason for closing has been communicated to the peer. > > Regular implementations: > > Core rule: A negotiation of a key=value pair is > complete/finished when both the Originator and Responder > have sent their values (non-reserved keywords). > > The core rule implies the the following: > > If a Responder replies with Reject, then the Originator > SHOULD NOT renegotiate the rejected key. > > If a Responder replies with Reject, it SHOULD sent its value > of that key on the next reply to the Originator. > > If an Originator finds the response to an offered key=value > pair to be unacceptable, it SHOULD send Reject and close the > connection. > > Please note that the core rule above ensures that both the > Originator and Responder _know_ each other's values if the > connection is closed due to Reject. This will give the user > of each node more information to find out what went wrong. > That is, this kind of negotiation is exhaustive. > > Let O: denote Originator and R: the Responder. > > Example 1: > ---------- > O: v = x --> > <-- R: v = Reject > > O: "" --> > <-- R: v = y > > O: 1) v = y is OK, continue as normal, > 2) v = y is unacceptable, > > v = Reject --> > close the connection (reason just given). > > Example 2: > ---------- > O: v = x --> > <-- R: v = y > > O: 1) v = y is OK, continue, as normal, > > 2) v = y is unacceptable, > > v = Reject --> > > close the connection (reason just given). > > -- > Luben From owner-ips@ece.cmu.edu Thu May 23 12:19:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16825 for ; Thu, 23 May 2002 12:19:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NFvmR14208 for ips-outgoing; Thu, 23 May 2002 11:57:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NFvjw14203 for ; Thu, 23 May 2002 11:57:45 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id BCD8B30706; Thu, 23 May 2002 11:57:44 -0400 (EDT) Date: Thu, 23 May 2002 08:55:47 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Subject: Re: iSCSI base64 and 12-92 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 23 May 2002, Julian Satran wrote: > Dear colleagues, > > I looked again at cryptography needs and I think that large numbers will > be needed and base64 is a decent and not invented here way to express > them. Just curious, which alogorythm needs them? Take care, Bill From owner-ips@ece.cmu.edu Thu May 23 12:28:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17138 for ; Thu, 23 May 2002 12:28:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NG7mP14830 for ips-outgoing; Thu, 23 May 2002 12:07:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NG7kw14822 for ; Thu, 23 May 2002 12:07:46 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4NG7bA21284; Thu, 23 May 2002 12:07:37 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g4NG7b712422; Thu, 23 May 2002 12:07:37 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 12:06:22 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937923@CORPMX14> From: Black_David@emc.com To: hufferd@us.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution Date: Thu, 23 May 2002 12:06:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-PerlMx-Spam: Gauge=XIIIIII, Probability=16%, Report="NO_REAL_NAME" Sender: owner-ips@ece.cmu.edu Precedence: bulk John, > Do you also mean that we can tell if a group preshared key > was used? How do we do that? Preshared key, yes, via the same sort of secured management interface that reports the IKE identity that authenticated and how it authenticated. OTOH, one can't tell in general whether it's a group or pairwise pre-shared key, because that falls into the area you've identified as "customer actions" - I'd use the phrase "good security policy and practices", but it's the same issue. There are instances in which it's possible to tell that a key is pre-shared among a group (e.g., if the same pre-shared key is bound to multiple IKE identities, and those IKE identities are in use simultaneously with the same counterparty), but in full generality determining whether a pre-shared key is only pairwise shared or shared among a larger group is the same sort of problem as determining whether Alice kept her password secret from Bob - if Bob knows Alice's password and logs in as Alice, it's very hard to figure out that this happened, especially if he does so from a system Alice uses regularly. Thanks, --David > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Wednesday, May 22, 2002 8:29 PM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed > resolution > > > > David, > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com > > > Black_David@emc.com@ece.cmu.edu on 05/22/2002 02:06:37 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: John Hufferd/San Jose/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed > resolution > > > > John, > > > The problem I am having with the proposal is, that I think we are > mandating > > customer actions not just implementation. > > To some extent, this is unavoidable, and we're already there > implicitly, as use of a low-entropy pre-shared key with IKE will > doubtless make IKE vulnerable in all sorts of undesirable ways. > For that matter, even SRP is only secure if the customer uses > it correctly (e.g., if Alice doesn't keep her password secret, > and Bob knows it, SRP will not protect Alice from Bob). > > > We are saying that if Chap passwords are used then they must > > do or must not do something else which is legal with IPsec. > > > > Since the IPsec process is really disjoint from the iSCSI > Login, there is > > no real way that we can tell what the customer did with > IPsec, and IKE. > > I don't think so. One can expect an IPsec implementation to > report the security policy and mechanisms (contents of the SPD, > and probably the SAD) that it is currently enforcing through > a suitably secured management interface. How to get access to > and use that interface would be up to the implementer combining > IPsec and iSCSI. > > > So some how I think the wordage needs to be adjusted to reflect this > > implementation vrs customer interaction, since I think the > only thing we > > can do is document on the packaging/directions, what should > or should not > > be done. > > Please propose new wording. > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- > > > From owner-ips@ece.cmu.edu Thu May 23 13:09:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18494 for ; Thu, 23 May 2002 13:09:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NGsZc17802 for ips-outgoing; Thu, 23 May 2002 12:54:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4NGsXw17798 for ; Thu, 23 May 2002 12:54:34 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4NGsSp09394 for ; Thu, 23 May 2002 12:54:28 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4NGsRc09382; Thu, 23 May 2002 12:54:27 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g4NGsQY17855; Thu, 23 May 2002 12:54:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15597.7882.981000.431753@gargle.gargle.HOWL> Date: Thu, 23 May 2002 12:54:34 -0400 From: Paul Koning To: luben@splentec.com Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: [iSCSI]: Key negotiation procedure proposal References: <3CED0AE8.23342500@splentec.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 23 May 2002) by Luben Tuikov: > But Julian, I'm _not_ talking here about discovering capabilities. > > This is just rules for Login/Text Operational Key Negotiation. > ... > Furthermore I don't think that this complicates negotiation, > If anything ,it makes it simpler. There is a rule for simple > implementations (Martins, your opinion?) and a rule > for fully developed implementations. > > It's just login/text negotiation rules. > > People, take a look at the rules and examples > and let me hear your opinion? (those of you > involved in login/text neg. discussions) I think it's unnecessarily complex. The "simple implementation" alone is plenty. paul From owner-ips@ece.cmu.edu Thu May 23 13:09:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18510 for ; Thu, 23 May 2002 13:09:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NGvrG18048 for ips-outgoing; Thu, 23 May 2002 12:57:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NGvpw18043 for ; Thu, 23 May 2002 12:57:51 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4NFuou09386; Thu, 23 May 2002 11:56:50 -0400 Message-ID: <3CED1F86.29394B25@splentec.com> Date: Thu, 23 May 2002 12:57:42 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bill Studenmund CC: iSCSI Subject: Re: [iSCSI]: Key negotiation procedure proposal References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Studenmund wrote: > > My only concern with this is that we now have to keep more state around; > we have to remember to send the key next negotiation, and the other side > has to know to send a blank message as part of that next negotiation. Yes, but as we already know negotiations are stateful! I.e. you have to remember what you sent! State: This can be accomplished by a linked list with status in each element. > Instead, why not just send it later in the first message? Because the Originator needs to know that its offer was Rejected. If it is a simple implementation it will close the connection with TCP FIN, else it will stick around for the rest of the negotiation, i.e. send more (other) key=value pairs or sent empty PDU as per the protocol. > > Let O: denote Originator and R: the Responder. > > > > Example 1: > > ---------- > > O: v = x --> > > <-- R: v = Reject > > > > O: "" --> > > <-- R: v = y > > We 1) make the negotiations happen faster, and 2) can keep less state > around (O doesn't need to send "", and R doesn't need to remmeber to send > v = y next time). The Originator _has_ to send something as are the rules of the protocol. This is very well described in the protocol. It may send OTHER variables for negotiation or just and empty PDU. As I mentioned the Originator has to know its offer failed so that it can then decide if it wants to close the connection with TCP FIN, or stick around (simple implementation vs. complete one) and send more (other) key=value pairs for negotiation. > All the implementations I've seen break the login text up one key/value > pair at a time, so seeing the same key twice won't cause a problem AFAICT. But this is not the rule, it is the exception. I negotiate all keys I can send in one packet! Please also note that the proposed negotiation procedure takes care of MULTIPLE key=value pairs being sent in each PDU, and their responses. This is important as not all implementations will send one variable at a time! I.e. to conserve time and bandwidth! Those negotiation procedure rules allow for the connection to survive even when all of the Originator keys have been Rejected, but the Responder sent back values acceptable by the Originator. I.e. complete ineroperability. -- Luben P.S. Those rules are the minimum consistent set of a larger set of rules which allow complete interoperability. Any mathematicians here? Bill, I suspect? From owner-ips@ece.cmu.edu Thu May 23 13:12:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18624 for ; Thu, 23 May 2002 13:12:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NGq2G17653 for ips-outgoing; Thu, 23 May 2002 12:52:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NGq1w17646 for ; Thu, 23 May 2002 12:52:01 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 12:50:41 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937925@CORPMX14> From: Black_David@emc.com To: wrstuden@wasabisystems.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution Date: Thu, 23 May 2002 12:50:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk [... various snips to focus on the SA replacement issue ...] > > The encryption can probably be removed by negotiating a new SA that > > doesn't encrypt and deleting the old one, but that still requires > > ESP integrity. > > Could we have a more complete example of this (SA changing in > mid-stride)? It is literally as described - the sender sets up a new SA, and deletes the old one. These are done via IKE in the usual fashion. > From talking with some IPsec implementers, it can be done. We > just will need to note a number of details to make sure we have it right. There is quite a bit of experience in getting IKE to interoperate - that's where most of the details are, and most of them aren't specific to this policy change. > One thing that will be needed is for us to be able to set policy on a > per-socket basis, and for us to be able to examine the policy > in place on a socket.That way a target can verify that a login is covered by > sufficiently-secure policy, and the initiator (and target) can adjust > policy (to relax it). Many/most IPsec implementations support this functionality locally (i.e., in the SPD/SAD). If per-socket granularity is needed, don't use an implementation that doesn't provide it. > There is of course the question of what to do if the other side doesn't > want to relax policy. :-) This'll be reflected in an IKE negotiation failure - the other side will refuse to set up the SA if it won't relax policy. Incompatible IKE policies can already result in inability to communicate - I don't know of any magic we can apply here. > A few other implementation notes. 1) some IPsec implementations will > continue using an older SA (the with-privacy one) for a while. That's why I used the words "and deleting the old one", as an implementation cannot use an SA that has been affirmatively deleted. The receiver needs to keep the old SA state around for a while to deal with in-flight packets, but a delete on the sender side had better cause an immediate switch to the new one. > 2) we need to have the initiator make sure it's using strong policy when > it does the CHAP phase - otherwise if it is logging back into a target > and happens to use a port number that it used before, the old (weaker) SA > might still be there. Yes. > I would prefer the key randomness be a MUST, so we can avoid this. While > rather doable, it will add more to the implementation complexity. Noted. With the current wording, if your implementation treats the key randomness as a MUST, it can avoid this. If you don't think the proposed text gets to this point, please point out where the problem is and suggest alternative wording. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu May 23 13:12:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18674 for ; Thu, 23 May 2002 13:12:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NGeWj16854 for ips-outgoing; Thu, 23 May 2002 12:40:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NGeTw16840 for ; Thu, 23 May 2002 12:40:29 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 12:39:09 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937924@CORPMX14> From: Black_David@emc.com To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution Date: Thu, 23 May 2002 12:39:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Milan, > I have also spoken to a few people with far more IPsec experience > than I. From the dazed expressions and dropped jaws, the sense I > get is that dynamic switching to more relaxed SAs is, how shall I > put this, not typical behavior? Legal, yes. Interoperably > implementable, probably. Ugly, not a doubt. FWIW, that was intended ... the "MUST use" IPsec ESP requirement is supposed to make the consequences of ignoring the SHOULD for machine- generated CHAP secrets so ugly/objectionable/etc. that it provides a powerful incentive to "do the right thing" and implement/use machine- generated CHAP secrets. Keep in mind that the "MUST use" *only applies* when the SHOULD for machine-generated strong CHAP secrets is ignored. Thanks for the backhanded confirmation that the requirement appears to have the intended/desired effect ;-). > I too would be far happier if we separated out the decision-bits again, > and let the end users decide > a) to allow their iSCSI implementations to authenticate each other > securely, > b) to provide privacy and/or enhanced integrity to the data sessions > as independent options. I think that's the intent. If CHAP is used with machine-generated strong secrets, the two aspects are independent. If CHAP is used with weak secrets such as passwords or hashes of passwords, see above. > It's bad enough to be appearing to legislate user behavior with a > "SHALL USE", but worse if it appears to be an arbitrary mandate > from above. As noted above, the intended target of that language is implementers who choose not to pay attention to the SHOULD. > I think the appropriate course here is to put in the > strong wording re selection of CHAP secrets, referencing the > available literature re potential exploits of dictionary keys. > Separately, recommend IPsec use for session privacy, > integrity, and identification verification, where appropriate > to the user's needs. Noted, thanks. At the risk of opening a serious Pandora's box, one of the underlying concerns in this area is that it's an ill-kept secret that many implementers are in the process of ignoring or sidestepping the "MUST implement" ESP and IKE requirements. It would be bad if they likewise ignored or sidestepped a MUST or SHOULD on appropriate generation/selection of CHAP secrets, hence the proposal for serious negative consequences of using weak secrets in order to put teeth into the requirement to use strong CHAP secrets. Important reminder: In the proposed language, if the implementation supports strong CHAP secrets and takes all reasonable measures to cause their use, the "MUST use" IPsec ESP requirement does not apply. "all reasonable measures" is the best that can be done due to the requirement to accept externally generated CHAP secrets - while these can be checked for sufficient length, there's no way to check them for sufficient entropy/randomness (e.g., there's no way to tell whether 96 bits that appear random were generated from electrical noise and really are random vs. generated by hashing (e.g., SHA-1) 0xdeadbeef, in which case they contain very little randomness). If anyone's reaction is "but the proposed text doesn't say that", please propose alternate text (e.g., concrete testable requirements for "all reasonable measures" - it might be possible to put MUSTs against those requirements in place of the "MUST use" IPsec ESP requirement). Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu May 23 13:13:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18692 for ; Thu, 23 May 2002 13:13:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NGgsr17051 for ips-outgoing; Thu, 23 May 2002 12:42:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NGgqw17046 for ; Thu, 23 May 2002 12:42:52 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4NGgk71035854 for ; Thu, 23 May 2002 18:42:46 +0200 Received: from d10hubm1.telaviv.ibm.com (d10hubm1.telaviv.ibm.com [9.148.216.39]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4NGfSW127804 for ; Thu, 23 May 2002 18:41:29 +0200 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: Old words left around To: "Julian Satran" Cc: "ips" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Thu, 23 May 2002 09:39:37 -0700 X-MIMETrack: Serialize by Router on D10HUBM1/10/H/IBM(Release 5.0.9a |January 7, 2002) at 23/05/2002 19:41:28 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk It is also at the top of page 181 in 12-92. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Julian Satran@IBMIL 05/23/2002 06:04 AM To: John Hufferd/San Jose/IBM@IBMUS@IBMDE cc: ips@ece.cmu.edu From: Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI: Old words left around (Document link: John Hufferd) What version - I can't find it in 12.91 - Julo John Hufferd@IBMUS To: Julian Satran/Haifa/IBM@IBMIL@IBMDE cc: ips@ece.cmu.edu 05/23/2002 03:19 From: John Hufferd/San Jose/IBM@IBMUS AM Subject: iSCSI: Old words left around Julian, I think I may have found some old words left around from earlier times. Top of 178, we say "...the restart option of the Login should be used." We should just delete the sentence, since we just explained how to do it, two sentences above that. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Thu May 23 13:13:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18730 for ; Thu, 23 May 2002 13:13:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NGN6315684 for ips-outgoing; Thu, 23 May 2002 12:23:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NGN4w15680 for ; Thu, 23 May 2002 12:23:04 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id D48B630706; Thu, 23 May 2002 12:23:03 -0400 (EDT) Date: Thu, 23 May 2002 09:21:06 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Luben Tuikov Cc: iSCSI , Julian Satran Subject: Re: [iSCSI]: Key negotiation procedure proposal In-Reply-To: <3CECF020.8ACFE673@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 23 May 2002, Luben Tuikov wrote: > I'm proposing the following key negotiation procedure. It > preserves the no-renegotiation of keys rule and all the > rules of login request and response currently used in the > draft (12-91). It applies to any kind of value (list, > boolean, integer, etc.). > > Simple implementations: > > Simple implementations SHOULD close the connection right > after Reject has been communicated. This ensures that the > reason for closing has been communicated to the peer. > > Regular implementations: > > Core rule: A negotiation of a key=value pair is > complete/finished when both the Originator and Responder > have sent their values (non-reserved keywords). > > The core rule implies the the following: > > If a Responder replies with Reject, then the Originator > SHOULD NOT renegotiate the rejected key. > > If a Responder replies with Reject, it SHOULD sent its value > of that key on the next reply to the Originator. My only concern with this is that we now have to keep more state around; we have to remember to send the key next negotiation, and the other side has to know to send a blank message as part of that next negotiation. Instead, why not just send it later in the first message? > If an Originator finds the response to an offered key=value > pair to be unacceptable, it SHOULD send Reject and close the > connection. > > Please note that the core rule above ensures that both the > Originator and Responder _know_ each other's values if the > connection is closed due to Reject. This will give the user > of each node more information to find out what went wrong. > That is, this kind of negotiation is exhaustive. > > Let O: denote Originator and R: the Responder. > > Example 1: > ---------- > O: v = x --> > <-- R: v = Reject > > O: "" --> > <-- R: v = y i.e. O: v = x --> <-- R: v = Reject <-- R: v = y We 1) make the negotiations happen faster, and 2) can keep less state around (O doesn't need to send "", and R doesn't need to remmeber to send v = y next time). All the implementations I've seen break the login text up one key/value pair at a time, so seeing the same key twice won't cause a problem AFAICT. > O: 1) v = y is OK, continue as normal, > 2) v = y is unacceptable, > > v = Reject --> > close the connection (reason just given). > > > Example 2: > ---------- > O: v = x --> > <-- R: v = y > > O: 1) v = y is OK, continue, as normal, > > 2) v = y is unacceptable, > > v = Reject --> > > close the connection (reason just given). Except for the above, looks good. Take care, Bill From owner-ips@ece.cmu.edu Thu May 23 13:14:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18757 for ; Thu, 23 May 2002 13:14:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NH70v18619 for ips-outgoing; Thu, 23 May 2002 13:07:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NH6ww18609 for ; Thu, 23 May 2002 13:06:58 -0400 (EDT) Received: from chamao (chamao [147.11.45.39]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id KAA15374; Thu, 23 May 2002 10:05:43 -0700 (PDT) From: "Michael Krueger" To: "Julian Satran" , Subject: RE: iSCSI base64 and 12-92 Date: Thu, 23 May 2002 10:06:48 -0700 Message-ID: <006b01c2027c$398ce350$272d0b93@chamao.wrs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, May 23, 2002 7:07 AM, Julian Satran wrote: > As we have to keep them for numbers I reinstated them for small values too > (why implement a check) and for those that don't take > numerical big-endian representation for granted there is now text that > says it without referring to internal representation. Retaining base-64 encoding for normal-sized numbers (size less than or equal to the machine's largest arithmetic word size, usually 32 or 64 bits) may make the language in the spec simpler, but it does NOT simplify implementation by eliminating a check; in fact, it would require additional checks and implementation complexity. Keys that can contain large numbers (larger than the machine's largest arithmetic word size) must be handled differently from normal-sized numbers anyway, precisely because they are beyond the machine's normal arithmetic capabilities; therefore, a check based on the key type must be done no matter what. If the spec requires support for base-64 encoding for normal-sized numbers, implementers will also have to check for the "0b" prefix, pass the string off to a base-64 decoding routine (taking care not to overflow the machine's word size), and then properly pad, byte-swap, and cast the result, or, if "0b" was not found, call strtol() instead. This seems like needless implementation complexity to support something NOBODY will do, i.e., specify a normal-sized number like MaxConnections in base 64! If the base-64 requirement for normal-sized numbers were dropped, a single call to strtol() would suffice. In short, let's keep it simple: decimal and hexadecimal representations for normal-sized numbers, hexadecimal and base-64 representations for binary items and large-sized numbers. (I would still argue that "large-sized numbers" are just a special case of binary items, but that's a fine point.) Michael -- Michael J. Krueger mailto:michael.krueger@windriver.com Wind River Networks http://www.windriver.com 500 Wind River Way phone: 510-749-2130 Alameda, CA 94501 fax: 510-749-2010 From owner-ips@ece.cmu.edu Thu May 23 13:18:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18898 for ; Thu, 23 May 2002 13:18:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NGvjp18033 for ips-outgoing; Thu, 23 May 2002 12:57:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4NGvhw18027 for ; Thu, 23 May 2002 12:57:43 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4NGvbp09474 for ; Thu, 23 May 2002 12:57:37 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4NGvbc09462; Thu, 23 May 2002 12:57:37 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g4NGvaL17965; Thu, 23 May 2002 12:57:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15597.8072.734000.462828@gargle.gargle.HOWL> Date: Thu, 23 May 2002 12:57:44 -0400 From: Paul Koning To: wrstuden@wasabisystems.com Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI base64 and 12-92 References: X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 23 May 2002) by Bill Studenmund: > On Thu, 23 May 2002, Julian Satran wrote: > > > Dear colleagues, > > > > I looked again at cryptography needs and I think that large numbers will > > be needed and base64 is a decent and not invented here way to express > > them. > > Just curious, which alogorythm needs them? I was wondering the same. Quite possibly I muddled things by talking earlier about cases that don't actually appear in iSCSI. The ones that DO appear in iSCSI all involve strings, not numbers. (That includes SRP -- it uses large integers at some steps of the algorithm, but externally at the protocol level it is specified in terms of strings.) Apart from that, I don't see any reason at all why that means we should allow Base64 for "ordinary" integers. I remember a number of comments objecting to that idea and none in favor of it, nor any reason why it should be done. So why do it? paul From owner-ips@ece.cmu.edu Thu May 23 13:54:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20344 for ; Thu, 23 May 2002 13:54:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NHBsG18931 for ips-outgoing; Thu, 23 May 2002 13:11:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NHBqw18927 for ; Thu, 23 May 2002 13:11:52 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4NGAcu09471; Thu, 23 May 2002 12:10:38 -0400 Message-ID: <3CED22C2.D4117F81@splentec.com> Date: Thu, 23 May 2002 13:11:30 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: [iSCSI]: Key negotiation procedure proposal References: <3CED0AE8.23342500@splentec.com> <15597.7882.981000.431753@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Paul Koning wrote: > > I think it's unnecessarily complex. The "simple implementation" alone > is plenty. Certainly! But if we want more than that, then mathematics tells me that those are the rules. (I.e. those are the minimum consistent set of rules which achieve the task at hand. It also tells me that there is no ``in the middle'' implementation.) Please also note that ``simple implementations'' can co-exist with ``complete impementations''. It's just that complete ones will get the TCP FIN, when rejecting a simple implementation's key=value pair, or just TCP FIN if the simple implementation rejected theirs. Julian, most of the negotiation the way we have it now, already observes most of those rules. And as to your request ``if they can be proven useful'' -- a few examples on your own will convince even the most doubtful heart. :-) -- Luben P.S. I just don't want to end up writing a paper about this (co-authors welcome) as it happened for CRC32C. From owner-ips@ece.cmu.edu Thu May 23 13:56:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20377 for ; Thu, 23 May 2002 13:56:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NHYWc20402 for ips-outgoing; Thu, 23 May 2002 13:34:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4NHYTw20395 for ; Thu, 23 May 2002 13:34:29 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4NHYOp10458 for ; Thu, 23 May 2002 13:34:24 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4NHYNc10446; Thu, 23 May 2002 13:34:23 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g4NHYMQ18861; Thu, 23 May 2002 13:34:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15597.10279.246000.572079@gargle.gargle.HOWL> Date: Thu, 23 May 2002 13:34:31 -0400 From: Paul Koning To: Black_David@emc.com Cc: wrstuden@wasabisystems.com, ips@ece.cmu.edu Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution References: <277DD60FB639D511AC0400B0D068B71E02937925@CORPMX14> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 23 May 2002) by Black_David@emc.com: > [... various snips to focus on the SA replacement issue ...] > > > > The encryption can probably be removed by negotiating a new SA that > > > doesn't encrypt and deleting the old one, but that still requires > > > ESP integrity. > > > > Could we have a more complete example of this (SA changing in > > mid-stride)? > > It is literally as described - the sender sets up a new SA, and deletes > the old one. These are done via IKE in the usual fashion. Unfortunately, it's NOT the usual fashion. It would be extremely unusual, to say the least, for an IPsec implementation to be willing to offer both encrypted and unencrypted SAs to the same destination. It is probably true that the protocol permits it, but as Milan pointed out, IPsec implementers will give you very funny looks if you suggest this to them. paul From owner-ips@ece.cmu.edu Thu May 23 14:41:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22467 for ; Thu, 23 May 2002 14:41:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NIAMG22699 for ips-outgoing; Thu, 23 May 2002 14:10:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NIAKw22695 for ; Thu, 23 May 2002 14:10:20 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id A622630706; Thu, 23 May 2002 14:10:19 -0400 (EDT) Date: Thu, 23 May 2002 11:08:22 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Luben Tuikov Cc: iSCSI Subject: Re: [iSCSI]: Key negotiation procedure proposal In-Reply-To: <3CED1F86.29394B25@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 23 May 2002, Luben Tuikov wrote: > Bill Studenmund wrote: > > > > My only concern with this is that we now have to keep more state around; > > we have to remember to send the key next negotiation, and the other side > > has to know to send a blank message as part of that next negotiation. > > Yes, but as we already know negotiations are stateful! > I.e. you have to remember what you sent! True, but you are proposing negotiation add an extra state, "partly sent." i.e. we've sent a Reject, and need to send a value next time. Before all we needed to remember is what we want to negotiate, what we have negotiated, and what we'll accept for new negotiations. Now we have to remember that we are in the middle of a reject/reoffer. > State: This can be accomplished by a linked list with status > in each element. It can, but we don't have to, so why should we? > > Instead, why not just send it later in the first message? > > Because the Originator needs to know that its offer was > Rejected. If it is a simple implementation it will close > the connection with TCP FIN, else it will stick around > for the rest of the negotiation, i.e. send more (other) > key=value pairs or sent empty PDU as per the protocol. That statement doesn't make sense. The originator WILL know its offer was rejected; there's a "key=Reject" in the login payload. I don't understand how the fact that's a reject isn't clear to the originator. I'm suggesting that we not wait for a future packet pair to send the value we would be happy with. As you so strongly pointed out, we can have multiple key=value tuples, why not repeat this key twice, once to indicate reject, and once to indicate our value. Thus the originator gets all the info it needs very quickly, we save a packet pair, and we don't need to add more state. i.e. addlen = snprintf(buffer, "%s=Reject\000%s=%s", key, key, newval); to generate the text response for this negotiation step. > > > Let O: denote Originator and R: the Responder. > > > > > > Example 1: > > > ---------- > > > O: v = x --> > > > <-- R: v = Reject > > > > > > O: "" --> > > > <-- R: v = y > > > > We 1) make the negotiations happen faster, and 2) can keep less state > > around (O doesn't need to send "", and R doesn't need to remmeber to send > > v = y next time). > > The Originator _has_ to send something as are the rules > of the protocol. This is very well described in the protocol. > It may send OTHER variables for negotiation or just and empty > PDU. > > As I mentioned the Originator has to know its offer failed > so that it can then decide if it wants to close the connection > with TCP FIN, or stick around (simple implementation vs. complete one) > and send more (other) key=value pairs for negotiation. You snipped my diagram, so I can't explain how we took exactly different spins on it. As above, I wasn't talking about two packets from the responder, but two key/value pairs that share the same key in the same text payload of one login response. > > All the implementations I've seen break the login text up one key/value > > pair at a time, so seeing the same key twice won't cause a problem AFAICT. > > But this is not the rule, it is the exception. > > I negotiate all keys I can send in one packet! So do I. > Please also note that the proposed negotiation procedure > takes care of MULTIPLE key=value pairs being sent in each PDU, > and their responses. And my suggestion was to make use of that ability to make it so we don't have the extra pair of packets you described. :-) > This is important as not all implementations will > send one variable at a time! I.e. to conserve > time and bandwidth! > > Those negotiation procedure rules allow for the connection > to survive even when all of the Originator keys have been Rejected, > but the Responder sent back values acceptable by the Originator. > I.e. complete ineroperability. And I think it's a good idea. It also clarifies the use of Reject. With the tweak I suggested above, it just happens faster. :-) Take care, Bill From owner-ips@ece.cmu.edu Thu May 23 14:42:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22548 for ; Thu, 23 May 2002 14:42:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NHwbf21967 for ips-outgoing; Thu, 23 May 2002 13:58:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NHwYw21963 for ; Thu, 23 May 2002 13:58:34 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 13:57:04 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937926@CORPMX14> From: Black_David@emc.com To: ranga@netapp.com Cc: ips@ece.cmu.edu Subject: RE: Flipped locations between d11 and d12. Date: Thu, 23 May 2002 13:56:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The new notation has a long history of use in networking specifications and is required (not just "preferred") in all IETF standards-track RFCs. See the "Bit and Byte order in drawings" Section of http://www.ietf.org/ID-nits.html It's unfortunate that we caught the need to make this change relatively late in the process, but the change does need to be made ... otherwise the draft will be returned to the WG with instructions to make the change. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Sankar, Ranga [mailto:ranga@netapp.com] > Sent: Wednesday, May 22, 2002 12:28 PM > To: 'Julian Satran' > Cc: 'ips@ece.cmu.edu'; Pittman, Joseph > Subject: RE: Flipped locations between d11 and d12. > > > The new notation is counter intuitive and causes confusion. > If there is no specific reasoni would prefer it to be the way it > was in earlier drafts (D11). > > -ranga > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Wednesday, May 22, 2002 1:35 AM > > To: Sankar, Ranga > > Cc: 'ips@ece.cmu.edu'; Julian Satran > > Subject: Re: Flipped locations between d11 and d12. > > > > > > > > It is no mistake. It is only that this new notation is the > > one preferred by > > the RFC editor. > > > > Julo > > > > > > > > > > "Sankar, Ranga" > > > > > "'ips@ece.cmu.edu'" > > > > app.com> cc: > > Julian Satran/Haifa/IBM@IBMIL > > > > Subject: > > Flipped locations between d11 and d12. > > > > 05/21/2002 10:54 > > > > PM > > > > Please respond to > > > > "Sankar, Ranga" > > > > > > > > > > > > > > > > > > > > Looks like the bit locations are flipped between Version 11 and 12. > > > > For example Bit 0 of Byte 1 corresponds to T bit in Version 12 > > In Version 11 and below Bit 7 of Byte 1 corresponds to T bit. > > > > Is this intended or an error in the draft. > > > > Version 12 > > > > Login Response > > Byte / 0 | 1 | 2 > | 3 > > | > > |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| > > <--------- > > . . 0x23 > > > > Version 11 > > Byte / 0 | 1 | 2 | 3 | / | | | | > > |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| > > <---------- > > +---------------+---------------+---------------+---------------+ > > 0|.|.| 0x23 |T|0 0 0|CSG|NSG| Version-max | > > Version-active| > > > > -ranga > > > > > > > > > From owner-ips@ece.cmu.edu Thu May 23 14:43:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22590 for ; Thu, 23 May 2002 14:43:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NI1RO22138 for ips-outgoing; Thu, 23 May 2002 14:01:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NI1Qw22133 for ; Thu, 23 May 2002 14:01:26 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 14:01:20 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937927@CORPMX14> From: Black_David@emc.com To: ni1d@arrl.net Cc: ips@ece.cmu.edu Subject: iSCSI - SA change Date: Thu, 23 May 2002 14:00:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Can we put an end to this rathole please? This discussion thread is about helping out implementers who ignore a SHOULD, an exercise that strikes me as increasingly pointless. Thanks, --David > Excerpt of message (sent 23 May 2002) by Black_David@emc.com: > > [... various snips to focus on the SA replacement issue ...] > > > > > > The encryption can probably be removed by negotiating a > new SA that > > > > doesn't encrypt and deleting the old one, but that > still requires > > > > ESP integrity. > > > > > > Could we have a more complete example of this (SA changing in > > > mid-stride)? > > > > It is literally as described - the sender sets up a new SA, > and deletes > > the old one. These are done via IKE in the usual fashion. > > Unfortunately, it's NOT the usual fashion. It would be extremely > unusual, to say the least, for an IPsec implementation to be willing > to offer both encrypted and unencrypted SAs to the same destination. > > It is probably true that the protocol permits it, but as Milan pointed > out, IPsec implementers will give you very funny looks if you suggest > this to them. > > paul > From owner-ips@ece.cmu.edu Thu May 23 14:43:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22608 for ; Thu, 23 May 2002 14:43:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NIQxZ23892 for ips-outgoing; Thu, 23 May 2002 14:26:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13705.mail.yahoo.com (web13705.mail.yahoo.com [216.136.175.138]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4NIQtw23880 for ; Thu, 23 May 2002 14:26:55 -0400 (EDT) Message-ID: <20020523182654.46189.qmail@web13705.mail.yahoo.com> Received: from [192.52.58.5] by web13705.mail.yahoo.com via HTTP; Thu, 23 May 2002 11:26:54 PDT Date: Thu, 23 May 2002 11:26:54 -0700 (PDT) From: Martins Krikis Subject: Re: iSCSI: list negotiation description To: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I looked at 12-90. I hadn't seen the announcements for newer drafts. My fault. So 12-92 does not have the text I was referring to anymore, which is good, thanks. However, since it still says "MAY use the constant Reject", can we know what other options there are? I.e., why "MAY" and not "MUST"? (This is now page 73 of 12-92.) Martins Krikis, Intel Corp. --- Julian Satran wrote: > What version did you look at? Considering the date > of your mail it must > have been 12-91 only that 12-91 does not contain the > text you quote - Julo > > > > > Martins Krikis > Sent by: owner-ips@ece.cmu.edu > 05/23/2002 12:37 AM > Please respond to Martins Krikis > > > To: ips@ece.cmu.edu > cc: > Subject: iSCSI: list negotiation > description > > > > First a question again: > > What is the point of allowing "inadmissible > values" (or in case of lists, lack of acceptable > values) be answered with an "admissible value"? > > Now the problems. > > Page 69, bottom paragraph: > > If a responder does support, understand or > is allowed to use none of the offered options > with a specific originator, it MAY use the > constant "Reject" or it MAY respond with an > admissible value. The selection of a value > not offered is considered a negotiation > failure and is handled as a protocol error. > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10066.html > made me believe that the phrase "or it MAY respond > with an admissible value..." will be removed. > > Since it hasn't been, I'll point out again that > it contradicts the very next sentence, because > this "admissible value" would be a "value not > offered". > Also, I must say that I almost regret having > started picking on the beginning of this paragraph, > because IMHO it has gotten worse. I'm still > proposing this: > > If each of the offered values is not understood > or not supported, or the responder is not allowed > to use it with the specific originator, it MUST > use the constant "Reject". > > Note that because other reasonable alternatives > are eliminated, the original "MAY" can change to > "MUST". (Which should be a good thing, BTW.) > > Thanks, > > Martins Krikis, Intel Corp. > > Disclaimer: these opinions are my own and may not > not be those of my employer > > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > > > __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Thu May 23 15:26:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23735 for ; Thu, 23 May 2002 15:26:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NIqE225717 for ips-outgoing; Thu, 23 May 2002 14:52:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NIqAw25703 for ; Thu, 23 May 2002 14:52:10 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 7F37330706; Thu, 23 May 2002 14:52:09 -0400 (EDT) Date: Thu, 23 May 2002 11:50:12 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Luben Tuikov Cc: iSCSI Subject: Re: [iSCSI]: Key negotiation procedure proposal In-Reply-To: <3CED1F86.29394B25@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 23 May 2002, Luben Tuikov wrote: > Those negotiation procedure rules allow for the connection > to survive even when all of the Originator keys have been Rejected, > but the Responder sent back values acceptable by the Originator. > I.e. complete ineroperability. One thing I wanted to make clear. I like Luben's idea. The main thing I like about it is we have ambiguity in how we handle negotiations now, and this change 1) removes the ambiguity, and 2) encorporates elements that others seem to want in negotiation. My one thought though is we can, as mentioned in other messages, close Luben's Reject behavior more quickly; we can do it and keep total negotiations down to one login pdu each direction. :-) Take care, Bill From owner-ips@ece.cmu.edu Thu May 23 15:28:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23778 for ; Thu, 23 May 2002 15:28:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NJ0A326255 for ips-outgoing; Thu, 23 May 2002 15:00:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NJ08w26251 for ; Thu, 23 May 2002 15:00:08 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4NHxAu09958; Thu, 23 May 2002 13:59:10 -0400 Message-ID: <3CED3C32.B157663A@splentec.com> Date: Thu, 23 May 2002 15:00:02 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bill Studenmund CC: iSCSI Subject: Re: [iSCSI]: Key negotiation procedure proposal References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill Studenmund wrote: > > That statement doesn't make sense. I didn't see that you meant to send the Responder's offer along with the responder's Reject. I see what you mean. > I'm suggesting that we not wait for a future packet pair to send the value > we would be happy with. As you so strongly pointed out, we can have > multiple key=value tuples, why not repeat this key twice, once to indicate > reject, and once to indicate our value. Thus the originator gets all the > info it needs very quickly, we save a packet pair, and we don't need to > add more state. This certianly sounds reasonable. I'm happy with that. So to make it more formal, the second implied rule should read: If a Responder replies with Reject, it SHOULD sent its value of that key on the same reply to the Originator.  To recap: --------------------- Simple implementations: Simple implementations SHOULD close the connection right after Reject has been communicated. This ensures that the reason for closing has been communicated to the peer. Regular implementations: Core rule: A negotiation of a key=value pair is complete/finished when both the Originator and Responder have sent their values (non-reserved keywords). The core rule implies the the following: If a Responder replies with Reject, then the Originator SHOULD NOT renegotiate the rejected key. If a Responder replies with Reject, it SHOULD send its value of that key in the same reply PDU to the Originator after the key=Reject pair. If an Originator finds the response to an offered key=value pair to be unacceptable, it SHOULD send Reject and close the connection. ------------------ Well people, what do you think? Bill, thanks for your analysis and support. -- Luben From owner-ips@ece.cmu.edu Thu May 23 15:32:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23874 for ; Thu, 23 May 2002 15:32:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NJ9vS26818 for ips-outgoing; Thu, 23 May 2002 15:09:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NJ9sw26809 for ; Thu, 23 May 2002 15:09:54 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id F30D530706; Thu, 23 May 2002 15:09:53 -0400 (EDT) Date: Thu, 23 May 2002 12:07:57 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Luben Tuikov Cc: iSCSI Subject: Re: [iSCSI]: Key negotiation procedure proposal In-Reply-To: <3CED3C32.B157663A@splentec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 23 May 2002, Luben Tuikov wrote: > Bill Studenmund wrote: > > This certianly sounds reasonable. I'm happy with that. > So to make it more formal, the second implied rule should > read: > > If a Responder replies with Reject, it SHOULD sent its value > of that key on the same reply to the Originator. >  > To recap: > --------------------- > Simple implementations: > > Simple implementations SHOULD close the connection right > after Reject has been communicated. This ensures that the > reason for closing has been communicated to the peer. > > Regular implementations: > > Core rule: A negotiation of a key=value pair is > complete/finished when both the Originator and Responder > have sent their values (non-reserved keywords). > > The core rule implies the the following: > > If a Responder replies with Reject, then the Originator > SHOULD NOT renegotiate the rejected key. > > If a Responder replies with Reject, it SHOULD send its value > of that key in the same reply PDU to the Originator after the > key=Reject pair. > > If an Originator finds the response to an offered key=value > pair to be unacceptable, it SHOULD send Reject and close the > connection. > ------------------ > > Well people, what do you think? Sounds good. I think it's fairly clean, and direct for implementors to work with. :-) > Bill, thanks for your analysis and support. No problem. Take care, Bill From owner-ips@ece.cmu.edu Thu May 23 16:20:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25660 for ; Thu, 23 May 2002 16:19:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NJcai28934 for ips-outgoing; Thu, 23 May 2002 15:38:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13701.mail.yahoo.com (web13701.mail.yahoo.com [216.136.175.134]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4NJcYw28930 for ; Thu, 23 May 2002 15:38:34 -0400 (EDT) Message-ID: <20020523193834.15021.qmail@web13701.mail.yahoo.com> Received: from [192.52.58.5] by web13701.mail.yahoo.com via HTTP; Thu, 23 May 2002 12:38:34 PDT Date: Thu, 23 May 2002 12:38:34 -0700 (PDT) From: Martins Krikis Subject: Re: [iSCSI]: Key negotiation procedure proposal To: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, I'm afraid I'm agreeing with Bill or Paul more here than with you. The simple version looks perfectly acceptable. I would not mandate closing the connection, since I am also perfectly happy considering (on both sides) the Reject-ed key to be "negotiated to the current value" (i.e., negotiated, but the value doesn't change on commit). But even if closing is mandated, that's fine with me. In fact, it is simpler so should be preferable. If we go into the more complex version, where you propose to let the originator know what values would have made the responder happy... hmm... First of all what you propose looks like renegotion to me. It's now originating from the other side, so it is kind-of justifyable and explainable. However, just like Bill I don't like having to send the key again in the next sequence. It does require some new values for the state of the key. Something like "received and rejected, but not yet sent". Every new possibility for a state means more checks upon reception and possibly even when sending each key. Repeating the same key in the same PDU sounds better, since then no new state is necessary (sent+received) suffices. Or does it? What if there is no space to send the key again in the same PDU and it has to be left for the next time? Then it does need this extra state again. Also, if it does get Reject-ed by the other side (original Originator, now Responder), we don't want to treat it as a no-renegotiation violation, (unless we'll be closing the connection), so we may need state. To put it briefly, I think it still is too complicated. The less state we can get away with, the better. Speaking of mathematics, we have to express clearly what the requirements are, then we can start proving minimal sets of rules to satisfy those requirements. Do we have a requirement to let the other side know what values we would have accepted? I'm saying, let's just Reject what we don't like, close the connection if we wish, and if the other side doesn't like it, its admin can give our admin a call and find what values we like. > > Example 2: > > ---------- > > O: v = x --> > > <-- R: v = y > > > > O: 1) v = y is OK, continue, as normal, > > > > 2) v = y is unacceptable, > > > > v = Reject --> > > > > close the connection (reason just given). I don't quite get this one. How can y be unacceptable? Did it violate the selection rules? If so, it's a protocol error. We can just close the connection or send the Reject PDU (not a key=Reject thing), or send a Login Response with bad status, then close the connection, it all depends of who we are. In summary, I think I'm happy with what's currently in 12-92, i.e., a key used twice by the same side is a no-renegotiation violation. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Thu May 23 16:21:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25700 for ; Thu, 23 May 2002 16:21:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NJehE29114 for ips-outgoing; Thu, 23 May 2002 15:40:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NJefw29107 for ; Thu, 23 May 2002 15:40:41 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4NJeVHr036794; Thu, 23 May 2002 21:40:31 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4NJeUg80404; Thu, 23 May 2002 21:40:30 +0200 To: Paul Koning Cc: ips@ece.cmu.edu, wrstuden@wasabisystems.com MIME-Version: 1.0 Subject: Re: iSCSI base64 and 12-92 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 23 May 2002 22:40:26 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 23/05/2002 22:40:31, Serialize complete at 23/05/2002 22:40:31 Content-Type: multipart/alternative; boundary="=_alternative 006AF5BEC2256BC2_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006AF5BEC2256BC2_= Content-Type: text/plain; charset="us-ascii" If base 64 is neede for large integers there is no good reason to test that it is not used for short integers. Julo Paul Koning 05/23/2002 07:57 PM Please respond to Paul Koning To: wrstuden@wasabisystems.com cc: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu Subject: Re: iSCSI base64 and 12-92 Excerpt of message (sent 23 May 2002) by Bill Studenmund: > On Thu, 23 May 2002, Julian Satran wrote: > > > Dear colleagues, > > > > I looked again at cryptography needs and I think that large numbers will > > be needed and base64 is a decent and not invented here way to express > > them. > > Just curious, which alogorythm needs them? I was wondering the same. Quite possibly I muddled things by talking earlier about cases that don't actually appear in iSCSI. The ones that DO appear in iSCSI all involve strings, not numbers. (That includes SRP -- it uses large integers at some steps of the algorithm, but externally at the protocol level it is specified in terms of strings.) Apart from that, I don't see any reason at all why that means we should allow Base64 for "ordinary" integers. I remember a number of comments objecting to that idea and none in favor of it, nor any reason why it should be done. So why do it? paul --=_alternative 006AF5BEC2256BC2_= Content-Type: text/html; charset="us-ascii"
If base 64 is neede for large integers there is no good reason to test that it is not used for short integers.

Julo


Paul Koning <ni1d@arrl.net>

05/23/2002 07:57 PM
Please respond to Paul Koning

       
        To:        wrstuden@wasabisystems.com
        cc:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        Subject:        Re: iSCSI base64 and  12-92

       


Excerpt of message (sent 23 May 2002) by Bill Studenmund:
> On Thu, 23 May 2002, Julian Satran wrote:
>
> > Dear colleagues,
> >
> > I looked again at cryptography needs and I think that large numbers will
> > be needed and base64 is a decent and not invented here way to express
> > them.
>
> Just curious, which alogorythm needs them?

I was wondering the same.  Quite possibly I muddled things by talking
earlier about cases that don't actually appear in iSCSI.  The ones
that DO appear in iSCSI all involve strings, not numbers.  (That
includes SRP -- it uses large integers at some steps of the algorithm,
but externally at the protocol level it is specified in terms of
strings.)

Apart from that, I don't see any reason at all why that means we
should allow Base64 for "ordinary" integers.  I remember a number of
comments objecting to that idea and none in favor of it, nor any
reason why it should be done.  So why do it?

      paul

--=_alternative 006AF5BEC2256BC2_=-- From owner-ips@ece.cmu.edu Thu May 23 16:24:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25815 for ; Thu, 23 May 2002 16:24:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NJekc29126 for ips-outgoing; Thu, 23 May 2002 15:40:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NJegw29113; Thu, 23 May 2002 15:40:42 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4NJeaHr050792; Thu, 23 May 2002 21:40:36 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4NJeZg117102; Thu, 23 May 2002 21:40:35 +0200 To: Martins Krikis Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: list negotiation description X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 23 May 2002 22:40:28 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 23/05/2002 22:40:35, Serialize complete at 23/05/2002 22:40:35 Content-Type: multipart/alternative; boundary="=_alternative 006BEFE6C2256BC2_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006BEFE6C2256BC2_= Content-Type: text/plain; charset="us-ascii" In fact - depending on what it rejects - it may also decide to terminate the connection (e.g., a security negotiation with unacceptable parameters). It is probably better to make this explicit as in: If a responder does not understand any particular value in a list it MUST ignore it. If a responder does support, understand or is allowed to use none of the offered options with a specific originator, it may use the constant "Reject" or terminate the negotiation. Julo Martins Krikis Sent by: owner-ips@ece.cmu.edu 05/23/2002 09:26 PM Please respond to Martins Krikis To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: list negotiation description I looked at 12-90. I hadn't seen the announcements for newer drafts. My fault. So 12-92 does not have the text I was referring to anymore, which is good, thanks. However, since it still says "MAY use the constant Reject", can we know what other options there are? I.e., why "MAY" and not "MUST"? (This is now page 73 of 12-92.) Martins Krikis, Intel Corp. --- Julian Satran wrote: > What version did you look at? Considering the date > of your mail it must > have been 12-91 only that 12-91 does not contain the > text you quote - Julo > > > > > Martins Krikis > Sent by: owner-ips@ece.cmu.edu > 05/23/2002 12:37 AM > Please respond to Martins Krikis > > > To: ips@ece.cmu.edu > cc: > Subject: iSCSI: list negotiation > description > > > > First a question again: > > What is the point of allowing "inadmissible > values" (or in case of lists, lack of acceptable > values) be answered with an "admissible value"? > > Now the problems. > > Page 69, bottom paragraph: > > If a responder does support, understand or > is allowed to use none of the offered options > with a specific originator, it MAY use the > constant "Reject" or it MAY respond with an > admissible value. The selection of a value > not offered is considered a negotiation > failure and is handled as a protocol error. > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10066.html > made me believe that the phrase "or it MAY respond > with an admissible value..." will be removed. > > Since it hasn't been, I'll point out again that > it contradicts the very next sentence, because > this "admissible value" would be a "value not > offered". > Also, I must say that I almost regret having > started picking on the beginning of this paragraph, > because IMHO it has gotten worse. I'm still > proposing this: > > If each of the offered values is not understood > or not supported, or the responder is not allowed > to use it with the specific originator, it MUST > use the constant "Reject". > > Note that because other reasonable alternatives > are eliminated, the original "MAY" can change to > "MUST". (Which should be a good thing, BTW.) > > Thanks, > > Martins Krikis, Intel Corp. > > Disclaimer: these opinions are my own and may not > not be those of my employer > > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > > > __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com --=_alternative 006BEFE6C2256BC2_= Content-Type: text/html; charset="us-ascii"
In fact - depending on what it rejects - it may also decide to terminate the connection (e.g., a security negotiation with unacceptable parameters).
It is probably better to make this explicit as in:

If a responder does not understand any particular value in a list it MUST ignore it. If a responder does support, understand or is allowed to use none of the offered options with a specific originator, it may use the constant "Reject" or terminate the negotiation.

Julo


Martins Krikis <mkrikis@yahoo.com>
Sent by: owner-ips@ece.cmu.edu

05/23/2002 09:26 PM
Please respond to Martins Krikis

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        Re: iSCSI: list negotiation description

       


I looked at 12-90. I hadn't seen the announcements
for newer drafts. My fault. So 12-92 does not have
the text I was referring to anymore, which is good,
thanks. However, since it still says "MAY use the
constant Reject", can we know what other options
there are? I.e., why "MAY" and not "MUST"?
(This is now page 73 of 12-92.)

 Martins Krikis, Intel Corp.


--- Julian Satran <Julian_Satran@il.ibm.com> wrote:
> What version did you look at?  Considering the date
> of your mail it must
> have been 12-91 only that 12-91 does not contain the
> text you quote - Julo
>
>
>
>
> Martins Krikis <mkrikis@yahoo.com>
> Sent by: owner-ips@ece.cmu.edu
> 05/23/2002 12:37 AM
> Please respond to Martins Krikis
>
>  
>         To:     ips@ece.cmu.edu
>         cc:
>         Subject:        iSCSI: list negotiation
> description
>
>  
>
> First a question again:
>
> What is the point of allowing "inadmissible
> values" (or in case of lists, lack of acceptable
> values) be answered with an "admissible value"?
>
> Now the problems.
>
> Page 69, bottom paragraph:
>
>   If a responder does support, understand or
>   is allowed to use none of the offered options
>   with a specific originator, it MAY use the
>   constant "Reject" or it MAY respond with an
>   admissible value. The selection of a value
>   not offered is considered a negotiation
>   failure and is handled as a protocol error.
>
>
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10066.html
> made me believe that the phrase "or it MAY respond
> with an admissible value..." will be removed.
>
> Since it hasn't been, I'll point out again that
> it contradicts the very next sentence, because
> this "admissible value" would be a "value not
> offered".
> Also, I must say that I almost regret having
> started picking on the beginning of this paragraph,
> because IMHO it has gotten worse. I'm still
> proposing this:
>
>   If each of the offered values is not understood
>   or not supported, or the responder is not allowed
>   to use it with the specific originator, it MUST
>   use the constant "Reject".
>
> Note that because other reasonable alternatives
> are eliminated, the original "MAY" can change to
> "MUST". (Which should be a good thing, BTW.)
>
> Thanks,
>
>   Martins Krikis, Intel Corp.
>
> Disclaimer: these opinions are my own and may not
>             not be those of my employer
>
>
> __________________________________________________
> Do You Yahoo!?
> LAUNCH - Your Yahoo! Music Experience
> http://launch.yahoo.com
>
>
>


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

--=_alternative 006BEFE6C2256BC2_=-- From owner-ips@ece.cmu.edu Thu May 23 16:30:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26092 for ; Thu, 23 May 2002 16:30:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NK5qB00824 for ips-outgoing; Thu, 23 May 2002 16:05:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4NK5nw00813 for ; Thu, 23 May 2002 16:05:49 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4NK5lp15404 for ; Thu, 23 May 2002 16:05:47 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4NK5lc15395; Thu, 23 May 2002 16:05:47 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g4NK5kj23650; Thu, 23 May 2002 16:05:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15597.19362.938000.44684@gargle.gargle.HOWL> Date: Thu, 23 May 2002 16:05:54 -0400 From: Paul Koning To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu, wrstuden@wasabisystems.com Subject: Re: iSCSI base64 and 12-92 References: X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 23 May 2002) by Julian Satran: > If base 64 is neede for large integers there is no good reason to test > that it is not used for short integers. Not true. They are fundamentally different datatypes. "short" integers are int, or long, or something like that. Large integers are a software-defined datatype, typically an octetstring perhaps with additional control variables. See any bignum package for the details. The conversion routines used for these two are completely different and quite unrelated. paul From owner-ips@ece.cmu.edu Thu May 23 17:00:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27083 for ; Thu, 23 May 2002 16:59:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NKXSa02601 for ips-outgoing; Thu, 23 May 2002 16:33:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail2.hd.intel.com (hdfdns02.hd.intel.com [192.52.58.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NKXRw02597 for ; Thu, 23 May 2002 16:33:27 -0400 (EDT) Received: from mkrikis-laptop (mkrikis-laptop.hd.intel.com [10.127.144.226]) by mail2.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.39 2002/05/13 20:36:23 root Exp $) with ESMTP id g4NKXLQ15652 for ; Thu, 23 May 2002 20:33:21 GMT Received: from martinsk by mkrikis-laptop with local (Exim 3.35 #1 (Debian)) id 17B0Cj-0000Mv-00 for ; Thu, 23 May 2002 16:33:01 -0500 To: ips@ece.cmu.edu Subject: Re: [iSCSI]: Key negotiation procedure proposal Message-Id: From: Martins Krikis Date: Thu, 23 May 2002 16:33:01 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, Luben, Sorry, my previous response was already somewhat dated. Hard to keep up with you. :-) > Regular implementations: > > Core rule: A negotiation of a key=value pair is > complete/finished when both the Originator and Responder > have sent their values (non-reserved keywords). > > The core rule implies the the following: > > If a Responder replies with Reject, then the Originator > SHOULD NOT renegotiate the rejected key. Does it mean it should not send or does it mean "should not send with a non-reserved value"? > If a Responder replies with Reject, it SHOULD send its value > of that key in the same reply PDU to the Originator after the > key=Reject pair. There is the problem that it may not fit. If we leave it for the next round, we have to remember that the state for this key is such. In order to avoid this problem, we could use the key only once, but use a list of values: first element "Reject", next elements whatever was the value (or value list) that the Responder would like. But, that's another big complication, so I am NOT proposing it. > If an Originator finds the response to an offered key=value > pair to be unacceptable, it SHOULD send Reject and close the > connection. But then the Responder (who both Reject-ed and responded to the key) must remember that it not only sent the key but also rejected the key, i.e., sent a value that does not necessarily fit in the selection rules and which is not guaranteed to be liked by the Originator, because if it is not liked, this Originator most likely will send a Reject, which is not to be treated as a no-renegotionation violation but just as a harmless little Reject. Thus, I think we need more state for this. But we gain the knowledge of what values the other side likes. I like the latter feature of course, but hate introducing more state. Plus I was getting to feel happy about the current situation. If the goal of this is to have a way to figure out what the other side likes, perhaps it is simpler to reinstate the "key=?" syntax, with the changed semantics, that the Responder must send its acceptable values (not current). This would not count as a start of a new negotiation, of course, so no extra state here. I.e., O: k=u,v,w (I want (in order of preference) u, v or w) R: k=Reject (But I hate all of those) O: k=? (What do you like then?) R: k=x,y,z (I like (in order of preference) x, y and z) Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. From owner-ips@ece.cmu.edu Thu May 23 17:30:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28087 for ; Thu, 23 May 2002 17:30:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NKqcW03792 for ips-outgoing; Thu, 23 May 2002 16:52:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from snjspop1.snjs.qwest.net (snjspop1.snjs.qwest.net [168.103.24.1]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4NKqXw03776 for ; Thu, 23 May 2002 16:52:33 -0400 (EDT) Received: (qmail 97883 invoked from network); 23 May 2002 20:52:33 -0000 Received: from 168-103-214-76.dslgw2.snva.qwest.net (HELO theglowmonster) (168.103.214.76) by snjspop1.snjs.qwest.net with SMTP; 23 May 2002 20:52:33 -0000 Date: Thu, 23 May 2002 13:50:59 -0700 Message-ID: From: "Randy Jennings" To: "Bill Studenmund" , "Luben Tuikov" Cc: "iSCSI" Subject: RE: [iSCSI]: Key negotiation procedure proposal MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit A minor note on a weird possibility. There is a remote chance that the PDU with both keys could span PDU's by adding up to more than the MaxPDULength or whatever it ends up being called. As such, I do not think you could mandate it be in the same PDU, but that it be next in the Login stream. I think this falls under, "I know what you meant, just say it." For example: O ----> key=[some really long and obnoxious value that just barely fits in the PDU size]/000 <--------T key=Reject/000 key=[some really long and obnoxious value that does not fit in the PDU size] O --------> "" <--------T [the remnants]/000 At least, that is how I remember it working. Sincerely, Randy Jennings Data Transit From owner-ips@ece.cmu.edu Thu May 23 17:34:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28264 for ; Thu, 23 May 2002 17:34:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NLCjt05012 for ips-outgoing; Thu, 23 May 2002 17:12:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NLCfw05001 for ; Thu, 23 May 2002 17:12:41 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id D86CD30706; Thu, 23 May 2002 17:12:40 -0400 (EDT) Date: Thu, 23 May 2002 14:10:44 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Randy Jennings Cc: Luben Tuikov , iSCSI Subject: RE: [iSCSI]: Key negotiation procedure proposal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 23 May 2002, Randy Jennings wrote: > A minor note on a weird possibility. > > There is a remote chance that the PDU with both keys could span PDU's by > adding up to more than the MaxPDULength or whatever it ends up being called. > As such, I do not think you could mandate it be in the same PDU, but that it > be next in the Login stream. I think this falls under, "I know what you > meant, just say it." True, and I thought I was addressing that, but the words didn't do what I meant. I wanted to say that the second response should be later in the same login negotiation blob. i.e. that which can span multiple PDUs. Do we have a term for that? Take care, Bill From owner-ips@ece.cmu.edu Thu May 23 17:34:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28314 for ; Thu, 23 May 2002 17:34:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NL1a404341 for ips-outgoing; Thu, 23 May 2002 17:01:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NL1Xw04335 for ; Thu, 23 May 2002 17:01:34 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 17:01:17 -0400 Message-ID: From: Sanjay Goyal To: "'ips@ece.cmu.edu'" Subject: iSCSI: Data-In PDU having MaxBurstSize restriction for a sequence Date: Thu, 23 May 2002 17:01:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi What is the rational behind having MaxBurstSize constraining a Sequence for Data-In PDUs? As Initiator has to receive all the data from Target as Data-In PDUs anyway, what good is it to set F-bit every MaxBurstSize? It rather should be set, after whatever amount of data Target has in its buffer has been transmitted. Would somebody suggest a good example when Initiator can take advantage of F-bit being set every MaxBurstSize. I understand that A-bit is used in conjuction with MaxBurstSize, however my context of the question is when A-bit is not used. Regards Sanjay Goyal From owner-ips@ece.cmu.edu Thu May 23 18:24:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29384 for ; Thu, 23 May 2002 18:24:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NLs4w07505 for ips-outgoing; Thu, 23 May 2002 17:54:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NLs2w07500 for ; Thu, 23 May 2002 17:54:02 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id AF36330706; Thu, 23 May 2002 17:54:01 -0400 (EDT) Date: Thu, 23 May 2002 14:52:05 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Paul Koning , Subject: Re: iSCSI base64 and 12-92 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 23 May 2002, Julian Satran wrote: > If base 64 is neede for large integers there is no good reason to test > that it is not used for short integers. I respectfully disagree. base64 is awkward for numbers, as it is not a numerical encoding. At least if the length of the number (in octets) is variable. 1, 2, 4, and 8 octet numbers are fine. But 3, 5, 6, and 7 are just plain gross. We have to load them into a correspondingly larger data type (32 or 64-bit unsigned int as appropriate), and then mask off unsent bytes. Oh, and if we're on an LE box, we then have to byte-swap the thing. Julo, have you actually coded a base64 decoder for the small (less than 2^64) ints we use in the protocol and verified its correctness? I will admit I haven't but that's because as I worked on it, it got very gross. And for no discernalbe benefit. Yes, we can do it. But I'd rather put the effort verifying this would take into making some other part of the code work well. I think what would be much easier for us is to just say that base64 is only usable for binary strings. Period. If there is a authentication protocol that needs to exchange large numbers that does not also specify the wire-format for said numbers, I suggest that for iSCSI we specify that the authentication protocol must provide the iSCSI negotiation code with a binary string representing/containing the number. The iSCSI negotiation code then passes said string to the authentication code on the other side. The code on the other side then interprets the string as a number. Yes, this is a semantics step. But it means that we can get rid of exchanging numbers so large that we would really like base64 - from iscsi's point of view they are binary strings. The iscsi infrastructure doesn't need to bother with trying to think of them as numbers. Take care, Bill From owner-ips@ece.cmu.edu Thu May 23 18:25:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29405 for ; Thu, 23 May 2002 18:25:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NLnxK07283 for ips-outgoing; Thu, 23 May 2002 17:49:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NLnmw07268 for ; Thu, 23 May 2002 17:49:48 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4NKmju10800; Thu, 23 May 2002 16:48:45 -0400 Message-ID: <3CED63F1.D6A74595@splentec.com> Date: Thu, 23 May 2002 17:49:37 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Martins Krikis CC: ips@ece.cmu.edu Subject: Re: [iSCSI]: Key negotiation procedure proposal References: <20020523193834.15021.qmail@web13701.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Martins Krikis wrote: > > I'm afraid I'm agreeing with Bill or Paul more here > than with you. In other words you'd use ``simple implementation'' rule. That is fine. > First of all what you propose looks like > renegotion to me. It is NOT, since the Originator is NOT allowed to send the same key twice, see implied rule 1. (If a Responder replies with Reject, then the Originator SHOULD NOT renegotiate the rejected key.) > However, just like Bill I don't like having to > send the key again in the next sequence. This has already been finalized -- see the mailing list. > What if there is no space to send the key again > in the same PDU and it has to be left for the > next time? You could put it right after: e.g. [BHS+[opt]]key=Reject\000key=reponder_value\000... > Then it does need this extra state > again. Also, if it does get Reject-ed by the > other side (original Originator, now Responder), > we don't want to treat it as a no-renegotiation > violation, (unless we'll be closing the connection), > so we may need state. Please note when this happens, there's no choice but to close the connection! I.e. both sides rejected each other's values -- this is the core rule, and the result of rejection on both sides == non-operability. Yes, you do need state at the originator. > To put it briefly, I think it still is too > complicated. The less state we can get away > with, the better. Well this is implementation issues. I think that the negotiation schematic is pretty simple, easiliy transferable into if () {} else {} etc. > Speaking of mathematics, we have to express clearly > what the requirements are, then we can start proving > minimal sets of rules to satisfy those requirements. I think that all here in this mailing list know what the requrements are -- interoperability. > Do we have a requirement to let the other side know > what values we would have accepted? I'm saying, let's > just Reject what we don't like, close the connection > if we wish, There is no other choice Martins -- is it? (Interoperability...) > > > Example 2: > > > ---------- > > > O: v = x --> > > > <-- R: v = y > > > > > > O: 1) v = y is OK, continue, as normal, > > > > > > 2) v = y is unacceptable, > > > > > > v = Reject --> > > > > > > close the connection (reason just given). > > I don't quite get this one. How can y be unacceptable? Say, its a mininum of some values and the Originator found y to be too small. Anyway, we have to cover all. > In summary, I think I'm happy with what's currently > in 12-92, i.e., a key used twice by the same side > is a no-renegotiation violation. Currently it looks like ``simple implementations'' with the added bonus of loops. First, Originator shouldn't ``guess'' and keep sending same_key=value pairs indefinitely. Second, in 4.2.2, 12-92, third change-bar from top has a inconsistenly problem (contradiction) as has been shown in this mailing list many times before. Depending on MAY 1) Reject, 2) send admissible value plus the next sentence ``not admissible by the selection rules...'' we get to a contradicion of negotiation... ? -- Luben From owner-ips@ece.cmu.edu Thu May 23 18:27:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29451 for ; Thu, 23 May 2002 18:27:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NMF3208710 for ips-outgoing; Thu, 23 May 2002 18:15:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NMF0w08694 for ; Thu, 23 May 2002 18:15:00 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 7932C30706; Thu, 23 May 2002 18:14:59 -0400 (EDT) Date: Thu, 23 May 2002 15:13:03 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Martins Krikis Cc: Subject: Re: [iSCSI]: Key negotiation procedure proposal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 23 May 2002, Martins Krikis wrote: > Bill, Luben, > > Sorry, my previous response was already somewhat dated. Hard to keep > up with you. :-) Heh! > > Regular implementations: > > > > Core rule: A negotiation of a key=value pair is > > complete/finished when both the Originator and Responder > > have sent their values (non-reserved keywords). > > > > The core rule implies the the following: > > > > If a Responder replies with Reject, then the Originator > > SHOULD NOT renegotiate the rejected key. > > Does it mean it should not send or does it mean "should not send > with a non-reserved value"? I took it as "should not send with a non-reserved value". The Originator either gets to accept that the Responder can do, or it shuts down the connection. I'm afraid that if we don't do something like that, we can end up with negotiations that don't terminate or converge. > > If a Responder replies with Reject, it SHOULD send its value > > of that key in the same reply PDU to the Originator after the > > key=Reject pair. > > There is the problem that it may not fit. If we leave it for the > next round, we have to remember that the state for this key is such. > In order to avoid this problem, we could use the key only once, > but use a list of values: first element "Reject", next elements > whatever was the value (or value list) that the Responder would > like. But, that's another big complication, so I am NOT proposing it. I think we need some more terminology. When you support SPKM and Kerberos authentication protocols, you must be able to receive 64k of text. This text is going to come in multiple PDUs. What do we want to call this blob of text? Stage? SO the above would be: "If a Responder replies with Reject, it SHOULD send its value of that key in the same reply *stage* to the Originator after the key=Reject pair." ?? Another word? Yes, it can be in a different PDU, but it has to be in the same negotiation step. > > If an Originator finds the response to an offered key=value > > pair to be unacceptable, it SHOULD send Reject and close the > > connection. > > But then the Responder (who both Reject-ed and responded to the key) > must remember that it not only sent the key but also rejected the > key, i.e., sent a value that does not necessarily fit in the selection > rules and which is not guaranteed to be liked by the Originator, > because if it is not liked, this Originator most likely will > send a Reject, which is not to be treated as a no-renegotionation > violation but just as a harmless little Reject. Maybe what we sould do is if the originator is the initiator, when it choses to reject, it closes the connection. Only when the originator is the target does it then send a Reject key. It also returns a non-zero status indicating that the connection is ending. That way we perform the minimum steps required by the protocol to end things. > Thus, I think we need more state for this. But we gain the knowledge > of what values the other side likes. I like the latter feature > of course, but hate introducing more state. Plus I was getting > to feel happy about the current situation. > > If the goal of this is to have a way to figure out what the other > side likes, perhaps it is simpler to reinstate the "key=?" > syntax, with the changed semantics, that the Responder must > send its acceptable values (not current). This would not count > as a start of a new negotiation, of course, so no extra state here. > > I.e., > > O: k=u,v,w (I want (in order of preference) u, v or w) > R: k=Reject (But I hate all of those) > O: k=? (What do you like then?) > R: k=x,y,z (I like (in order of preference) x, y and z) That wouldn't work with Luben's definitions. We could change them to make it work, but I'm not sure if it's worth it. We'd be opening up the non-convergence potential problems. While I think the key=? syntax can be useful, I'm not sure if we want to use it as above. I'm just not sure how to enforce that negotiations terminate. Take care, Bill From owner-ips@ece.cmu.edu Thu May 23 18:27:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29464 for ; Thu, 23 May 2002 18:27:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NM8gs08316 for ips-outgoing; Thu, 23 May 2002 18:08:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NM8ew08312 for ; Thu, 23 May 2002 18:08:40 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4NL7gu10921; Thu, 23 May 2002 17:07:42 -0400 Message-ID: <3CED6862.EB1BAA9F@splentec.com> Date: Thu, 23 May 2002 18:08:34 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Martins Krikis CC: ips@ece.cmu.edu Subject: Re: [iSCSI]: Key negotiation procedure proposal References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Martins Krikis wrote: > > > Regular implementations: > > > > Core rule: A negotiation of a key=value pair is > > complete/finished when both the Originator and Responder > > have sent their values (non-reserved keywords). > > > > The core rule implies the the following: > > > > If a Responder replies with Reject, then the Originator > > SHOULD NOT renegotiate the rejected key. > > Does it mean it should not send or does it mean "should not send > with a non-reserved value"? It means that the Originator SHOULD NOT send any more offers. (key=another-value(s)) > > If a Responder replies with Reject, it SHOULD send its value > > of that key in the same reply PDU to the Originator after the > > key=Reject pair. > There is the problem that it may not fit. Yes, Randy mentioned this already and gave an excellent example. Well, this is an open question. Anyone? > > If an Originator finds the response to an offered key=value > > pair to be unacceptable, it SHOULD send Reject and close the > > connection. > > But then the Responder (who both Reject-ed and responded to the key) > must remember that it not only sent the key but also rejected the > key, i.e., sent a value that does not necessarily fit in the selection NO! it must only remember the value of the key it sent! The Originator will 1) close the connection with Reject, 2) accept the value quetly. (I can know, implied rule 1, but we have to STOP somewhere or we'll never get to FF phase :-)) > rules and which is not guaranteed to be liked by the Originator, > because if it is not liked, this Originator most likely will > send a Reject, which is not to be treated as a no-renegotionation > violation but just as a harmless little Reject. key=Reject is never considered renegotiation, since there is no valid value being offered! > Thus, I think we need more state for this. But we gain the knowledge > of what values the other side likes. I like the latter feature > of course, but hate introducing more state. Plus I was getting > to feel happy about the current situation. Oh, well, there is the ``simple implementation'' rule. Please remember that there is always the ``simple implementation'' rule (compatible with ``regular implementation''). If the people feel comfortable with the logic then, some may implement ``simple'' others may implement ``regular'', both will interoperate and will get the job done. > O: k=u,v,w (I want (in order of preference) u, v or w) > R: k=Reject (But I hate all of those) > O: k=? (What do you like then?) > R: k=x,y,z (I like (in order of preference) x, y and z) This will never work since ``k(R) Intersection k(O) = Empty''. If it did, then O: cheated in its offer! (and should be banned from operating ;-)) -- Luben From owner-ips@ece.cmu.edu Thu May 23 19:24:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00308 for ; Thu, 23 May 2002 19:24:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NMqb510797 for ips-outgoing; Thu, 23 May 2002 18:52:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13702.mail.yahoo.com (web13702.mail.yahoo.com [216.136.175.135]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4NMqZw10793 for ; Thu, 23 May 2002 18:52:35 -0400 (EDT) Message-ID: <20020523225235.71611.qmail@web13702.mail.yahoo.com> Received: from [192.52.58.5] by web13702.mail.yahoo.com via HTTP; Thu, 23 May 2002 15:52:35 PDT Date: Thu, 23 May 2002 15:52:35 -0700 (PDT) From: Martins Krikis Subject: Re: [iSCSI]: Key negotiation procedure proposal To: Luben Tuikov Cc: ips@ece.cmu.edu In-Reply-To: <3CED63F1.D6A74595@splentec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, I'm not sure whether what you are proposing is or is not an improvement to the current situation, but unless it is perfect, we have no chance of changing anything. So here are my comments. > In other words you'd use ``simple implementation'' > rule. That is fine. No. I'm not that kind of guy. I'd make an implementation that could behave either as the simple one or as the complex one, depending on how it's configured to behave. :-) > > First of all what you propose looks like > > renegotion to me. > > It is NOT, since the Originator is NOT allowed > to send the same key twice, see implied rule 1. > (If a Responder replies with Reject, then the > Originator > SHOULD NOT renegotiate the rejected key.) But the Responder may, yes I know, I understand. All I was trying to say is that after a key has traveled in both direction seeing it travel again _looks_ like a renegotiation. Period. That's true even for my (later and not too serious) key=? reinstantement proposal. I understand that you could define what a renegotiation is and exempt this case because it hasn't yet traveled in that direction together with an unreserved value. But then we need more state than now. So, I understand that you don't call this a renegotiation, but I don't consider it beautiful either. Sorry. > > However, just like Bill I don't like having to > > send the key again in the next sequence. > > This has already been finalized -- see the > mailing list. Mails crossed over the wires. I can't help the lag. > > What if there is no space to send the key again > > in the same PDU and it has to be left for the > > next time? > > You could put it right after: e.g. > [BHS+[opt]]key=Reject\000key=reponder_value\000... Of course I would put it right after. Why would I wait? But that does not guarantee that it will fit. So what now? Adjusting the state, of course. > > Then it does need this extra state > > again. Also, if it does get Reject-ed by the > > other side (original Originator, now Responder), > > we don't want to treat it as a no-renegotiation > > violation, (unless we'll be closing the > connection), > > so we may need state. > > Please note when this happens, there's no > choice but to close the connection! > I.e. both sides rejected each other's > values -- this is the core rule, and the result > of rejection on both sides == non-operability. I know! But I should just close the connection now and log that I have met an incompatible Originator instead of sending X-vendor-blah-login-reject-reason=duplicate_key and then close it. Subtle nuanses maybe, but my admin may like to know. > Yes, you do need state at the originator. A super-nice implementation needs it on both sides. And more than currently. That's the reason I'm not yet crazy about this proposal. Once the protocol can work with as much or less state, I'll be more agreeable. > I think that the negotiation schematic is pretty > simple, easiliy transferable into if () {} else {} > etc. I think it is more complicated than the current situation, where I've got already plenty of all kinds of flags. I'm reluctant to introduce more. > I think that all here in this mailing list know > what the requrements are -- interoperability. If we're speaking mathematics, we will need to get more precise. > > Do we have a requirement to let the other side > know > > what values we would have accepted? I'm saying, > let's > > just Reject what we don't like, close the > connection > > if we wish, > > There is no other choice Martins -- is it? > (Interoperability...) Other choice than closing? Yes---we can keep it open and consider it negotiated for commit purposes, yet the value won't change. Other choice than interoperability? No, I guess there isn't. But interoperability can be easier achieved with sides not sending junk to the other side, than requiring rejecting sides to show what they would have liked... > > > > Example 2: > > > > ---------- > > > > O: v = x --> > > > > <-- R: v = y > > > > > > > > O: 1) v = y is OK, continue, as normal, > > > > > > > > 2) v = y is unacceptable, > > > > > > > > v = Reject --> > > > > > > > > close the connection (reason just given). > > > > I don't quite get this one. How can y be > > unacceptable? > > Say, its a mininum of some values and the Originator > found y to be too small. It shouldn't find it too small. I don't think that's allowed. For those kind of things we have ranges. If using a range in negotiation is not allowed, then a compliant implementation should be happy with any number that can be obtained by applying the selection rule (min or max, so far) to the number it supplied and to any number in the acceptable range. Alright, so here we have a chance to get more words in the draft (whichever way it is). > > In summary, I think I'm happy with what's > currently > > in 12-92, i.e., a key used twice by the same side > > is a no-renegotiation violation. > > Currently it looks like ``simple implementations'' > with the added bonus of loops. Your example of loops (unless there have been more) was based on the possibility of renegotiation. The way I understand it (confirmed by a private email from Julian) renegotiation is now disallowed. Yes, even for Rejects, Irrelevants and NotUnderstoods. The phrase that Pat suggested got added in 12-92, except the last sentence. I have asked Julian why. Plus, loops aren't as tragic as is complicating the protocol. I don't mind having a configurable counter that puts an upper bound on the number of negotiation rounds. That's one variable per all keys, instead of additional if/else cases to be done for each key. But the way I see it, we cannot have loops anymore. So what we have is like your "simple version", except that closing the connection is not mandated. And simplicity is good. If we mandate closure, I'm fine with that too. In fact, I think it is the best, but not by an amount worth fighting for. > First, Originator shouldn't ``guess'' and keep > sending > same_key=value pairs indefinitely. He no longer can. That would be a renegotiation. > Second, in 4.2.2, 12-92, third change-bar from top > has a inconsistenly problem (contradiction) > as has been shown in this mailing list many times > before. > Depending on MAY 1) Reject, 2) send admissible value > plus the next sentence ``not admissible by the > selection rules...'' we get to a contradicion > of negotiation... Yes, true, not the clearest text. However, I actually object to the whole idea of cutting any slack to non-conforming Originators by not Reject-ing their keys and sending a "good value" instead. I don't think it is good. So I'm for the removal of this possibility first, and only if somebody convinces me about the value of it, then for making the text more precise. Take care, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Thu May 23 19:40:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00644 for ; Thu, 23 May 2002 19:40:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NNN7B12163 for ips-outgoing; Thu, 23 May 2002 19:23:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NNN5w12159 for ; Thu, 23 May 2002 19:23:05 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4NNN4Wo011300; Thu, 23 May 2002 19:23:04 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4NNN3K113352; Thu, 23 May 2002 17:23:03 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: [iSCSI]: Key negotiation procedure proposal To: Martins Krikis Cc: Luben Tuikov , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Thu, 23 May 2002 16:21:14 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/23/2002 05:23:02 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Martins said: "...However, I actually object to the whole idea of cutting any slack to non-conforming Originators by not Rejecting their keys and sending a "good value" instead. I don't think it is good. So I'm for the removal of this possibility...." I agree with this. I do not know if we have to end the connection after the Reject, but if the Originator sends it again, then shut down. I see no value in going on and on (like this thread). lets move to closure here. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Martins Krikis @ece.cmu.edu on 05/23/2002 03:52:35 PM Sent by: owner-ips@ece.cmu.edu To: Luben Tuikov cc: ips@ece.cmu.edu Subject: Re: [iSCSI]: Key negotiation procedure proposal Luben, I'm not sure whether what you are proposing is or is not an improvement to the current situation, but unless it is perfect, we have no chance of changing anything. So here are my comments. > In other words you'd use ``simple implementation'' > rule. That is fine. No. I'm not that kind of guy. I'd make an implementation that could behave either as the simple one or as the complex one, depending on how it's configured to behave. :-) > > First of all what you propose looks like > > renegotion to me. > > It is NOT, since the Originator is NOT allowed > to send the same key twice, see implied rule 1. > (If a Responder replies with Reject, then the > Originator > SHOULD NOT renegotiate the rejected key.) But the Responder may, yes I know, I understand. All I was trying to say is that after a key has traveled in both direction seeing it travel again _looks_ like a renegotiation. Period. That's true even for my (later and not too serious) key=? reinstantement proposal. I understand that you could define what a renegotiation is and exempt this case because it hasn't yet traveled in that direction together with an unreserved value. But then we need more state than now. So, I understand that you don't call this a renegotiation, but I don't consider it beautiful either. Sorry. > > However, just like Bill I don't like having to > > send the key again in the next sequence. > > This has already been finalized -- see the > mailing list. Mails crossed over the wires. I can't help the lag. > > What if there is no space to send the key again > > in the same PDU and it has to be left for the > > next time? > > You could put it right after: e.g. > [BHS+[opt]]key=Reject\000key=reponder_value\000... Of course I would put it right after. Why would I wait? But that does not guarantee that it will fit. So what now? Adjusting the state, of course. > > Then it does need this extra state > > again. Also, if it does get Reject-ed by the > > other side (original Originator, now Responder), > > we don't want to treat it as a no-renegotiation > > violation, (unless we'll be closing the > connection), > > so we may need state. > > Please note when this happens, there's no > choice but to close the connection! > I.e. both sides rejected each other's > values -- this is the core rule, and the result > of rejection on both sides == non-operability. I know! But I should just close the connection now and log that I have met an incompatible Originator instead of sending X-vendor-blah-login-reject-reason=duplicate_key and then close it. Subtle nuanses maybe, but my admin may like to know. > Yes, you do need state at the originator. A super-nice implementation needs it on both sides. And more than currently. That's the reason I'm not yet crazy about this proposal. Once the protocol can work with as much or less state, I'll be more agreeable. > I think that the negotiation schematic is pretty > simple, easiliy transferable into if () {} else {} > etc. I think it is more complicated than the current situation, where I've got already plenty of all kinds of flags. I'm reluctant to introduce more. > I think that all here in this mailing list know > what the requrements are -- interoperability. If we're speaking mathematics, we will need to get more precise. > > Do we have a requirement to let the other side > know > > what values we would have accepted? I'm saying, > let's > > just Reject what we don't like, close the > connection > > if we wish, > > There is no other choice Martins -- is it? > (Interoperability...) Other choice than closing? Yes---we can keep it open and consider it negotiated for commit purposes, yet the value won't change. Other choice than interoperability? No, I guess there isn't. But interoperability can be easier achieved with sides not sending junk to the other side, than requiring rejecting sides to show what they would have liked... > > > > Example 2: > > > > ---------- > > > > O: v = x --> > > > > <-- R: v = y > > > > > > > > O: 1) v = y is OK, continue, as normal, > > > > > > > > 2) v = y is unacceptable, > > > > > > > > v = Reject --> > > > > > > > > close the connection (reason just given). > > > > I don't quite get this one. How can y be > > unacceptable? > > Say, its a mininum of some values and the Originator > found y to be too small. It shouldn't find it too small. I don't think that's allowed. For those kind of things we have ranges. If using a range in negotiation is not allowed, then a compliant implementation should be happy with any number that can be obtained by applying the selection rule (min or max, so far) to the number it supplied and to any number in the acceptable range. Alright, so here we have a chance to get more words in the draft (whichever way it is). > > In summary, I think I'm happy with what's > currently > > in 12-92, i.e., a key used twice by the same side > > is a no-renegotiation violation. > > Currently it looks like ``simple implementations'' > with the added bonus of loops. Your example of loops (unless there have been more) was based on the possibility of renegotiation. The way I understand it (confirmed by a private email from Julian) renegotiation is now disallowed. Yes, even for Rejects, Irrelevants and NotUnderstoods. The phrase that Pat suggested got added in 12-92, except the last sentence. I have asked Julian why. Plus, loops aren't as tragic as is complicating the protocol. I don't mind having a configurable counter that puts an upper bound on the number of negotiation rounds. That's one variable per all keys, instead of additional if/else cases to be done for each key. But the way I see it, we cannot have loops anymore. So what we have is like your "simple version", except that closing the connection is not mandated. And simplicity is good. If we mandate closure, I'm fine with that too. In fact, I think it is the best, but not by an amount worth fighting for. > First, Originator shouldn't ``guess'' and keep > sending > same_key=value pairs indefinitely. He no longer can. That would be a renegotiation. > Second, in 4.2.2, 12-92, third change-bar from top > has a inconsistenly problem (contradiction) > as has been shown in this mailing list many times > before. > Depending on MAY 1) Reject, 2) send admissible value > plus the next sentence ``not admissible by the > selection rules...'' we get to a contradicion > of negotiation... Yes, true, not the clearest text. However, I actually object to the whole idea of cutting any slack to non-conforming Originators by not Reject-ing their keys and sending a "good value" instead. I don't think it is good. So I'm for the removal of this possibility first, and only if somebody convinces me about the value of it, then for making the text more precise. Take care, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Thu May 23 20:19:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01429 for ; Thu, 23 May 2002 20:19:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NNakr12812 for ips-outgoing; Thu, 23 May 2002 19:36:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.isus.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NNaiw12806 for ; Thu, 23 May 2002 19:36:45 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 19:36:39 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937932@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: FW: Internet-Draft Cutoff Dates for Yokohama, Japan Date: Thu, 23 May 2002 19:35:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk From: Internet-Drafts Administrator [mailto:internet-drafts@ietf.org] Sent: Wednesday, May 22, 2002 3:01 PM Subject: Internet-Draft Cutoff Dates for Yokohama, Japan NOTE: There are two (2) Internet-Draft Cutoff dates June 24th: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, June 24th, at 09:00 US-EST. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, June 24th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of June 24th will NOT be accepted. July 1st: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, July 1st, 2002 at 09:00 US-EST. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concerns. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_54.html From owner-ips@ece.cmu.edu Thu May 23 20:19:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01442 for ; Thu, 23 May 2002 20:19:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NNweu13889 for ips-outgoing; Thu, 23 May 2002 19:58:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13706.mail.yahoo.com (web13706.mail.yahoo.com [216.136.175.139]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4NNwcw13885 for ; Thu, 23 May 2002 19:58:38 -0400 (EDT) Message-ID: <20020523235837.23337.qmail@web13706.mail.yahoo.com> Received: from [192.52.58.5] by web13706.mail.yahoo.com via HTTP; Thu, 23 May 2002 16:58:37 PDT Date: Thu, 23 May 2002 16:58:37 -0700 (PDT) From: Martins Krikis Subject: Re: [iSCSI]: Key negotiation procedure proposal To: Bill Studenmund Cc: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I'm gonna skip most of what I already commented on in response to Luben. > I think we need some more terminology. > > When you support SPKM and Kerberos authentication > protocols, you must be > able to receive 64k of text. This text is going to > come in multiple PDUs. > > What do we want to call this blob of text? Stage? SO > the above would be: > "If a Responder replies with Reject, it SHOULD send > its value > of that key in the same reply *stage* to the > Originator after the > key=Reject pair." > > ?? Another word? Yes, it can be in a different PDU, > but it has to be in > the same negotiation step. That's the problem---the "negotiation step". Currently a step is basically PDU-wide. You cannot force the other side to hold off answering before you've sent all the data that you want processed together. Since we need to know what physically went out on the wire and what didn't (to be able to process reception of same keys properly), we cannot just leave ready-to-be-sent text sittin in buffers. We cannot prepare a key=value unless we're sure it will fit. That's true in general, not just for this key=Reject\0Key=BetterValue\0 situation. I think we need a flag there to tell the other side to hold off processing. No replies necessary until the flag goes off. > > But then the Responder (who both Reject-ed and > responded to the key) > > must remember that it not only sent the key but > also rejected the > > key, i.e., sent a value that does not necessarily > fit in the selection > > rules and which is not guaranteed to be liked by > the Originator, > > because if it is not liked, this Originator most > likely will > > send a Reject, which is not to be treated as a > no-renegotionation > > violation but just as a harmless little Reject. > > Maybe what we sould do is if the originator is the > initiator, when it > choses to reject, it closes the connection. Only > when the originator is > the target does it then send a Reject key. It also > returns a non-zero > status indicating that the connection is ending. > That way we perform the > minimum steps required by the protocol to end > things. I don't know, but it doesn't sound simple anymore. It would be good to preserve symmetry. And actually, we probably shouldn't talk about closing the connection too much as negotiation reset or Reject PDU are similar alternatives for Text Requests/Rsps. > > O: k=u,v,w (I want (in order of > preference) u, v or w) > > R: k=Reject (But I hate all of > those) > > O: k=? (What do you like > then?) > > R: k=x,y,z (I like (in order of > preference) x, y and z) > > That wouldn't work with Luben's definitions. We > could change them to make > it work, but I'm not sure if it's worth it. We'd be > opening up the > non-convergence potential problems. I didn't intend this to fit in with Luben's definitions but with the current ones. The O: key=? is meant to be entirely optional, in fact. Anyway, I don't need this, but I think it is a more natural way to get the "other side's values". > While I think the key=? syntax can be useful, I'm > not sure if we want to > use it as above. I'm just not sure how to enforce > that negotiations > terminate. That's now simple. There is no renegotiation possible. Empty requests discouraged, so it should not take too long. There are no strict guarantees (and would not be even with Luben's proposal) because of empty requests/responses. In general, a counter of "negotiation rounds" and an upper bound is simpler than extra rules. In fact, I don't mind the no-renegotiation rule thrown out altogether. All I ever wanted was that if it's used then it's used for everything (including reserved values). Take care, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Thu May 23 20:22:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01467 for ; Thu, 23 May 2002 20:21:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NNYDk12672 for ips-outgoing; Thu, 23 May 2002 19:34:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13703.mail.yahoo.com (web13703.mail.yahoo.com [216.136.175.136]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4NNYBw12668 for ; Thu, 23 May 2002 19:34:11 -0400 (EDT) Message-ID: <20020523233411.37359.qmail@web13703.mail.yahoo.com> Received: from [192.52.58.5] by web13703.mail.yahoo.com via HTTP; Thu, 23 May 2002 16:34:11 PDT Date: Thu, 23 May 2002 16:34:11 -0700 (PDT) From: Martins Krikis Subject: Re: [iSCSI]: Key negotiation procedure proposal To: Luben Tuikov Cc: ips@ece.cmu.edu In-Reply-To: <3CED6862.EB1BAA9F@splentec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Luben Tuikov wrote: > > > If a Responder replies with Reject, then the > Originator > > > SHOULD NOT renegotiate the rejected key. > > > > Does it mean it should not send or does it mean > "should not send > > with a non-reserved value"? > > It means that the Originator SHOULD NOT send any > more offers. (key=another-value(s)) I knew. I should stop putting requests for more precision in the form of questions to which I know the answers. My fault. > > There is the problem that it may not fit. > > Yes, Randy mentioned this already and gave an > excellent > example. > > Well, this is an open question. Anyone? We can mandate that if the DataSegment does not end with a \0 (which would mean that all included key=value pairs are complete and terminated), then it should not be processed yet, but the next piece waited for to be concatenated with. And we'd drop the need to send PDUs in the other direction. This would be even better achieved with a flag in the header. I.e., if a (new) flag is set in the header of a Text/Login Request/Response PDU, then it means that more such PDUs are coming and their data is to be concatenated together (once the flag is unset in the last one) before processing. This would in fact allow a nice separation of the negotiation logic from the en/de-capsulator. (For example, if willing to send lots of values, the sender just dumps them to the encapsulator instead of worrying how many will fit and how many will need their state adjusted to be sent next (can't just mark them sent yet, because there may be surprises if they arrive)). In general the possibility of split data is a pain and any way to alleviate this pain would be very welcome by many, I suspect. > > > If an Originator finds the response to an > offered key=value > > > pair to be unacceptable, it SHOULD send Reject > and close the > > > connection. > > > > But then the Responder (who both Reject-ed and > responded to the key) > > must remember that it not only sent the key but > also rejected the > > key, i.e., sent a value that does not necessarily > fit in the selection > > NO! it must only remember the value of the key it > sent! You don't have to object yet, it gets clearer at the end of my paragraph. > The Originator will 1) close the connection with > Reject, > 2) accept the value quetly. (I can know, implied > rule 1, > but we have to STOP somewhere or we'll never get to > FF phase :-)) Stopping is not a problem. There is no renegotiation. Anyway, I've lost track here a little of what you're saying. > > rules and which is not guaranteed to be liked by > the Originator, > > because if it is not liked, this Originator most > likely will > > send a Reject, which is not to be treated as a > no-renegotionation > > violation but just as a harmless little Reject. > > key=Reject is never considered renegotiation, since > there is no > valid value being offered! For me seeing a key twice raises big red alarms. I look at the key first, IMHO, naturally. key=Reject is also wrong as an offer, so in order to allow for receiving it (w/o big red alarms either due to renegotion or due to "Reject in offer"), we have to prepare first. So we need more state than currently (for the ultra-fine implementations at least). And yes, connection will have to be closed, yet I'd like to know precisely the reason why. > Oh, well, there is the ``simple implementation'' > rule. > > Please remember that there is always the ``simple > implementation'' > rule (compatible with ``regular implementation''). And it is compatible with the current state of affairs as well. In fact, it is subsumed by the current protocol. It already allows Reject-ing a key and then closing the connection. Wait, there might be nuances for text vs. login. Anyway, very minor differences if any between your "simple implemention" and what would be currently already allowed. > If the people feel comfortable with the logic then, > some > may implement ``simple'' others may implement > ``regular'', > both will interoperate and will get the job done. Yes, but "regular" could, IMO, stay as it is. I now hold the view that there are no renegotiations possible. If other people don't, we have to keep asking Julian to clarify yet again and put it in a very visible place in the draft. > > O: k=u,v,w (I want (in order of > preference) u, v or w) > > R: k=Reject (But I hate all of > those) > > O: k=? (What do you like > then?) > > R: k=x,y,z (I like (in order of > preference) x, y and z) > > This will never work since ``k(R) Intersection k(O) > = Empty''. > If it did, then O: cheated in its offer! (and should > be banned > from operating ;-)) I didn't say it would work. I know the intersection is empty. I tried to show that learning what values the other side may like is more naturally done with inquiries than with forced depositions. The only improvement that I see from your proposal is that in case a value gets Reject-ed, the sender knows what values the other side would have liked. (Because most other things have been taken care of, I think.) But that effect can be achieved by an inquiry, not by protocol changes that require more state. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Thu May 23 20:22:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01486 for ; Thu, 23 May 2002 20:22:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4NNZvA12746 for ips-outgoing; Thu, 23 May 2002 19:35:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4NNZuw12739 for ; Thu, 23 May 2002 19:35:56 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4NNZmt00026 for ; Thu, 23 May 2002 19:35:48 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g4NNZl708327 for ; Thu, 23 May 2002 19:35:47 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 19:34:33 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937931@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI: FW: Last Call: Preparation of Internationalized Strings ( 'stringprep') to Proposed Standard Date: Thu, 23 May 2002 19:34:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-PerlMx-Spam: Gauge=XXIIIIIII, Probability=27%, Report="NO_REAL_NAME, SUBJ_HAS_SPACES" Sender: owner-ips@ece.cmu.edu Precedence: bulk The stringprep draft that international character support for iSCSI names depends on has just gone to IETF Last Call, FYI. --David -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Wednesday, May 22, 2002 11:13 AM Subject: Last Call: Preparation of Internationalized Strings ('stringprep') to Proposed Standard The IESG has received a request to consider Preparation of Internationalized Strings ('stringprep') as a Proposed Standard. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 4, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-03.txt From owner-ips@ece.cmu.edu Thu May 23 21:13:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02640 for ; Thu, 23 May 2002 21:13:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O0hW915850 for ips-outgoing; Thu, 23 May 2002 20:43:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13707.mail.yahoo.com (web13707.mail.yahoo.com [216.136.175.140]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4O0hUw15844 for ; Thu, 23 May 2002 20:43:30 -0400 (EDT) Message-ID: <20020524004329.91427.qmail@web13707.mail.yahoo.com> Received: from [192.52.58.5] by web13707.mail.yahoo.com via HTTP; Thu, 23 May 2002 17:43:29 PDT Date: Thu, 23 May 2002 17:43:29 -0700 (PDT) From: Martins Krikis Subject: Re: iSCSI base64 and 12-92 To: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Bill Studenmund wrote: > On Thu, 23 May 2002, Julian Satran wrote: > > > If base 64 is neede for large integers there is no > good reason to test > > that it is not used for short integers. > > I respectfully disagree. base64 is awkward for > numbers, as it is not a > numerical encoding. Me too. Base64 should not be allowed for anything that's currently negotiable in the operational stage. > At least if the length of the > number (in octets) is > variable. 1, 2, 4, and 8 octet numbers are fine. But > 3, 5, 6, and 7 are > just plain gross. We have to load them into a > correspondingly larger data > type (32 or 64-bit unsigned int as appropriate), and > then mask off > unsent bytes. Oh, and if we're on an LE box, we then > have to byte-swap the > thing. That's not really the problem. For encoding a small number in base64, you byte-swap if necessary, pass the leading 0-bytes (if any), then run your regular base64 encoding that operates on strings. For decoding, you run the decoder (that operates on strings) first, count the resulting bytes, move it in your 32-bit or 64-bit register from the "right end", add 0-bytes (if necessary) on the left end and byteswap. But since we know in advance whether a key can take just small numerical values or whether it can take large ones (actually, none do, they all take something to be looked up in various RFCs, which I doubt will call them "large numbers" anyway), we don't want to first check the key for 0b and then run it through the procedure given above. Just calling strtoul() is better. For those keys that can take large number values (even though I'm fairly sure that what's really needed there are binary strings happening to represent large numbers), we'll happily run just base64 decoders (and there will not be any need to move the result into 32-bit or 64-bit registers or byteswap). > Julo, have you actually coded a base64 decoder for > the small (less than > 2^64) ints we use in the protocol and verified its > correctness? I will > admit I haven't but that's because as I worked on > it, it got very gross. > And for no discernalbe benefit. Yes, we can do it. > But I'd rather put the > effort verifying this would take into making some > other part of the code > work well. A decoder is a decoder, it does work even on 0-length input. It works on strings, produces "binary strings". Putting the right number of 0-bytes to the left and byteswapping should not go in the decoder, it should be a separate thing, IMHO. But I also see no benefit in even allowing the small numbers to be given in any representation that cannot be thrown at strtoul() as is. > I think what would be much easier for us is to just > say that base64 is > only usable for binary strings. Period. Agreed. > If there is a authentication protocol that needs to > exchange large numbers > that does not also specify the wire-format for said > numbers, I suggest > that for iSCSI we specify that the authentication > protocol must provide > the iSCSI negotiation code with a binary string > representing/containing > the number. The iSCSI negotiation code then passes > said string to the > authentication code on the other side. The code on > the other side then > interprets the string as a number. Absolutely. > Yes, this is a semantics step. But it means that we > can get rid of > exchanging numbers so large that we would really > like base64 - from > iscsi's point of view they are binary strings. The > iscsi infrastructure > doesn't need to bother with trying to think of them > as numbers. Yes. If no, then where are the large numbers that we're worried about? I don't see any keys defined as taking large numbers for values yet. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Thu May 23 21:14:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02662 for ; Thu, 23 May 2002 21:14:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O0wBo16545 for ips-outgoing; Thu, 23 May 2002 20:58:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13703.mail.yahoo.com (web13703.mail.yahoo.com [216.136.175.136]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4O0w9w16540 for ; Thu, 23 May 2002 20:58:10 -0400 (EDT) Message-ID: <20020524005809.48346.qmail@web13703.mail.yahoo.com> Received: from [192.52.58.5] by web13703.mail.yahoo.com via HTTP; Thu, 23 May 2002 17:58:09 PDT Date: Thu, 23 May 2002 17:58:09 -0700 (PDT) From: Martins Krikis Subject: Re: [iSCSI]: Key negotiation procedure proposal To: Luben Tuikov , John Hufferd Cc: ips@ece.cmu.edu In-Reply-To: <3CED87F2.EF092B1B@splentec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Luben Tuikov wrote: > > I do not know if we have to end the connection > after the Reject, but if the > > Originator sends it again, then shut down. I see > no value in going on and > > on (like this thread). lets move to closure here. > > Ok, ``simple implementation'' handles this. And it's a good one. But it's a subset of what's currently allowed. Yes we could fight for restricting the current rules a little and thus hit your "simple implementation" proposal exactly, but, it's probably not worth doing it. > But, John, what else can we do after sending > key=Reject > _and_ inter-operate?! Live with former (possibly default values) or we don't interoperate. Why should I try my best to interoperate with somebody who is either incompatible with me (in case of list-value rejection) or who is sending me junk (simple-value rejection)? > We have to have some stringent rules, in order to > achieve inter-operability _and_ negotiation > convergence. If there is strict no-renegotiation (including keys answered with reserved values), which I now believe is the case, then there is little worry about convergence. And you need a counter anyway, to guard against never ending blank requests. As to interoperability, I'm saying "play tough" and soon everybody will be forced to play by the rules. > If you have a constructive suggestion (a rule, > ruleset, etc.), > please post it. We can just leave it as it is, perhaps stressing a little more that no key may ever travel twice in the same direction (regardless of value). Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Thu May 23 21:15:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02696 for ; Thu, 23 May 2002 21:15:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O0NYu14969 for ips-outgoing; Thu, 23 May 2002 20:23:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4O0NWw14965 for ; Thu, 23 May 2002 20:23:32 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4NNMNu11491; Thu, 23 May 2002 19:22:23 -0400 Message-ID: <3CED87F2.EF092B1B@splentec.com> Date: Thu, 23 May 2002 20:23:14 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Hufferd CC: Martins Krikis , ips@ece.cmu.edu Subject: Re: [iSCSI]: Key negotiation procedure proposal References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John Hufferd wrote: > > Martins said: > "...However, I actually object to the whole idea of cutting any slack to > non-conforming Originators by not Rejecting their keys and sending a "good > value" instead. I don't think it is good. So I'm for the removal of this > possibility...." > > I agree with this. > > I do not know if we have to end the connection after the Reject, but if the > Originator sends it again, then shut down. I see no value in going on and > on (like this thread). lets move to closure here. Ok, ``simple implementation'' handles this. But, John, what else can we do after sending key=Reject _and_ inter-operate?! We have to have some stringent rules, in order to achieve inter-operability _and_ negotiation convergence. If you have a constructive suggestion (a rule, ruleset, etc.), please post it. -- Luben From owner-ips@ece.cmu.edu Thu May 23 21:55:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03625 for ; Thu, 23 May 2002 21:55:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O1VC018049 for ips-outgoing; Thu, 23 May 2002 21:31:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4O1V5w18043 for ; Thu, 23 May 2002 21:31:05 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4O1V4FD126018; Thu, 23 May 2002 21:31:04 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4O1UwK205682; Thu, 23 May 2002 19:30:58 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: [iSCSI]: Key negotiation procedure proposal Rephrased To: Luben Tuikov Cc: Martins Krikis , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Thu, 23 May 2002 18:29:10 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/23/2002 07:30:58 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I am rephrasing the last note: There are two things, to do when the key=value comes in wrong... (That is after you respond with a Reject). 1. terminate the connection OR 2. continue but do not accept that key again.(If attempted, terminate the connection) a. What ever the defaults are, they stand. b. If there is no default, and the value is needed, terminate the connection. As for 1, it is simple and not an interoperability problem -- FIX the Problem. As for 2: * I do not think you need to be to formal here. Either defaults work, or they don't. If they don't, then terminate and Fix the problem. * I do not think this brings up interoperability problems. If it doesn't work, terminate and fix the problem. This is good enough. Pick 1 or 2 and lets stop polishing the error case. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Luben Tuikov @ns.splentec.com on 05/23/2002 05:23:14 PM Sent by: luben@ns.splentec.com To: John Hufferd/San Jose/IBM@IBMUS cc: Martins Krikis , ips@ece.cmu.edu Subject: Re: [iSCSI]: Key negotiation procedure proposal John Hufferd wrote: > > Martins said: > "...However, I actually object to the whole idea of cutting any slack to > non-conforming Originators by not Rejecting their keys and sending a "good > value" instead. I don't think it is good. So I'm for the removal of this > possibility...." > > I agree with this. > > I do not know if we have to end the connection after the Reject, but if the > Originator sends it again, then shut down. I see no value in going on and > on (like this thread). lets move to closure here. Ok, ``simple implementation'' handles this. But, John, what else can we do after sending key=Reject _and_ inter-operate?! We have to have some stringent rules, in order to achieve inter-operability _and_ negotiation convergence. If you have a constructive suggestion (a rule, ruleset, etc.), please post it. -- Luben From owner-ips@ece.cmu.edu Thu May 23 21:56:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03655 for ; Thu, 23 May 2002 21:56:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O1KvV17554 for ips-outgoing; Thu, 23 May 2002 21:20:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4O1JYw17501 for ; Thu, 23 May 2002 21:19:34 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4O1JXWo043380; Thu, 23 May 2002 21:19:33 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4O1JWj54878; Thu, 23 May 2002 19:19:32 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: [iSCSI]: Key negotiation procedure proposal To: Luben Tuikov Cc: Martins Krikis , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Thu, 23 May 2002 18:17:44 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/23/2002 07:19:32 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk There are two things, to do when the key=value come in wrong (after sending a reject): 1. terminate the connection OR 2. continue but do not accept that key again.(If attempted, terminate the connection) a. What ever the defaults are, they stand. b. If there is no default, and the value is needed, terminate the connection. As for 1, it is simple and not an interoperability problem -- FIX the Problem. As for 2: * I do not think you need to be to formal here. Either defaults work, or they don't. If they don't, then terminate and Fix the problem. * I do not think this brings up interoperability problems. If it doesn't work, terminate and fix the problem. This is good enough. Pick 1 or 2 and lets stop polishing the error case. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Luben Tuikov @ns.splentec.com on 05/23/2002 05:23:14 PM Sent by: luben@ns.splentec.com To: John Hufferd/San Jose/IBM@IBMUS cc: Martins Krikis , ips@ece.cmu.edu Subject: Re: [iSCSI]: Key negotiation procedure proposal John Hufferd wrote: > > Martins said: > "...However, I actually object to the whole idea of cutting any slack to > non-conforming Originators by not Rejecting their keys and sending a "good > value" instead. I don't think it is good. So I'm for the removal of this > possibility...." > > I agree with this. > > I do not know if we have to end the connection after the Reject, but if the > Originator sends it again, then shut down. I see no value in going on and > on (like this thread). lets move to closure here. Ok, ``simple implementation'' handles this. But, John, what else can we do after sending key=Reject _and_ inter-operate?! We have to have some stringent rules, in order to achieve inter-operability _and_ negotiation convergence. If you have a constructive suggestion (a rule, ruleset, etc.), please post it. -- Luben From owner-ips@ece.cmu.edu Thu May 23 21:57:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03668 for ; Thu, 23 May 2002 21:57:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O1Lih17612 for ips-outgoing; Thu, 23 May 2002 21:21:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4O1Lgw17607 for ; Thu, 23 May 2002 21:21:42 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 661E530706; Thu, 23 May 2002 21:21:41 -0400 (EDT) Date: Thu, 23 May 2002 18:19:45 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Martins Krikis Cc: Subject: Re: [iSCSI]: Key negotiation procedure proposal In-Reply-To: <20020523235837.23337.qmail@web13706.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 23 May 2002, Martins Krikis wrote: > I'm gonna skip most of what I already commented > on in response to Luben. That's fine. > > I think we need some more terminology. > > > > When you support SPKM and Kerberos authentication > > protocols, you must be > > able to receive 64k of text. This text is going to > > come in multiple PDUs. > > > > What do we want to call this blob of text? Stage? SO > > the above would be: > > "If a Responder replies with Reject, it SHOULD send > > its value > > of that key in the same reply *stage* to the > > Originator after the > > key=Reject pair." > > > > ?? Another word? Yes, it can be in a different PDU, > > but it has to be in > > the same negotiation step. > > That's the problem---the "negotiation step". > Currently a step is basically PDU-wide. You cannot > force the other side to hold off answering before > you've sent all the data that you want processed > together. Since we need to know what physically > went out on the wire and what didn't (to be able > to process reception of same keys properly), we > cannot just leave ready-to-be-sent text sittin > in buffers. We cannot prepare a key=value unless > we're sure it will fit. That's true in general, > not just for this key=Reject\0Key=BetterValue\0 > situation. I think we need a flag there to tell > the other side to hold off processing. No replies > necessary until the flag goes off. But we do! It's not a flag, but we do have the capability. I'm not spelled out as clearly as it might be, but here's references from 12-90. 9.12.10 Login Parameters (bottom of page 169) All the rules specified in Section 9.10.4 Text for text requests/ responses also hold for login requests/responses. Keys and their explanations are listed in Chapter 10 (security negotiation keys) and ... 9.10.4 describes how a text response can span multiple PDUs. 9.10.3 shows a text rexponse spanning multiple PDUs. It's not as clear as I think it should be, but my understanding (which has been confirmed/developed by EMails from others) is that if you get a login PDU whose last data byte (not padding, but byte in the data length) is not a NUL (0x00), you have more coming. You should then send an empty PDU to the other side, and then you'll get more data. Works rather well, but should be explained better. Also, it would be nice if it were stated that sending new key/value pairs in the "I'm ready for more" PDUs is a protocol error. Otherwise one side is feeding the other info before the other has had a chance to finish responding. Oh, nits: 1) I'm not sure what meaning transit and NSG would have when the initiator is sending these "I'm ready for more" PDUs. 2) The target shouldn't set "transit" until its sending the last of an extended-PDU data transfer. 3) If you are sending data that will span multiple PDUs, you MUST not send a PDU that has a zero (0x00) in its last data byte. i.e. say you're sending 12 k, and build an 8k pdu. The very last byte of that 8k must not be zero, or else the other side won't realize there's more coming. > > > But then the Responder (who both Reject-ed and > > responded to the key) > > > must remember that it not only sent the key but > > also rejected the > > > key, i.e., sent a value that does not necessarily > > fit in the selection > > > rules and which is not guaranteed to be liked by > > the Originator, > > > because if it is not liked, this Originator most > > likely will > > > send a Reject, which is not to be treated as a > > no-renegotionation > > > violation but just as a harmless little Reject. > > > > Maybe what we sould do is if the originator is the > > initiator, when it > > choses to reject, it closes the connection. Only > > when the originator is > > the target does it then send a Reject key. It also > > returns a non-zero > > status indicating that the connection is ending. > > That way we perform the > > minimum steps required by the protocol to end > > things. > > I don't know, but it doesn't sound simple anymore. > It would be good to preserve symmetry. And actually, > we probably shouldn't talk about closing the > connection too much as negotiation reset or Reject > PDU are similar alternatives for Text Requests/Rsps. I guess my thought was, do you have to send a packet anyway according to the protocol. If you're the initiator, no. If you're the target, yes (you're supposed to respond to the login cmd). If you weren't going to send a packet anyway, don't send one because of the Reject (and your decision that the reject is faital to the connection). :-) Good point about text nego. I think everyone is using the same parsing innards for both, and we should be careful of having a text nego pull down a connection. If it has to, it has to. But let's be careful. > > > O: k=u,v,w (I want (in order of > > preference) u, v or w) > > > R: k=Reject (But I hate all of > > those) > > > O: k=? (What do you like > > then?) > > > R: k=x,y,z (I like (in order of > > preference) x, y and z) > > > > That wouldn't work with Luben's definitions. We > > could change them to make > > it work, but I'm not sure if it's worth it. We'd be > > opening up the > > non-convergence potential problems. > > I didn't intend this to fit in with Luben's > definitions but with the current ones. The > O: key=? is meant to be entirely optional, in fact. > Anyway, I don't need this, but I think it is a > more natural way to get the "other side's values". Devil's advocate question, if you don't understand key=?, would asking for the other side's values then constitute a negotiation failure? :-) Sounds like there's more discussion and concensus to be had. :-) Take care, Bill From owner-ips@ece.cmu.edu Thu May 23 21:57:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03692 for ; Thu, 23 May 2002 21:57:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O1bn318345 for ips-outgoing; Thu, 23 May 2002 21:37:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4O0Pjw15080 for ; Thu, 23 May 2002 20:25:45 -0400 (EDT) Received: from hpindda.cup.hp.com (hpindda.cup.hp.com [15.13.95.92]) by palrel12.hp.com (Postfix) with ESMTP id 746C6E0063D for ; Thu, 23 May 2002 17:25:39 -0700 (PDT) Received: (from ashokr@localhost) by hpindda.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) id RAA26653 for ips@ece.cmu.edu; Thu, 23 May 2002 17:25:38 -0700 (PDT) From: Ashok Rajagopalan Message-Id: <200205240025.RAA26653@hpindda.cup.hp.com> Subject: iSCSI: TotalAHSlength in response pdus To: ips@ece.cmu.edu Date: Thu, 23 May 2002 17:25:38 -0700 (PDT) X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Since section 9.2 states "iSCSI response PDUs do not have AH segments" why do SCSI response PDU, Task Management Resp PDU etc.. have TotalAHSLength? Shouldn't it be reserved. In addition DataSegmentLength to be made reserved in most of the response pdus e.g. Task Mgt resp etc.. Thanks, Ashok From owner-ips@ece.cmu.edu Thu May 23 23:05:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05281 for ; Thu, 23 May 2002 23:05:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O2POG20387 for ips-outgoing; Thu, 23 May 2002 22:25:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4O2PMw20383 for ; Thu, 23 May 2002 22:25:22 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id E32B430706; Thu, 23 May 2002 22:25:17 -0400 (EDT) Date: Thu, 23 May 2002 19:23:21 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Martins Krikis Cc: Subject: Re: iSCSI base64 and 12-92 In-Reply-To: <20020524004329.91427.qmail@web13707.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 23 May 2002, Martins Krikis wrote: To quote David, I think we're in violent agreement. :-) > --- Bill Studenmund > wrote: > > > On Thu, 23 May 2002, Julian Satran wrote: > > > > > If base 64 is neede for large integers there is no > > good reason to test > > > that it is not used for short integers. > > > > I respectfully disagree. base64 is awkward for > > numbers, as it is not a > > numerical encoding. > > Me too. Base64 should not be allowed for anything > that's currently negotiable in the operational stage. > > > At least if the length of the > > number (in octets) is > > variable. 1, 2, 4, and 8 octet numbers are fine. But > > 3, 5, 6, and 7 are > > just plain gross. We have to load them into a > > correspondingly larger data > > type (32 or 64-bit unsigned int as appropriate), and > > then mask off > > unsent bytes. Oh, and if we're on an LE box, we then > > have to byte-swap the > > thing. > > That's not really the problem. For encoding a > small number in base64, you byte-swap if necessary, > pass the leading 0-bytes (if any), then run > your regular base64 encoding that operates on strings. > For decoding, you run the decoder (that operates > on strings) first, count the resulting bytes, > move it in your 32-bit or 64-bit register from the > "right end", add 0-bytes (if necessary) on the > left end and byteswap. I think we're both agreeing it's cumbersome. :-) > > Julo, have you actually coded a base64 decoder for > > the small (less than > > 2^64) ints we use in the protocol and verified its > > correctness? I will > > admit I haven't but that's because as I worked on > > it, it got very gross. > > And for no discernalbe benefit. Yes, we can do it. > > But I'd rather put the > > effort verifying this would take into making some > > other part of the code > > work well. > > A decoder is a decoder, it does work even > on 0-length input. It works on strings, produces > "binary strings". Putting the right number of > 0-bytes to the left and byteswapping should not > go in the decoder, it should be a separate thing, > IMHO. But I also see no benefit in even allowing > the small numbers to be given in any representation > that cannot be thrown at strtoul() as is. Oh, I was talking about the whole thing, the decoder that takes base64 & returns a #. That's the base64 decoder chained with the code to turn the result into a number. [violent agreement snipped :-) ] Take care, Bill From owner-ips@ece.cmu.edu Thu May 23 23:05:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05294 for ; Thu, 23 May 2002 23:05:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O2RSX20512 for ips-outgoing; Thu, 23 May 2002 22:27:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13709.mail.yahoo.com (web13709.mail.yahoo.com [216.136.175.251]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4O2RQw20506 for ; Thu, 23 May 2002 22:27:26 -0400 (EDT) Message-ID: <20020524022725.61867.qmail@web13709.mail.yahoo.com> Received: from [192.52.58.5] by web13709.mail.yahoo.com via HTTP; Thu, 23 May 2002 19:27:25 PDT Date: Thu, 23 May 2002 19:27:25 -0700 (PDT) From: Martins Krikis Subject: Re: [iSCSI]: Key negotiation procedure proposal To: Bill Studenmund Cc: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk > > That's the problem---the "negotiation step". > > Currently a step is basically PDU-wide. You cannot > > force the other side to hold off answering before > > you've sent all the data that you want processed > > together. Since we need to know what physically > > went out on the wire and what didn't (to be able > > to process reception of same keys properly), we > > cannot just leave ready-to-be-sent text sittin > > in buffers. We cannot prepare a key=value unless > > we're sure it will fit. That's true in general, > > not just for this key=Reject\0Key=BetterValue\0 > > situation. I think we need a flag there to tell > > the other side to hold off processing. No replies > > necessary until the flag goes off. > > But we do! It's not a flag, but we do have the > capability. The capability to send our pairs in multiple PDUs yes, but we don't have the capability to stop the other side from responding to the first ones seen while we haven't sent all that we were planning to send yet. > It's not as clear as I think it should be, but my > understanding (which has > been confirmed/developed by EMails from others) is > that if you get a login > PDU whose last data byte (not padding, but byte in > the data length) is not > a NUL (0x00), you have more coming. You should then > send an empty PDU to > the other side, and then you'll get more data. I haven't seen a requirement to send an empty PDU. In fact, since I view all keys as independent, I'm sending however much I can send in each an every PDU, not waiting for the other side to finish up and send a PDU ending in a NUL byte. I.e., I will not send you blank PDUs as a favor, because the spec hasn't required me to do so and I didn't think it was needed. I thought I was saving time by sending PDUs with my responses (to what can be responded to). I now realized that I had a problem by leaving stuff sitting in buffers but marking it as sent. I can fix it, but I see that the protocol allowing this is what's making it messy. So, if we were required to use blank PDUs until the other side sends us something ending in NUL, things were actually great. Still, not as good as an explicit flag, since data has to be looked at, not just stored away, but decent. However, the requirement for a blank PDU has escaped me if it exists. Somebody please enlighten me. > Also, it would be nice if it were stated that > sending new key/value pairs > in the "I'm ready for more" PDUs is a protocol > error. Otherwise one side > is feeding the other info before the other has had a > chance to finish > responding. Yeah, so I'm afraid it is not a protocol error currently. If it is, I'm happier already. Then, of course, we could say that blank PDUs aren't even necessary, the sending side can just send all PDUs that it had to send. > Oh, nits: 1) I'm not sure what meaning transit and > NSG would have when the > initiator is sending these "I'm ready for more" > PDUs. 2) The target > shouldn't set "transit" until its sending the last > of an extended-PDU data > transfer. NSG=CSG and no T/F flag set (until possibly the last of thos PDUs). > 3) If you are sending data that will span multiple > PDUs, you MUST not send > a PDU that has a zero (0x00) in its last data byte. > i.e. say you're > sending 12 k, and build an 8k pdu. The very last > byte of that 8k must not > be zero, or else the other side won't realize > there's more coming. This I know and was observing diligently. But I don't believe there is a requirement for the other side to refrain from sending data and to send just blank PDUs. Looks like we need some clarity here. > Devil's advocate question, if you don't understand > key=?, would asking for > the other side's values then constitute a > negotiation failure? :-) Asking would be legal, but the other side will likely not see it that way. Anyway, I am NOT seriously proposing this. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Thu May 23 23:07:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05388 for ; Thu, 23 May 2002 23:07:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O2cSD21006 for ips-outgoing; Thu, 23 May 2002 22:38:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13702.mail.yahoo.com (web13702.mail.yahoo.com [216.136.175.135]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4O2cQw21002 for ; Thu, 23 May 2002 22:38:26 -0400 (EDT) Message-ID: <20020524023826.99894.qmail@web13702.mail.yahoo.com> Received: from [192.52.58.5] by web13702.mail.yahoo.com via HTTP; Thu, 23 May 2002 19:38:26 PDT Date: Thu, 23 May 2002 19:38:26 -0700 (PDT) From: Martins Krikis Subject: Re: [iSCSI]: Key negotiation procedure proposal To: John Hufferd , Luben Tuikov Cc: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I agree entirely. But we need the draft to become a little clearer for everybody to see it that way. In particular, we need to stress more the "absolutely no renegotiation (even for Reject-ed keys)" rule and we need to disallow sending an "admissible value" in response as a favor to a buggy or incompatible Originator. (Although, sending the "admissible value" is rather unimportant (except for the text problem, perhaps), because a node need not do it, nor does it need to provoke the other side in doing it.) > 2. continue but do not accept that key again.(If nor send! > attempted, terminate the > connection) Martins Krikis, Intel Corp. Disclaimer: these opinions are my own and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Thu May 23 23:08:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05434 for ; Thu, 23 May 2002 23:08:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O2xQ521897 for ips-outgoing; Thu, 23 May 2002 22:59:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13705.mail.yahoo.com (web13705.mail.yahoo.com [216.136.175.138]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4O2xOw21893 for ; Thu, 23 May 2002 22:59:24 -0400 (EDT) Message-ID: <20020524025920.24352.qmail@web13705.mail.yahoo.com> Received: from [192.52.58.5] by web13705.mail.yahoo.com via HTTP; Thu, 23 May 2002 19:59:20 PDT Date: Thu, 23 May 2002 19:59:20 -0700 (PDT) From: Martins Krikis Subject: iSCSI: TargetPortalGroupTag 0? To: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Page 26 of 12-92 says the values are 1 to 65535. Page 208 allows 0 as well. Is there a special purpose for 0, or is there a typo somewhere? I would very much like to leave 0 out of acceptable values, it is mighty convenient to have a nice reserved value. Martins Krikis, Intel Corp. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Thu May 23 23:24:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05870 for ; Thu, 23 May 2002 23:24:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O33KJ22090 for ips-outgoing; Thu, 23 May 2002 23:03:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4O33Iw22086 for ; Thu, 23 May 2002 23:03:18 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id D3FA230706; Thu, 23 May 2002 23:03:17 -0400 (EDT) Date: Thu, 23 May 2002 20:01:22 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Martins Krikis Cc: Subject: Re: [iSCSI]: Key negotiation procedure proposal In-Reply-To: <20020524022725.61867.qmail@web13709.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 23 May 2002, Martins Krikis wrote: > > But we do! It's not a flag, but we do have the > > capability. > > The capability to send our pairs in multiple PDUs > yes, but we don't have the capability to stop > the other side from responding to the first ones > seen while we haven't sent all that we were planning > to send yet. We will need to define it as an error. > > It's not as clear as I think it should be, but my > > understanding (which has > > been confirmed/developed by EMails from others) is > > that if you get a login > > PDU whose last data byte (not padding, but byte in > > the data length) is not > > a NUL (0x00), you have more coming. You should then > > send an empty PDU to > > the other side, and then you'll get more data. > > I haven't seen a requirement to send an empty PDU. It's not written anywhere. All I can say is that: 1) the sample for text negotiation (9.10.3) shows empty PDUs, and 2) if we don't do it, negotiation becomes a REAL mess. :-) > In fact, since I view all keys as independent, I'm > sending however much I can send in each an every > PDU, not waiting for the other side to finish up > and send a PDU ending in a NUL byte. I.e., I will > not send you blank PDUs as a favor, because the spec > hasn't required me to do so and I didn't think it > was needed. I thought I was saving time by sending > PDUs with my responses (to what can be responded to). > I now realized that I had a problem by leaving > stuff sitting in buffers but marking it as sent. > I can fix it, but I see that the protocol allowing > this is what's making it messy. So, if we were > required to use blank PDUs until the other side > sends us something ending in NUL, things were > actually great. Still, not as good as an explicit > flag, since data has to be looked at, not just > stored away, but decent. However, the requirement > for a blank PDU has escaped me if it exists. > Somebody please enlighten me. A flag would be fine too. I think we definitely need a better description of how it's suppsoed to work.. > > Also, it would be nice if it were stated that > > sending new key/value pairs > > in the "I'm ready for more" PDUs is a protocol > > error. Otherwise one side > > is feeding the other info before the other has had a > > chance to finish > > responding. > > Yeah, so I'm afraid it is not a protocol error > currently. If it is, I'm happier already. > Then, of course, we could say that blank PDUs > aren't even necessary, the sending side can just > send all PDUs that it had to send. I think we should make it an error. :-) > > Oh, nits: 1) I'm not sure what meaning transit and > > NSG would have when the > > initiator is sending these "I'm ready for more" > > PDUs. 2) The target > > shouldn't set "transit" until its sending the last > > of an extended-PDU data > > transfer. > > NSG=CSG and no T/F flag > set (until possibly the last of thos PDUs). If no T bit, NSG == reserved = 0. The last one of a set of PDUs should probably reflect the desired state. > > 3) If you are sending data that will span multiple > > PDUs, you MUST not send > > a PDU that has a zero (0x00) in its last data byte. > > i.e. say you're > > sending 12 k, and build an 8k pdu. The very last > > byte of that 8k must not > > be zero, or else the other side won't realize > > there's more coming. > > This I know and was observing diligently. But I > don't believe there is a requirement for the > other side to refrain from sending data and > to send just blank PDUs. > > Looks like we need some clarity here. Indeed. :-) > > Devil's advocate question, if you don't understand > > key=?, would asking for > > the other side's values then constitute a > > negotiation failure? :-) > > Asking would be legal, but the other side will > likely not see it that way. Anyway, I am NOT > seriously proposing this. Ahhh.. Ok. :-) Take care, Bill From owner-ips@ece.cmu.edu Thu May 23 23:44:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06574 for ; Thu, 23 May 2002 23:44:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O3Bav22430 for ips-outgoing; Thu, 23 May 2002 23:11:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailnpd.hcltech.com ([203.197.145.76]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4O3BWw22422 for ; Thu, 23 May 2002 23:11:33 -0400 (EDT) Received: from npd.hcltech.com (IDENT:pamanick@pamanick.hcltech.com [192.168.100.58]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id g4O2odM03782; Fri, 24 May 2002 08:20:40 +0530 Message-ID: <3CEDACFA.239B6698@npd.hcltech.com> Date: Fri, 24 May 2002 08:31:14 +0530 From: Parthi Organization: HCL Tech X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ashok Rajagopalan CC: ips@ece.cmu.edu Subject: Re: iSCSI: TotalAHSlength in response pdus References: <200205240025.RAA26653@hpindda.cup.hp.com> Content-Type: multipart/alternative; boundary="------------445855206F987AFA80E93AC8" Sender: owner-ips@ece.cmu.edu Precedence: bulk --------------445855206F987AFA80E93AC8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ashok Rajagopalan wrote: > Hello, > > Since section 9.2 states "iSCSI response PDUs do not have AH segments" > why do SCSI response PDU, Task Management Resp PDU etc.. have TotalAHSLength? > Shouldn't it be reserved. In addition DataSegmentLength to be made reserved > in most of the response pdus e.g. Task Mgt resp etc.. > > Thanks, > Ashok Ashok, TotalAHSLength must be 0 "reserved" for PDUs that don't have AHS. AHS is only used to encapsulate an extended CDB. This scenario TotalAHSLength would be 0. -- Parthiban M, iSCSI Driver Team, HCL Technologies Ltd., Tel : (+91)-44-3741939 to 42, Extn. 2332 http://san.hcltech.com --------------445855206F987AFA80E93AC8 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ashok Rajagopalan wrote:
Hello,

Since section 9.2 states "iSCSI response PDUs do not have AH segments"
why do SCSI response PDU, Task Management Resp PDU etc.. have TotalAHSLength?
Shouldn't it be reserved. In addition DataSegmentLength to be made reserved
in most of the response pdus e.g. Task Mgt resp etc..

Thanks,
Ashok

Ashok,

    TotalAHSLength must be 0 "reserved" for PDUs that don't have AHS.
AHS is only used to encapsulate an extended CDB. This scenario
TotalAHSLength would be 0. 

-- 
Parthiban M,
iSCSI Driver Team,
HCL Technologies Ltd.,          Tel : (+91)-44-3741939 to 42, Extn. 2332
http://san.hcltech.com
  --------------445855206F987AFA80E93AC8-- From owner-ips@ece.cmu.edu Thu May 23 23:50:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06727 for ; Thu, 23 May 2002 23:50:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O3KuL22816 for ips-outgoing; Thu, 23 May 2002 23:20:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13701.mail.yahoo.com (web13701.mail.yahoo.com [216.136.175.134]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4O3Ktw22811 for ; Thu, 23 May 2002 23:20:55 -0400 (EDT) Message-ID: <20020524032054.84875.qmail@web13701.mail.yahoo.com> Received: from [192.52.58.5] by web13701.mail.yahoo.com via HTTP; Thu, 23 May 2002 20:20:54 PDT Date: Thu, 23 May 2002 20:20:54 -0700 (PDT) From: Martins Krikis Subject: Re: [iSCSI]: Key negotiation procedure proposal To: Bill Studenmund Cc: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Bill Studenmund wrote: > > I haven't seen a requirement to send an empty PDU. > > It's not written anywhere. All I can say is that: 1) > the sample for text > negotiation (9.10.3) shows empty PDUs, and 2) if we > don't do it, > negotiation becomes a REAL mess. :-) Agreed. > > Yeah, so I'm afraid it is not a protocol error > > currently. If it is, I'm happier already. > > Then, of course, we could say that blank PDUs > > aren't even necessary, the sending side can just > > send all PDUs that it had to send. > > I think we should make it an error. :-) Yes, we should make it an error. And on a second thought, having the blank PDUs travelling in the other direction is perhaps even simpler than allowing nothing to go in the other direction; at least it does not require changes to the text in this regard. So I'm for requiring blank PDUs in this case. > > NSG=CSG and no T/F flag > > set (until possibly the last of thos PDUs). > > If no T bit, NSG == reserved = 0. But does it even matter what NSG is in this case? Either way is fine with me. > The last one of a set of PDUs should probably > reflect the desired state. Yes. We may have to change the subject to make this post noticable. I doubt too many people are following the current subject at this point. Martins Krikis, Intel Corp. Disclaimer: my opinions, not necessarily Intel's. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Fri May 24 00:37:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07970 for ; Fri, 24 May 2002 00:37:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O402a24781 for ips-outgoing; Fri, 24 May 2002 00:00:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4O400w24775 for ; Fri, 24 May 2002 00:00:00 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4O3xn71093312; Fri, 24 May 2002 05:59:49 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4O3xnW103632; Fri, 24 May 2002 05:59:49 +0200 To: Paul Koning Cc: ips@ece.cmu.edu, wrstuden@wasabisystems.com MIME-Version: 1.0 Subject: Re: iSCSI base64 and 12-92 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 24 May 2002 06:59:44 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 24/05/2002 06:59:49, Serialize complete at 24/05/2002 06:59:49 Content-Type: multipart/alternative; boundary="=_alternative 00156625C2256BC3_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00156625C2256BC3_= Content-Type: text/plain; charset="us-ascii" I've lokked again at one of the most popular bignum packages - the one from MIT - and it seems to me that we are talking about two different things. conversion from b64 to a binary number - and checking that it fits in the integer length you prealllocated using a large integer 1 is a trivial operation in b64 and is unrelated to the package you are using (if you are using one) and you will want to do it with the same code for large or small integer. At the end of this phase you should know if the number the size required by the protocol or not and you will have to do this test in any case And the conversion is not part of any packege i.e. if you decide not to use bignum arithmetic - and you are not mandated to implement it - the the conversion is just placing 6 bit values in predefined positions in an integer. 2 Use of the large integer is an implementer choice - and if does not use bignum it does not have to fit in. In any case if we mandate b64 as being valid only for big numbers we have to check this and this is wasteful In summary - conversion must be done (for large numbers - as you don't know ahead of time how large the number used is going to be) and it is practically the same for small numbers. Then why check? And the bignum-packge itself you don't have to include it if don't implement large-number cryptography. Julo Paul Koning 05/23/2002 11:05 PM Please respond to Paul Koning To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, wrstuden@wasabisystems.com Subject: Re: iSCSI base64 and 12-92 Excerpt of message (sent 23 May 2002) by Julian Satran: > If base 64 is neede for large integers there is no good reason to test > that it is not used for short integers. Not true. They are fundamentally different datatypes. "short" integers are int, or long, or something like that. Large integers are a software-defined datatype, typically an octetstring perhaps with additional control variables. See any bignum package for the details. The conversion routines used for these two are completely different and quite unrelated. paul --=_alternative 00156625C2256BC3_= Content-Type: text/html; charset="us-ascii"
I've lokked again at one of the most popular bignum packages - the one from MIT - and it seems to me that
we are talking about two different things.
  1. conversion from b64 to a binary number - and checking that it fits in the integer length you prealllocated
  2. using a large integer


    1 is a trivial operation in b64 and is unrelated to the package you are using (if you are using one) and you will want to do it with the same code for large or small integer. At the end of this phase you should know if the number the size required by the protocol or not and you will have to do this test in any case
    And the conversion is not part of any packege i.e. if you decide not to use bignum arithmetic - and you are not mandated to implement it -
    the the conversion is just placing 6 bit values in predefined positions in an integer.

    2 Use of the large integer is an implementer choice - and if does not use bignum it does not have to fit in.

    In any case if we mandate b64 as being valid only for big numbers we have to check this and this is wasteful

    In summary - conversion must be done (for large numbers - as you don't know ahead of time how large the number used is going to be) and it is practically the same for small numbers. Then why check?

    And the bignum-packge itself you don't have to include it if don't implement large-number cryptography.

    Julo



    Paul Koning <ni1d@arrl.net>

    05/23/2002 11:05 PM
    Please respond to Paul Koning

    		       
            To:        Julian Satran/Haifa/IBM@IBMIL
            cc:        ips@ece.cmu.edu, wrstuden@wasabisystems.com
            Subject:        Re: iSCSI base64 and  12-92

           


    Excerpt of message (sent 23 May 2002) by Julian Satran:
    > If base 64 is neede for large integers there is no good reason to test
    > that it is not used for short integers.

    Not true.  They are fundamentally different datatypes.  "short"
    integers are int, or long, or something like that.  Large integers are
    a software-defined datatype, typically an octetstring perhaps with
    additional control variables.  See any bignum package for the
    details.  

    The conversion routines used for these two are completely different
    and quite unrelated.

       paul

--=_alternative 00156625C2256BC3_=-- From owner-ips@ece.cmu.edu Fri May 24 01:14:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08547 for ; Fri, 24 May 2002 01:14:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O4iPI26999 for ips-outgoing; Fri, 24 May 2002 00:44:25 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4O4iNw26993; Fri, 24 May 2002 00:44:23 -0400 (EDT) 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 g4O4i7kn023096; Fri, 24 May 2002 06:44:07 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4O4i1X64514; Fri, 24 May 2002 06:44:06 +0200 To: Ashok Rajagopalan Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: TotalAHSlength in response pdus X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 24 May 2002 07:43:56 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 24/05/2002 07:44:06, Serialize complete at 24/05/2002 07:44:06 Content-Type: multipart/alternative; boundary="=_alternative 00191FC4C2256BC3_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00191FC4C2256BC3_= Content-Type: text/plain; charset="us-ascii" For uniformity in handling. It is in fact reserved bu for AHS-Length :-) (they may need one in he future). Julo Ashok Rajagopalan Sent by: owner-ips@ece.cmu.edu 05/24/2002 03:25 AM Please respond to Ashok Rajagopalan To: ips@ece.cmu.edu cc: Subject: iSCSI: TotalAHSlength in response pdus Hello, Since section 9.2 states "iSCSI response PDUs do not have AH segments" why do SCSI response PDU, Task Management Resp PDU etc.. have TotalAHSLength? Shouldn't it be reserved. In addition DataSegmentLength to be made reserved in most of the response pdus e.g. Task Mgt resp etc.. Thanks, Ashok --=_alternative 00191FC4C2256BC3_= Content-Type: text/html; charset="us-ascii"
For uniformity in handling. It is in fact reserved bu for AHS-Length :-) (they may need one in he future). Julo


Ashok Rajagopalan <ashokr@hpindda.cup.hp.com>
Sent by: owner-ips@ece.cmu.edu

05/24/2002 03:25 AM
Please respond to Ashok Rajagopalan

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: TotalAHSlength in response pdus

       



Hello,

Since section 9.2 states "iSCSI response PDUs do not have AH segments"
why do SCSI response PDU, Task Management Resp PDU etc.. have TotalAHSLength?
Shouldn't it be reserved. In addition DataSegmentLength to be made reserved
in most of the response pdus e.g. Task Mgt resp etc..

Thanks,
Ashok

--=_alternative 00191FC4C2256BC3_=-- From owner-ips@ece.cmu.edu Fri May 24 01:15:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08566 for ; Fri, 24 May 2002 01:15:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O4v4Z27576 for ips-outgoing; Fri, 24 May 2002 00:57:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4O4uxw27559; Fri, 24 May 2002 00:56:59 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4O4ur71090310; Fri, 24 May 2002 06:56:53 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4O4uqX53498; Fri, 24 May 2002 06:56:52 +0200 To: Martins Krikis Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: TargetPortalGroupTag 0? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 24 May 2002 07:56:48 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 24/05/2002 07:56:52, Serialize complete at 24/05/2002 07:56:52 Content-Type: multipart/alternative; boundary="=_alternative 001A8F40C2256BC3_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001A8F40C2256BC3_= Content-Type: text/plain; charset="us-ascii" 0 is a typo - julo Martins Krikis Sent by: owner-ips@ece.cmu.edu 05/24/2002 05:59 AM Please respond to Martins Krikis To: ips@ece.cmu.edu cc: Subject: iSCSI: TargetPortalGroupTag 0? Page 26 of 12-92 says the values are 1 to 65535. Page 208 allows 0 as well. Is there a special purpose for 0, or is there a typo somewhere? I would very much like to leave 0 out of acceptable values, it is mighty convenient to have a nice reserved value. Martins Krikis, Intel Corp. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com --=_alternative 001A8F40C2256BC3_= Content-Type: text/html; charset="us-ascii"
0 is a typo - julo


Martins Krikis <mkrikis@yahoo.com>
Sent by: owner-ips@ece.cmu.edu

05/24/2002 05:59 AM
Please respond to Martins Krikis

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: TargetPortalGroupTag 0?

       


Page 26 of 12-92 says the values are 1 to 65535.

Page 208 allows 0 as well.

Is there a special purpose for 0, or is there a typo
somewhere? I would very much like to leave 0 out
of acceptable values, it is mighty convenient to
have a nice reserved value.

Martins Krikis, Intel Corp.




__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

--=_alternative 001A8F40C2256BC3_=-- From owner-ips@ece.cmu.edu Fri May 24 01:16:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08590 for ; Fri, 24 May 2002 01:16:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O4v4R27574 for ips-outgoing; Fri, 24 May 2002 00:57:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4O4v0w27563; Fri, 24 May 2002 00:57:00 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4O4us71054980; Fri, 24 May 2002 06:56:54 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4O4urX53500; Fri, 24 May 2002 06:56:53 +0200 To: Parthi Cc: Ashok Rajagopalan , ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: TotalAHSlength in response pdus X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 24 May 2002 07:56:48 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 24/05/2002 07:56:53, Serialize complete at 24/05/2002 07:56:53 Content-Type: multipart/alternative; boundary="=_alternative 001AB8D5C2256BC3_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001AB8D5C2256BC3_= Content-Type: text/plain; charset="us-ascii" AHS could be used for more than encapsulating an extended CDB - Julo Parthi Sent by: owner-ips@ece.cmu.edu 05/24/2002 06:01 AM Please respond to Parthi To: Ashok Rajagopalan cc: ips@ece.cmu.edu Subject: Re: iSCSI: TotalAHSlength in response pdus Ashok Rajagopalan wrote: Hello, Since section 9.2 states "iSCSI response PDUs do not have AH segments" why do SCSI response PDU, Task Management Resp PDU etc.. have TotalAHSLength? Shouldn't it be reserved. In addition DataSegmentLength to be made reserved in most of the response pdus e.g. Task Mgt resp etc.. Thanks, Ashok Ashok, TotalAHSLength must be 0 "reserved" for PDUs that don't have AHS. AHS is only used to encapsulate an extended CDB. This scenario TotalAHSLength would be 0. -- Parthiban M, iSCSI Driver Team, HCL Technologies Ltd., Tel : (+91)-44-3741939 to 42, Extn. 2332 http://san.hcltech.com --=_alternative 001AB8D5C2256BC3_= Content-Type: text/html; charset="us-ascii"
AHS could be used for more than encapsulating an extended CDB - Julo


Parthi <pamanick@npd.hcltech.com>
Sent by: owner-ips@ece.cmu.edu

05/24/2002 06:01 AM
Please respond to Parthi

       
        To:        Ashok Rajagopalan <ashokr@hpindda.cup.hp.com>
        cc:        ips@ece.cmu.edu
        Subject:        Re: iSCSI: TotalAHSlength in response pdus

       


Ashok Rajagopalan wrote:
Hello,

Since section 9.2 states "iSCSI response PDUs do not have AH segments"
why do SCSI response PDU, Task Management Resp PDU etc.. have TotalAHSLength?
Shouldn't it be reserved. In addition DataSegmentLength to be made reserved
in most of the response pdus e.g. Task Mgt resp etc..

Thanks,
Ashok

Ashok,

    TotalAHSLength must be 0 "reserved" for PDUs that don't have AHS.
AHS is only used to encapsulate an extended CDB. This scenario
TotalAHSLength would be 0.
--
Parthiban M,
iSCSI Driver Team,
HCL Technologies Ltd.,          Tel : (+91)-44-3741939 to 42, Extn. 2332
http://san.hcltech.com

 

--=_alternative 001AB8D5C2256BC3_=-- From owner-ips@ece.cmu.edu Fri May 24 01:24:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08665 for ; Fri, 24 May 2002 01:24:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4O4i1B26973 for ips-outgoing; Fri, 24 May 2002 00:44:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4O4htw26963; Fri, 24 May 2002 00:43:56 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4O4hnHr036740; Fri, 24 May 2002 06:43:49 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4O4hmX94072; Fri, 24 May 2002 06:43:48 +0200 To: Martins Krikis Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: [iSCSI]: Key negotiation procedure proposal X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 24 May 2002 07:43:43 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 24/05/2002 07:43:48, Serialize complete at 24/05/2002 07:43:48 Content-Type: multipart/alternative; boundary="=_alternative 00166167C2256BC3_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00166167C2256BC3_= Content-Type: text/plain; charset="us-ascii" All this thread is based on the assumption that discovery of what other side capabilities are is a good thing to have in the protocol. Except for one item the group has decided a long time ago against it. The messages consume an inordinate amount of time from all of us - and we are looking for things to fix (big or small). If you think that negotiations have to be done some other way that is essentially better - please discuss this between yourselves and submit an ID. If something is badl in what we do now please be as concrete and brief as possible in outlining what is wrong and all of us will certainly listen - as we did in the past. Julo Martins Krikis Sent by: owner-ips@ece.cmu.edu 05/24/2002 12:33 AM Please respond to Martins Krikis To: ips@ece.cmu.edu cc: Subject: Re: [iSCSI]: Key negotiation procedure proposal Bill, Luben, Sorry, my previous response was already somewhat dated. Hard to keep up with you. :-) > Regular implementations: > > Core rule: A negotiation of a key=value pair is > complete/finished when both the Originator and Responder > have sent their values (non-reserved keywords). > > The core rule implies the the following: > > If a Responder replies with Reject, then the Originator > SHOULD NOT renegotiate the rejected key. Does it mean it should not send or does it mean "should not send with a non-reserved value"? > If a Responder replies with Reject, it SHOULD send its value > of that key in the same reply PDU to the Originator after the > key=Reject pair. There is the problem that it may not fit. If we leave it for the next round, we have to remember that the state for this key is such. In order to avoid this problem, we could use the key only once, but use a list of values: first element "Reject", next elements whatever was the value (or value list) that the Responder would like. But, that's another big complication, so I am NOT proposing it. > If an Originator finds the response to an offered key=value > pair to be unacceptable, it SHOULD send Reject and close the > connection. But then the Responder (who both Reject-ed and responded to the key) must remember that it not only sent the key but also rejected the key, i.e., sent a value that does not necessarily fit in the selection rules and which is not guaranteed to be liked by the Originator, because if it is not liked, this Originator most likely will send a Reject, which is not to be treated as a no-renegotionation violation but just as a harmless little Reject. Thus, I think we need more state for this. But we gain the knowledge of what values the other side likes. I like the latter feature of course, but hate introducing more state. Plus I was getting to feel happy about the current situation. If the goal of this is to have a way to figure out what the other side likes, perhaps it is simpler to reinstate the "key=?" syntax, with the changed semantics, that the Responder must send its acceptable values (not current). This would not count as a start of a new negotiation, of course, so no extra state here. I.e., O: k=u,v,w (I want (in order of preference) u, v or w) R: k=Reject (But I hate all of those) O: k=? (What do you like then?) R: k=x,y,z (I like (in order of preference) x, y and z) Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. --=_alternative 00166167C2256BC3_= Content-Type: text/html; charset="us-ascii"
All this thread is based on the assumption that discovery of what other side capabilities are is a good thing to have in the protocol.
Except for one item the group has decided a long time ago against it.
The messages consume an inordinate amount of time from all of us - and we are looking for things to fix (big or small).
If you think that negotiations have to be done some other way that is essentially better - please discuss this between yourselves and  submit an ID.
If something is badl in what we do now please be as concrete and brief as possible in outlining what is wrong and all of us will certainly listen - as we did in the past.

Julo


Martins Krikis <mkrikis@yahoo.com>
Sent by: owner-ips@ece.cmu.edu

05/24/2002 12:33 AM
Please respond to Martins Krikis

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        Re: [iSCSI]: Key negotiation procedure proposal

       


Bill, Luben,

Sorry, my previous response was already somewhat dated. Hard to keep
up with you. :-)

> Regular implementations:
>
> Core rule: A negotiation of a key=value pair is
> complete/finished when both the Originator and Responder
> have sent their values (non-reserved keywords).
>
> The core rule implies the the following:
>
> If a Responder replies with Reject, then the Originator
> SHOULD NOT renegotiate the rejected key.

Does it mean it should not send or does it mean "should not send
with a non-reserved value"?

> If a Responder replies with Reject, it SHOULD send its value
> of that key in the same reply PDU to the Originator after the
> key=Reject pair.

There is the problem that it may not fit. If we leave it for the
next round, we have to remember that the state for this key is such.
In order to avoid this problem, we could use the key only once,
but use a list of values: first element "Reject", next elements
whatever was the value (or value list) that the Responder would
like. But, that's another big complication, so I am NOT proposing it.

> If an Originator finds the response to an offered key=value
> pair to be unacceptable, it SHOULD send Reject and close the
> connection.

But then the Responder (who both Reject-ed and responded to the key)
must remember that it not only sent the key but also rejected the
key, i.e., sent a value that does not necessarily fit in the selection
rules and which is not guaranteed to be liked by the Originator,
because if it is not liked, this Originator most likely will
send a Reject, which is not to be treated as a no-renegotionation
violation but just as a harmless little Reject.

Thus, I think we need more state for this. But we gain the knowledge
of what values the other side likes. I like the latter feature
of course, but hate introducing more state. Plus I was getting
to feel happy about the current situation.

If the goal of this is to have a way to figure out what the other
side likes, perhaps it is simpler to reinstate the "key=?"
syntax, with the changed semantics, that the Responder must
send its acceptable values (not current). This would not count
as a start of a new negotiation, of course, so no extra state here.

I.e.,

O: k=u,v,w                   (I want (in order of preference) u, v or w)
R: k=Reject                  (But I hate all of those)
O: k=?                       (What do you like then?)
R: k=x,y,z                   (I like (in order of preference) x, y and z)

 Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not be those of my employer.

--=_alternative 00166167C2256BC3_=-- From owner-ips@ece.cmu.edu Fri May 24 09:27:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27812 for ; Fri, 24 May 2002 09:27:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4OCiWK28350 for ips-outgoing; Fri, 24 May 2002 08:44:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4OBLRw24888 for ; Fri, 24 May 2002 07:21:28 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23319; Fri, 24 May 2002 07:21:06 -0400 (EDT) Message-Id: <200205241121.HAA23319@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-ifcp-mib-01.txt Date: Fri, 24 May 2002 07:21:05 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Definitions of Managed Objects For iFCP Author(s) : K. Gibbons, J. Tseng, C. Monia, F. Travostino Filename : draft-ietf-ips-ifcp-mib-01.txt Pages : 20 Date : 23-May-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based monitoring and management of the Internet Fibre Channel Protocol (iFCP). This memo specifies a MIB module in a manner that is compliant to the SMIv2. The set of objects is consistent with the SNMP framework and existing SNMP standards. This memo is a product of the IP Storage (IPS) working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ips@ece.cmu.edu and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-mib-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-ifcp-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-ifcp-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020523132552.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-ifcp-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-ifcp-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020523132552.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Fri May 24 09:27:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27825 for ; Fri, 24 May 2002 09:27:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4OCiba28358 for ips-outgoing; Fri, 24 May 2002 08:44:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4OBLXw24904 for ; Fri, 24 May 2002 07:21:33 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23338; Fri, 24 May 2002 07:21:11 -0400 (EDT) Message-Id: <200205241121.HAA23338@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-ifcp-wglcc-00.txt,.pdf Date: Fri, 24 May 2002 07:21:11 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Responses to iFCP Rev. 10 Last Call Comments Author(s) : C. Monia, F. Travostino, J. Tseng Filename : draft-ietf-ips-ifcp-wglcc-00.txt,.pdf Pages : 45 Date : 23-May-02 This document is a compilation of responses to review comments received for revision 10 if the iFCP specification [IFCP] during the preliminary last call period from 3/4/2002 to 3/18/2002. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-wglcc-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-ifcp-wglcc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-ifcp-wglcc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020523132601.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-ifcp-wglcc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-ifcp-wglcc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020523132601.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Fri May 24 13:03:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05665 for ; Fri, 24 May 2002 13:03:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4OGDOq10857 for ips-outgoing; Fri, 24 May 2002 12:13:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4OGDMw10847 for ; Fri, 24 May 2002 12:13:22 -0400 (EDT) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA07884; Fri, 24 May 2002 09:13:15 -0700 (PDT) From: Keith McCloghrie Message-Id: <200205241613.JAA07884@cisco.com> Subject: Re: FC Mgmt mib To: arvindp@cisco.com Date: Fri, 24 May 2002 09:13:15 -0700 (PDT) Cc: ips@ece.cmu.edu, smoffett@cisco.com, sriramnj@cisco.com, nramesh@cisco.com, gklee@cisco.com X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Arvind, (Sorry for the delay in responding.) It seems to me that you are requesting the following three changes: 1. a new code point for FcUnitFunctions - I think this is fine, except how about calling it 'tunnel' ?? 2. Changing the fcmLinkTable from mandatory to optional - I think this is fine. 3. A new table for 'tunnel' ports - I'd rather not add a new table unless it's absolutely necessary. How about I just broaden the scope of the fcmEPortTable so that it applies not only to E_Ports but also to 'tunnel' ports ?? The MIB will also need a new group for devices supporting 'tunnel' functionality, which will contain just fcmEPortClassFCredit and fcmEPortClassFDataFieldSize, right ?? If you agree to the above (and nobody else objects), then I'll go ahead and update the MIB. The only other pending changes are an alignment of the meanings of bits of the FcUnitFunctions TC with the latest update to the meanings in the GS-4 specification (note that FcUnitFunctions's SYNTAX is unchanged), and some other typos. In fact, if anyone else has any changes that they would like to propose before Last Call, can I request that they raise them now. Thanks, Keith. > From: Arvind Prabhudev > Message-ID: > Date: Mon, 29 Apr 2002 21:06:40 -0700 (PDT) > To: ips@ece.umn.edu > Subject: FC Mgmt mib > > (This is regarding draft-ietf-ips-fcmgmt-mib-01) > > Hello, > > I am writing on behalf of a group at Cisco which is developing an optical > box. One of our linecards is aimed at providing Fibre Channel aggregation > while simultaneously extending fibrechannel connectivity to much larger > distances. Fibre channel frames are encapsulated into ethernet frames, > tagged with a flow identifier and these frames are packet multiplexed > over the trunk interface (which operates at the ITU grid frequency). > > -------+ +---------+ +---------+ +------- > Regular| FC |Our box 1| GigE |Our box 2| FC |Regular > FC port+---------+ X Tx+-----------+Ty Y +---------+FC Port > A | | | | | | B > -------+ +---------+ +---------+ +------- > > In figure above, FC streams from multiple X & Y ports are ethernet > encapsulated and multiplexed over Tx & Ty ports respectively. > > We were considering supporting the draft-ietf-ips-fcmgmt-mib-01 for > providing fibre channel management of our box. We had a few requests in > this regard. > > As described above, we do not terminate fibrechannel at the FC-2 level. > We handle only upto FC-1 level. We remain transparent to the fibre channel > connectivity. We feel that there is no appropriate value in the > FcUnitFunctions type that would describe the nature of our box. We > would like to propose a new code point 'transport'. > > Secondly, we wanted a means to report the BB Credit on our (X & Y) ports. > There are FcBbCredit objects in fcmFxPortTable & fcmEPortTable through > which we can report this value. But, we are neither an F nor E port. So > would it possible to consider our ports as a new category of 'transport' > ports which do SAN extension and have a separate table for it which has BB > credit object? > > The last issue is regarding the fcmLinkTable. It is currently mandatory. > We would prefer that the table was made optional. Ofcourse, the table in > its current form does not preclude not populating it, if nothing was > learnt. Any information about the ID of the source port & node that we are > connected to, which we might discover by potentially snooping the frames, > we would like to report via the PTOPO-MIB (rfc2922). > > I hope our inputs could be incorporated into the proposed FC mgmt MIB draft. > Please let us know what you think. > > best regards, > Arvind > From owner-ips@ece.cmu.edu Fri May 24 14:03:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07896 for ; Fri, 24 May 2002 14:03:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4OHL9d15432 for ips-outgoing; Fri, 24 May 2002 13:21:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4OHL8w15427 for ; Fri, 24 May 2002 13:21:08 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 6C64B30706; Fri, 24 May 2002 13:21:07 -0400 (EDT) Date: Fri, 24 May 2002 10:19:09 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Paul Koning , Subject: Re: iSCSI base64 and 12-92 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 23 May 2002, Julian Satran wrote: > If base 64 is neede for large integers there is no good reason to test > that it is not used for short integers. Julo, You still haven't explained why we need base64 for large numbers. What security negotiation schemes are we using that need to exchange large numbers as numbers; where the scheme expects the number in host byte order as opposed to a specific on-wire format. More specifically you have not explained why the iSCSI parameter negotiation system needs to be able to deal with large base64 numbers. If we actually have any protocol which strangely wants large numbers in local byte order, why not have the keys in question defined as exchanging a binary string which is the number in network byte order? The advantage of the above is that we then can drop base64 as a number encoding scheme. The key negotiation system(s) need only deal with base64 binary strings, things base64 is good (no, great) for. And we can support any cryptographic scheme we choose to in the future; the only thing we're loosing is pain. So what is wrong with the above? I mean do we really want to have to support "MaxConnections=0b0Q=="? Take care, Bill From owner-ips@ece.cmu.edu Fri May 24 14:03:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07910 for ; Fri, 24 May 2002 14:03:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4OHR2s15848 for ips-outgoing; Fri, 24 May 2002 13:27:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4OHR0w15843 for ; Fri, 24 May 2002 13:27:00 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4OHQsp31291 for ; Fri, 24 May 2002 13:26:55 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4OHQsc31282; Fri, 24 May 2002 13:26:54 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g4OHQsl31357; Fri, 24 May 2002 13:26:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15598.30686.48304.427221@pkoning.dev.equallogic.com> Date: Fri, 24 May 2002 13:26:54 -0400 From: Paul Koning To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu, wrstuden@wasabisystems.com Subject: Re: iSCSI base64 and 12-92 References: X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Let me rephrase what I'm looking for, because the picture seems to be getting muddled. I would like to see Base64 permitted ONLY for those parameters that are long octetstrings. Basically, that's only the crypto parameters. For all other integer parameters -- which are 64 bit or smaller integers -- permit only hex and decimal. The reason is that these are different datatypes internally, so you will be using different conversion routines. Conversion from Base64 to int is an "unnatural act" and I would prefer not to have to add that code. paul From owner-ips@ece.cmu.edu Fri May 24 14:03:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07932 for ; Fri, 24 May 2002 14:03:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4OHj1B17204 for ips-outgoing; Fri, 24 May 2002 13:45:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4OHixw17199 for ; Fri, 24 May 2002 13:44:59 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id B6A4230706; Fri, 24 May 2002 13:44:58 -0400 (EDT) Date: Fri, 24 May 2002 10:43:01 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Paul Koning Cc: , Subject: Re: iSCSI base64 and 12-92 In-Reply-To: <15598.30686.48304.427221@pkoning.dev.equallogic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 24 May 2002, Paul Koning wrote: Wow. I feel like I'm on one of those talkshows or AOL. Me too!!!!! > Let me rephrase what I'm looking for, because the picture seems to be > getting muddled. > > I would like to see Base64 permitted ONLY for those parameters that > are long octetstrings. Basically, that's only the crypto parameters. I *strongly* agree. Especially since if we have a crypto method that wants to excahnge long numbers, we can define the exchange to be of formated binary strings; we move the hard stuff to the crypto system that wants it. > For all other integer parameters -- which are 64 bit or smaller > integers -- permit only hex and decimal. I'd make that decimal & hex for small numbers (64 bit or less), and hex for larger ones (not sure if we have any). > The reason is that these are different datatypes internally, so you > will be using different conversion routines. Conversion from Base64 > to int is an "unnatural act" and I would prefer not to have to > add that code. Agreed! Take care, Bill From owner-ips@ece.cmu.edu Fri May 24 14:03:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07946 for ; Fri, 24 May 2002 14:03:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4OHQXq15807 for ips-outgoing; Fri, 24 May 2002 13:26:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4OHQVw15801; Fri, 24 May 2002 13:26:31 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 89F8F30706; Fri, 24 May 2002 13:26:30 -0400 (EDT) Date: Fri, 24 May 2002 10:24:33 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Parthi , Ashok Rajagopalan , , Subject: Re: iSCSI: TotalAHSlength in response pdus In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 24 May 2002, Julian Satran wrote: > AHS could be used for more than encapsulating an extended CDB - Julo While the above is quite true, doesn't that go against the statement quoted below that responses don't have AH segments? I think the question is more doesn't the spec contradict itself rather than should we or shouldn't we have AH segments in a response; right now we seem to be saying both yes AND no. :-) Take care, Bill > Parthi > Sent by: owner-ips@ece.cmu.edu > 05/24/2002 06:01 AM > Please respond to Parthi > > > To: Ashok Rajagopalan > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: TotalAHSlength in response pdus > > > > Ashok Rajagopalan wrote: > Hello, > Since section 9.2 states "iSCSI response PDUs do not have AH segments" > why do SCSI response PDU, Task Management Resp PDU etc.. have > TotalAHSLength? > Shouldn't it be reserved. In addition DataSegmentLength to be made > reserved > in most of the response pdus e.g. Task Mgt resp etc.. > Thanks, > Ashok > Ashok, > TotalAHSLength must be 0 "reserved" for PDUs that don't have AHS. > AHS is only used to encapsulate an extended CDB. This scenario > TotalAHSLength would be 0. > -- > Parthiban M, > iSCSI Driver Team, > HCL Technologies Ltd., Tel : (+91)-44-3741939 to 42, Extn. 2332 > http://san.hcltech.com > > > From owner-ips@ece.cmu.edu Fri May 24 15:45:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12053 for ; Fri, 24 May 2002 15:45:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4OJ2O221930 for ips-outgoing; Fri, 24 May 2002 15:02:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4OJ2Gw21915 for ; Fri, 24 May 2002 15:02:17 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel9.hp.com (Postfix) with ESMTP id 428EC805389; Fri, 24 May 2002 15:02:00 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 5C37314C; Fri, 24 May 2002 15:01:47 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 15:01:47 -0400 Message-ID: <499DC368E25AD411B3F100902740AD6508E9A3F5@xrose03.rose.hp.com> From: "ERICKSON,SHAWN (HP-Roseville,ex1)" To: "'Bill Studenmund'" , Julian Satran Cc: Paul Koning , ips@ece.cmu.edu Subject: RE: iSCSI base64 and 12-92 Date: Fri, 24 May 2002 15:01:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I agree with Paul & Bill. I don't see the need for base64 encoding of numbers or for iSCSI caring/knowing about big numbers, treat them as binary and let the end consumers of the information handle any needed translation. -Shawn > -----Original Message----- > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] > Sent: Friday, May 24, 2002 10:19 AM > To: Julian Satran > Cc: Paul Koning; ips@ece.cmu.edu > Subject: Re: iSCSI base64 and 12-92 > > > On Thu, 23 May 2002, Julian Satran wrote: > > > If base 64 is neede for large integers there is no good > reason to test > > that it is not used for short integers. > > Julo, > > You still haven't explained why we need base64 for large numbers. What > security negotiation schemes are we using that need to exchange large > numbers as numbers; where the scheme expects the number in > host byte order > as opposed to a specific on-wire format. > > More specifically you have not explained why the iSCSI parameter > negotiation system needs to be able to deal with large base64 numbers. > > If we actually have any protocol which strangely wants large > numbers in > local byte order, why not have the keys in question defined > as exchanging > a binary string which is the number in network byte order? > > The advantage of the above is that we then can drop base64 as a number > encoding scheme. The key negotiation system(s) need only deal > with base64 > binary strings, things base64 is good (no, great) for. And we > can support > any cryptographic scheme we choose to in the future; the only > thing we're > loosing is pain. > > So what is wrong with the above? > > I mean do we really want to have to support "MaxConnections=0b0Q=="? > > Take care, > > Bill > From owner-ips@ece.cmu.edu Fri May 24 15:52:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12333 for ; Fri, 24 May 2002 15:52:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4OJcee24146 for ips-outgoing; Fri, 24 May 2002 15:38:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13709.mail.yahoo.com (web13709.mail.yahoo.com [216.136.175.251]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4OJccw24142 for ; Fri, 24 May 2002 15:38:39 -0400 (EDT) Message-ID: <20020524193837.72837.qmail@web13709.mail.yahoo.com> Received: from [192.52.58.5] by web13709.mail.yahoo.com via HTTP; Fri, 24 May 2002 12:38:37 PDT Date: Fri, 24 May 2002 12:38:37 -0700 (PDT) From: Martins Krikis Subject: iSCSI: Negotiation clarifications still needed To: Julian Satran Cc: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk The previous thread went on too long, but since it has now quieted down, I'll conjecture that the following are the aspects that still need to be addressed. 1. Not everybody seemed to have noticed that it is NOT legal to send the same key again, if it has once been negotiated (including negotiations that end with a reserved value (Reject, Irrelevant or NotUnderstood). I think it would benefit the draft to add the sentence that Pat proposed to paragraph 5 or page 72 in 12-92: "Sending the key again would be a re-negotiation". That I think would make it crystal clear. 2. When the key=value pairs that Originator is sending are broken across multiple PDUs, it is not clear whether the Responder may start responding to the keys as soon as it receives them or whether it should send blank PDUs back (as in the example on page 164 of 12-92) until it gets a PDU, the data part of which ends in a NUL byte (thus signaling that there are no broken key=value pairs at the end of it). I am proposing that the draft should make it explicit that only blank PDUs are to be sent. This allows decoupling of key=value generation from their encapsulation in PDUs (i.e., the generating logic need not worry about whether a key=value pair will fit and go out in this PDU or has to be retained to go out in the next). I can explain in detail why this is important (it has to do with teh possibility of receiving the "just-about outgoing" keys) but I'm keeping this "brief". Furthermore, it is my feeling that instead of checking the last bytes of a PDU for NUL, it would be better if the end-of-data was marked by a flag in the header. This way encapsulation will be simpler---just put as much data in the PDU as fits there and raise the flag if it isn't all, instead of checking whether it ends in a NUL and possibly shortening data to make it not end like that. 3. There is an opinion that on page 73 of 12-92, the phrase that says "or the responder may select an admissible value" is in contradiction to the very next sentence. There is also an opinion that this phrase is entirely unnecessary and detrimental to achieving broad interoperability (I call it "cutting slack to misbehaving or incompatible originators"). I don't have a suggestion since I consider the "feature" that this phrase allows of little importance to a properly built iSCSI node. 4. This is new. When doing Text Request/Response negotiations (i.e., in FFP), it seems that the Initiator commits to the new values when it receives a response from the Target with the F bit set. It is unclear when the Target should commit. Should it switch to using the new values as soon as it sends its response with the F-bit set, or should it do so only when it knows that the Initiator received its response? Commiting right away is simpler and since responses with F-bits set have TTT=0xffffffff and thus may not be reset, sounds plausible. If the values have importance on the next reception, it may also be important to commit timely. However, what if the Initiator doesn't get this response? Target now has committed, Initiator hasn't. Committing later puts the burden on Initiator to send something effectively telling "I've received your final response". Otherwise the Target will time out and not commit. This response can get lost too. Basically, it is beginning to look a bit like (what was it called?) "distributed consensus problem"? I think it goes like this: Two generals that are on oposite sides of the enemy want to synchronize their attack, and start sending messengers through with messages like "attack at dawn->", "<-ok, attack at dawn", "I know you know we attack at dawn->", "<-, I know you know I know we attack at dawn", etc., etc., ... But at no point can they commit yet... Is anybody else worried about this? Anyway, so when should a target commit? Page 83 of 12-92 is the relevant reference. Thanks, Martins Krikis Disclaimer: these opinions are my own and may not be those of my employer. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Fri May 24 16:43:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13863 for ; Fri, 24 May 2002 16:43:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4OJtv625185 for ips-outgoing; Fri, 24 May 2002 15:55:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4OJtsw25180; Fri, 24 May 2002 15:55:55 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 6010D30706; Fri, 24 May 2002 15:55:54 -0400 (EDT) Date: Fri, 24 May 2002 12:53:57 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Martins Krikis , , Subject: Re: [iSCSI]: Key negotiation procedure proposal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 24 May 2002, Julian Satran wrote: > All this thread is based on the assumption that discovery of what other > side capabilities are is a good thing to have in the protocol. We must be reading different threads. While I've seen discovery mentioned and discussed, it's not been a base assumption of what I understood the thread was about. > Except for one item the group has decided a long time ago against it. > The messages consume an inordinate amount of time from all of us - and we > are looking for things to fix (big or small). The thread was about the fact people think that login negotiation needs fixing. It could be the negotiation methods need changing (as in Lubin's suggestion), or the text needs changing to something more like what John wrote. The point though is that the current negotiation description is broken in the minds of a number of implementors. It sounds like it is not broken in the minds of a number of the WG members who have been involved for a while. So from that I conclude the spec hasn't been capturing what is in the WG's thoughts; the spec needs work. > If you think that negotiations have to be done some other way that is > essentially better - please discuss this between yourselves and submit an > ID. I think that would be a reasonable suggestion if we were talking about making it spiffier & better. But we're complaining that we think it's broken. Telling us to go off and come back with an ID does not strike me as a suggestion which will help us converge to an answer. Take care, Bill From owner-ips@ece.cmu.edu Fri May 24 17:53:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16476 for ; Fri, 24 May 2002 17:53:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4OLGxj29913 for ips-outgoing; Fri, 24 May 2002 17:16:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4OLGvw29909 for ; Fri, 24 May 2002 17:16:57 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id ABC22D607; Fri, 24 May 2002 15:16:56 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 885B21B2; Fri, 24 May 2002 15:16:56 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 24 May 2002 15:16:51 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 15:16:50 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09D2AD@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: mkrikis@yahoo.com, Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiation clarifications still needed Date: Fri, 24 May 2002 15:16:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Martins, Comments referenced by the same items Martins used. 1. Julian sent an email saying he would put the text I proposed in (though the text you quoted is not the whole text). 2. I think that the principle we have been using on text negotiation was that each key negotion is a separate item. Your proposal would be counter to that and I don't think it would be an improvement. The target should be allowed to respond to any complete key-value pair it has received. When a key-value pair is straddling the PDU bondary, then it shouldn't respond to that key until the complete key-value pair has been received. There is one potential corner case issue that should to be covered. Targets can initiate keys. If key-value pairs didn't straddle PDU boundaries, then ensuring that there is a clear originator for each offered key is easy. You can originate any key that you haven't received an offer of from your partner. But now keys can straddle PDUs. If the text between the last separater and the end of the PDU is Ma, then you don't know what key your partner has started to offer. If the partner was starting to offer MaxBurstSize and you offer it in the next PDU of the exchange, both sides may think they are originator. I suggest one of the following a) don't allow keys to straddle PDU boundaries. b) don't allow originating a key when the last login PDU ended in a partial key. c) don't allow offering a key where the start of the key matches a partial key at the end of the last login PDU. 3. Yes, we noticed a little while ago that losing a packet at the end of negotiation could hang things up though the concern is mainly for a full feature phase negotiation. Looking at 6.8, any timeout during negotiation causes the login and its TCP connection to be terminated. The whole negotiation process (see the point about origninators in 2) depends upon a one-by-one exchange of PDUs. PDU loss has to terminate it. Therefore, the target commits to the end of login as described for T5 target. It has sent the final login response with a status of zero. Moves to S5. If the login response doesn't get to the initiator, then either the initiator will close the connection due to the timeout. Since the target is in S4, loss of the transport connection will cause it to go to S8 and R1 of the cleanup state machine. It presumably will not take the M2 transition because the intiator isn't going to do cleanup for a connection it thinks wasn't in full feature phase. It will take M1 due to timeout - not elegant but good enough. The concern was Full Feature Phase negotation. Until negotiation ends, it can be reset and no values change. When the target sends the last Text Response PDU, then it thinks negotiation has ended and it applies the new values. If that PDU doesn't reach the initiatior, then it terminates the entire negotiation and continues to use the old values. The two ends are using different values. We decided to not raise this as an issue because it is such a corner case - we are operating over a reliable connection so PDUs shouldn't be lost (unless the whole path goes down in which case it doesn't matter). Also, there are few values exchanged during full feature so it isn't worthwhile to add complexity. Regards, Pat -----Original Message----- From: Martins Krikis [mailto:mkrikis@yahoo.com] Sent: Friday, May 24, 2002 12:39 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: iSCSI: Negotiation clarifications still needed The previous thread went on too long, but since it has now quieted down, I'll conjecture that the following are the aspects that still need to be addressed. 1. Not everybody seemed to have noticed that it is NOT legal to send the same key again, if it has once been negotiated (including negotiations that end with a reserved value (Reject, Irrelevant or NotUnderstood). I think it would benefit the draft to add the sentence that Pat proposed to paragraph 5 or page 72 in 12-92: "Sending the key again would be a re-negotiation". That I think would make it crystal clear. 2. When the key=value pairs that Originator is sending are broken across multiple PDUs, it is not clear whether the Responder may start responding to the keys as soon as it receives them or whether it should send blank PDUs back (as in the example on page 164 of 12-92) until it gets a PDU, the data part of which ends in a NUL byte (thus signaling that there are no broken key=value pairs at the end of it). I am proposing that the draft should make it explicit that only blank PDUs are to be sent. This allows decoupling of key=value generation from their encapsulation in PDUs (i.e., the generating logic need not worry about whether a key=value pair will fit and go out in this PDU or has to be retained to go out in the next). I can explain in detail why this is important (it has to do with teh possibility of receiving the "just-about outgoing" keys) but I'm keeping this "brief". Furthermore, it is my feeling that instead of checking the last bytes of a PDU for NUL, it would be better if the end-of-data was marked by a flag in the header. This way encapsulation will be simpler---just put as much data in the PDU as fits there and raise the flag if it isn't all, instead of checking whether it ends in a NUL and possibly shortening data to make it not end like that. 3. There is an opinion that on page 73 of 12-92, the phrase that says "or the responder may select an admissible value" is in contradiction to the very next sentence. There is also an opinion that this phrase is entirely unnecessary and detrimental to achieving broad interoperability (I call it "cutting slack to misbehaving or incompatible originators"). I don't have a suggestion since I consider the "feature" that this phrase allows of little importance to a properly built iSCSI node. 4. This is new. When doing Text Request/Response negotiations (i.e., in FFP), it seems that the Initiator commits to the new values when it receives a response from the Target with the F bit set. It is unclear when the Target should commit. Should it switch to using the new values as soon as it sends its response with the F-bit set, or should it do so only when it knows that the Initiator received its response? Commiting right away is simpler and since responses with F-bits set have TTT=0xffffffff and thus may not be reset, sounds plausible. If the values have importance on the next reception, it may also be important to commit timely. However, what if the Initiator doesn't get this response? Target now has committed, Initiator hasn't. Committing later puts the burden on Initiator to send something effectively telling "I've received your final response". Otherwise the Target will time out and not commit. This response can get lost too. Basically, it is beginning to look a bit like (what was it called?) "distributed consensus problem"? I think it goes like this: Two generals that are on oposite sides of the enemy want to synchronize their attack, and start sending messengers through with messages like "attack at dawn->", "<-ok, attack at dawn", "I know you know we attack at dawn->", "<-, I know you know I know we attack at dawn", etc., etc., ... But at no point can they commit yet... Is anybody else worried about this? Anyway, so when should a target commit? Page 83 of 12-92 is the relevant reference. Thanks, Martins Krikis Disclaimer: these opinions are my own and may not be those of my employer. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Fri May 24 17:54:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16508 for ; Fri, 24 May 2002 17:54:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4OLfV901191 for ips-outgoing; Fri, 24 May 2002 17:41:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4OLfUw01186 for ; Fri, 24 May 2002 17:41:30 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4OLfTWo039584; Fri, 24 May 2002 17:41:29 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4OLfSH221340; Fri, 24 May 2002 15:41:28 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: [iSCSI]: Key negotiation procedure proposal To: Bill Studenmund Cc: "ips" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Fri, 24 May 2002 14:39:37 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/24/2002 03:41:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I do not see the new draft as broken, it is a bit clearer. And it has worked in the plugfests. We only have had about 3-4 folks that have been having a problem here, most of the rest are busy doing meaning work. But these 3 folks have been chatting a lot. What I see is some folks dealing with is preference not brokenness. There might be some words that you want to clear up. Please suggest them, but lets not get into preferences on how one would like it to work I think we are past that, lets just clear up the miss understanding. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Bill Studenmund @ece.cmu.edu on 05/24/2002 12:53:57 PM Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL cc: Martins Krikis , , Subject: Re: [iSCSI]: Key negotiation procedure proposal On Fri, 24 May 2002, Julian Satran wrote: > All this thread is based on the assumption that discovery of what other > side capabilities are is a good thing to have in the protocol. We must be reading different threads. While I've seen discovery mentioned and discussed, it's not been a base assumption of what I understood the thread was about. > Except for one item the group has decided a long time ago against it. > The messages consume an inordinate amount of time from all of us - and we > are looking for things to fix (big or small). The thread was about the fact people think that login negotiation needs fixing. It could be the negotiation methods need changing (as in Lubin's suggestion), or the text needs changing to something more like what John wrote. The point though is that the current negotiation description is broken in the minds of a number of implementors. It sounds like it is not broken in the minds of a number of the WG members who have been involved for a while. So from that I conclude the spec hasn't been capturing what is in the WG's thoughts; the spec needs work. > If you think that negotiations have to be done some other way that is > essentially better - please discuss this between yourselves and submit an > ID. I think that would be a reasonable suggestion if we were talking about making it spiffier & better. But we're complaining that we think it's broken. Telling us to go off and come back with an ID does not strike me as a suggestion which will help us converge to an answer. Take care, Bill From owner-ips@ece.cmu.edu Fri May 24 19:11:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18987 for ; Fri, 24 May 2002 19:11:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4OMxXc04723 for ips-outgoing; Fri, 24 May 2002 18:59:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail2.hd.intel.com (hdfdns02.hd.intel.com [192.52.58.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4OMxWw04717 for ; Fri, 24 May 2002 18:59:32 -0400 (EDT) Received: from mkrikis-laptop (mkrikis-laptop.hd.intel.com [10.127.144.226]) by mail2.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with ESMTP id g4OMxPS05341; Fri, 24 May 2002 22:59:25 GMT Received: from martinsk by mkrikis-laptop with local (Exim 3.35 #1 (Debian)) id 17BOxa-0000cP-00; Fri, 24 May 2002 18:59:02 -0500 To: hufferd@us.ibm.com, ips@ece.cmu.edu, wrstuden@wasabisystems.com Subject: Re: [iSCSI]: Key negotiation procedure proposal Message-Id: From: Martins Krikis Date: Fri, 24 May 2002 18:59:02 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk John L. Hufferd wrote: > I do not see the new draft as broken, it is a bit clearer. Yes, getting clearer little by little, because some people fight for clarity. Once it gets crystal clear in the area of negotiation, I'll say "thanks" and leave it alone. Please note that some of the very clear and right things that you have been saying, even things that you have said should be put in the draft, are NOT there! > And it has > worked in the plugfests. That does not constitute a proof that it is not broken. > We only have had about 3-4 folks that have been > having a problem here, Yes, I was having a problem here. Because this mailing list erroneously convinced me that renegotiating Reject-ed keys is allowed. I actually believed this and recoded a previously perfectly good implementation. After raising text clarity issues I was then being assured about completely the opposite, in fact we got some text in the draft proving the opposite. Now I have to undo the changes to my implementation. Do you think I'm having fun with this here? Do you think I'd like to move to other areas of iSCSI only to implement those too the wrong way? I'm pretty mad about the (now ex-) renegotiation issue actually! > most of the rest are busy doing meaning work. I'd rather have my manager decide whether I'm doing meaning work or not. Saving a company from doing a wrong implementation seems like a fairly worthwhile cause to me. > But these 3 folks have been chatting a lot. Yes, that's very unfortunate. But it could have all been prevented simply by having a clearer draft to work with. > What I see is some folks dealing with is preference not brokenness. On some issues yes. Some of us prefer simplicity, others prefer feature completeness, others prefer not doing anything "this late". This could have all been avoided by having the specification be more deterministic, or just less ambiguous. > There might be some words that you want to clear up. > Please suggest them, Done already. > but lets not get into preferences on how one would like it to > work I think we are past that, lets just clear up the miss understanding. That's what we're trying to do. Unfortunately the misunderstandings often reveal deaper deficiencies. And Julian asked to submit proposals, which is what I just did regarding pairs broken across PDUs. Martins Krikis, Intel Corp. Disclaimer: these are my own opinions and not necessarily my employer's. From owner-ips@ece.cmu.edu Fri May 24 19:14:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19127 for ; Fri, 24 May 2002 19:14:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4OMTQQ03433 for ips-outgoing; Fri, 24 May 2002 18:29:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13707.mail.yahoo.com (web13707.mail.yahoo.com [216.136.175.140]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4OMTOw03427 for ; Fri, 24 May 2002 18:29:24 -0400 (EDT) Message-ID: <20020524222923.53285.qmail@web13707.mail.yahoo.com> Received: from [192.52.58.5] by web13707.mail.yahoo.com via HTTP; Fri, 24 May 2002 15:29:23 PDT Date: Fri, 24 May 2002 15:29:23 -0700 (PDT) From: Martins Krikis Subject: RE: iSCSI: Negotiation clarifications still needed To: pat_thaler@agilent.com, Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C09D2AD@axcs04.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- pat_thaler@agilent.com wrote: > Martins, > > Comments referenced by the same items Martins used. > > 1. Julian sent an email saying he would put the text > > I proposed in (though the text you quoted is not the > > whole text). Julian put in part of the text (in 12-92). I quoted the part that he didn't put in. I'm wondering why. Julian, I asked you once personally, and asked on the list again. Why don't you put the remaining part of Pat's text in so that there are no doubts about this issue? > 2. I think that the principle we have been using on > text negotiation was that each key negotion is a > separate item. Your proposal would be counter to > that > and I don't think it would be an improvement. I thought so too until yesterday, in fact my implementation was NOT sending just blank PDUs, but I realized it had a subtle bug, having to do with what you describe as a "corner case" below. > The > target should be allowed to respond to any complete > key-value pair it has received. When a key-value > pair is straddling the PDU bondary, then it > shouldn't > respond to that key until the complete key-value > pair > has been received. of course, since it may not even know for sure what the straddling key or value is... > There is one potential corner case issue that should > to be covered. Targets can initiate keys. If > key-value > pairs didn't straddle PDU boundaries, then ensuring > that there is a clear originator for each offered > key > is easy. You can originate any key that you haven't > received an offer of from your partner. That's roughly why I made the proposal to look for a "data-end" flag. > But now keys > can straddle PDUs. If the text between the last > separater > and the end of the PDU is Ma, then you don't know > what > key your partner has started to offer. If the > partner > was starting to offer MaxBurstSize and you offer it > in > the next PDU of the exchange, both sides may think > they > are originator. And that is bad. Also, if we don't consider MaxBurstSize as offered, then the side that put "Ma" in the PDU is in a somewhat uneasy situation for that key's state... it cannot consider it sent, however, presumably it had some value ready for it, so it had gone through some logic for that key. It just becomes a clumsy situation. > I suggest one of the following > a) don't allow keys to straddle PDU boundaries. This would work, but is not as clean as having a data-end flag introduced, which signals that now the other side should respond. With your proposal the Originator when it prepares each key and value must check that the key and '=' fits entirely, otherwise it must put it back and likely go through the process again in the next round. Here we have the key + value generation logic tightly coupled with the iSCSI encapsulator (which knows how much is fitting). > b) don't allow originating a key when the last login > PDU ended in a partial key. Do you mean don't allow originating any key at all or do you mean the same as in (c) below? If the former, then this is practically the same as what I'm proposing, except my restriction would be in effect if any part of key=value pair is straddled. That requires just checking for NUL-s at the end of the PDU and not looking farther back for '='-s. Still an even cleaner aproach is a new flag in the header. > c) don't allow offering a key where the start of the > key > matches a partial key at the end of the last login > PDU. This would work too. But is not a very clean aproach to the problem. Before considering whether to originate a key we have to compare it to the incomplete key that's left over from the just received PDU. Furthermore, the side that sent the incomplete key ideally should remember that it sent an incomplete key and check incoming keys against the incomplete one to catch the other side in cheating... My point really is that ideally we want to see something like this: Initiator: key1=value1 key2=value2 key3=value3 ... key17=value17 Target: key1=value1 ... key17=value17 key18=value18 ... key34=key34 Initiator: key18=value18 ... key34=key34 Done. We don't want to worry about how this splits up in PDUs. Just like when I'm writing to a BSD-socket I don't care in which IP datagram each byte travels. And if I'm trying to send a certain block of data and expect the other side to answer once it receives it all, I don't like it interrupting my thought and beginning to answer little by little after each IP packet received. The point is that negotiation would be more natural if it where "block-based", where each side can send its block of data to the other side without being interrupted with partial answers and new keys requiring answers. Right now we've made PDU the block, but that is not convenient because PDU size is limited, and thus not all data (that a node may have worked hard preparing) may fit. Because it all doesn't fit, the other side may start originating the same data that we would have sent if only the PDU had been larger. We get into extra complications trying to avoid the problem of both sides thinking that they originated something. Perhaps an even better analogy is the IP protocol itself. IP datagrams can get fragmented en route. Yet I know of no protocols that would work on individual fragments of them, they all first assemble the whole IP datagram, then see what can be done with it. Same thing here. An iSCSI node likely has a bunch of key=value pairs that it wants to send to the other side and it is an extra hassle to keep checking how many will fit and how many won't, then adjusting state for those, etc., etc. It is way cleaner to just pass all data down to the encapsulating layer, knowing that the other side won't do a thing before all this data hasn't been received and reassembled there. I'm saying my proposal is cleaner. Your proposals use bandwidth more efficiently but are more complex. This is not a performance critical area of the specification, nor are we even worrying about a very likely case. I honestly believe that typically most everything that a node wants to send will fit. Thus, I think the cleaner aproach should be preferred. > 3. Yes, we noticed a little while ago that losing a This was my #4, BTW, but that's OK. > packet at the end of negotiation could hang things > up > though the concern is mainly for a full feature > phase > negotiation. Looking at 6.8, any timeout during > negotiation causes the login and its TCP connection > to > be terminated. The whole negotiation process (see > the > point about origninators in 2) depends upon a > one-by-one > exchange of PDUs. PDU loss has to terminate it. I'm beginning to skip and snip text here because I was explicitly worried about the Text Request/Response case, not Logins. > The concern was Full Feature Phase negotation. Until > > negotiation ends, it can be reset and no values > change. > When the target sends the last Text Response PDU, > then > it thinks negotiation has ended and it applies the > new values. So you're suggesting that the target commits to the new values as soon as it sends the last Text Response PDU. This is what I've been doing, but from other posts on the list I know that other people preferred to wait till the next PDU from the initiator. > If that PDU doesn't reach the > initiatior, > then it terminates the entire negotiation and just to be precise, it = initiator. > continues > to use the old values. The two ends are using > different > values. Yes, that's what I'm worried about and don't see a good way out. If the workgroup is aware that this is possible and is happy to live with it, then I can probably leave the issue alone. > We decided to not raise this as an issue because it > is > such a corner case - we are operating over a > reliable > connection so PDUs shouldn't be lost (unless the > whole > path goes down in which case it doesn't matter). > Also, > there are few values exchanged during full feature > so > it isn't worthwhile to add complexity. OK, I'll take your word for it. Thanks, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Fri May 24 19:52:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20334 for ; Fri, 24 May 2002 19:52:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4ONETH05363 for ips-outgoing; Fri, 24 May 2002 19:14:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4ONERw05358 for ; Fri, 24 May 2002 19:14:28 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel12.hp.com (Postfix) with ESMTP id 209FCE004BC; Fri, 24 May 2002 16:14:22 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id QAA01286; Fri, 24 May 2002 16:16:08 -0700 (PDT) Message-ID: <00d801c20378$bbbba170$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Sanjay Goyal" , References: Subject: Re: iSCSI: Data-In PDU having MaxBurstSize restriction for a sequence Date: Fri, 24 May 2002 16:14:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sanjay, There were earlier messages on this in the archive. One of the reasons we decided to require F-bit for every MaxBurstSize of Data-In is to ensure that initiator may use that as a hint to send Data-Out in the case of bidirectional commands. The truth is that we don't know if such a hint is required, but it is architected for a possible use if implementations need it. Note that A-bit is not related to F-bit really - except both bits are somehow related to MaxBurstSize ("at most once" Vs "at least once"). Hope that helps. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Sanjay Goyal" To: Sent: Thursday, May 23, 2002 2:01 PM Subject: iSCSI: Data-In PDU having MaxBurstSize restriction for a sequence > Hi > What is the rational behind having MaxBurstSize constraining a Sequence for > Data-In PDUs? > As Initiator has to receive all the data from Target as Data-In PDUs > anyway, what good is it to set F-bit every MaxBurstSize? It rather should be > set, after whatever amount of data Target has in its buffer has been > transmitted. > Would somebody suggest a good example when Initiator can take advantage of > F-bit being set every MaxBurstSize. > I understand that A-bit is used in conjuction with MaxBurstSize, however my > context of the question is when A-bit is not used. > > Regards > Sanjay Goyal > From owner-ips@ece.cmu.edu Fri May 24 19:53:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20422 for ; Fri, 24 May 2002 19:53:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4ONirJ06526 for ips-outgoing; Fri, 24 May 2002 19:44:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4ONilw06520 for ; Fri, 24 May 2002 19:44:52 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 95494D090; Fri, 24 May 2002 17:44:46 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 29C52120; Fri, 24 May 2002 17:44:46 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 24 May 2002 17:44:41 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 17:44:41 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09D2EF@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: ni1d@arrl.net, luben@splentec.com Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: [iSCSI]: Key negotiation procedure proposal Date: Fri, 24 May 2002 17:44:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I agree. The only reason for a rejected key is that the orignator offered something that shouldn't have ever been offered or provided a list with no acceptable options to the responder. There isn't any point in continuing the negotiation. Pat -----Original Message----- From: Paul Koning [mailto:ni1d@arrl.net] Sent: Thursday, May 23, 2002 9:55 AM To: luben@splentec.com Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: Re: [iSCSI]: Key negotiation procedure proposal Excerpt of message (sent 23 May 2002) by Luben Tuikov: > But Julian, I'm _not_ talking here about discovering capabilities. > > This is just rules for Login/Text Operational Key Negotiation. > ... > Furthermore I don't think that this complicates negotiation, > If anything ,it makes it simpler. There is a rule for simple > implementations (Martins, your opinion?) and a rule > for fully developed implementations. > > It's just login/text negotiation rules. > > People, take a look at the rules and examples > and let me hear your opinion? (those of you > involved in login/text neg. discussions) I think it's unnecessarily complex. The "simple implementation" alone is plenty. paul From owner-ips@ece.cmu.edu Fri May 24 20:26:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21624 for ; Fri, 24 May 2002 20:26:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4P09gJ07604 for ips-outgoing; Fri, 24 May 2002 20:09:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4P09fw07600 for ; Fri, 24 May 2002 20:09:41 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 67003D6F7; Fri, 24 May 2002 18:09:40 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 373EAEB; Fri, 24 May 2002 18:09:40 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 24 May 2002 18:09:40 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 18:09:40 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09D2F8@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: luben@splentec.com, hufferd@us.ibm.com Cc: mkrikis@yahoo.com, ips@ece.cmu.edu Subject: RE: [iSCSI]: Key negotiation procedure proposal Date: Fri, 24 May 2002 18:09:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I think it also makes sense to close the connection. Why try to interoperate when something is broken and for the existing parameters, there is no reason for a Reject when an appropriate type value was offerred? But if one really wants to give it a try there is a reasonable value to use. All parameters that have a default can use that as the commit value if an attempt to negotiate at login experiences a Reject. During full feature they can use the old value. Regards, Pat -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Thursday, May 23, 2002 5:23 PM To: John Hufferd Cc: Martins Krikis; ips@ece.cmu.edu Subject: Re: [iSCSI]: Key negotiation procedure proposal John Hufferd wrote: > > Martins said: > "...However, I actually object to the whole idea of cutting any slack to > non-conforming Originators by not Rejecting their keys and sending a "good > value" instead. I don't think it is good. So I'm for the removal of this > possibility...." > > I agree with this. > > I do not know if we have to end the connection after the Reject, but if the > Originator sends it again, then shut down. I see no value in going on and > on (like this thread). lets move to closure here. Ok, ``simple implementation'' handles this. But, John, what else can we do after sending key=Reject _and_ inter-operate?! We have to have some stringent rules, in order to achieve inter-operability _and_ negotiation convergence. If you have a constructive suggestion (a rule, ruleset, etc.), please post it. -- Luben From owner-ips@ece.cmu.edu Fri May 24 20:26:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21627 for ; Fri, 24 May 2002 20:26:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4ONnaI06733 for ips-outgoing; Fri, 24 May 2002 19:49:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4ONnYw06728 for ; Fri, 24 May 2002 19:49:34 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel12.hp.com (Postfix) with ESMTP id 6B029E00868; Fri, 24 May 2002 16:49:28 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id QAA06458; Fri, 24 May 2002 16:51:15 -0700 (PDT) Message-ID: <00e401c2037d$a344b6e0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Martins Krikis" , "Julian Satran" Cc: References: <20020524193837.72837.qmail@web13709.mail.yahoo.com> Subject: Re: iSCSI: Negotiation clarifications still needed Date: Fri, 24 May 2002 16:49:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Martins, Comments in the same order. 1. Julian may be adding wording for this. 2. Seems to me that we need to stipulate that only key values may straddle PDU boundaries - key names (ideally inclusive of "=") shall not. That should avoid requiring blank PDUs. 3. I don't have a strong opinion on this. I don't believe this can cause interoperability problems; OTOH, I don't care if the responder isn't that liberal. 4. Julian and I discussed this scenario a while ago. As you precisely described, only a non-stop dialogue can be reliable and we can't afford a non-stop dialogue. I suppose one can recover the StatSN with a SNACK in FFP, or terminate the connection upon a timeout. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Martins Krikis" To: "Julian Satran" Cc: Sent: Friday, May 24, 2002 12:38 PM Subject: iSCSI: Negotiation clarifications still needed > The previous thread went on too long, but since it > has now quieted down, I'll conjecture that the > following are the aspects that still need to be > addressed. > > 1. Not everybody seemed to have noticed that it is > NOT legal to send the same key again, if it > has once been negotiated (including negotiations > that end with a reserved value (Reject, > Irrelevant or NotUnderstood). > > I think it would benefit the draft to add the > sentence that Pat proposed to paragraph 5 or page > 72 in 12-92: "Sending the key again would be a > re-negotiation". That I think would make it crystal > clear. > > 2. When the key=value pairs that Originator is > sending are broken across multiple PDUs, it > is not clear whether the Responder may start > responding to the keys as soon as it receives > them or whether it should send blank PDUs back > (as in the example on page 164 of 12-92) until > it gets a PDU, the data part of which ends in > a NUL byte (thus signaling that there are no > broken key=value pairs at the end of it). > > I am proposing that the draft should make it explicit > that only blank PDUs are to be sent. This allows > decoupling of key=value generation from > their encapsulation in PDUs (i.e., the generating > logic need not worry about whether a key=value > pair will fit and go out in this PDU or has to > be retained to go out in the next). I can explain > in detail why this is important (it has to do > with teh possibility of receiving the "just-about > outgoing" keys) but I'm keeping this "brief". > > Furthermore, it is my feeling that instead of > checking the last bytes of a PDU for NUL, it > would be better if the end-of-data was marked by > a flag in the header. This way encapsulation will > be simpler---just put as much data in the PDU as > fits there and raise the flag if it isn't all, > instead of checking whether it ends in a NUL and > possibly shortening data to make it not end like > that. > > 3. There is an opinion that on page 73 of 12-92, > the phrase that says "or the responder may > select an admissible value" is in contradiction > to the very next sentence. There is also an > opinion that this phrase is entirely unnecessary > and detrimental to achieving broad > interoperability (I call it "cutting slack to > misbehaving or incompatible originators"). > > I don't have a suggestion since I consider the > "feature" that this phrase allows of little > importance to a properly built iSCSI node. > > 4. This is new. When doing Text Request/Response > negotiations (i.e., in FFP), it seems > that the Initiator commits to the new values > when it receives a response from the Target with > the F bit set. It is unclear when the Target should > commit. Should it switch to using the new values > as soon as it sends its response with the F-bit > set, or should it do so only when it knows that > the Initiator received its response? > > Commiting right away is simpler and since responses > with F-bits set have TTT=0xffffffff and thus > may not be reset, sounds plausible. If the > values have importance on the next reception, > it may also be important to commit timely. However, > what if the Initiator doesn't get this response? > Target now has committed, Initiator hasn't. Committing > later puts the burden on Initiator to send something > effectively telling "I've received your final > response". Otherwise the Target will time out and > not commit. This response can get lost too. > > Basically, it is beginning to look a bit like > (what was it called?) "distributed consensus problem"? > I think it goes like this: > > Two generals that are on oposite sides of the > enemy want to synchronize their attack, and > start sending messengers through with messages > like > "attack at dawn->", > "<-ok, attack at dawn", > "I know you know we attack at dawn->", > "<-, I know you know I know we attack at dawn", > etc., etc., ... > But at no point can they commit yet... > > Is anybody else worried about this? > Anyway, so when should a target commit? Page 83 > of 12-92 is the relevant reference. > > Thanks, > > Martins Krikis > > Disclaimer: these opinions are my own and may > not be those of my employer. > > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > From owner-ips@ece.cmu.edu Fri May 24 21:02:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22891 for ; Fri, 24 May 2002 21:02:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4P0S5s08442 for ips-outgoing; Fri, 24 May 2002 20:28:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4P0S3w08437 for ; Fri, 24 May 2002 20:28:03 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 20:26:42 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BED6@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI inband auth: Rough Consensus + Direction Date: Fri, 24 May 2002 20:26:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Based on the email on the list since the proposed resolution text was announced, I think there is rough consensus on the following points: (1) CHAP w/strong secrets is acceptable in principle as the "MUST implement" authentication method. (2) No change should be made to the requirements for bi-directional authentication that existed previously - the SHOULD for bidirectional use of CHAP (if CHAP is used) is not appropriate. (3) Add Paul Koning's example and related text on preventing reflection attacks on bi-directional CHAP. (4) SRP remains in the draft as a "MAY implement" method. That's progress, but what we don't have rough consensus on is the practical details of requiring CHAP w/strong secrets, specifically the latter portion of "SHOULD use strong secrets w/CHAP, otherwise MUST use ESP encryption to protect weak secrets". I believe the problems in this area are caused by a lack of details on what an implementer has to do to satisfy the "SHOULD" in order to avoid getting whacked with the "MUST". The proposed resolution text leaves open the possibility that misbehavior by a user (e.g., failure to RTFM and/or follow instructions given by a setup tool) could cause the implementer/vendor to become responsible for the MUST - that was definitely not the intent of the proposal, and I think John Hufferd made this point. I suggest that the direction to finish closing this issue is to draw up a list of measures that the draft declares to be sufficient to satisfy the SHOULD (i.e., the draft contains text saying that if an implementation does , , ..., and , the implementation has satisified "SHOULD use strong secrets" requirement and hence the "MUST use ESP encryption" requirement does not apply, where and the like are under control of the implementer). This is importnat regardless of whether we change the "SHOULD" for strong CHAP secrets to a "MUST". Here's a very quick start at what the contents of such a list could be: - Secrets must be 96 bits in size - Provide means to generate secrets from real randomness, and accept externally generated secrets. Do not provide means to generate a smaller secret or one with less randomness. - Do not provide any means (e.g., GUI, CLI or other external interface) to expand a smaller secret to 96+ bits or accept external input of a smaller secret. - Disallow any secret with 16+ bits of leading 0's? (helps defend against accidentally truncating to 64 or 32 bits) - Documentation and configuration tools must warn users about the danger of secrets based on insufficient randomness. None of the above items are set in stone. Please comment and suggest revisions/extensions to the above list. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri May 24 21:03:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22978 for ; Fri, 24 May 2002 21:03:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4P0i0O09142 for ips-outgoing; Fri, 24 May 2002 20:44:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4P0hww09138 for ; Fri, 24 May 2002 20:43:58 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id F0C8E30706; Fri, 24 May 2002 20:43:57 -0400 (EDT) Date: Fri, 24 May 2002 17:41:57 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: , , Subject: RE: iSCSI: Negotiation clarifications still needed In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C09D2AD@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 24 May 2002 pat_thaler@agilent.com wrote: ** note there's a proposed experiment at the end. Please try it and see what you think of how your code does :-) ** > Martins, > > Comments referenced by the same items Martins used. > > 1. Julian sent an email saying he would put the text > I proposed in (though the text you quoted is not the > whole text). > > 2. I think that the principle we have been using on > text negotiation was that each key negotion is a > separate item. Your proposal would be counter to that > and I don't think it would be an improvement. The > target should be allowed to respond to any complete > key-value pair it has received. When a key-value > pair is straddling the PDU bondary, then it shouldn't > respond to that key until the complete key-value pair > has been received. Has anyone actually operated negotiations in the mode where keys don't fully fit and there are multiple keys to deal with? I'd expect not since the default PDU data payload is 8k, and I don't think we really have 8k worth of negotiation parameters. While we do have security parameters which can get over 8k, the security negotiations I saw (when scanning the spec) only had one key in flight at a time (thus we don't get into this case). To be honest, what Martins proposed is exactly what I read the spec to indicate! :-) It's also what I've coded, and was pretty easy to do. The example showing the spec text negotiation certainly indicated that's the way to do things. :-| The reason I really like what Martins has suggested (and which we talked about in private EMail) is that my head hurts when I think about how to build code to deal with what you describe. Here's the case that makes my head hurt: Initiator builds up a set of keys and starts to negotiate them. Due to the fact it had too much text, it can't send it all in one go. So it builds up the first PDU, and sends it. It now 1) must remember where it is (so it can finish in the next PDU), and 2) deal with the key negotiations that come back from the target in response to the first PDU. When the reply comes back from the target, the initiator has both handle the keys the target sends back and the unsent ones it has. You partially cover that below by talking about not letting the target initiate keys when we had a partial send. But there's another case too: Say the response from the target ALSO doesn't fit in one PDU. Yes, the target's not going to respond to the key=value pair that wasn't complete, but say its response to everything else was bigger than the initiator's representation of said keys. For this case to happen, the target's response has to grow more than the first bit of the PDU-spanning key/value pair. The case where I can see this happening is we had a mix of boolean-or keys and other keys. And for these bolean-or keys, the initiator wanted NO but the target wanted YES. So the target's response is bounded to be bigger. Or maybe there were some Rejects in there when the offer was less than 7 bytes long. So now we have TWO PDU-spanning key sets. And the target didn't originate anything. :-) Yes, this is a rare case. But it can happen. And, for iSCSI to be robust, we need to prevent it. When I think about this, my head spins. It seems much simpler to me to let one side finish sending before the other starts responding. That way we won't end up with having to deal with any corner cases. :-) > There is one potential corner case issue that should > to be covered. Targets can initiate keys. If key-value > pairs didn't straddle PDU boundaries, then ensuring > that there is a clear originator for each offered key > is easy. You can originate any key that you haven't > received an offer of from your partner. But now keys > can straddle PDUs. If the text between the last separater > and the end of the PDU is Ma, then you don't know what > key your partner has started to offer. If the partner > was starting to offer MaxBurstSize and you offer it in > the next PDU of the exchange, both sides may think they > are originator. Yeah, that's the other corner case. What Martins suggests just seems easier to me. We decouple negotiation parsing from sending/receiving negotiation packets. The only time we hand data to the nego. parser, all the key/value pairs are there. We then generate all the response we want to send. If needed we send said over multiple PDUs. Among other things, we DON'T need to even deal with split keys at all; they get reassembled before we look at them! Here's a sample logic flow: dealing_with_input_login_cmd/rsp() { if (have_more_to_send_from_last_time) { send a PDU containing more data if (this_PDU_finishes_data_flow) clear have_more_to_send_from_last_time; return; } if (PDU.len != 0) { read PDU's data to buffer if (this_pdu_isn't_last) return } Process_input_buffer_and_generate_response Send a PDU containing data if (not_all_data_sent) set have_more_to_send_from_last_time; } The same logic flow works for both text and login, and avoids LOTS of headaches. *** Experiement *** Here's a simple experiment to try. Try cranking down the default PDU length your implementation uses to something rediculously small, like 64 bytes, and see what happens when you negotiate a login. Are you happy with the results? Take care, Bill From owner-ips@ece.cmu.edu Fri May 24 21:03:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22991 for ; Fri, 24 May 2002 21:03:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4P0iFg09154 for ips-outgoing; Fri, 24 May 2002 20:44:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4P0iEw09150 for ; Fri, 24 May 2002 20:44:14 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4P0iDFD081278; Fri, 24 May 2002 20:44:13 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4P0i7H48528; Fri, 24 May 2002 18:44:07 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: [iSCSI]: Key negotiation procedure proposal To: Martins Krikis Cc: ips@ece.cmu.edu, wrstuden@wasabisystems.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Fri, 24 May 2002 17:42:16 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/24/2002 06:44:07 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Martins, I am sorry I do not see it like you do. We have been having a shot-gun approach, to every thing at the same time. Please focus on one thing at a time and drive that to closure. That way we can discard the personal preferences without getting it tied up with worthwhile things. If you want to work with three topics, lets have three threads, etc. But we need to drive to closure with focus. I can not blame Julian, this thread has become a stew for everything. And I do not think it is fair for you to attack him. We have over 270 pages of stuff, and you are focused on a narrow point, which is fine, but if there is not clarity, agreement, or closure, therefore he can not add it to the document. The problem is not Julian!!! . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Martins Krikis on 05/24/2002 04:59:02 PM To: John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu, wrstuden@wasabisystems.com cc: Subject: Re: [iSCSI]: Key negotiation procedure proposal John L. Hufferd wrote: > I do not see the new draft as broken, it is a bit clearer. Yes, getting clearer little by little, because some people fight for clarity. Once it gets crystal clear in the area of negotiation, I'll say "thanks" and leave it alone. Please note that some of the very clear and right things that you have been saying, even things that you have said should be put in the draft, are NOT there! > And it has > worked in the plugfests. That does not constitute a proof that it is not broken. > We only have had about 3-4 folks that have been > having a problem here, Yes, I was having a problem here. Because this mailing list erroneously convinced me that renegotiating Reject-ed keys is allowed. I actually believed this and recoded a previously perfectly good implementation. After raising text clarity issues I was then being assured about completely the opposite, in fact we got some text in the draft proving the opposite. Now I have to undo the changes to my implementation. Do you think I'm having fun with this here? Do you think I'd like to move to other areas of iSCSI only to implement those too the wrong way? I'm pretty mad about the (now ex-) renegotiation issue actually! > most of the rest are busy doing meaning work. I'd rather have my manager decide whether I'm doing meaning work or not. Saving a company from doing a wrong implementation seems like a fairly worthwhile cause to me. > But these 3 folks have been chatting a lot. Yes, that's very unfortunate. But it could have all been prevented simply by having a clearer draft to work with. > What I see is some folks dealing with is preference not brokenness. On some issues yes. Some of us prefer simplicity, others prefer feature completeness, others prefer not doing anything "this late". This could have all been avoided by having the specification be more deterministic, or just less ambiguous. > There might be some words that you want to clear up. > Please suggest them, Done already. > but lets not get into preferences on how one would like it to > work I think we are past that, lets just clear up the miss understanding. That's what we're trying to do. Unfortunately the misunderstandings often reveal deaper deficiencies. And Julian asked to submit proposals, which is what I just did regarding pairs broken across PDUs. Martins Krikis, Intel Corp. Disclaimer: these are my own opinions and not necessarily my employer's. From owner-ips@ece.cmu.edu Fri May 24 21:04:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23037 for ; Fri, 24 May 2002 21:04:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4P0jCZ09216 for ips-outgoing; Fri, 24 May 2002 20:45:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13708.mail.yahoo.com (web13708.mail.yahoo.com [216.136.175.141]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4P0jAw09206 for ; Fri, 24 May 2002 20:45:10 -0400 (EDT) Message-ID: <20020525004509.99479.qmail@web13708.mail.yahoo.com> Received: from [192.52.58.5] by web13708.mail.yahoo.com via HTTP; Fri, 24 May 2002 17:45:09 PDT Date: Fri, 24 May 2002 17:45:09 -0700 (PDT) From: Martins Krikis Subject: Re: iSCSI: Negotiation clarifications still needed To: "Mallikarjun C." , Julian Satran Cc: ips@ece.cmu.edu In-Reply-To: <00e401c2037d$a344b6e0$edd52b0f@rose.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun wrote: > 2. Seems to me that we need to stipulate that only > key values > may straddle PDU boundaries - key names (ideally > inclusive > of "=") shall not. That should avoid requiring > blank PDUs. Definitely inclusive of "=". Otherwise there are no strict guarantees that the whole key has been received (we may have keys that are prefixes to other keys in future, and vendor keys may be like that). I can implement it and live with it if that's what people decide on. I just want people to understand that it is conceptually a more complex aproach than requiring strictly blank PDUs and having a data-end flag. (Even if we don't add a new flag and decide data-end by looking for NUL-s at the end, we get a cleaner scheme.) Allowing non-blank PDUs gives better bandwith utilization under presumably rare circumstances (all pairs not fitting), but introduces more complexity for your everyday case. If we only stipulate that no key ever gets broken, then there is the following "clumsiness" required. When "originating" a key=value pair, it has to be checked whether the key will fit fully in the PDU or not, and if not, then "originating" must be postponed. We also need either a more elaborate state for the key (to mark key as received but value as not; so it is not processable yet, nor originatable anymore), or for each key=value pair being originated, key has to be checked against the buffer that would hold the "leftover stuff" from the just received PDU, otherwise we may illegally originate it. Doable, but not clean. I still think that letting the whole set-of-pairs go through (no matter over how many PDUs spread) before the other side is allowed to process them is cleanest. Martins Krikis, Intel Corp. Disclaimer: these opinions are my own and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Fri May 24 21:05:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23078 for ; Fri, 24 May 2002 21:05:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4P0k6W09274 for ips-outgoing; Fri, 24 May 2002 20:46:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4P0k5w09270 for ; Fri, 24 May 2002 20:46:05 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4P0jux08719; Fri, 24 May 2002 20:45:57 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g4P0ju727845; Fri, 24 May 2002 20:45:56 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 20:44:40 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BED7@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI base64 and 12-92 Date: Fri, 24 May 2002 20:44:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-PerlMx-Spam: Gauge=XIIIIII, Probability=16%, Report="NO_REAL_NAME" Sender: owner-ips@ece.cmu.edu Precedence: bulk In the hope of putting an end to this thread, I believe I see rough consensus for the position that Paul Koning succinctly states as: > I would like to see Base64 permitted ONLY for those parameters that > are long octetstrings. Basically, that's only the crypto parameters. And the succinct answer to the question of why it shouldn't be supported for everything is that it confines the b64 support to the crypto-related code in an implementation. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri May 24 21:22:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23546 for ; Fri, 24 May 2002 21:22:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4P133L09979 for ips-outgoing; Fri, 24 May 2002 21:03:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4P131w09975 for ; Fri, 24 May 2002 21:03:01 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4P130Wo052128; Fri, 24 May 2002 21:03:00 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4P12xX146806; Fri, 24 May 2002 19:02:59 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: Non Spanning key To: Martins Krikis Cc: "Mallikarjun C." , "Julian Satran" , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Fri, 24 May 2002 18:01:08 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/24/2002 07:02:59 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk OK, (note the change of subject. So we can focus on one thing at a time.) I am fine with what Mallikarjun said, and do not fine it a problem to do. I propose that Mallikarjun's approach be our closure. That is, Keywords (including the =) do not span PDUs. Can I get agreement. If so we can then move to the next issue. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Martins Krikis @ece.cmu.edu on 05/24/2002 05:45:09 PM Sent by: owner-ips@ece.cmu.edu To: "Mallikarjun C." , Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI: Negotiation clarifications still needed Mallikarjun wrote: > 2. Seems to me that we need to stipulate that only > key values > may straddle PDU boundaries - key names (ideally > inclusive > of "=") shall not. That should avoid requiring > blank PDUs. Definitely inclusive of "=". Otherwise there are no strict guarantees that the whole key has been received (we may have keys that are prefixes to other keys in future, and vendor keys may be like that). I can implement it and live with it if that's what people decide on. I just want people to understand that it is conceptually a more complex aproach than requiring strictly blank PDUs and having a data-end flag. (Even if we don't add a new flag and decide data-end by looking for NUL-s at the end, we get a cleaner scheme.) Allowing non-blank PDUs gives better bandwith utilization under presumably rare circumstances (all pairs not fitting), but introduces more complexity for your everyday case. If we only stipulate that no key ever gets broken, then there is the following "clumsiness" required. When "originating" a key=value pair, it has to be checked whether the key will fit fully in the PDU or not, and if not, then "originating" must be postponed. We also need either a more elaborate state for the key (to mark key as received but value as not; so it is not processable yet, nor originatable anymore), or for each key=value pair being originated, key has to be checked against the buffer that would hold the "leftover stuff" from the just received PDU, otherwise we may illegally originate it. Doable, but not clean. I still think that letting the whole set-of-pairs go through (no matter over how many PDUs spread) before the other side is allowed to process them is cleanest. Martins Krikis, Intel Corp. Disclaimer: these opinions are my own and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Fri May 24 21:28:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23758 for ; Fri, 24 May 2002 21:28:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4P1GMP10513 for ips-outgoing; Fri, 24 May 2002 21:16:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4P1GLw10509 for ; Fri, 24 May 2002 21:16:21 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4P1GBx13903; Fri, 24 May 2002 21:16:12 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g4P1GB729372; Fri, 24 May 2002 21:16:11 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 21:14:55 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BED8@CORPMX14> From: Black_David@emc.com To: hufferd@us.ibm.com Cc: ips@ece.cmu.edu Subject: iSCSI: Renegotiation and Non Spanning key Date: Fri, 24 May 2002 21:14:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-PerlMx-Spam: Gauge=XIIIIII, Probability=16%, Report="NO_REAL_NAME" Sender: owner-ips@ece.cmu.edu Precedence: bulk Ok, let me step in and observe a bit of rough consensus. Martins' first issue was a request for clarifying text to make it clear that keys cannot be renegotiated even if the first negotiation ended with Reject, Irrelevant, or NotUnderstood. That clarifying text needs to go into the draft, as I believe I've seen more than one request for it. For the PDU spanning issue, I believe the rough consensus is that the key plus the following "=" character MUST NOT span a PDU boundary. Thanks, --David > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Friday, May 24, 2002 9:01 PM > To: Martins Krikis > Cc: Mallikarjun C.; Julian Satran; ips@ece.cmu.edu > Subject: Re: iSCSI: Non Spanning key > > > > OK, (note the change of subject. So we can focus on one > thing at a time.) > > I am fine with what Mallikarjun said, and do not fine it a > problem to do. > > I propose that Mallikarjun's approach be our closure. That > is, Keywords > (including the =) do not span PDUs. > > Can I get agreement. > > If so we can then move to the next issue. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com > > > Martins Krikis @ece.cmu.edu on 05/24/2002 > 05:45:09 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: "Mallikarjun C." , Julian > Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: Negotiation clarifications still needed > > > > Mallikarjun wrote: > > > 2. Seems to me that we need to stipulate that only > > key values > > may straddle PDU boundaries - key names (ideally > > inclusive > > of "=") shall not. That should avoid requiring > > blank PDUs. > > Definitely inclusive of "=". Otherwise there are > no strict guarantees that the whole key has been > received (we may have keys that are prefixes to > other keys in future, and vendor keys may be like > that). > > I can implement it and live with it if that's what > people decide on. I just want people to understand > that it is conceptually a more complex aproach than > requiring strictly blank PDUs and having a data-end > flag. (Even if we don't add a new flag and decide > data-end by looking for NUL-s at the end, we get > a cleaner scheme.) Allowing non-blank PDUs gives > better bandwith utilization under > presumably rare circumstances (all pairs not fitting), > but introduces more complexity for your everyday case. > > If we only stipulate that no key ever gets broken, > then there is the following "clumsiness" required. > When "originating" a key=value pair, it has to be > checked whether the key will fit fully in the PDU > or not, and if not, then "originating" must be > postponed. We also need either a more elaborate > state for the key (to mark key as received but > value as not; so it is not processable yet, nor > originatable anymore), or for each key=value pair > being originated, key has to be checked against > the buffer that would hold the "leftover stuff" > from the just received PDU, otherwise we may > illegally originate it. Doable, but not clean. > > I still think that letting the whole set-of-pairs > go through (no matter over how many PDUs spread) > before the other side is allowed to process them > is cleanest. > > Martins Krikis, Intel Corp. > > Disclaimer: these opinions are my own and may > not be those of my employer > > > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > > > From owner-ips@ece.cmu.edu Fri May 24 22:31:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26148 for ; Fri, 24 May 2002 22:31:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4P1uCR11991 for ips-outgoing; Fri, 24 May 2002 21:56:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13708.mail.yahoo.com (web13708.mail.yahoo.com [216.136.175.141]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4P1uAw11987 for ; Fri, 24 May 2002 21:56:10 -0400 (EDT) Message-ID: <20020525015610.6233.qmail@web13708.mail.yahoo.com> Received: from [192.52.58.5] by web13708.mail.yahoo.com via HTTP; Fri, 24 May 2002 18:56:10 PDT Date: Fri, 24 May 2002 18:56:10 -0700 (PDT) From: Martins Krikis Subject: Re: iSCSI: Renegotiation and Non Spanning key To: ips@ece.cmu.edu In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564BED8@CORPMX14> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Black_David@emc.com wrote: > For the PDU spanning issue, I believe the rough > consensus > is that the key plus the following "=" character > MUST NOT > span a PDU boundary. It might be fairer to wait till Tuesday for a real consensus (it's a long weekend here and it's Friday 9:50pm on the east coast, USA). If this is the way we go (and not what I proposed), then there also needs to be text along these lines: "A node MUST NOT send any key that has been received with incomplete (including empty) value". In other words, you cannot just leave the incomplete leftover junk laying around in buffers, you must check against it your outgoing keys. It all could have been avoided. Even checking for whether a key and '=' fully fits could have been avoided. Your call. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Sat May 25 01:51:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04289 for ; Sat, 25 May 2002 01:51:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4P5QHP19747 for ips-outgoing; Sat, 25 May 2002 01:26:17 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4P5QFw19742 for ; Sat, 25 May 2002 01:26:15 -0400 (EDT) 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 g4P5Q3hZ029848; Sat, 25 May 2002 07:26:03 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4P5Q2m101602; Sat, 25 May 2002 07:26:02 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu, mkrikis@yahoo.com MIME-Version: 1.0 Subject: RE: iSCSI: Negotiation clarifications still needed X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 25 May 2002 08:26:08 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 25/05/2002 08:26:02, Serialize complete at 25/05/2002 08:26:02 Content-Type: multipart/alternative; boundary="=_alternative 001D17A2C2256BC4_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001D17A2C2256BC4_= Content-Type: text/plain; charset="us-ascii" Pat your proposed 2b may be what we are looking for - i.e. a responder may not originate a key if it has an incomplete key text. The text we may want to add to section 4.2 is: Key=value pairs may span PDU boundaries. A responder having a received partial key text MUST refrain from originating any new key=value negotiations until it has no incomplete key text. This way one avoids having both negotiating entities assuming the originator role in a negotiation. Julo pat_thaler@agilent.com 05/25/2002 12:16 AM Please respond to pat_thaler To: mkrikis@yahoo.com, Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiation clarifications still needed Martins, Comments referenced by the same items Martins used. 1. Julian sent an email saying he would put the text I proposed in (though the text you quoted is not the whole text). 2. I think that the principle we have been using on text negotiation was that each key negotion is a separate item. Your proposal would be counter to that and I don't think it would be an improvement. The target should be allowed to respond to any complete key-value pair it has received. When a key-value pair is straddling the PDU bondary, then it shouldn't respond to that key until the complete key-value pair has been received. There is one potential corner case issue that should to be covered. Targets can initiate keys. If key-value pairs didn't straddle PDU boundaries, then ensuring that there is a clear originator for each offered key is easy. You can originate any key that you haven't received an offer of from your partner. But now keys can straddle PDUs. If the text between the last separater and the end of the PDU is Ma, then you don't know what key your partner has started to offer. If the partner was starting to offer MaxBurstSize and you offer it in the next PDU of the exchange, both sides may think they are originator. I suggest one of the following a) don't allow keys to straddle PDU boundaries. b) don't allow originating a key when the last login PDU ended in a partial key. c) don't allow offering a key where the start of the key matches a partial key at the end of the last login PDU. 3. Yes, we noticed a little while ago that losing a packet at the end of negotiation could hang things up though the concern is mainly for a full feature phase negotiation. Looking at 6.8, any timeout during negotiation causes the login and its TCP connection to be terminated. The whole negotiation process (see the point about origninators in 2) depends upon a one-by-one exchange of PDUs. PDU loss has to terminate it. Therefore, the target commits to the end of login as described for T5 target. It has sent the final login response with a status of zero. Moves to S5. If the login response doesn't get to the initiator, then either the initiator will close the connection due to the timeout. Since the target is in S4, loss of the transport connection will cause it to go to S8 and R1 of the cleanup state machine. It presumably will not take the M2 transition because the intiator isn't going to do cleanup for a connection it thinks wasn't in full feature phase. It will take M1 due to timeout - not elegant but good enough. The concern was Full Feature Phase negotation. Until negotiation ends, it can be reset and no values change. When the target sends the last Text Response PDU, then it thinks negotiation has ended and it applies the new values. If that PDU doesn't reach the initiatior, then it terminates the entire negotiation and continues to use the old values. The two ends are using different values. We decided to not raise this as an issue because it is such a corner case - we are operating over a reliable connection so PDUs shouldn't be lost (unless the whole path goes down in which case it doesn't matter). Also, there are few values exchanged during full feature so it isn't worthwhile to add complexity. Regards, Pat -----Original Message----- From: Martins Krikis [mailto:mkrikis@yahoo.com] Sent: Friday, May 24, 2002 12:39 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: iSCSI: Negotiation clarifications still needed The previous thread went on too long, but since it has now quieted down, I'll conjecture that the following are the aspects that still need to be addressed. 1. Not everybody seemed to have noticed that it is NOT legal to send the same key again, if it has once been negotiated (including negotiations that end with a reserved value (Reject, Irrelevant or NotUnderstood). I think it would benefit the draft to add the sentence that Pat proposed to paragraph 5 or page 72 in 12-92: "Sending the key again would be a re-negotiation". That I think would make it crystal clear. 2. When the key=value pairs that Originator is sending are broken across multiple PDUs, it is not clear whether the Responder may start responding to the keys as soon as it receives them or whether it should send blank PDUs back (as in the example on page 164 of 12-92) until it gets a PDU, the data part of which ends in a NUL byte (thus signaling that there are no broken key=value pairs at the end of it). I am proposing that the draft should make it explicit that only blank PDUs are to be sent. This allows decoupling of key=value generation from their encapsulation in PDUs (i.e., the generating logic need not worry about whether a key=value pair will fit and go out in this PDU or has to be retained to go out in the next). I can explain in detail why this is important (it has to do with teh possibility of receiving the "just-about outgoing" keys) but I'm keeping this "brief". Furthermore, it is my feeling that instead of checking the last bytes of a PDU for NUL, it would be better if the end-of-data was marked by a flag in the header. This way encapsulation will be simpler---just put as much data in the PDU as fits there and raise the flag if it isn't all, instead of checking whether it ends in a NUL and possibly shortening data to make it not end like that. 3. There is an opinion that on page 73 of 12-92, the phrase that says "or the responder may select an admissible value" is in contradiction to the very next sentence. There is also an opinion that this phrase is entirely unnecessary and detrimental to achieving broad interoperability (I call it "cutting slack to misbehaving or incompatible originators"). I don't have a suggestion since I consider the "feature" that this phrase allows of little importance to a properly built iSCSI node. 4. This is new. When doing Text Request/Response negotiations (i.e., in FFP), it seems that the Initiator commits to the new values when it receives a response from the Target with the F bit set. It is unclear when the Target should commit. Should it switch to using the new values as soon as it sends its response with the F-bit set, or should it do so only when it knows that the Initiator received its response? Commiting right away is simpler and since responses with F-bits set have TTT=0xffffffff and thus may not be reset, sounds plausible. If the values have importance on the next reception, it may also be important to commit timely. However, what if the Initiator doesn't get this response? Target now has committed, Initiator hasn't. Committing later puts the burden on Initiator to send something effectively telling "I've received your final response". Otherwise the Target will time out and not commit. This response can get lost too. Basically, it is beginning to look a bit like (what was it called?) "distributed consensus problem"? I think it goes like this: Two generals that are on oposite sides of the enemy want to synchronize their attack, and start sending messengers through with messages like "attack at dawn->", "<-ok, attack at dawn", "I know you know we attack at dawn->", "<-, I know you know I know we attack at dawn", etc., etc., ... But at no point can they commit yet... Is anybody else worried about this? Anyway, so when should a target commit? Page 83 of 12-92 is the relevant reference. Thanks, Martins Krikis Disclaimer: these opinions are my own and may not be those of my employer. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com --=_alternative 001D17A2C2256BC4_= Content-Type: text/html; charset="us-ascii"
Pat your proposed 2b may be what we are looking for - i.e. a responder may not originate a key if it has an incomplete key text.

The text we may want to add to section 4.2 is:

Key=value pairs may span PDU boundaries. A responder having a received partial key text MUST refrain from originating any new key=value negotiations until it has no incomplete key text. This way one avoids having both negotiating entities assuming the originator role in a negotiation.


Julo


pat_thaler@agilent.com

05/25/2002 12:16 AM
Please respond to pat_thaler

       
        To:        mkrikis@yahoo.com, Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: Negotiation clarifications still needed

       


Martins,

Comments referenced by the same items Martins used.

1. Julian sent an email saying he would put the text
I proposed in (though the text you quoted is not the
whole text).

2. I think that the principle we have been using on
text negotiation was that each key negotion is a
separate item. Your proposal would be counter to that
and I don't think it would be an improvement. The
target should be allowed to respond to any complete
key-value pair it has received. When a key-value
pair is straddling the PDU bondary, then it shouldn't
respond to that key until the complete key-value pair
has been received.

There is one potential corner case issue that should
to be covered. Targets can initiate keys. If key-value
pairs didn't straddle PDU boundaries, then ensuring
that there is a clear originator for each offered key
is easy. You can originate any key that you haven't
received an offer of from your partner. But now keys
can straddle PDUs. If the text between the last separater
and the end of the PDU is Ma, then you don't know what
key your partner has started to offer. If the partner
was starting to offer MaxBurstSize and you offer it in
the next PDU of the exchange, both sides may think they
are originator.

I suggest one of the following
a) don't allow keys to straddle PDU boundaries.
b) don't allow originating a key when the last login
PDU ended in a partial key.
c) don't allow offering a key where the start of the key
matches a partial key at the end of the last login
PDU.

3. Yes, we noticed a little while ago that losing a
packet at the end of negotiation could hang things up
though the concern is mainly for a full feature phase
negotiation. Looking at 6.8, any timeout during
negotiation causes the login and its TCP connection to
be terminated. The whole negotiation process (see the
point about origninators in 2) depends upon a one-by-one
exchange of PDUs. PDU loss has to terminate it.

Therefore, the target commits to the end of login
as described for T5 target. It has sent the final
login response with a status of zero. Moves to S5.
If the login response doesn't get to the initiator,
then either the initiator will close the connection
due to the timeout. Since the target is in S4, loss
of the transport connection will cause it to go to
S8 and R1 of the cleanup state machine. It presumably
will not take the M2 transition because the intiator
isn't going to do cleanup for a connection it thinks
wasn't in full feature phase. It will take M1 due to
timeout - not elegant but good enough.

The concern was Full Feature Phase negotation. Until
negotiation ends, it can be reset and no values change.
When the target sends the last Text Response PDU, then
it thinks negotiation has ended and it applies the
new values. If that PDU doesn't reach the initiatior,
then it terminates the entire negotiation and continues
to use the old values. The two ends are using different
values.

We decided to not raise this as an issue because it is
such a corner case - we are operating over a reliable
connection so PDUs shouldn't be lost (unless the whole
path goes down in which case it doesn't matter). Also,
there are few values exchanged during full feature so
it isn't worthwhile to add complexity.

Regards,
Pat

-----Original Message-----
From: Martins Krikis [mailto:mkrikis@yahoo.com]
Sent: Friday, May 24, 2002 12:39 PM
To: Julian Satran
Cc: ips@ece.cmu.edu
Subject: iSCSI: Negotiation clarifications still needed


The previous thread went on too long, but since it
has now quieted down, I'll conjecture that the
following are the aspects that still need to be
addressed.

1. Not everybody seemed to have noticed that it is
  NOT legal to send the same key again, if it
  has once been negotiated (including negotiations
  that end with a reserved value (Reject,
  Irrelevant or NotUnderstood).

I think it would benefit the draft to add the
sentence that Pat proposed to paragraph 5 or page
72 in 12-92: "Sending the key again would be a
re-negotiation". That I think would make it crystal
clear.

2. When the key=value pairs that Originator is
  sending are broken across multiple PDUs, it
  is not clear whether the Responder may start
  responding to the keys as soon as it receives
  them or whether it should send blank PDUs back
  (as in the example on page 164 of 12-92) until
  it gets a PDU, the data part of which ends in
  a NUL byte (thus signaling that there are no
  broken key=value pairs at the end of it).

I am proposing that the draft should make it explicit
that only blank PDUs are to be sent. This allows
decoupling of key=value generation from
their encapsulation in PDUs (i.e., the generating
logic need not worry about whether a key=value
pair will fit and go out in this PDU or has to
be retained to go out in the next). I can explain
in detail why this is important (it has to do
with teh possibility of receiving the "just-about
outgoing" keys) but I'm keeping this "brief".

Furthermore, it is my feeling that instead of
checking the last bytes of a PDU for NUL, it
would be better if the end-of-data was marked by
a flag in the header. This way encapsulation will
be simpler---just put as much data in the PDU as
fits there and raise the flag if it isn't all,
instead of checking whether it ends in a NUL and
possibly shortening data to make it not end like
that.

3. There is an opinion that on page 73 of 12-92,
  the phrase that says "or the responder may
  select an admissible value" is in contradiction
  to the very next sentence. There is also an
  opinion that this phrase is entirely unnecessary
  and detrimental to achieving broad
  interoperability (I call it "cutting slack to
  misbehaving or incompatible originators").

I don't have a suggestion since I consider the
"feature" that this phrase allows of little
importance to a properly built iSCSI node.

4. This is new. When doing Text Request/Response
negotiations (i.e., in FFP), it seems
that the Initiator commits to the new values
when it receives a response from the Target with
the F bit set. It is unclear when the Target should
commit. Should it switch to using the new values
as soon as it sends its response with the F-bit
set, or should it do so only when it knows that
the Initiator received its response?

Commiting right away is simpler and since responses
with F-bits set have TTT=0xffffffff and thus
may not be reset, sounds plausible. If the
values have importance on the next reception,
it may also be important to commit timely. However,
what if the Initiator doesn't get this response?
Target now has committed, Initiator hasn't. Committing
later puts the burden on Initiator to send something
effectively telling "I've received your final
response". Otherwise the Target will time out and
not commit. This response can get lost too.

Basically, it is beginning to look a bit like
(what was it called?) "distributed consensus problem"?
I think it goes like this:

Two generals that are on oposite sides of the
enemy want to synchronize their attack, and
start sending messengers through with messages
like
 "attack at dawn->",
 "<-ok, attack at dawn",
 "I know you know we attack at dawn->",
 "<-, I know you know I know we attack at dawn",
 etc., etc., ...
But at no point can they commit yet...

Is anybody else worried about this?
Anyway, so when should a target commit? Page 83
of 12-92 is the relevant reference.

Thanks,

 Martins Krikis

Disclaimer: these opinions are my own and may
           not be those of my employer.


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

--=_alternative 001D17A2C2256BC4_=-- From owner-ips@ece.cmu.edu Sat May 25 01:53:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04389 for ; Sat, 25 May 2002 01:53:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4P5AZ119206 for ips-outgoing; Sat, 25 May 2002 01:10:35 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4P5AXw19201 for ; Sat, 25 May 2002 01:10:33 -0400 (EDT) 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 g4P5ALhZ064764; Sat, 25 May 2002 07:10:21 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4P5AGm82136; Sat, 25 May 2002 07:10:20 +0200 To: "Mallikarjun C." Cc: ips@ece.cmu.edu, "Martins Krikis" MIME-Version: 1.0 Subject: Re: iSCSI: Negotiation clarifications still needed X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 25 May 2002 08:10:25 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 25/05/2002 08:10:20, Serialize complete at 25/05/2002 08:10:20 Content-Type: multipart/alternative; boundary="=_alternative 001B9C20C2256BC4_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001B9C20C2256BC4_= Content-Type: text/plain; charset="us-ascii" I agree with Mallikarjun on all but one point - requiring a key not to straddle PDU boundaries. This list had a long debate on the subject. We thought (initially) that not having any pair straddle PD boundaries is the best thing to do and we had it untill it became obvious that we have to support very short PDUs. The we went for allowing spanning and the scheme we had in mind was a sender preparing its strings and chopping them into PDUs without any parsing and state. What you suggest now is parsing at send and that may add unnecessary complexity - and I really don't see why. Julo "Mallikarjun C." 05/25/2002 02:49 AM Please respond to "Mallikarjun C." To: "Martins Krikis" , Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: iSCSI: Negotiation clarifications still needed Martins, Comments in the same order. 1. Julian may be adding wording for this. 2. Seems to me that we need to stipulate that only key values may straddle PDU boundaries - key names (ideally inclusive of "=") shall not. That should avoid requiring blank PDUs. 3. I don't have a strong opinion on this. I don't believe this can cause interoperability problems; OTOH, I don't care if the responder isn't that liberal. 4. Julian and I discussed this scenario a while ago. As you precisely described, only a non-stop dialogue can be reliable and we can't afford a non-stop dialogue. I suppose one can recover the StatSN with a SNACK in FFP, or terminate the connection upon a timeout. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Martins Krikis" To: "Julian Satran" Cc: Sent: Friday, May 24, 2002 12:38 PM Subject: iSCSI: Negotiation clarifications still needed > The previous thread went on too long, but since it > has now quieted down, I'll conjecture that the > following are the aspects that still need to be > addressed. > > 1. Not everybody seemed to have noticed that it is > NOT legal to send the same key again, if it > has once been negotiated (including negotiations > that end with a reserved value (Reject, > Irrelevant or NotUnderstood). > > I think it would benefit the draft to add the > sentence that Pat proposed to paragraph 5 or page > 72 in 12-92: "Sending the key again would be a > re-negotiation". That I think would make it crystal > clear. > > 2. When the key=value pairs that Originator is > sending are broken across multiple PDUs, it > is not clear whether the Responder may start > responding to the keys as soon as it receives > them or whether it should send blank PDUs back > (as in the example on page 164 of 12-92) until > it gets a PDU, the data part of which ends in > a NUL byte (thus signaling that there are no > broken key=value pairs at the end of it). > > I am proposing that the draft should make it explicit > that only blank PDUs are to be sent. This allows > decoupling of key=value generation from > their encapsulation in PDUs (i.e., the generating > logic need not worry about whether a key=value > pair will fit and go out in this PDU or has to > be retained to go out in the next). I can explain > in detail why this is important (it has to do > with teh possibility of receiving the "just-about > outgoing" keys) but I'm keeping this "brief". > > Furthermore, it is my feeling that instead of > checking the last bytes of a PDU for NUL, it > would be better if the end-of-data was marked by > a flag in the header. This way encapsulation will > be simpler---just put as much data in the PDU as > fits there and raise the flag if it isn't all, > instead of checking whether it ends in a NUL and > possibly shortening data to make it not end like > that. > > 3. There is an opinion that on page 73 of 12-92, > the phrase that says "or the responder may > select an admissible value" is in contradiction > to the very next sentence. There is also an > opinion that this phrase is entirely unnecessary > and detrimental to achieving broad > interoperability (I call it "cutting slack to > misbehaving or incompatible originators"). > > I don't have a suggestion since I consider the > "feature" that this phrase allows of little > importance to a properly built iSCSI node. > > 4. This is new. When doing Text Request/Response > negotiations (i.e., in FFP), it seems > that the Initiator commits to the new values > when it receives a response from the Target with > the F bit set. It is unclear when the Target should > commit. Should it switch to using the new values > as soon as it sends its response with the F-bit > set, or should it do so only when it knows that > the Initiator received its response? > > Commiting right away is simpler and since responses > with F-bits set have TTT=0xffffffff and thus > may not be reset, sounds plausible. If the > values have importance on the next reception, > it may also be important to commit timely. However, > what if the Initiator doesn't get this response? > Target now has committed, Initiator hasn't. Committing > later puts the burden on Initiator to send something > effectively telling "I've received your final > response". Otherwise the Target will time out and > not commit. This response can get lost too. > > Basically, it is beginning to look a bit like > (what was it called?) "distributed consensus problem"? > I think it goes like this: > > Two generals that are on oposite sides of the > enemy want to synchronize their attack, and > start sending messengers through with messages > like > "attack at dawn->", > "<-ok, attack at dawn", > "I know you know we attack at dawn->", > "<-, I know you know I know we attack at dawn", > etc., etc., ... > But at no point can they commit yet... > > Is anybody else worried about this? > Anyway, so when should a target commit? Page 83 > of 12-92 is the relevant reference. > > Thanks, > > Martins Krikis > > Disclaimer: these opinions are my own and may > not be those of my employer. > > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > --=_alternative 001B9C20C2256BC4_= Content-Type: text/html; charset="us-ascii"
I agree with Mallikarjun on all but one point - requiring a key not to straddle PDU boundaries.
This list had a long debate on the subject. We thought (initially) that not having any pair straddle PD boundaries is the best thing to do and we had it untill it became obvious that we have to support very short PDUs.
The we went for allowing spanning and the scheme we had in  mind was a sender preparing its strings and chopping them into PDUs without any parsing and state. What you suggest now is parsing at send and that may add unnecessary complexity - and I really don't see why.

Julo


"Mallikarjun C." <cbm@rose.hp.com>

05/25/2002 02:49 AM
Please respond to "Mallikarjun C."

       
        To:        "Martins Krikis" <mkrikis@yahoo.com>, Julian Satran/Haifa/IBM@IBMIL
        cc:        <ips@ece.cmu.edu>
        Subject:        Re: iSCSI: Negotiation clarifications still needed

       


Martins,

Comments in the same order.

1. Julian may be adding wording for this.

2. Seems to me that we need to stipulate that only key values
   may straddle PDU boundaries - key names (ideally inclusive
   of "=") shall not.  That should avoid requiring blank PDUs.

3. I don't have a strong opinion on this.  I don't believe this can
   cause interoperability problems; OTOH, I don't care if the responder
   isn't that liberal.

4. Julian and I discussed this scenario a while ago.  As you precisely
   described, only a non-stop dialogue can be reliable and we can't
   afford a non-stop dialogue.  I suppose one can recover the StatSN
   with a SNACK in FFP, or terminate the connection upon a timeout.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com


----- Original Message -----
From: "Martins Krikis" <mkrikis@yahoo.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, May 24, 2002 12:38 PM
Subject: iSCSI: Negotiation clarifications still needed


> The previous thread went on too long, but since it
> has now quieted down, I'll conjecture that the
> following are the aspects that still need to be
> addressed.
>
> 1. Not everybody seemed to have noticed that it is
>    NOT legal to send the same key again, if it
>    has once been negotiated (including negotiations
>    that end with a reserved value (Reject,
>    Irrelevant or NotUnderstood).
>
> I think it would benefit the draft to add the
> sentence that Pat proposed to paragraph 5 or page
> 72 in 12-92: "Sending the key again would be a
> re-negotiation". That I think would make it crystal
> clear.
>
> 2. When the key=value pairs that Originator is
>    sending are broken across multiple PDUs, it
>    is not clear whether the Responder may start
>    responding to the keys as soon as it receives
>    them or whether it should send blank PDUs back
>    (as in the example on page 164 of 12-92) until
>    it gets a PDU, the data part of which ends in
>    a NUL byte (thus signaling that there are no
>    broken key=value pairs at the end of it).
>
> I am proposing that the draft should make it explicit
> that only blank PDUs are to be sent. This allows
> decoupling of key=value generation from
> their encapsulation in PDUs (i.e., the generating
> logic need not worry about whether a key=value
> pair will fit and go out in this PDU or has to
> be retained to go out in the next). I can explain
> in detail why this is important (it has to do
> with teh possibility of receiving the "just-about
> outgoing" keys) but I'm keeping this "brief".
>
> Furthermore, it is my feeling that instead of
> checking the last bytes of a PDU for NUL, it
> would be better if the end-of-data was marked by
> a flag in the header. This way encapsulation will
> be simpler---just put as much data in the PDU as
> fits there and raise the flag if it isn't all,
> instead of checking whether it ends in a NUL and
> possibly shortening data to make it not end like
> that.
>
> 3. There is an opinion that on page 73 of 12-92,
>    the phrase that says "or the responder may
>    select an admissible value" is in contradiction
>    to the very next sentence. There is also an
>    opinion that this phrase is entirely unnecessary
>    and detrimental to achieving broad
>    interoperability (I call it "cutting slack to
>    misbehaving or incompatible originators").
>
> I don't have a suggestion since I consider the
> "feature" that this phrase allows of little
> importance to a properly built iSCSI node.
>
> 4. This is new. When doing Text Request/Response
> negotiations (i.e., in FFP), it seems
> that the Initiator commits to the new values
> when it receives a response from the Target with
> the F bit set. It is unclear when the Target should
> commit. Should it switch to using the new values
> as soon as it sends its response with the F-bit
> set, or should it do so only when it knows that
> the Initiator received its response?
>
> Commiting right away is simpler and since responses
> with F-bits set have TTT=0xffffffff and thus
> may not be reset, sounds plausible. If the
> values have importance on the next reception,
> it may also be important to commit timely. However,
> what if the Initiator doesn't get this response?
> Target now has committed, Initiator hasn't. Committing
> later puts the burden on Initiator to send something
> effectively telling "I've received your final
> response". Otherwise the Target will time out and
> not commit. This response can get lost too.
>
> Basically, it is beginning to look a bit like
> (what was it called?) "distributed consensus problem"?
> I think it goes like this:
>
> Two generals that are on oposite sides of the
> enemy want to synchronize their attack, and
> start sending messengers through with messages
> like
>   "attack at dawn->",
>   "<-ok, attack at dawn",
>   "I know you know we attack at dawn->",
>   "<-, I know you know I know we attack at dawn",
>   etc., etc., ...
> But at no point can they commit yet...
>
> Is anybody else worried about this?
> Anyway, so when should a target commit? Page 83
> of 12-92 is the relevant reference.
>
> Thanks,
>
>   Martins Krikis
>
> Disclaimer: these opinions are my own and may
>             not be those of my employer.
>
>
> __________________________________________________
> Do You Yahoo!?
> LAUNCH - Your Yahoo! Music Experience
> http://launch.yahoo.com
>



--=_alternative 001B9C20C2256BC4_=-- From owner-ips@ece.cmu.edu Sat May 25 02:35:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14689 for ; Sat, 25 May 2002 02:35:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4P5xIr20882 for ips-outgoing; Sat, 25 May 2002 01:59:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4P5xGw20876 for ; Sat, 25 May 2002 01:59:16 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4P5xFWo047832 for ; Sat, 25 May 2002 01:59:15 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4P5x5H165766 for ; Fri, 24 May 2002 23:59:14 -0600 X-Priority: 1 (High) Importance: Normal Subject: iSCSI:Violation of no Spanning Rule To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Fri, 24 May 2002 22:57:14 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/24/2002 11:59:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk OK, (note, the change of subject again. So we can focus on one thing at a time.) Let me now propose another rule. If the offering party, fails the no Spanning Rule, Terminate the connection. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Martins Krikis @ece.cmu.edu on 05/24/2002 06:56:10 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: Renegotiation and Non Spanning key --- Black_David@emc.com wrote: > For the PDU spanning issue, I believe the rough > consensus > is that the key plus the following "=" character > MUST NOT > span a PDU boundary. It might be fairer to wait till Tuesday for a real consensus (it's a long weekend here and it's Friday 9:50pm on the east coast, USA). If this is the way we go (and not what I proposed), then there also needs to be text along these lines: "A node MUST NOT send any key that has been received with incomplete (including empty) value". In other words, you cannot just leave the incomplete leftover junk laying around in buffers, you must check against it your outgoing keys. It all could have been avoided. Even checking for whether a key and '=' fully fits could have been avoided. Your call. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Sat May 25 02:42:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15070 for ; Sat, 25 May 2002 02:42:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4P6GXW21450 for ips-outgoing; Sat, 25 May 2002 02:16:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4P6GVw21446 for ; Sat, 25 May 2002 02:16:31 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4P6GUFD015148 for ; Sat, 25 May 2002 02:16:31 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4P6GTX89446 for ; Sat, 25 May 2002 00:16:29 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: Negotiation clarifications still needed To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Fri, 24 May 2002 23:14:36 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/25/2002 12:16:29 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g4P6GWw21447 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit With the risk of sounding fickle, I can also buy this idea, and your wordage. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 05/24/2002 10:26:08 PM Sent by: owner-ips@ece.cmu.edu To: pat_thaler@agilent.com cc: ips@ece.cmu.edu, mkrikis@yahoo.com Subject: RE: iSCSI: Negotiation clarifications still needed Pat your proposed 2b may be what we are looking for - i.e. a responder may not originate a key if it has an incomplete key text. The text we may want to add to section 4.2 is: Key=value pairs may span PDU boundaries. A responder having a received partial key text MUST refrain from originating any new key=value negotiations until it has no incomplete key text. This way one avoids having both negotiating entities assuming the originator role in a negotiation. Julo pat_thaler@a gilent.com         To:        mkrikis@yahoo.com, Julian Satran/Haifa/IBM@IBMIL 05/25/2002         cc:        ips@ece.cmu.edu 12:16 AM         Subject:        RE: iSCSI: Negotiation Please clarifications still needed respond to pat_thaler Martins, Comments referenced by the same items Martins used. 1. Julian sent an email saying he would put the text I proposed in (though the text you quoted is not the whole text). 2. I think that the principle we have been using on text negotiation was that each key negotion is a separate item. Your proposal would be counter to that and I don't think it would be an improvement. The target should be allowed to respond to any complete key-value pair it has received. When a key-value pair is straddling the PDU bondary, then it shouldn't respond to that key until the complete key-value pair has been received. There is one potential corner case issue that should to be covered. Targets can initiate keys. If key-value pairs didn't straddle PDU boundaries, then ensuring that there is a clear originator for each offered key is easy. You can originate any key that you haven't received an offer of from your partner. But now keys can straddle PDUs. If the text between the last separater and the end of the PDU is Ma, then you don't know what key your partner has started to offer. If the partner was starting to offer MaxBurstSize and you offer it in the next PDU of the exchange, both sides may think they are originator. I suggest one of the following a) don't allow keys to straddle PDU boundaries. b) don't allow originating a key when the last login PDU ended in a partial key. c) don't allow offering a key where the start of the key matches a partial key at the end of the last login PDU. 3. Yes, we noticed a little while ago that losing a packet at the end of negotiation could hang things up though the concern is mainly for a full feature phase negotiation. Looking at 6.8, any timeout during negotiation causes the login and its TCP connection to be terminated. The whole negotiation process (see the point about origninators in 2) depends upon a one-by-one exchange of PDUs. PDU loss has to terminate it. Therefore, the target commits to the end of login as described for T5 target. It has sent the final login response with a status of zero. Moves to S5. If the login response doesn't get to the initiator, then either the initiator will close the connection due to the timeout. Since the target is in S4, loss of the transport connection will cause it to go to S8 and R1 of the cleanup state machine. It presumably will not take the M2 transition because the intiator isn't going to do cleanup for a connection it thinks wasn't in full feature phase. It will take M1 due to timeout - not elegant but good enough. The concern was Full Feature Phase negotation. Until negotiation ends, it can be reset and no values change. When the target sends the last Text Response PDU, then it thinks negotiation has ended and it applies the new values. If that PDU doesn't reach the initiatior, then it terminates the entire negotiation and continues to use the old values. The two ends are using different values. We decided to not raise this as an issue because it is such a corner case - we are operating over a reliable connection so PDUs shouldn't be lost (unless the whole path goes down in which case it doesn't matter). Also, there are few values exchanged during full feature so it isn't worthwhile to add complexity. Regards, Pat -----Original Message----- From: Martins Krikis [mailto:mkrikis@yahoo.com] Sent: Friday, May 24, 2002 12:39 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: iSCSI: Negotiation clarifications still needed The previous thread went on too long, but since it has now quieted down, I'll conjecture that the following are the aspects that still need to be addressed. 1. Not everybody seemed to have noticed that it is   NOT legal to send the same key again, if it   has once been negotiated (including negotiations   that end with a reserved value (Reject,   Irrelevant or NotUnderstood). I think it would benefit the draft to add the sentence that Pat proposed to paragraph 5 or page 72 in 12-92: "Sending the key again would be a re-negotiation". That I think would make it crystal clear. 2. When the key=value pairs that Originator is   sending are broken across multiple PDUs, it   is not clear whether the Responder may start   responding to the keys as soon as it receives   them or whether it should send blank PDUs back   (as in the example on page 164 of 12-92) until   it gets a PDU, the data part of which ends in   a NUL byte (thus signaling that there are no   broken key=value pairs at the end of it). I am proposing that the draft should make it explicit that only blank PDUs are to be sent. This allows decoupling of key=value generation from their encapsulation in PDUs (i.e., the generating logic need not worry about whether a key=value pair will fit and go out in this PDU or has to be retained to go out in the next). I can explain in detail why this is important (it has to do with teh possibility of receiving the "just-about outgoing" keys) but I'm keeping this "brief". Furthermore, it is my feeling that instead of checking the last bytes of a PDU for NUL, it would be better if the end-of-data was marked by a flag in the header. This way encapsulation will be simpler---just put as much data in the PDU as fits there and raise the flag if it isn't all, instead of checking whether it ends in a NUL and possibly shortening data to make it not end like that. 3. There is an opinion that on page 73 of 12-92,   the phrase that says "or the responder may   select an admissible value" is in contradiction   to the very next sentence. There is also an   opinion that this phrase is entirely unnecessary   and detrimental to achieving broad   interoperability (I call it "cutting slack to   misbehaving or incompatible originators"). I don't have a suggestion since I consider the "feature" that this phrase allows of little importance to a properly built iSCSI node. 4. This is new. When doing Text Request/Response negotiations (i.e., in FFP), it seems that the Initiator commits to the new values when it receives a response from the Target with the F bit set. It is unclear when the Target should commit. Should it switch to using the new values as soon as it sends its response with the F-bit set, or should it do so only when it knows that the Initiator received its response? Commiting right away is simpler and since responses with F-bits set have TTT=0xffffffff and thus may not be reset, sounds plausible. If the values have importance on the next reception, it may also be important to commit timely. However, what if the Initiator doesn't get this response? Target now has committed, Initiator hasn't. Committing later puts the burden on Initiator to send something effectively telling "I've received your final response". Otherwise the Target will time out and not commit. This response can get lost too. Basically, it is beginning to look a bit like (what was it called?) "distributed consensus problem"? I think it goes like this: Two generals that are on oposite sides of the enemy want to synchronize their attack, and start sending messengers through with messages like  "attack at dawn->",  "<-ok, attack at dawn",  "I know you know we attack at dawn->",  "<-, I know you know I know we attack at dawn",  etc., etc., ... But at no point can they commit yet... Is anybody else worried about this? Anyway, so when should a target commit? Page 83 of 12-92 is the relevant reference. Thanks,  Martins Krikis Disclaimer: these opinions are my own and may            not be those of my employer. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Sun May 26 12:45:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26199 for ; Sun, 26 May 2002 12:44:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4QFqg616930 for ips-outgoing; Sun, 26 May 2002 11:52:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4QFqew16921 for ; Sun, 26 May 2002 11:52:40 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4QFqXHr024916; Sun, 26 May 2002 17:52:33 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4QFqT367308; Sun, 26 May 2002 17:52:29 +0200 Importance: Normal Subject: iSCSI inband auth: Rough Consensus + Direction To: Black_David@emc.com Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Ofer Biran" Date: Sun, 26 May 2002 18:51:48 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 26/05/2002 18:52:32 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, Your guidelines are generally reasonable, I have the following comments: 1. I think we overlooked one aspect which is the convenience of human readable passwords in various scenarios. SRP is OK for them, but so is CHAP above encrypted IPsec - so a better approach might be a text that only (but aggressively) disqualifies CHAP + weak secret + no-IPsec-encryption. 2. The first part of the CHAP reflection prevention is already covered in iSCSI 10.5 (CHAP): "If the initiator authentication fails, the target MUST answer with a Login reject with "Authentication Failure" status. Otherwise, if the initiator required target authentication, the target MUST reply with CHAP_N= CHAP_R= " So based on the above and the guidelines, here is a suggested CHAP text for iSCSI "7.2 In-band Initiator-Target Authentication". I believe it's also simpler and more concrete on what implementations must and must not do: ------------------------------------------------------------------- Compliant iSCSI implementation MUST implement the CHAP authentication method [RFC1994] (see Section 10.5). When CHAP is performed over non-encrypted channel, it is vulnerable to an off-line dictionary attack. Implementations MUST support use of up to 128 bits random CHAP secrets, including the means to generate such secrets and to accept them from an external generation source. Implementations MUST NOT provide secret generation (or expansion) means other than random generation. If CHAP is used with secret weaker than 96 random bits, than IPsec encryption (according to the implementation requirements in "7.3.2 Confidentiality") MUST be used to protect the connection. Moreover, in this case IKE authentication with group pre-shared keys MUST NOT be used. When CHAP is used with secret less then 96 bits, compliant implementation MUST NOT continue with the login unless it can verify that IPsec encryption is being used to protect the connection. Initiators MUST NOT reuse the CHAP challenge sent by the Responder for the other direction of a bi-directional authentication. Responders MUST check for this condition and close the iSCSI TCP connection if it occurs. ------------------------------------------------------------------- Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 From owner-ips@ece.cmu.edu Mon May 27 10:27:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19463 for ; Mon, 27 May 2002 10:27:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4RDiOa09420 for ips-outgoing; Mon, 27 May 2002 09:44:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4RDiMw09414 for ; Mon, 27 May 2002 09:44:22 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4RChEu06012; Mon, 27 May 2002 08:43:15 -0400 Message-ID: <3CF23830.9344CC@splentec.com> Date: Mon, 27 May 2002 09:44:16 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI , Julian Satran Subject: Logout request -- reason? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I was under the impression that byte 1 in BHS is a flags byte -- i.e. bit values. I now see that the reason code is moved exactly there, in the Logout request PDU. Could anyone please explain the logic behind this? At the same time byte 3 and 4 are reserved to 0. Why don't we: 1) Move the reason code to byte 1. This will make it _consistent_ with the response byte in Logout Response. 2) Make the value start at 0x80, as to hide the ugliness of F = 1, and the fact that we are trying to fit a numerical value (!) and a bit value (!) in the same octet. Comments? -- Luben From owner-ips@ece.cmu.edu Mon May 27 10:28:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19480 for ; Mon, 27 May 2002 10:28:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4RDn2R09564 for ips-outgoing; Mon, 27 May 2002 09:49:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4RDn1w09560 for ; Mon, 27 May 2002 09:49:01 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4RClru06037; Mon, 27 May 2002 08:47:53 -0400 Message-ID: <3CF23947.D2D5186C@splentec.com> Date: Mon, 27 May 2002 09:48:55 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI , Julian Satran Subject: [iSCSI:] Logout request -- reason? Correction References: <3CF23830.9344CC@splentec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Let me correct this: I was under the impression that byte 1 in BHS is a flags byte -- i.e. bit values. I now see that the reason code is moved exactly there, in the Logout request PDU. Could anyone please explain the logic behind this? At the same time byte 2 and 3 are reserved to 0. Why don't we: 1) Move the reason code to byte 2. This will make it _consistent_ with the response byte in Logout Response. 2) Make the value start at 0x80, as to hide the ugliness of F = 1, and the fact that we are trying to fit a numerical value (!) and a bit value (!) in the same octet. Comments? -- Luben From owner-ips@ece.cmu.edu Mon May 27 13:17:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22298 for ; Mon, 27 May 2002 13:17:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4RGKvp15107 for ips-outgoing; Mon, 27 May 2002 12:20:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4RGKtw15102 for ; Mon, 27 May 2002 12:20:55 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4RFJlu06744; Mon, 27 May 2002 11:19:47 -0400 Message-ID: <3CF25CE1.82A6EE84@splentec.com> Date: Mon, 27 May 2002 12:20:49 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI , Julian Satran Subject: Re: [iSCSI:] Logout request -- reason? Correction References: <3CF23830.9344CC@splentec.com> <3CF23947.D2D5186C@splentec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Could we do the same to Task Mgmt. Func. Req. (Function -> byte 2) and to SNACK (Type -> byte 2). Both PDUs have byte 2 reserved to 0. If not, please elaborate. -- Luben Luben Tuikov wrote: > > Let me correct this: > > I was under the impression that byte 1 in BHS > is a flags byte -- i.e. bit values. > > I now see that the reason code is moved exactly there, > in the Logout request PDU. > > Could anyone please explain the logic behind this? > > At the same time byte 2 and 3 are reserved to 0. > > Why don't we: > > 1) Move the reason code to byte 2. This will > make it _consistent_ with the response byte > in Logout Response. > > 2) Make the value start at 0x80, as to hide > the ugliness of F = 1, and the fact that > we are trying to fit a numerical value (!) > and a bit value (!) in the same octet. > > Comments? From owner-ips@ece.cmu.edu Mon May 27 15:19:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23971 for ; Mon, 27 May 2002 15:19:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4RIWjd20143 for ips-outgoing; Mon, 27 May 2002 14:32:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4RIWhw20139 for ; Mon, 27 May 2002 14:32:43 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4RIWXHr038340; Mon, 27 May 2002 20:32:33 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4RIWNY64654; Mon, 27 May 2002 20:32:32 +0200 To: Luben Tuikov Cc: iSCSI MIME-Version: 1.0 Subject: Re: [iSCSI:] Logout request -- reason? Correction X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 27 May 2002 21:32:21 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 27/05/2002 21:32:31, Serialize complete at 27/05/2002 21:32:31 Content-Type: multipart/alternative; boundary="=_alternative 005A3560C2256BC6_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005A3560C2256BC6_= Content-Type: text/plain; charset="us-ascii" Reason & Function codes are there for several request types. (e.g., task management). I did announce my intent to move it there for uniformity - a long time ago - when it was requested by a list member - and waited for comments. Julo BTW - you appear to be sending mail from ns.splentec.com and a reply there ends always with bounced mail. Luben Tuikov Sent by: luben@ns.splentec.com 05/27/2002 04:48 PM Please respond to Luben Tuikov To: iSCSI , Julian Satran/Haifa/IBM@IBMIL cc: Subject: [iSCSI:] Logout request -- reason? Correction Let me correct this: I was under the impression that byte 1 in BHS is a flags byte -- i.e. bit values. I now see that the reason code is moved exactly there, in the Logout request PDU. Could anyone please explain the logic behind this? At the same time byte 2 and 3 are reserved to 0. Why don't we: 1) Move the reason code to byte 2. This will make it _consistent_ with the response byte in Logout Response. 2) Make the value start at 0x80, as to hide the ugliness of F = 1, and the fact that we are trying to fit a numerical value (!) and a bit value (!) in the same octet. Comments? -- Luben --=_alternative 005A3560C2256BC6_= Content-Type: text/html; charset="us-ascii"
Reason  & Function codes are there for several request types. (e.g., task management).

I did announce my intent to move it there for uniformity  - a long time ago - when it was requested by a list member - and waited for comments.

Julo

BTW - you appear to be sending mail from ns.splentec.com and a reply there ends always with bounced mail.



Luben Tuikov <luben@splentec.com>
Sent by: luben@ns.splentec.com

05/27/2002 04:48 PM
Please respond to Luben Tuikov

       
        To:        iSCSI <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        [iSCSI:] Logout request -- reason? Correction

       


Let me correct this:

I was under the impression that byte 1 in BHS
is a flags byte -- i.e. bit values.

I now see that the reason code is moved exactly there,
in the Logout request PDU.

Could anyone please explain the logic behind this?

At the same time byte 2 and 3 are reserved to 0.

Why don't we:

1)  Move the reason code to byte 2. This will
   make it _consistent_ with the response byte
   in Logout Response.

2)  Make the value start at 0x80, as to hide
   the ugliness of F = 1, and the fact that
   we are trying to fit a numerical value (!)
   and a bit value (!) in the same octet.

Comments?

--
Luben

--=_alternative 005A3560C2256BC6_=-- From owner-ips@ece.cmu.edu Mon May 27 17:35:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25256 for ; Mon, 27 May 2002 17:35:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4RKk6p25095 for ips-outgoing; Mon, 27 May 2002 16:46:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4RKk0w25089 for ; Mon, 27 May 2002 16:46:00 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4RJilu07896; Mon, 27 May 2002 15:44:47 -0400 Message-ID: <3CF29AFD.448E1981@splentec.com> Date: Mon, 27 May 2002 16:45:49 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran CC: iSCSI Subject: Re: [iSCSI:] Logout request -- reason? Correction References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian Satran wrote: > > Reason & Function codes are there for several request types. (e.g., task management). > > I did announce my intent to move it there for uniformity - a long time ago - when it was > requested by a list member - and waited for comments. You have my vote on moving the function numeric to byte 2 (Logout Request & TMF Request). As well as moving the Type numeric to byte 2 in SNACK. This will make things pretty consistent. Everyone okay with this? -- Luben > BTW - you appear to be sending mail from ns.splentec.com and a reply there ends always with > bounced mail. Attached below is a copy of the SMTP header of the message which arrived at the mailing list. Yes, the last stop of our (Splentec) messages do go through ns.splentec.com, but your MUA (Mail User Agent) SHOULD go with its reply by either Reply To: or of not available by From:. It SHOULD NOT reply to any of the Received: headers' machines. Which RFC was this in? emacs, netscape, yahoo.com, etc. have no problem replying to my messages. So I guess the problem is in Lotus Notes, NOT in sendmail. Please contact your vendor. --cut---- From - Mon May 27 16:22:47 2002 Return-Path: Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4RE2Du06409 for ; Mon, 27 May 2002 10:02:13 -0400 Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4RDn2R09564 for ips-outgoing; Mon, 27 May 2002 09:49:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4RDn1w09560 for ; Mon, 27 May 2002 09:49:01 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4RClru06037; Mon, 27 May 2002 08:47:53 -0400 Message-ID: <3CF23947.D2D5186C@splentec.com> Date: Mon, 27 May 2002 09:48:55 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI , Julian Satran Subject: [iSCSI:] Logout request -- reason? Correction References: <3CF23830.9344CC@splentec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk --cut-- From owner-ips@ece.cmu.edu Mon May 27 20:14:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26343 for ; Mon, 27 May 2002 20:14:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4RNWVU01106 for ips-outgoing; Mon, 27 May 2002 19:32:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4RNWTw01102 for ; Mon, 27 May 2002 19:32:30 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4RNWSqU032626; Mon, 27 May 2002 19:32:28 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4RNWRD177030; Mon, 27 May 2002 17:32:27 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: [iSCSI:] Logout request -- reason? Correction To: Luben Tuikov Cc: "Julian Satran" , iSCSI X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Mon, 27 May 2002 16:30:27 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/27/2002 05:32:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk There is nothing broken here, this is preference. I see no reason to move it again. Julian, did announce it and we accepted it. We should be moving towards closure. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Luben Tuikov @ece.cmu.edu on 05/27/2002 01:45:49 PM Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL cc: iSCSI Subject: Re: [iSCSI:] Logout request -- reason? Correction Julian Satran wrote: > > Reason & Function codes are there for several request types. (e.g., task management). > > I did announce my intent to move it there for uniformity - a long time ago - when it was > requested by a list member - and waited for comments. You have my vote on moving the function numeric to byte 2 (Logout Request & TMF Request). As well as moving the Type numeric to byte 2 in SNACK. This will make things pretty consistent. Everyone okay with this? -- Luben > BTW - you appear to be sending mail from ns.splentec.com and a reply there ends always with > bounced mail. Attached below is a copy of the SMTP header of the message which arrived at the mailing list. Yes, the last stop of our (Splentec) messages do go through ns.splentec.com, but your MUA (Mail User Agent) SHOULD go with its reply by either Reply To: or of not available by From:. It SHOULD NOT reply to any of the Received: headers' machines. Which RFC was this in? emacs, netscape, yahoo.com, etc. have no problem replying to my messages. So I guess the problem is in Lotus Notes, NOT in sendmail. Please contact your vendor. --cut---- From - Mon May 27 16:22:47 2002 Return-Path: Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4RE2Du06409 for ; Mon, 27 May 2002 10:02:13 -0400 Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4RDn2R09564 for ips-outgoing; Mon, 27 May 2002 09:49:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4RDn1w09560 for ; Mon, 27 May 2002 09:49:01 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4RClru06037; Mon, 27 May 2002 08:47:53 -0400 Message-ID: <3CF23947.D2D5186C@splentec.com> Date: Mon, 27 May 2002 09:48:55 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: iSCSI , Julian Satran Subject: [iSCSI:] Logout request -- reason? Correction References: <3CF23830.9344CC@splentec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk --cut-- From owner-ips@ece.cmu.edu Tue May 28 01:39:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00482 for ; Tue, 28 May 2002 01:39:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4S4wFt12796 for ips-outgoing; Tue, 28 May 2002 00:58:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4S4wDw12792 for ; Tue, 28 May 2002 00:58:14 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4S4w79D023952 for ; Tue, 28 May 2002 06:58:07 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4S4w7o84502 for ; Tue, 28 May 2002 06:58:07 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Countdown is at 12-94 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Tue, 28 May 2002 07:52:44 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 28/05/2002 07:58:06, Serialize complete at 28/05/2002 07:58:06 Content-Type: multipart/alternative; boundary="=_alternative 001ACCFFC2256BC7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001ACCFFC2256BC7_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, Countdown is now at 12-94. You may want look at our attempt to close the authentication hole. Regards, Julo --=_alternative 001ACCFFC2256BC7_= Content-Type: text/html; charset="us-ascii"
Dear colleagues,

Countdown is now at 12-94. You may want look at our attempt to close the authentication hole.

Regards,
Julo --=_alternative 001ACCFFC2256BC7_=-- From owner-ips@ece.cmu.edu Tue May 28 10:41:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20495 for ; Tue, 28 May 2002 10:41:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SDr9k13021 for ips-outgoing; Tue, 28 May 2002 09:53:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4SDr8w13017 for ; Tue, 28 May 2002 09:53:08 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4SDr2p01467 for ; Tue, 28 May 2002 09:53:02 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4SDr1c01458; Tue, 28 May 2002 09:53:01 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g4SDr1p06354; Tue, 28 May 2002 09:53:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15603.35773.84895.601871@pkoning.dev.equallogic.com> Date: Tue, 28 May 2002 09:53:01 -0400 From: Paul Koning To: luben@splentec.com Cc: ips@ece.cmu.edu Subject: Re: [iSCSI:] Logout request -- reason? Correction References: <3CF23830.9344CC@splentec.com> <3CF23947.D2D5186C@splentec.com> <3CF25CE1.82A6EE84@splentec.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Luben" == Luben Tuikov writes: Luben> Could we do the same to Task Mgmt. Func. Req. (Function -> Luben> byte 2) and to SNACK (Type -> byte 2). Both PDUs have byte 2 Luben> reserved to 0. Luben> If not, please elaborate. I objected before and I'll object again. It would be very nice if we could stop making gratuitous changes to packet formats and get the spec finished instead. paul From owner-ips@ece.cmu.edu Tue May 28 12:39:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24205 for ; Tue, 28 May 2002 12:39:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SFraq20752 for ips-outgoing; Tue, 28 May 2002 11:53:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SFrWw20741 for ; Tue, 28 May 2002 11:53:32 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4SEqHu12208; Tue, 28 May 2002 10:52:17 -0400 Message-ID: <3CF3A7F1.3426C4F2@splentec.com> Date: Tue, 28 May 2002 11:53:21 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: ips@ece.cmu.edu, John Hufferd Subject: Re: [iSCSI:] Logout request -- reason? Correction References: <3CF23830.9344CC@splentec.com> <3CF23947.D2D5186C@splentec.com> <3CF25CE1.82A6EE84@splentec.com> <15603.35773.84895.601871@pkoning.dev.equallogic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John Hufferd wrote: > > There is nothing broken here, this is preference. I see no reason to move > it again. Julian, did announce it and we accepted it. > We should be moving towards closure. > Paul Koning wrote: > > I objected before and I'll object again. > > It would be very nice if we could stop making gratuitous changes to > packet formats and get the spec finished instead. In other words you have no problem with those changes taking place, you simply oppose to them, lest the PDU format become more object oriented friendly. The people in C wouldn't mind that much since they are used to dealing with bit shifting and what not, but the people in C++ where this inconsistency would mean an ugly base class, and an unbecoming implementation would cringe at the look of it. You should've at least recognised that this would be a _good_ architectural change, and then give your reasons for _not_ implementing it, rather than calling them ``gratuitous changes''. I'm not posting here out of whim -- I really do care. -- Luben From owner-ips@ece.cmu.edu Tue May 28 13:24:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25737 for ; Tue, 28 May 2002 13:24:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SGZPw23502 for ips-outgoing; Tue, 28 May 2002 12:35:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SGZNw23497 for ; Tue, 28 May 2002 12:35:23 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4SGZCqU019424; Tue, 28 May 2002 12:35:12 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4SGZBc149200; Tue, 28 May 2002 10:35:11 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: [iSCSI:] Logout request -- reason? Correction To: Luben Tuikov Cc: Paul Koning , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Tue, 28 May 2002 09:33:10 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/28/2002 10:35:11 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I think you are over stating you case. I, and others I have talked to do not see this as a problem with OO code. In any event, we are not in the business of "code beauty". If we put that as a base, we would never complete. Lets focus on what is broken! . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Luben Tuikov @ece.cmu.edu on 05/28/2002 08:53:21 AM Sent by: owner-ips@ece.cmu.edu To: Paul Koning cc: ips@ece.cmu.edu, John Hufferd/San Jose/IBM@IBMUS Subject: Re: [iSCSI:] Logout request -- reason? Correction John Hufferd wrote: > > There is nothing broken here, this is preference. I see no reason to move > it again. Julian, did announce it and we accepted it. > We should be moving towards closure. > Paul Koning wrote: > > I objected before and I'll object again. > > It would be very nice if we could stop making gratuitous changes to > packet formats and get the spec finished instead. In other words you have no problem with those changes taking place, you simply oppose to them, lest the PDU format become more object oriented friendly. The people in C wouldn't mind that much since they are used to dealing with bit shifting and what not, but the people in C++ where this inconsistency would mean an ugly base class, and an unbecoming implementation would cringe at the look of it. You should've at least recognised that this would be a _good_ architectural change, and then give your reasons for _not_ implementing it, rather than calling them ``gratuitous changes''. I'm not posting here out of whim -- I really do care. -- Luben From owner-ips@ece.cmu.edu Tue May 28 13:28:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25936 for ; Tue, 28 May 2002 13:28:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SGo9D24496 for ips-outgoing; Tue, 28 May 2002 12:50:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SGo7w24492 for ; Tue, 28 May 2002 12:50:07 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 9C9D7702; Tue, 28 May 2002 10:50:06 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 49C8B15C; Tue, 28 May 2002 10:50:06 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 10:50:05 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 10:50:05 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09D4B2@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Julian Satran , "THALER,PAT (A-Roseville,ex1)" Cc: ips@ece.cmu.edu, mkrikis@yahoo.com Subject: RE: iSCSI: Negotiation clarifications still needed Date: Tue, 28 May 2002 10:49:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-dae9bdac-724e-11d6-bae3-009027404a4a" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-dae9bdac-724e-11d6-bae3-009027404a4a Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20667.B2421AB0" ------_=_NextPart_001_01C20667.B2421AB0 Content-Type: text/plain; charset="iso-8859-1" Julian, I think the text looks fine except for the word "responder" which is difficult because one is a "responder" or an "originator" per key and having received a partial key, one doesn't know whether one is a responder or an originator yet. It would be better to replace "responder" with "initiator or target" Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, May 24, 2002 10:26 PM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu; mkrikis@yahoo.com Subject: RE: iSCSI: Negotiation clarifications still needed Pat your proposed 2b may be what we are looking for - i.e. a responder may not originate a key if it has an incomplete key text. The text we may want to add to section 4.2 is: Key=value pairs may span PDU boundaries. A responder having a received partial key text MUST refrain from originating any new key=value negotiations until it has no incomplete key text. This way one avoids having both negotiating entities assuming the originator role in a negotiation. Julo pat_thaler@agilent.com 05/25/2002 12:16 AM Please respond to pat_thaler To: mkrikis@yahoo.com, Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiation clarifications still needed Martins, Comments referenced by the same items Martins used. 1. Julian sent an email saying he would put the text I proposed in (though the text you quoted is not the whole text). 2. I think that the principle we have been using on text negotiation was that each key negotion is a separate item. Your proposal would be counter to that and I don't think it would be an improvement. The target should be allowed to respond to any complete key-value pair it has received. When a key-value pair is straddling the PDU bondary, then it shouldn't respond to that key until the complete key-value pair has been received. There is one potential corner case issue that should to be covered. Targets can initiate keys. If key-value pairs didn't straddle PDU boundaries, then ensuring that there is a clear originator for each offered key is easy. You can originate any key that you haven't received an offer of from your partner. But now keys can straddle PDUs. If the text between the last separater and the end of the PDU is Ma, then you don't know what key your partner has started to offer. If the partner was starting to offer MaxBurstSize and you offer it in the next PDU of the exchange, both sides may think they are originator. I suggest one of the following a) don't allow keys to straddle PDU boundaries. b) don't allow originating a key when the last login PDU ended in a partial key. c) don't allow offering a key where the start of the key matches a partial key at the end of the last login PDU. 3. Yes, we noticed a little while ago that losing a packet at the end of negotiation could hang things up though the concern is mainly for a full feature phase negotiation. Looking at 6.8, any timeout during negotiation causes the login and its TCP connection to be terminated. The whole negotiation process (see the point about origninators in 2) depends upon a one-by-one exchange of PDUs. PDU loss has to terminate it. Therefore, the target commits to the end of login as described for T5 target. It has sent the final login response with a status of zero. Moves to S5. If the login response doesn't get to the initiator, then either the initiator will close the connection due to the timeout. Since the target is in S4, loss of the transport connection will cause it to go to S8 and R1 of the cleanup state machine. It presumably will not take the M2 transition because the intiator isn't going to do cleanup for a connection it thinks wasn't in full feature phase. It will take M1 due to timeout - not elegant but good enough. The concern was Full Feature Phase negotation. Until negotiation ends, it can be reset and no values change. When the target sends the last Text Response PDU, then it thinks negotiation has ended and it applies the new values. If that PDU doesn't reach the initiatior, then it terminates the entire negotiation and continues to use the old values. The two ends are using different values. We decided to not raise this as an issue because it is such a corner case - we are operating over a reliable connection so PDUs shouldn't be lost (unless the whole path goes down in which case it doesn't matter). Also, there are few values exchanged during full feature so it isn't worthwhile to add complexity. Regards, Pat -----Original Message----- From: Martins Krikis [mailto:mkrikis@yahoo.com] Sent: Friday, May 24, 2002 12:39 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: iSCSI: Negotiation clarifications still needed The previous thread went on too long, but since it has now quieted down, I'll conjecture that the following are the aspects that still need to be addressed. 1. Not everybody seemed to have noticed that it is NOT legal to send the same key again, if it has once been negotiated (including negotiations that end with a reserved value (Reject, Irrelevant or NotUnderstood). I think it would benefit the draft to add the sentence that Pat proposed to paragraph 5 or page 72 in 12-92: "Sending the key again would be a re-negotiation". That I think would make it crystal clear. 2. When the key=value pairs that Originator is sending are broken across multiple PDUs, it is not clear whether the Responder may start responding to the keys as soon as it receives them or whether it should send blank PDUs back (as in the example on page 164 of 12-92) until it gets a PDU, the data part of which ends in a NUL byte (thus signaling that there are no broken key=value pairs at the end of it). I am proposing that the draft should make it explicit that only blank PDUs are to be sent. This allows decoupling of key=value generation from their encapsulation in PDUs (i.e., the generating logic need not worry about whether a key=value pair will fit and go out in this PDU or has to be retained to go out in the next). I can explain in detail why this is important (it has to do with teh possibility of receiving the "just-about outgoing" keys) but I'm keeping this "brief". Furthermore, it is my feeling that instead of checking the last bytes of a PDU for NUL, it would be better if the end-of-data was marked by a flag in the header. This way encapsulation will be simpler---just put as much data in the PDU as fits there and raise the flag if it isn't all, instead of checking whether it ends in a NUL and possibly shortening data to make it not end like that. 3. There is an opinion that on page 73 of 12-92, the phrase that says "or the responder may select an admissible value" is in contradiction to the very next sentence. There is also an opinion that this phrase is entirely unnecessary and detrimental to achieving broad interoperability (I call it "cutting slack to misbehaving or incompatible originators"). I don't have a suggestion since I consider the "feature" that this phrase allows of little importance to a properly built iSCSI node. 4. This is new. When doing Text Request/Response negotiations (i.e., in FFP), it seems that the Initiator commits to the new values when it receives a response from the Target with the F bit set. It is unclear when the Target should commit. Should it switch to using the new values as soon as it sends its response with the F-bit set, or should it do so only when it knows that the Initiator received its response? Commiting right away is simpler and since responses with F-bits set have TTT=0xffffffff and thus may not be reset, sounds plausible. If the values have importance on the next reception, it may also be important to commit timely. However, what if the Initiator doesn't get this response? Target now has committed, Initiator hasn't. Committing later puts the burden on Initiator to send something effectively telling "I've received your final response". Otherwise the Target will time out and not commit. This response can get lost too. Basically, it is beginning to look a bit like (what was it called?) "distributed consensus problem"? I think it goes like this: Two generals that are on oposite sides of the enemy want to synchronize their attack, and start sending messengers through with messages like "attack at dawn->", "<-ok, attack at dawn", "I know you know we attack at dawn->", "<-, I know you know I know we attack at dawn", etc., etc., ... But at no point can they commit yet... Is anybody else worried about this? Anyway, so when should a target commit? Page 83 of 12-92 is the relevant reference. Thanks, Martins Krikis Disclaimer: these opinions are my own and may not be those of my employer. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com ------_=_NextPart_001_01C20667.B2421AB0 Content-Type: text/html; charset="iso-8859-1"

Julian,
 
I think the text looks fine except for the word "responder" which is difficult because one is a "responder" or an "originator" per key and having received a partial key, one doesn't know whether one is a responder or an originator yet. It would be better to replace "responder" with "initiator or target"
 
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, May 24, 2002 10:26 PM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu; mkrikis@yahoo.com
Subject: RE: iSCSI: Negotiation clarifications still needed


Pat your proposed 2b may be what we are looking for - i.e. a responder may not originate a key if it has an incomplete key text.

The text we may want to add to section 4.2 is:

Key=value pairs may span PDU boundaries. A responder having a received partial key text MUST refrain from originating any new key=value negotiations until it has no incomplete key text. This way one avoids having both negotiating entities assuming the originator role in a negotiation.


Julo


pat_thaler@agilent.com

05/25/2002 12:16 AM
Please respond to pat_thaler

       
        To:        mkrikis@yahoo.com, Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: Negotiation clarifications still needed

       


Martins,

Comments referenced by the same items Martins used.

1. Julian sent an email saying he would put the text
I proposed in (though the text you quoted is not the
whole text).

2. I think that the principle we have been using on
text negotiation was that each key negotion is a
separate item. Your proposal would be counter to that
and I don't think it would be an improvement. The
target should be allowed to respond to any complete
key-value pair it has received. When a key-value
pair is straddling the PDU bondary, then it shouldn't
respond to that key until the complete key-value pair
has been received.

There is one potential corner case issue that should
to be covered. Targets can initiate keys. If key-value
pairs didn't straddle PDU boundaries, then ensuring
that there is a clear originator for each offered key
is easy. You can originate any key that you haven't
received an offer of from your partner. But now keys
can straddle PDUs. If the text between the last separater
and the end of the PDU is Ma, then you don't know what
key your partner has started to offer. If the partner
was starting to offer MaxBurstSize and you offer it in
the next PDU of the exchange, both sides may think they
are originator.

I suggest one of the following
a) don't allow keys to straddle PDU boundaries.
b) don't allow originating a key when the last login
PDU ended in a partial key.
c) don't allow offering a key where the start of the key
matches a partial key at the end of the last login
PDU.

3. Yes, we noticed a little while ago that losing a
packet at the end of negotiation could hang things up
though the concern is mainly for a full feature phase
negotiation. Looking at 6.8, any timeout during
negotiation causes the login and its TCP connection to
be terminated. The whole negotiation process (see the
point about origninators in 2) depends upon a one-by-one
exchange of PDUs. PDU loss has to terminate it.

Therefore, the target commits to the end of login
as described for T5 target. It has sent the final
login response with a status of zero. Moves to S5.
If the login response doesn't get to the initiator,
then either the initiator will close the connection
due to the timeout. Since the target is in S4, loss
of the transport connection will cause it to go to
S8 and R1 of the cleanup state machine. It presumably
will not take the M2 transition because the intiator
isn't going to do cleanup for a connection it thinks
wasn't in full feature phase. It will take M1 due to
timeout - not elegant but good enough.

The concern was Full Feature Phase negotation. Until
negotiation ends, it can be reset and no values change.
When the target sends the last Text Response PDU, then
it thinks negotiation has ended and it applies the
new values. If that PDU doesn't reach the initiatior,
then it terminates the entire negotiation and continues
to use the old values. The two ends are using different
values.

We decided to not raise this as an issue because it is
such a corner case - we are operating over a reliable
connection so PDUs shouldn't be lost (unless the whole
path goes down in which case it doesn't matter). Also,
there are few values exchanged during full feature so
it isn't worthwhile to add complexity.

Regards,
Pat


-----Original Message-----
From: Martins Krikis [mailto:mkrikis@yahoo.com]
Sent: Friday, May 24, 2002 12:39 PM
To: Julian Satran
Cc: ips@ece.cmu.edu
Subject: iSCSI: Negotiation clarifications still needed


The previous thread went on too long, but since it
has now quieted down, I'll conjecture that the
following are the aspects that still need to be
addressed.

1. Not everybody seemed to have noticed that it is
  NOT legal to send the same key again, if it
  has once been negotiated (including negotiations
  that end with a reserved value (Reject,
  Irrelevant or NotUnderstood).

I think it would benefit the draft to add the
sentence that Pat proposed to paragraph 5 or page
72 in 12-92: "Sending the key again would be a
re-negotiation". That I think would make it crystal
clear.

2. When the key=value pairs that Originator is
  sending are broken across multiple PDUs, it
  is not clear whether the Responder may start
  responding to the keys as soon as it receives
  them or whether it should send blank PDUs back
  (as in the example on page 164 of 12-92) until
  it gets a PDU, the data part of which ends in
  a NUL byte (thus signaling that there are no
  broken key=value pairs at the end of it).

I am proposing that the draft should make it explicit
that only blank PDUs are to be sent. This allows
decoupling of key=value generation from
their encapsulation in PDUs (i.e., the generating
logic need not worry about whether a key=value
pair will fit and go out in this PDU or has to
be retained to go out in the next). I can explain
in detail why this is important (it has to do
with teh possibility of receiving the "just-about
outgoing" keys) but I'm keeping this "brief".

Furthermore, it is my feeling that instead of
checking the last bytes of a PDU for NUL, it
would be better if the end-of-data was marked by
a flag in the header. This way encapsulation will
be simpler---just put as much data in the PDU as
fits there and raise the flag if it isn't all,
instead of checking whether it ends in a NUL and
possibly shortening data to make it not end like
that.

3. There is an opinion that on page 73 of 12-92,
  the phrase that says "or the responder may
  select an admissible value" is in contradiction
  to the very next sentence. There is also an
  opinion that this phrase is entirely unnecessary
  and detrimental to achieving broad
  interoperability (I call it "cutting slack to
  misbehaving or incompatible originators").

I don't have a suggestion since I consider the
"feature" that this phrase allows of little
importance to a properly built iSCSI node.

4. This is new. When doing Text Request/Response
negotiations (i.e., in FFP), it seems
that the Initiator commits to the new values
when it receives a response from the Target with
the F bit set. It is unclear when the Target should
commit. Should it switch to using the new values
as soon as it sends its response with the F-bit
set, or should it do so only when it knows that
the Initiator received its response?

Commiting right away is simpler and since responses
with F-bits set have TTT=0xffffffff and thus
may not be reset, sounds plausible. If the
values have importance on the next reception,
it may also be important to commit timely. However,
what if the Initiator doesn't get this response?
Target now has committed, Initiator hasn't. Committing
later puts the burden on Initiator to send something
effectively telling "I've received your final
response". Otherwise the Target will time out and
not commit. This response can get lost too.

Basically, it is beginning to look a bit like
(what was it called?) "distributed consensus problem"?
I think it goes like this:

Two generals that are on oposite sides of the
enemy want to synchronize their attack, and
start sending messengers through with messages
like
 "attack at dawn->",
 "<-ok, attack at dawn",
 "I know you know we attack at dawn->",
 "<-, I know you know I know we attack at dawn",
 etc., etc., ...
But at no point can they commit yet...

Is anybody else worried about this?
Anyway, so when should a target commit? Page 83
of 12-92 is the relevant reference.

Thanks,

 Martins Krikis

Disclaimer: these opinions are my own and may
           not be those of my employer.


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com


------_=_NextPart_001_01C20667.B2421AB0-- ------=_NextPartTM-000-dae9bdac-724e-11d6-bae3-009027404a4a-- From owner-ips@ece.cmu.edu Tue May 28 14:13:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26952 for ; Tue, 28 May 2002 14:13:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SHWZO27593 for ips-outgoing; Tue, 28 May 2002 13:32:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SHWXw27586 for ; Tue, 28 May 2002 13:32:33 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id 17818E00AC4; Tue, 28 May 2002 10:32:28 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id KAA20412; Tue, 28 May 2002 10:32:19 -0700 (PDT) Message-ID: <3CF3C0ED.E210A870@cup.hp.com> Date: Tue, 28 May 2002 10:39:57 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Luben Tuikov Cc: iSCSI Subject: Re: [iSCSI:] Logout request -- reason? Correction References: <3CF23830.9344CC@splentec.com> <3CF23947.D2D5186C@splentec.com> <3CF25CE1.82A6EE84@splentec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Can we stop making changes to the iscsi pdu formats ? We are never going to make it to RFC and ship some iscsi products, if we continue to keep requesting cosmetic changes to the spec. We should freeze the spec now and stop making changes, unless the change fixes something that is broken. Thanks, Santosh Luben Tuikov wrote: > > Could we do the same to Task Mgmt. Func. Req. > (Function -> byte 2) and to SNACK (Type -> byte 2). > Both PDUs have byte 2 reserved to 0. > > If not, please elaborate. > > -- > Luben > > Luben Tuikov wrote: > > > > Let me correct this: > > > > I was under the impression that byte 1 in BHS > > is a flags byte -- i.e. bit values. > > > > I now see that the reason code is moved exactly there, > > in the Logout request PDU. > > > > Could anyone please explain the logic behind this? > > > > At the same time byte 2 and 3 are reserved to 0. > > > > Why don't we: > > > > 1) Move the reason code to byte 2. This will > > make it _consistent_ with the response byte > > in Logout Response. > > > > 2) Make the value start at 0x80, as to hide > > the ugliness of F = 1, and the fact that > > we are trying to fit a numerical value (!) > > and a bit value (!) in the same octet. > > > > Comments? -- The world is so fast that there are days when the person who says it can't be done is interrupted by the person who is doing it. ~ Anon From owner-ips@ece.cmu.edu Tue May 28 14:17:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27092 for ; Tue, 28 May 2002 14:17:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SHVM627491 for ips-outgoing; Tue, 28 May 2002 13:31:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SHVKw27487 for ; Tue, 28 May 2002 13:31:20 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 13:29:53 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564BEE3@CORPMX14> From: Black_David@emc.com To: luben@splentec.com Cc: ips@ece.cmu.edu Subject: RE: [iSCSI:] Logout request -- reason? Correction Date: Tue, 28 May 2002 13:29:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, > In other words you have no problem with those changes > taking place, you simply oppose to them, lest the > PDU format become more object oriented friendly. I think that's somewhat overdone and out of line. The formats have been this way for a while now, and we are well past the point where this sort of change is appropriate for abstract beautification reasons such as "object oriented friendly". We could spend the next 6 months rearranging the iSCSI header structures to suit some ideals of beauty and architectural cleanliness, and even though there are doubtless some people who would like to "help" with this, I'm fairly certain that the rough consensus of the WG is not to spend the next 6 months on this activity. > You should've at least recognised that this would > be a _good_ architectural change, and then give your reasons > for _not_ implementing it, rather than calling them > ``gratuitous changes''. There's quite a bit of "running code" out there that deserves some degree of respect - the fact that these changes break it suggests that something other than an opinion that the result will be more "object oriented friendly" is needed to motivate them. At the moment, both "rough consensus" and "running code" appear to suggest that they are not appropriate. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Luben Tuikov [mailto:luben@splentec.com] > Sent: Tuesday, May 28, 2002 11:53 AM > To: Paul Koning > Cc: ips@ece.cmu.edu; John Hufferd > Subject: Re: [iSCSI:] Logout request -- reason? Correction > > > John Hufferd wrote: > > > > There is nothing broken here, this is preference. I see no > reason to move > > it again. Julian, did announce it and we accepted it. > > We should be moving towards closure. > > > > Paul Koning wrote: > > > > I objected before and I'll object again. > > > > It would be very nice if we could stop making gratuitous changes to > > packet formats and get the spec finished instead. > > In other words you have no problem with those changes > taking place, you simply oppose to them, lest the > PDU format become more object oriented friendly. > > The people in C wouldn't mind that much since they are used to > dealing with bit shifting and what not, but the people in > C++ where this inconsistency would mean an ugly base class, > and an unbecoming implementation would cringe at the look of it. > > You should've at least recognised that this would > be a _good_ architectural change, and then give your reasons > for _not_ implementing it, rather than calling them > ``gratuitous changes''. > > I'm not posting here out of whim -- I really do care. > > -- > Luben From owner-ips@ece.cmu.edu Tue May 28 14:17:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27107 for ; Tue, 28 May 2002 14:17:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SHT5227315 for ips-outgoing; Tue, 28 May 2002 13:29:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SHT3w27311 for ; Tue, 28 May 2002 13:29:04 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id E5DCCCB1E; Tue, 28 May 2002 11:28:58 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id F07A83E5; Tue, 28 May 2002 11:28:49 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 11:28:42 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 11:28:42 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09D4E6@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: luben@splentec.com, ips@ece.cmu.edu, Julian_Satran@il.ibm.com Subject: RE: [iSCSI:] Logout request -- reason? Correction Date: Tue, 28 May 2002 11:28:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, I don't see where you got that impression. The BHS layout shows bytes 1 through 3 as opcode specific fields. The kinds of opcode specific fields will be different depending upon opcode. Pat -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Monday, May 27, 2002 6:49 AM To: iSCSI; Julian Satran Subject: [iSCSI:] Logout request -- reason? Correction Let me correct this: I was under the impression that byte 1 in BHS is a flags byte -- i.e. bit values. I now see that the reason code is moved exactly there, in the Logout request PDU. Could anyone please explain the logic behind this? At the same time byte 2 and 3 are reserved to 0. Why don't we: 1) Move the reason code to byte 2. This will make it _consistent_ with the response byte in Logout Response. 2) Make the value start at 0x80, as to hide the ugliness of F = 1, and the fact that we are trying to fit a numerical value (!) and a bit value (!) in the same octet. Comments? -- Luben From owner-ips@ece.cmu.edu Tue May 28 14:21:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27254 for ; Tue, 28 May 2002 14:21:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SHv2Y29320 for ips-outgoing; Tue, 28 May 2002 13:57:02 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SHv0w29316 for ; Tue, 28 May 2002 13:57:00 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4SHumNU004630; Tue, 28 May 2002 19:56:48 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4SHulb117044; Tue, 28 May 2002 19:56:47 +0200 To: "THALER,PAT (A-Roseville,ex1)" Cc: ips@ece.cmu.edu, mkrikis@yahoo.com, "THALER,PAT (A-Roseville,ex1)" MIME-Version: 1.0 Subject: RE: iSCSI: Negotiation clarifications still needed X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 28 May 2002 20:56:40 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 28/05/2002 20:56:48, Serialize complete at 28/05/2002 20:56:48 Content-Type: multipart/alternative; boundary="=_alternative 005E6798C2256BC7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005E6798C2256BC7_= Content-Type: text/plain; charset="us-ascii" fine - thanks - Julo "THALER,PAT (A-Roseville,ex1)" 05/28/2002 07:49 PM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL, "THALER,PAT (A-Roseville,ex1)" cc: ips@ece.cmu.edu, mkrikis@yahoo.com Subject: RE: iSCSI: Negotiation clarifications still needed Julian, I think the text looks fine except for the word "responder" which is difficult because one is a "responder" or an "originator" per key and having received a partial key, one doesn't know whether one is a responder or an originator yet. It would be better to replace "responder" with "initiator or target" Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, May 24, 2002 10:26 PM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu; mkrikis@yahoo.com Subject: RE: iSCSI: Negotiation clarifications still needed Pat your proposed 2b may be what we are looking for - i.e. a responder may not originate a key if it has an incomplete key text. The text we may want to add to section 4.2 is: Key=value pairs may span PDU boundaries. A responder having a received partial key text MUST refrain from originating any new key=value negotiations until it has no incomplete key text. This way one avoids having both negotiating entities assuming the originator role in a negotiation. Julo pat_thaler@agilent.com 05/25/2002 12:16 AM Please respond to pat_thaler To: mkrikis@yahoo.com, Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiation clarifications still needed Martins, Comments referenced by the same items Martins used. 1. Julian sent an email saying he would put the text I proposed in (though the text you quoted is not the whole text). 2. I think that the principle we have been using on text negotiation was that each key negotion is a separate item. Your proposal would be counter to that and I don't think it would be an improvement. The target should be allowed to respond to any complete key-value pair it has received. When a key-value pair is straddling the PDU bondary, then it shouldn't respond to that key until the complete key-value pair has been received. There is one potential corner case issue that should to be covered. Targets can initiate keys. If key-value pairs didn't straddle PDU boundaries, then ensuring that there is a clear originator for each offered key is easy. You can originate any key that you haven't received an offer of from your partner. But now keys can straddle PDUs. If the text between the last separater and the end of the PDU is Ma, then you don't know what key your partner has started to offer. If the partner was starting to offer MaxBurstSize and you offer it in the next PDU of the exchange, both sides may think they are originator. I suggest one of the following a) don't allow keys to straddle PDU boundaries. b) don't allow originating a key when the last login PDU ended in a partial key. c) don't allow offering a key where the start of the key matches a partial key at the end of the last login PDU. 3. Yes, we noticed a little while ago that losing a packet at the end of negotiation could hang things up though the concern is mainly for a full feature phase negotiation. Looking at 6.8, any timeout during negotiation causes the login and its TCP connection to be terminated. The whole negotiation process (see the point about origninators in 2) depends upon a one-by-one exchange of PDUs. PDU loss has to terminate it. Therefore, the target commits to the end of login as described for T5 target. It has sent the final login response with a status of zero. Moves to S5. If the login response doesn't get to the initiator, then either the initiator will close the connection due to the timeout. Since the target is in S4, loss of the transport connection will cause it to go to S8 and R1 of the cleanup state machine. It presumably will not take the M2 transition because the intiator isn't going to do cleanup for a connection it thinks wasn't in full feature phase. It will take M1 due to timeout - not elegant but good enough. The concern was Full Feature Phase negotation. Until negotiation ends, it can be reset and no values change. When the target sends the last Text Response PDU, then it thinks negotiation has ended and it applies the new values. If that PDU doesn't reach the initiatior, then it terminates the entire negotiation and continues to use the old values. The two ends are using different values. We decided to not raise this as an issue because it is such a corner case - we are operating over a reliable connection so PDUs shouldn't be lost (unless the whole path goes down in which case it doesn't matter). Also, there are few values exchanged during full feature so it isn't worthwhile to add complexity. Regards, Pat -----Original Message----- From: Martins Krikis [mailto:mkrikis@yahoo.com] Sent: Friday, May 24, 2002 12:39 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: iSCSI: Negotiation clarifications still needed The previous thread went on too long, but since it has now quieted down, I'll conjecture that the following are the aspects that still need to be addressed. 1. Not everybody seemed to have noticed that it is NOT legal to send the same key again, if it has once been negotiated (including negotiations that end with a reserved value (Reject, Irrelevant or NotUnderstood). I think it would benefit the draft to add the sentence that Pat proposed to paragraph 5 or page 72 in 12-92: "Sending the key again would be a re-negotiation". That I think would make it crystal clear. 2. When the key=value pairs that Originator is sending are broken across multiple PDUs, it is not clear whether the Responder may start responding to the keys as soon as it receives them or whether it should send blank PDUs back (as in the example on page 164 of 12-92) until it gets a PDU, the data part of which ends in a NUL byte (thus signaling that there are no broken key=value pairs at the end of it). I am proposing that the draft should make it explicit that only blank PDUs are to be sent. This allows decoupling of key=value generation from their encapsulation in PDUs (i.e., the generating logic need not worry about whether a key=value pair will fit and go out in this PDU or has to be retained to go out in the next). I can explain in detail why this is important (it has to do with teh possibility of receiving the "just-about outgoing" keys) but I'm keeping this "brief". Furthermore, it is my feeling that instead of checking the last bytes of a PDU for NUL, it would be better if the end-of-data was marked by a flag in the header. This way encapsulation will be simpler---just put as much data in the PDU as fits there and raise the flag if it isn't all, instead of checking whether it ends in a NUL and possibly shortening data to make it not end like that. 3. There is an opinion that on page 73 of 12-92, the phrase that says "or the responder may select an admissible value" is in contradiction to the very next sentence. There is also an opinion that this phrase is entirely unnecessary and detrimental to achieving broad interoperability (I call it "cutting slack to misbehaving or incompatible originators"). I don't have a suggestion since I consider the "feature" that this phrase allows of little importance to a properly built iSCSI node. 4. This is new. When doing Text Request/Response negotiations (i.e., in FFP), it seems that the Initiator commits to the new values when it receives a response from the Target with the F bit set. It is unclear when the Target should commit. Should it switch to using the new values as soon as it sends its response with the F-bit set, or should it do so only when it knows that the Initiator received its response? Commiting right away is simpler and since responses with F-bits set have TTT=0xffffffff and thus may not be reset, sounds plausible. If the values have importance on the next reception, it may also be important to commit timely. However, what if the Initiator doesn't get this response? Target now has committed, Initiator hasn't. Committing later puts the burden on Initiator to send something effectively telling "I've received your final response". Otherwise the Target will time out and not commit. This response can get lost too. Basically, it is beginning to look a bit like (what was it called?) "distributed consensus problem"? I think it goes like this: Two generals that are on oposite sides of the enemy want to synchronize their attack, and start sending messengers through with messages like "attack at dawn->", "<-ok, attack at dawn", "I know you know we attack at dawn->", "<-, I know you know I know we attack at dawn", etc., etc., ... But at no point can they commit yet... Is anybody else worried about this? Anyway, so when should a target commit? Page 83 of 12-92 is the relevant reference. Thanks, Martins Krikis Disclaimer: these opinions are my own and may not be those of my employer. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com --=_alternative 005E6798C2256BC7_= Content-Type: text/html; charset="us-ascii"
fine - thanks - Julo


"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>

05/28/2002 07:49 PM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL, "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
        cc:        ips@ece.cmu.edu, mkrikis@yahoo.com
        Subject:        RE: iSCSI: Negotiation clarifications still needed

       


Julian,
 
I think the text looks fine except for the word "responder" which is difficult because one is a "responder" or an "originator" per key and having received a partial key, one doesn't know whether one is a responder or an originator yet. It would be better to replace "responder" with "initiator or target"
 
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, May 24, 2002 10:26 PM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu; mkrikis@yahoo.com
Subject: RE: iSCSI: Negotiation clarifications still needed

Pat your proposed 2b may be what we are looking for - i.e. a responder may not originate a key if it has an incomplete key text.

The text we may want to add to section 4.2 is:

Key=value pairs may span PDU boundaries. A responder having a received partial key text MUST refrain from originating any new key=value negotiations until it has no incomplete key text. This way one avoids having both negotiating entities assuming the originator role in a negotiation.


Julo

pat_thaler@agilent.com

05/25/2002 12:16 AM
Please respond to pat_thaler

       
       To:        mkrikis@yahoo.com, Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu
       Subject:        RE: iSCSI: Negotiation clarifications still needed

     



Martins,

Comments referenced by the same items Martins used.

1. Julian sent an email saying he would put the text
I proposed in (though the text you quoted is not the
whole text).

2. I think that the principle we have been using on
text negotiation was that each key negotion is a
separate item. Your proposal would be counter to that
and I don't think it would be an improvement. The
target should be allowed to respond to any complete
key-value pair it has received. When a key-value
pair is straddling the PDU bondary, then it shouldn't
respond to that key until the complete key-value pair
has been received.

There is one potential corner case issue that should
to be covered. Targets can initiate keys. If key-value
pairs didn't straddle PDU boundaries, then ensuring
that there is a clear originator for each offered key
is easy. You can originate any key that you haven't
received an offer of from your partner. But now keys
can straddle PDUs. If the text between the last separater
and the end of the PDU is Ma, then you don't know what
key your partner has started to offer. If the partner
was starting to offer MaxBurstSize and you offer it in
the next PDU of the exchange, both sides may think they
are originator.

I suggest one of the following
a) don't allow keys to straddle PDU boundaries.
b) don't allow originating a key when the last login
PDU ended in a partial key.
c) don't allow offering a key where the start of the key
matches a partial key at the end of the last login
PDU.

3. Yes, we noticed a little while ago that losing a
packet at the end of negotiation could hang things up
though the concern is mainly for a full feature phase
negotiation. Looking at 6.8, any timeout during
negotiation causes the login and its TCP connection to
be terminated. The whole negotiation process (see the
point about origninators in 2) depends upon a one-by-one
exchange of PDUs. PDU loss has to terminate it.

Therefore, the target commits to the end of login
as described for T5 target. It has sent the final
login response with a status of zero. Moves to S5.
If the login response doesn't get to the initiator,
then either the initiator will close the connection
due to the timeout. Since the target is in S4, loss
of the transport connection will cause it to go to
S8 and R1 of the cleanup state machine. It presumably
will not take the M2 transition because the intiator
isn't going to do cleanup for a connection it thinks
wasn't in full feature phase. It will take M1 due to
timeout - not elegant but good enough.

The concern was Full Feature Phase negotation. Until
negotiation ends, it can be reset and no values change.
When the target sends the last Text Response PDU, then
it thinks negotiation has ended and it applies the
new values. If that PDU doesn't reach the initiatior,
then it terminates the entire negotiation and continues
to use the old values. The two ends are using different
values.

We decided to not raise this as an issue because it is
such a corner case - we are operating over a reliable
connection so PDUs shouldn't be lost (unless the whole
path goes down in which case it doesn't matter). Also,
there are few values exchanged during full feature so
it isn't worthwhile to add complexity.

Regards,
Pat


-----Original Message-----
From: Martins Krikis [mailto:mkrikis@yahoo.com]
Sent: Friday, May 24, 2002 12:39 PM
To: Julian Satran
Cc: ips@ece.cmu.edu
Subject: iSCSI: Negotiation clarifications still needed


The previous thread went on too long, but since it
has now quieted down, I'll conjecture that the
following are the aspects that still need to be
addressed.

1. Not everybody seemed to have noticed that it is
 NOT legal to send the same key again, if it
 has once been negotiated (including negotiations
 that end with a reserved value (Reject,
 Irrelevant or NotUnderstood).

I think it would benefit the draft to add the
sentence that Pat proposed to paragraph 5 or page
72 in 12-92: "Sending the key again would be a
re-negotiation". That I think would make it crystal
clear.

2. When the key=value pairs that Originator is
 sending are broken across multiple PDUs, it
 is not clear whether the Responder may start
 responding to the keys as soon as it receives
 them or whether it should send blank PDUs back
 (as in the example on page 164 of 12-92) until
 it gets a PDU, the data part of which ends in
 a NUL byte (thus signaling that there are no
 broken key=value pairs at the end of it).

I am proposing that the draft should make it explicit
that only blank PDUs are to be sent. This allows
decoupling of key=value generation from
their encapsulation in PDUs (i.e., the generating
logic need not worry about whether a key=value
pair will fit and go out in this PDU or has to
be retained to go out in the next). I can explain
in detail why this is important (it has to do
with teh possibility of receiving the "just-about
outgoing" keys) but I'm keeping this "brief".

Furthermore, it is my feeling that instead of
checking the last bytes of a PDU for NUL, it
would be better if the end-of-data was marked by
a flag in the header. This way encapsulation will
be simpler---just put as much data in the PDU as
fits there and raise the flag if it isn't all,
instead of checking whether it ends in a NUL and
possibly shortening data to make it not end like
that.

3. There is an opinion that on page 73 of 12-92,
 the phrase that says "or the responder may
 select an admissible value" is in contradiction
 to the very next sentence. There is also an
 opinion that this phrase is entirely unnecessary
 and detrimental to achieving broad
 interoperability (I call it "cutting slack to
 misbehaving or incompatible originators").

I don't have a suggestion since I consider the
"feature" that this phrase allows of little
importance to a properly built iSCSI node.

4. This is new. When doing Text Request/Response
negotiations (i.e., in FFP), it seems
that the Initiator commits to the new values
when it receives a response from the Target with
the F bit set. It is unclear when the Target should
commit. Should it switch to using the new values
as soon as it sends its response with the F-bit
set, or should it do so only when it knows that
the Initiator received its response?

Commiting right away is simpler and since responses
with F-bits set have TTT=0xffffffff and thus
may not be reset, sounds plausible. If the
values have importance on the next reception,
it may also be important to commit timely. However,
what if the Initiator doesn't get this response?
Target now has committed, Initiator hasn't. Committing
later puts the burden on Initiator to send something
effectively telling "I've received your final
response". Otherwise the Target will time out and
not commit. This response can get lost too.

Basically, it is beginning to look a bit like
(what was it called?) "distributed consensus problem"?
I think it goes like this:

Two generals that are on oposite sides of the
enemy want to synchronize their attack, and
start sending messengers through with messages
like
"attack at dawn->",
"<-ok, attack at dawn",
"I know you know we attack at dawn->",
"<-, I know you know I know we attack at dawn",
etc., etc., ...
But at no point can they commit yet...

Is anybody else worried about this?
Anyway, so when should a target commit? Page 83
of 12-92 is the relevant reference.

Thanks,

Martins Krikis

Disclaimer: these opinions are my own and may
          not be those of my employer.


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

--=_alternative 005E6798C2256BC7_=-- From owner-ips@ece.cmu.edu Tue May 28 14:37:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27589 for ; Tue, 28 May 2002 14:37:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SI66529935 for ips-outgoing; Tue, 28 May 2002 14:06:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SI65w29931 for ; Tue, 28 May 2002 14:06:05 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 396FEBACA; Tue, 28 May 2002 12:06:04 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 8C1772BA; Tue, 28 May 2002 12:06:03 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 12:06:02 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 12:06:02 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09D50F@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: mkrikis@yahoo.com, cbm@rose.hp.com, Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiation clarifications still needed Date: Tue, 28 May 2002 12:05:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Martins, One doesn't have to have a more complex value for key state because one isn't required to initiate keys while one has a partial key-value. If one wishes to have a simpler implementation, then one could have a flag for whether the last received PDU ended with a complete key-value. If it did, one can send key responses and originate keys. If it didn't, one could send key responses. Even an implementation that does originate key-value pairs doesn't need to change its key state because we know there is never more than one key-value in an incomplete state. Therefore, one could check any key that one would like to originate against a partially received key-value before originating it. Pat -----Original Message----- From: Martins Krikis [mailto:mkrikis@yahoo.com] Sent: Friday, May 24, 2002 5:45 PM To: Mallikarjun C.; Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Negotiation clarifications still needed Mallikarjun wrote: > 2. Seems to me that we need to stipulate that only > key values > may straddle PDU boundaries - key names (ideally > inclusive > of "=") shall not. That should avoid requiring > blank PDUs. Definitely inclusive of "=". Otherwise there are no strict guarantees that the whole key has been received (we may have keys that are prefixes to other keys in future, and vendor keys may be like that). I can implement it and live with it if that's what people decide on. I just want people to understand that it is conceptually a more complex aproach than requiring strictly blank PDUs and having a data-end flag. (Even if we don't add a new flag and decide data-end by looking for NUL-s at the end, we get a cleaner scheme.) Allowing non-blank PDUs gives better bandwith utilization under presumably rare circumstances (all pairs not fitting), but introduces more complexity for your everyday case. If we only stipulate that no key ever gets broken, then there is the following "clumsiness" required. When "originating" a key=value pair, it has to be checked whether the key will fit fully in the PDU or not, and if not, then "originating" must be postponed. We also need either a more elaborate state for the key (to mark key as received but value as not; so it is not processable yet, nor originatable anymore), or for each key=value pair being originated, key has to be checked against the buffer that would hold the "leftover stuff" from the just received PDU, otherwise we may illegally originate it. Doable, but not clean. I still think that letting the whole set-of-pairs go through (no matter over how many PDUs spread) before the other side is allowed to process them is cleanest. Martins Krikis, Intel Corp. Disclaimer: these opinions are my own and may not be those of my employer __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ips@ece.cmu.edu Tue May 28 14:57:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27955 for ; Tue, 28 May 2002 14:57:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SIMrL01303 for ips-outgoing; Tue, 28 May 2002 14:22:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SIMpw01295 for ; Tue, 28 May 2002 14:22:51 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 5EAF8C239; Tue, 28 May 2002 12:22:45 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id DB69D2D2; Tue, 28 May 2002 12:22:44 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 12:22:44 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 12:22:44 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09D519@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: wrstuden@wasabisystems.com, pat_thaler@agilent.com Cc: mkrikis@yahoo.com, Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: Negotiation clarifications still needed Date: Tue, 28 May 2002 12:22:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, I don't think that we need to prevent that case. If the initiatior chooses to not initiate a key-value pair when it has received a partial key-value pair (or a partial key) and it doesn't have any keys to respond to, then it can continue the negotiation by sending a PDU with the tail of the partial key-value that it sent. Even if it doesn't have a partial key-value to send it can send a PDU with a blank text field. Either way, the target can then send another PDU finishing its partial key-value. This isn't broken so we don't have to change it to make iSCSI robust. Pat -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Friday, May 24, 2002 5:42 PM To: pat_thaler@agilent.com But there's another case too: Say the response from the target ALSO doesn't fit in one PDU. Yes, the target's not going to respond to the key=value pair that wasn't complete, but say its response to everything else was bigger than the initiator's representation of said keys. For this case to happen, the target's response has to grow more than the first bit of the PDU-spanning key/value pair. The case where I can see this happening is we had a mix of boolean-or keys and other keys. And for these bolean-or keys, the initiator wanted NO but the target wanted YES. So the target's response is bounded to be bigger. Or maybe there were some Rejects in there when the offer was less than 7 bytes long. So now we have TWO PDU-spanning key sets. And the target didn't originate anything. :-) Yes, this is a rare case. But it can happen. And, for iSCSI to be robust, we need to prevent it. From owner-ips@ece.cmu.edu Tue May 28 14:59:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27992 for ; Tue, 28 May 2002 14:59:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SI7ou00067 for ips-outgoing; Tue, 28 May 2002 14:07:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SI7mw00062 for ; Tue, 28 May 2002 14:07:48 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4SI7gPI022014 for ; Tue, 28 May 2002 11:07:42 -0700 (PDT) Received: from TMILES-W2K3.cisco.com (spike-w2k6.cisco.com [171.71.49.52]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA09185 for ; Tue, 28 May 2002 11:07:41 -0700 (PDT) Message-Id: <4.3.2.7.2.20020528110728.01c0d8d0@franklin.cisco.com> X-Sender: tmiles@franklin.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 May 2002 11:07:42 -0700 To: ips@ece.cmu.edu From: Ted Miles Subject: remove Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk From owner-ips@ece.cmu.edu Tue May 28 15:03:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28091 for ; Tue, 28 May 2002 15:03:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SIOfB01447 for ips-outgoing; Tue, 28 May 2002 14:24:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SIOYw01439 for ; Tue, 28 May 2002 14:24:34 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4SHNJu13228; Tue, 28 May 2002 13:23:19 -0400 Message-ID: <3CF3CB58.5BB038DC@splentec.com> Date: Tue, 28 May 2002 14:24:24 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: pat_thaler@agilent.com CC: ips@ece.cmu.edu Subject: Re: [iSCSI:] Logout request -- reason? Correction References: <1BEBA5E8600DD4119A50009027AF54A00C09D4E6@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit pat_thaler@agilent.com wrote: > > Luben, > > I don't see where you got that impression. The BHS layout shows bytes 1 through > 3 as opcode specific fields. The kinds of opcode specific fields will be different > depending upon opcode. Pat, I KNOW about the BHS template. If you had read my mail carefully you'd notice that I mention that putting a bit value _and_ a numeric value in the same octet is not a sound architectural idea. Then you'd deduce that since the F bit is used in _that_ PDU, it'd be a good idea to leave the rest 7 bits be bits (thus making one octet) and use the _next_ _whole_ _empty_ _reserved_ octet for the status/response code. Certainly everyone else understood what I meant. And the objection was _not_ your argument, but the fact that we are running out of time. -- Luben From owner-ips@ece.cmu.edu Tue May 28 15:57:02 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29282 for ; Tue, 28 May 2002 15:57:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SJEYQ05149 for ips-outgoing; Tue, 28 May 2002 15:14:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SJEVw05142 for ; Tue, 28 May 2002 15:14:31 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 8ECA13070A; Tue, 28 May 2002 15:14:30 -0400 (EDT) Date: Tue, 28 May 2002 12:12:33 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: "Mallikarjun C." , , Martins Krikis Subject: Re: iSCSI: Negotiation clarifications still needed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Sat, 25 May 2002, Julian Satran wrote: > I agree with Mallikarjun on all but one point - requiring a key not to > straddle PDU boundaries. > This list had a long debate on the subject. We thought (initially) that > not having any pair straddle PD boundaries is the best thing to do and we > had it untill it became obvious that we have to support very short PDUs. > The we went for allowing spanning and the scheme we had in mind was a > sender preparing its strings and chopping them into PDUs without any > parsing and state. What you suggest now is parsing at send and that may > add unnecessary complexity - and I really don't see why. I'm going to try and explain why; to answer the question in the end of the above paragraph. It's to avoid corner cases while doing what you say above, "preparing its strings and chopping them into PDUs." The simplest thing in my mind is to: 1) read the other side's offers into a buffer 2) parse that buffer generating responses to another buffer 3) send the output buffer Does that make sense? You don't have to agree, just does it make sense? The problem I see with what Pat described is that if you are in operational negotiation and have more than 1 PDU worth of data, you will be receiving input while you're in step 3. You have to be able to re-enter steps 1 & 2 before you can finish step 3. The bit about sending empty PDUs is an effort to avoid that. We are either in a sending-negotiation-text mode, or a parsing mode. We don't have to worry about strings being partially there, since we don't process until they are. We also don't have to worry about if our key/value pairs cross a PDU. The parser/negotiatior is MUCH simpler; it doesn't have to deal with all of that. Letting the target answer while the initiator is trying to send an extended PDU adds the following complications (AFAICT): 1) initiator has to make sure a key and the '=' don't get split on a PDU boundry. 2) if an initiator fills up a PDU, it has to stop processing & wait for the response. It also has to remember where it is so that it can finish sending that key/value next time. 3) The target has to detect a split key/value pair on in-bound, and a) store the received text, and b) remember not to offer said key or any others. 4) The target ALSO has to make sure ITS response doesn't fill up a PDU. If it does, it has to remember where IT is and that it has more to send. That's a lot of complexity and saved state. At least in my mind. That's the advantage I see of blank PDUs; we avoid all of the above complications. Truth be told, the corner cases probably don't apply at present. What we have (and are talking about) will work for security negotiation (we have to wait for the key to make it across) and for operational negotiation (since I don't think we have 8k worth of negotiation data). So for now the common case (no large vendor extentions) isn't going to tickle this set of problems. Does the statement of the perceived problem make sense, even if the opinion of the WG is to not use the empty PDUs? I would feel much comfortable with deciding to not use empty PDUs if folks said they understand the above point and they choose to address the problems differently. Thoughts? Take care, Bill From owner-ips@ece.cmu.edu Tue May 28 15:58:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29314 for ; Tue, 28 May 2002 15:58:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SJVqO06477 for ips-outgoing; Tue, 28 May 2002 15:31:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SJVow06472 for ; Tue, 28 May 2002 15:31:50 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id 15E79C00AE3; Tue, 28 May 2002 12:31:40 -0700 (PDT) Received: from cup.hp.com (hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id MAA25797; Tue, 28 May 2002 12:31:23 -0700 (PDT) Message-ID: <3CF3DCD0.C2AC635D@cup.hp.com> Date: Tue, 28 May 2002 12:38:56 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Luben Tuikov Cc: Martins Krikis , ips@ece.cmu.edu Subject: Re: [iSCSI]: Key negotiation procedure proposal References: <20020523225235.71611.qmail@web13702.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Martins Krikis wrote: > > Please note when this happens, there's no > > choice but to close the connection! > > I.e. both sides rejected each other's > > values -- this is the core rule, and the result > > of rejection on both sides == non-operability. > > I know! But I should just close the connection > now and log that I have met an incompatible Originator > > instead of sending > X-vendor-blah-login-reject-reason=duplicate_key > and then close it. Subtle nuanses maybe, but my > admin may like to know. > > > > Do we have a requirement to let the other side > > know > > > what values we would have accepted? I'm saying, > > let's > > > just Reject what we don't like, close the > > connection > > > if we wish, > > > > There is no other choice Martins -- is it? > > (Interoperability...) > > Other choice than closing? Yes---we can keep it > open and consider it negotiated for commit > purposes, yet the value won't change. Other > choice than interoperability? No, I guess > there isn't. But interoperability can be easier > achieved with sides not sending junk to the > other side, than requiring rejecting sides > to show what they would have liked... > However, I > actually object to the whole idea of cutting any > slack to non-conforming Originators by not Reject-ing > their keys and sending a "good value" instead. > I don't think it is good. So I'm for the removal of > this possibility first, and only if somebody > convinces me about the value of it, then for > making the text more precise. > Take care, > > Martins Krikis, Intel Corp. I agree with all the points Martins Krikis makes above. I strongly oppose the proposal made by Luben since it is too complex and it complicates the base negotiation scheme in an attempt to accomodate non-interoperable implementations. In order to communicate to the other side as to what was the problem with the login negotiation, there are several better/simpler ways to do this than to have to send the key back with the value the target would have supported. This does amount to re-negotiation and causes added complexity on both sides. If the target does not negotiate what the initiator requested, log an error message, issue a reject response and close the connection. The support personnel who diagnose the problem will be able to root cause the problem from the error log. Alternatively, consider enhancing the iscsi MIB statistics to provide better fault isolation data, so that the MIB statistics can be used to determine the root cause of the problem. There is no need to complicate the base login negotiation protocol in an attempt to deal with such non-interoperable implementations. This is not an issue of simple vs. complex implementations. Its a choice that should be made regarding what is the simplest way to provide a mechanism to fault isolate non-interoperable implementations. Also, in such cases, the market will decide which implementations will sell and those target implementations that cannot support what the initiator is negotiating will not sell in that server/OS market. The initiator is seldom going to change its negotiation options in an attempt to be able to interoperate with that target. Lastly, I think we ought to be freezing the spec and stop making changes that are'nt bug fixes. If we don't do that, we are never going to make it to RFC and ship some iscsi products. - Santosh -- The world is so fast that there are days when the person who says it can't be done is interrupted by the person who is doing it. ~ Anon From owner-ips@ece.cmu.edu Tue May 28 15:59:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29345 for ; Tue, 28 May 2002 15:59:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SJZcb06777 for ips-outgoing; Tue, 28 May 2002 15:35:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SJZZw06768 for ; Tue, 28 May 2002 15:35:36 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 62EE630706; Tue, 28 May 2002 15:35:35 -0400 (EDT) Date: Tue, 28 May 2002 12:33:38 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: Subject: Re: iSCSI inband auth: Rough Consensus + Direction In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564BED6@CORPMX14> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 24 May 2002 Black_David@emc.com wrote: > Based on the email on the list since the proposed resolution > text was announced, I think there is rough consensus on the > following points: > > (1) CHAP w/strong secrets is acceptable in principle as > the "MUST implement" authentication method. > (2) No change should be made to the requirements for > bi-directional authentication that existed previously > - the SHOULD for bidirectional use of CHAP (if > CHAP is used) is not appropriate. > (3) Add Paul Koning's example and related text on > preventing reflection attacks on bi-directional > CHAP. > (4) SRP remains in the draft as a "MAY implement" method. Sounds good. > That's progress, but what we don't have rough consensus on > is the practical details of requiring CHAP w/strong secrets, > specifically the latter portion of "SHOULD use strong secrets > w/CHAP, otherwise MUST use ESP encryption to protect weak > secrets". I believe the problems in this area are caused by > a lack of details on what an implementer has to do to satisfy > the "SHOULD" in order to avoid getting whacked with the "MUST". > The proposed resolution text leaves open the possibility > that misbehavior by a user (e.g., failure to RTFM and/or > follow instructions given by a setup tool) could cause the > implementer/vendor to become responsible for the MUST - > that was definitely not the intent of the proposal, > and I think John Hufferd made this point. > > I suggest that the direction to finish closing this issue > is to draw up a list of measures that the draft declares > to be sufficient to satisfy the SHOULD (i.e., the draft > contains text saying that if an implementation does , > , ..., and , the implementation has satisified > "SHOULD use strong secrets" requirement and hence the > "MUST use ESP encryption" requirement does not apply, where > and the like are under control of the implementer). > This is importnat regardless of whether we change > the "SHOULD" for strong CHAP secrets to a "MUST". I like this idea of requirements. I would though like to suggest that we make the points on whatever list we come up with as MUST or SHOULDs, and leave out the MUST use ESP requirement. That way we have a good-faith effort, and if an admin is dead-set on doing something stupid, well, it is their stupidity to do (and their data to loose). > Here's a very quick start at what the contents of such > a list could be: > > - Secrets must be 96 bits in size > - Provide means to generate secrets from real randomness, and > accept externally generated secrets. Do not provide means > to generate a smaller secret or one with less randomness. > - Do not provide any means (e.g., GUI, CLI or other external > interface) to expand a smaller secret to 96+ bits or accept > external input of a smaller secret. > - Disallow any secret with 16+ bits of leading 0's? (helps defend > against accidentally truncating to 64 or 32 bits) > - Documentation and configuration tools must warn users about > the danger of secrets based on insufficient randomness. > > None of the above items are set in stone. Please comment > and suggest revisions/extensions to the above list. I think that's an excelent list. I would be happy with the above list. The one place I have some concern is the disallowing any secret with more than 16+ bits of leading 0's. On the one hand if I ever HAVE to enter such a key (say I have to make things work with a stupidly-configured device administered by someone who has no interest in correcting the problem), I would like to be able to. On the other hand, if all initiators and targets had this test, there would be no way for said stupid problem to arise. Perhaps permit more than 16+ bits of leading 0's only if the administrator acknowleges s/he realizes this CHAP secret is insecure. Like how some OSs will complain in the chpass program if your password doesn't have numbers & letters, but will accept it if you type it in again. Oh, we've tried hard to maintain compatability with RADIUS servers. Do they all support 96-bit secrets? Thoughts? Take care, Bill From owner-ips@ece.cmu.edu Tue May 28 16:02:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29421 for ; Tue, 28 May 2002 16:02:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SJYem06680 for ips-outgoing; Tue, 28 May 2002 15:34:40 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SJYVw06670 for ; Tue, 28 May 2002 15:34:32 -0400 (EDT) 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 g4SJYPNU068036; Tue, 28 May 2002 21:34:25 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4SJYOo109320; Tue, 28 May 2002 21:34:24 +0200 To: "Mallikarjun C." Cc: ips@ece.cmu.edu, mkrikis@yahoo.com, pat_thaler@agilent.com MIME-Version: 1.0 Subject: Re: iSCSI: Negotiation clarifications still needed X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 28 May 2002 22:34:18 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 28/05/2002 22:34:23, Serialize complete at 28/05/2002 22:34:23 Content-Type: multipart/alternative; boundary="=_alternative 006A5B4FC2256BC7_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006A5B4FC2256BC7_= Content-Type: text/plain; charset="us-ascii" Mallikarjun, Thhe current text and your proposed text say basically the same think. If you feel that originating does not convey the meaning of originator I will rephrase it. I will not consider key-name and text-value as they would require a long re-reading of the text. Julo "Mallikarjun C." 05/28/2002 10:02 PM Please respond to "Mallikarjun C." To: , Julian Satran/Haifa/IBM@IBMIL cc: , Subject: Re: iSCSI: Negotiation clarifications still needed Julian, I generally agree with the intent of the wording. A couple of comments - - I assume you meant "text-value of a received key-name" by "key text" (the only occurrence of "key text" is here). I suggest we use the definitions on pages 68 & 69. [ This is somewhat unrelated. But with the advent of formal terminology now, I'd actually recommend that we replace all "key=value" usages in the text with "key-name=text-value".] - IMHO (if my above assumption is true), the proposed rule is overly constraining. o The originator would only have to refrain from originating new keys if a partial *key-name* is received. IOW, doesn't have to wait for the entire text-value to arrive (though it may). o The "no incomplete key text" should not imply that the responder is also forbidden from responding to other (complete) text-value offers that it had already received. As a pathological case, if every PDU begins from the middle of one text-value and concludes in the middle of the next text-value, the responder should not be required to sit out until all the proposals are received in full (though it may). Here's a strawman with some wordsmithing. Key=value pairs may span PDU boundaries. A responder having a received partial key-name or not received the following "=" in a PDU MUST refrain from originating any new key=value negotiations until it had received the key-name in full and the following "=" . In this case, the receiving entity can only assume the role of a responder for this key. This way one avoids having both negotiating entities assuming the originator role in a negotiation. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Cc: ; Sent: Friday, May 24, 2002 10:26 PM Subject: RE: iSCSI: Negotiation clarifications still needed > Pat your proposed 2b may be what we are looking for - i.e. a responder may > not originate a key if it has an incomplete key text. > > The text we may want to add to section 4.2 is: > > Key=value pairs may span PDU boundaries. A responder having a received > partial key text MUST refrain from originating any new key=value > negotiations until it has no incomplete key text. This way one avoids > having both negotiating entities assuming the originator role in a > negotiation. > > > Julo > > > > > pat_thaler@agilent.com > 05/25/2002 12:16 AM > Please respond to pat_thaler > > > To: mkrikis@yahoo.com, Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: Negotiation clarifications still needed > > > > Martins, > > Comments referenced by the same items Martins used. > > 1. Julian sent an email saying he would put the text > I proposed in (though the text you quoted is not the > whole text). > > 2. I think that the principle we have been using on > text negotiation was that each key negotion is a > separate item. Your proposal would be counter to that > and I don't think it would be an improvement. The > target should be allowed to respond to any complete > key-value pair it has received. When a key-value > pair is straddling the PDU bondary, then it shouldn't > respond to that key until the complete key-value pair > has been received. > > There is one potential corner case issue that should > to be covered. Targets can initiate keys. If key-value > pairs didn't straddle PDU boundaries, then ensuring > that there is a clear originator for each offered key > is easy. You can originate any key that you haven't > received an offer of from your partner. But now keys > can straddle PDUs. If the text between the last separater > and the end of the PDU is Ma, then you don't know what > key your partner has started to offer. If the partner > was starting to offer MaxBurstSize and you offer it in > the next PDU of the exchange, both sides may think they > are originator. > > I suggest one of the following > a) don't allow keys to straddle PDU boundaries. > b) don't allow originating a key when the last login > PDU ended in a partial key. > c) don't allow offering a key where the start of the key > matches a partial key at the end of the last login > PDU. > > 3. Yes, we noticed a little while ago that losing a > packet at the end of negotiation could hang things up > though the concern is mainly for a full feature phase > negotiation. Looking at 6.8, any timeout during > negotiation causes the login and its TCP connection to > be terminated. The whole negotiation process (see the > point about origninators in 2) depends upon a one-by-one > exchange of PDUs. PDU loss has to terminate it. > > Therefore, the target commits to the end of login > as described for T5 target. It has sent the final > login response with a status of zero. Moves to S5. > If the login response doesn't get to the initiator, > then either the initiator will close the connection > due to the timeout. Since the target is in S4, loss > of the transport connection will cause it to go to > S8 and R1 of the cleanup state machine. It presumably > will not take the M2 transition because the intiator > isn't going to do cleanup for a connection it thinks > wasn't in full feature phase. It will take M1 due to > timeout - not elegant but good enough. > > The concern was Full Feature Phase negotation. Until > negotiation ends, it can be reset and no values change. > When the target sends the last Text Response PDU, then > it thinks negotiation has ended and it applies the > new values. If that PDU doesn't reach the initiatior, > then it terminates the entire negotiation and continues > to use the old values. The two ends are using different > values. > > We decided to not raise this as an issue because it is > such a corner case - we are operating over a reliable > connection so PDUs shouldn't be lost (unless the whole > path goes down in which case it doesn't matter). Also, > there are few values exchanged during full feature so > it isn't worthwhile to add complexity. > > Regards, > Pat > > > -----Original Message----- > From: Martins Krikis [mailto:mkrikis@yahoo.com] > Sent: Friday, May 24, 2002 12:39 PM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: iSCSI: Negotiation clarifications still needed > > > The previous thread went on too long, but since it > has now quieted down, I'll conjecture that the > following are the aspects that still need to be > addressed. > > 1. Not everybody seemed to have noticed that it is > NOT legal to send the same key again, if it > has once been negotiated (including negotiations > that end with a reserved value (Reject, > Irrelevant or NotUnderstood). > > I think it would benefit the draft to add the > sentence that Pat proposed to paragraph 5 or page > 72 in 12-92: "Sending the key again would be a > re-negotiation". That I think would make it crystal > clear. > > 2. When the key=value pairs that Originator is > sending are broken across multiple PDUs, it > is not clear whether the Responder may start > responding to the keys as soon as it receives > them or whether it should send blank PDUs back > (as in the example on page 164 of 12-92) until > it gets a PDU, the data part of which ends in > a NUL byte (thus signaling that there are no > broken key=value pairs at the end of it). > > I am proposing that the draft should make it explicit > that only blank PDUs are to be sent. This allows > decoupling of key=value generation from > their encapsulation in PDUs (i.e., the generating > logic need not worry about whether a key=value > pair will fit and go out in this PDU or has to > be retained to go out in the next). I can explain > in detail why this is important (it has to do > with teh possibility of receiving the "just-about > outgoing" keys) but I'm keeping this "brief". > > Furthermore, it is my feeling that instead of > checking the last bytes of a PDU for NUL, it > would be better if the end-of-data was marked by > a flag in the header. This way encapsulation will > be simpler---just put as much data in the PDU as > fits there and raise the flag if it isn't all, > instead of checking whether it ends in a NUL and > possibly shortening data to make it not end like > that. > > 3. There is an opinion that on page 73 of 12-92, > the phrase that says "or the responder may > select an admissible value" is in contradiction > to the very next sentence. There is also an > opinion that this phrase is entirely unnecessary > and detrimental to achieving broad > interoperability (I call it "cutting slack to > misbehaving or incompatible originators"). > > I don't have a suggestion since I consider the > "feature" that this phrase allows of little > importance to a properly built iSCSI node. > > 4. This is new. When doing Text Request/Response > negotiations (i.e., in FFP), it seems > that the Initiator commits to the new values > when it receives a response from the Target with > the F bit set. It is unclear when the Target should > commit. Should it switch to using the new values > as soon as it sends its response with the F-bit > set, or should it do so only when it knows that > the Initiator received its response? > > Commiting right away is simpler and since responses > with F-bits set have TTT=0xffffffff and thus > may not be reset, sounds plausible. If the > values have importance on the next reception, > it may also be important to commit timely. However, > what if the Initiator doesn't get this response? > Target now has committed, Initiator hasn't. Committing > later puts the burden on Initiator to send something > effectively telling "I've received your final > response". Otherwise the Target will time out and > not commit. This response can get lost too. > > Basically, it is beginning to look a bit like > (what was it called?) "distributed consensus problem"? > I think it goes like this: > > Two generals that are on oposite sides of the > enemy want to synchronize their attack, and > start sending messengers through with messages > like > "attack at dawn->", > "<-ok, attack at dawn", > "I know you know we attack at dawn->", > "<-, I know you know I know we attack at dawn", > etc., etc., ... > But at no point can they commit yet... > > Is anybody else worried about this? > Anyway, so when should a target commit? Page 83 > of 12-92 is the relevant reference. > > Thanks, > > Martins Krikis > > Disclaimer: these opinions are my own and may > not be those of my employer. > > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > > > --=_alternative 006A5B4FC2256BC7_= Content-Type: text/html; charset="us-ascii"
Mallikarjun,

Thhe current text and your proposed text say basically the same think. If you feel that originating does not convey the meaning of originator I will rephrase it.

I will not consider key-name and text-value as they would require a long re-reading of the text.

Julo


"Mallikarjun C." <cbm@rose.hp.com>

05/28/2002 10:02 PM
Please respond to "Mallikarjun C."

       
        To:        <pat_thaler@agilent.com>, Julian Satran/Haifa/IBM@IBMIL
        cc:        <ips@ece.cmu.edu>, <mkrikis@yahoo.com>
        Subject:        Re: iSCSI: Negotiation clarifications still needed

       


Julian,

I generally agree with the intent of the wording.  A couple of comments -

- I assume you meant "text-value of a received key-name" by "key text"
 (the only occurrence of "key text" is here).   I suggest we use the definitions
 on pages 68 & 69.

 [ This is somewhat unrelated.  But with the advent of formal terminology now,
    I'd actually recommend that we replace all "key=value" usages in the text with
    "key-name=text-value".]

- IMHO (if my above assumption is true), the proposed rule is overly constraining.
   o The originator would only have to refrain from originating new keys if a partial
      *key-name* is received.  IOW, doesn't have to wait for the entire text-value
      to arrive (though it may).

   o The "no incomplete key text" should not imply that the responder is also
      forbidden from responding to other (complete) text-value offers that it had
      already received.  As a pathological case, if every PDU begins from the middle
      of one text-value and concludes in the middle of the next text-value, the responder
      should not be required to sit out until all the proposals are received in full
      (though it may).

Here's a strawman with some wordsmithing.

Key=value pairs may span PDU boundaries. A responder having a received partial key-name or not received the
following "=" in a PDU MUST refrain from originating any new key=value negotiations until it had received the
key-name in full and the following "=" . In this case, the receiving entity can only assume the role of a
responder for this key.  This way one avoids having both negotiating entities assuming the originator role in
a negotiation.

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com


----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <pat_thaler@agilent.com>
Cc: <ips@ece.cmu.edu>; <mkrikis@yahoo.com>
Sent: Friday, May 24, 2002 10:26 PM
Subject: RE: iSCSI: Negotiation clarifications still needed


> Pat your proposed 2b may be what we are looking for - i.e. a responder may
> not originate a key if it has an incomplete key text.
>
> The text we may want to add to section 4.2 is:
>
> Key=value pairs may span PDU boundaries. A responder having a received
> partial key text MUST refrain from originating any new key=value
> negotiations until it has no incomplete key text. This way one avoids
> having both negotiating entities assuming the originator role in a
> negotiation.
>
>
> Julo
>
>
>
>
> pat_thaler@agilent.com
> 05/25/2002 12:16 AM
> Please respond to pat_thaler
>
>
>         To:     mkrikis@yahoo.com, Julian Satran/Haifa/IBM@IBMIL
>         cc:     ips@ece.cmu.edu
>         Subject:        RE: iSCSI: Negotiation clarifications still needed
>
>
>
> Martins,
>
> Comments referenced by the same items Martins used.
>
> 1. Julian sent an email saying he would put the text
> I proposed in (though the text you quoted is not the
> whole text).
>
> 2. I think that the principle we have been using on
> text negotiation was that each key negotion is a
> separate item. Your proposal would be counter to that
> and I don't think it would be an improvement. The
> target should be allowed to respond to any complete
> key-value pair it has received. When a key-value
> pair is straddling the PDU bondary, then it shouldn't
> respond to that key until the complete key-value pair
> has been received.
>
> There is one potential corner case issue that should
> to be covered. Targets can initiate keys. If key-value
> pairs didn't straddle PDU boundaries, then ensuring
> that there is a clear originator for each offered key
> is easy. You can originate any key that you haven't
> received an offer of from your partner. But now keys
> can straddle PDUs. If the text between the last separater
> and the end of the PDU is Ma, then you don't know what
> key your partner has started to offer. If the partner
> was starting to offer MaxBurstSize and you offer it in
> the next PDU of the exchange, both sides may think they
> are originator.
>
> I suggest one of the following
> a) don't allow keys to straddle PDU boundaries.
> b) don't allow originating a key when the last login
> PDU ended in a partial key.
> c) don't allow offering a key where the start of the key
> matches a partial key at the end of the last login
> PDU.
>
> 3. Yes, we noticed a little while ago that losing a
> packet at the end of negotiation could hang things up
> though the concern is mainly for a full feature phase
> negotiation. Looking at 6.8, any timeout during
> negotiation causes the login and its TCP connection to
> be terminated. The whole negotiation process (see the
> point about origninators in 2) depends upon a one-by-one
> exchange of PDUs. PDU loss has to terminate it.
>
> Therefore, the target commits to the end of login
> as described for T5 target. It has sent the final
> login response with a status of zero. Moves to S5.
> If the login response doesn't get to the initiator,
> then either the initiator will close the connection
> due to the timeout. Since the target is in S4, loss
> of the transport connection will cause it to go to
> S8 and R1 of the cleanup state machine. It presumably
> will not take the M2 transition because the intiator
> isn't going to do cleanup for a connection it thinks
> wasn't in full feature phase. It will take M1 due to
> timeout - not elegant but good enough.
>
> The concern was Full Feature Phase negotation. Until
> negotiation ends, it can be reset and no values change.
> When the target sends the last Text Response PDU, then
> it thinks negotiation has ended and it applies the
> new values. If that PDU doesn't reach the initiatior,
> then it terminates the entire negotiation and continues
> to use the old values. The two ends are using different
> values.
>
> We decided to not raise this as an issue because it is
> such a corner case - we are operating over a reliable
> connection so PDUs shouldn't be lost (unless the whole
> path goes down in which case it doesn't matter). Also,
> there are few values exchanged during full feature so
> it isn't worthwhile to add complexity.
>
> Regards,
> Pat
>
>
> -----Original Message-----
> From: Martins Krikis [mailto:mkrikis@yahoo.com]
> Sent: Friday, May 24, 2002 12:39 PM
> To: Julian Satran
> Cc: ips@ece.cmu.edu
> Subject: iSCSI: Negotiation clarifications still needed
>
>
> The previous thread went on too long, but since it
> has now quieted down, I'll conjecture that the
> following are the aspects that still need to be
> addressed.
>
> 1. Not everybody seemed to have noticed that it is
>    NOT legal to send the same key again, if it
>    has once been negotiated (including negotiations
>    that end with a reserved value (Reject,
>    Irrelevant or NotUnderstood).
>
> I think it would benefit the draft to add the
> sentence that Pat proposed to paragraph 5 or page
> 72 in 12-92: "Sending the key again would be a
> re-negotiation". That I think would make it crystal
> clear.
>
> 2. When the key=value pairs that Originator is
>    sending are broken across multiple PDUs, it
>    is not clear whether the Responder may start
>    responding to the keys as soon as it receives
>    them or whether it should send blank PDUs back
>    (as in the example on page 164 of 12-92) until
>    it gets a PDU, the data part of which ends in
>    a NUL byte (thus signaling that there are no
>    broken key=value pairs at the end of it).
>
> I am proposing that the draft should make it explicit
> that only blank PDUs are to be sent. This allows
> decoupling of key=value generation from
> their encapsulation in PDUs (i.e., the generating
> logic need not worry about whether a key=value
> pair will fit and go out in this PDU or has to
> be retained to go out in the next). I can explain
> in detail why this is important (it has to do
> with teh possibility of receiving the "just-about
> outgoing" keys) but I'm keeping this "brief".
>
> Furthermore, it is my feeling that instead of
> checking the last bytes of a PDU for NUL, it
> would be better if the end-of-data was marked by
> a flag in the header. This way encapsulation will
> be simpler---just put as much data in the PDU as
> fits there and raise the flag if it isn't all,
> instead of checking whether it ends in a NUL and
> possibly shortening data to make it not end like
> that.
>
> 3. There is an opinion that on page 73 of 12-92,
>    the phrase that says "or the responder may
>    select an admissible value" is in contradiction
>    to the very next sentence. There is also an
>    opinion that this phrase is entirely unnecessary
>    and detrimental to achieving broad
>    interoperability (I call it "cutting slack to
>    misbehaving or incompatible originators").
>
> I don't have a suggestion since I consider the
> "feature" that this phrase allows of little
> importance to a properly built iSCSI node.
>
> 4. This is new. When doing Text Request/Response
> negotiations (i.e., in FFP), it seems
> that the Initiator commits to the new values
> when it receives a response from the Target with
> the F bit set. It is unclear when the Target should
> commit. Should it switch to using the new values
> as soon as it sends its response with the F-bit
> set, or should it do so only when it knows that
> the Initiator received its response?
>
> Commiting right away is simpler and since responses
> with F-bits set have TTT=0xffffffff and thus
> may not be reset, sounds plausible. If the
> values have importance on the next reception,
> it may also be important to commit timely. However,
> what if the Initiator doesn't get this response?
> Target now has committed, Initiator hasn't. Committing
> later puts the burden on Initiator to send something
> effectively telling "I've received your final
> response". Otherwise the Target will time out and
> not commit. This response can get lost too.
>
> Basically, it is beginning to look a bit like
> (what was it called?) "distributed consensus problem"?
> I think it goes like this:
>
> Two generals that are on oposite sides of the
> enemy want to synchronize their attack, and
> start sending messengers through with messages
> like
>   "attack at dawn->",
>   "<-ok, attack at dawn",
>   "I know you know we attack at dawn->",
>   "<-, I know you know I know we attack at dawn",
>   etc., etc., ...
> But at no point can they commit yet...
>
> Is anybody else worried about this?
> Anyway, so when should a target commit? Page 83
> of 12-92 is the relevant reference.
>
> Thanks,
>
>   Martins Krikis
>
> Disclaimer: these opinions are my own and may
>             not be those of my employer.
>
>
> __________________________________________________
> Do You Yahoo!?
> LAUNCH - Your Yahoo! Music Experience
> http://launch.yahoo.com
>
>
>

--=_alternative 006A5B4FC2256BC7_=-- From owner-ips@ece.cmu.edu Tue May 28 16:02:46 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29435 for ; Tue, 28 May 2002 16:02:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SJ2xU04280 for ips-outgoing; Tue, 28 May 2002 15:02:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SJ2tw04267 for ; Tue, 28 May 2002 15:02:56 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id 0EA0A600B04; Tue, 28 May 2002 12:02:50 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA19617; Tue, 28 May 2002 12:04:37 -0700 (PDT) Message-ID: <00bd01c2067a$4243edc0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , "Julian Satran" Cc: , References: Subject: Re: iSCSI: Negotiation clarifications still needed Date: Tue, 28 May 2002 12:02:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I generally agree with the intent of the wording. A couple of comments - - I assume you meant "text-value of a received key-name" by "key text" (the only occurrence of "key text" is here). I suggest we use the definitions on pages 68 & 69. [ This is somewhat unrelated. But with the advent of formal terminology now, I'd actually recommend that we replace all "key=value" usages in the text with "key-name=text-value".] - IMHO (if my above assumption is true), the proposed rule is overly constraining. o The originator would only have to refrain from originating new keys if a partial *key-name* is received. IOW, doesn't have to wait for the entire text-value to arrive (though it may). o The "no incomplete key text" should not imply that the responder is also forbidden from responding to other (complete) text-value offers that it had already received. As a pathological case, if every PDU begins from the middle of one text-value and concludes in the middle of the next text-value, the responder should not be required to sit out until all the proposals are received in full (though it may). Here's a strawman with some wordsmithing. Key=value pairs may span PDU boundaries. A responder having a received partial key-name or not received the following "=" in a PDU MUST refrain from originating any new key=value negotiations until it had received the key-name in full and the following "=" . In this case, the receiving entity can only assume the role of a responder for this key. This way one avoids having both negotiating entities assuming the originator role in a negotiation. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Cc: ; Sent: Friday, May 24, 2002 10:26 PM Subject: RE: iSCSI: Negotiation clarifications still needed > Pat your proposed 2b may be what we are looking for - i.e. a responder may > not originate a key if it has an incomplete key text. > > The text we may want to add to section 4.2 is: > > Key=value pairs may span PDU boundaries. A responder having a received > partial key text MUST refrain from originating any new key=value > negotiations until it has no incomplete key text. This way one avoids > having both negotiating entities assuming the originator role in a > negotiation. > > > Julo > > > > > pat_thaler@agilent.com > 05/25/2002 12:16 AM > Please respond to pat_thaler > > > To: mkrikis@yahoo.com, Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: Negotiation clarifications still needed > > > > Martins, > > Comments referenced by the same items Martins used. > > 1. Julian sent an email saying he would put the text > I proposed in (though the text you quoted is not the > whole text). > > 2. I think that the principle we have been using on > text negotiation was that each key negotion is a > separate item. Your proposal would be counter to that > and I don't think it would be an improvement. The > target should be allowed to respond to any complete > key-value pair it has received. When a key-value > pair is straddling the PDU bondary, then it shouldn't > respond to that key until the complete key-value pair > has been received. > > There is one potential corner case issue that should > to be covered. Targets can initiate keys. If key-value > pairs didn't straddle PDU boundaries, then ensuring > that there is a clear originator for each offered key > is easy. You can originate any key that you haven't > received an offer of from your partner. But now keys > can straddle PDUs. If the text between the last separater > and the end of the PDU is Ma, then you don't know what > key your partner has started to offer. If the partner > was starting to offer MaxBurstSize and you offer it in > the next PDU of the exchange, both sides may think they > are originator. > > I suggest one of the following > a) don't allow keys to straddle PDU boundaries. > b) don't allow originating a key when the last login > PDU ended in a partial key. > c) don't allow offering a key where the start of the key > matches a partial key at the end of the last login > PDU. > > 3. Yes, we noticed a little while ago that losing a > packet at the end of negotiation could hang things up > though the concern is mainly for a full feature phase > negotiation. Looking at 6.8, any timeout during > negotiation causes the login and its TCP connection to > be terminated. The whole negotiation process (see the > point about origninators in 2) depends upon a one-by-one > exchange of PDUs. PDU loss has to terminate it. > > Therefore, the target commits to the end of login > as described for T5 target. It has sent the final > login response with a status of zero. Moves to S5. > If the login response doesn't get to the initiator, > then either the initiator will close the connection > due to the timeout. Since the target is in S4, loss > of the transport connection will cause it to go to > S8 and R1 of the cleanup state machine. It presumably > will not take the M2 transition because the intiator > isn't going to do cleanup for a connection it thinks > wasn't in full feature phase. It will take M1 due to > timeout - not elegant but good enough. > > The concern was Full Feature Phase negotation. Until > negotiation ends, it can be reset and no values change. > When the target sends the last Text Response PDU, then > it thinks negotiation has ended and it applies the > new values. If that PDU doesn't reach the initiatior, > then it terminates the entire negotiation and continues > to use the old values. The two ends are using different > values. > > We decided to not raise this as an issue because it is > such a corner case - we are operating over a reliable > connection so PDUs shouldn't be lost (unless the whole > path goes down in which case it doesn't matter). Also, > there are few values exchanged during full feature so > it isn't worthwhile to add complexity. > > Regards, > Pat > > > -----Original Message----- > From: Martins Krikis [mailto:mkrikis@yahoo.com] > Sent: Friday, May 24, 2002 12:39 PM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: iSCSI: Negotiation clarifications still needed > > > The previous thread went on too long, but since it > has now quieted down, I'll conjecture that the > following are the aspects that still need to be > addressed. > > 1. Not everybody seemed to have noticed that it is > NOT legal to send the same key again, if it > has once been negotiated (including negotiations > that end with a reserved value (Reject, > Irrelevant or NotUnderstood). > > I think it would benefit the draft to add the > sentence that Pat proposed to paragraph 5 or page > 72 in 12-92: "Sending the key again would be a > re-negotiation". That I think would make it crystal > clear. > > 2. When the key=value pairs that Originator is > sending are broken across multiple PDUs, it > is not clear whether the Responder may start > responding to the keys as soon as it receives > them or whether it should send blank PDUs back > (as in the example on page 164 of 12-92) until > it gets a PDU, the data part of which ends in > a NUL byte (thus signaling that there are no > broken key=value pairs at the end of it). > > I am proposing that the draft should make it explicit > that only blank PDUs are to be sent. This allows > decoupling of key=value generation from > their encapsulation in PDUs (i.e., the generating > logic need not worry about whether a key=value > pair will fit and go out in this PDU or has to > be retained to go out in the next). I can explain > in detail why this is important (it has to do > with teh possibility of receiving the "just-about > outgoing" keys) but I'm keeping this "brief". > > Furthermore, it is my feeling that instead of > checking the last bytes of a PDU for NUL, it > would be better if the end-of-data was marked by > a flag in the header. This way encapsulation will > be simpler---just put as much data in the PDU as > fits there and raise the flag if it isn't all, > instead of checking whether it ends in a NUL and > possibly shortening data to make it not end like > that. > > 3. There is an opinion that on page 73 of 12-92, > the phrase that says "or the responder may > select an admissible value" is in contradiction > to the very next sentence. There is also an > opinion that this phrase is entirely unnecessary > and detrimental to achieving broad > interoperability (I call it "cutting slack to > misbehaving or incompatible originators"). > > I don't have a suggestion since I consider the > "feature" that this phrase allows of little > importance to a properly built iSCSI node. > > 4. This is new. When doing Text Request/Response > negotiations (i.e., in FFP), it seems > that the Initiator commits to the new values > when it receives a response from the Target with > the F bit set. It is unclear when the Target should > commit. Should it switch to using the new values > as soon as it sends its response with the F-bit > set, or should it do so only when it knows that > the Initiator received its response? > > Commiting right away is simpler and since responses > with F-bits set have TTT=0xffffffff and thus > may not be reset, sounds plausible. If the > values have importance on the next reception, > it may also be important to commit timely. However, > what if the Initiator doesn't get this response? > Target now has committed, Initiator hasn't. Committing > later puts the burden on Initiator to send something > effectively telling "I've received your final > response". Otherwise the Target will time out and > not commit. This response can get lost too. > > Basically, it is beginning to look a bit like > (what was it called?) "distributed consensus problem"? > I think it goes like this: > > Two generals that are on oposite sides of the > enemy want to synchronize their attack, and > start sending messengers through with messages > like > "attack at dawn->", > "<-ok, attack at dawn", > "I know you know we attack at dawn->", > "<-, I know you know I know we attack at dawn", > etc., etc., ... > But at no point can they commit yet... > > Is anybody else worried about this? > Anyway, so when should a target commit? Page 83 > of 12-92 is the relevant reference. > > Thanks, > > Martins Krikis > > Disclaimer: these opinions are my own and may > not be those of my employer. > > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > > > From owner-ips@ece.cmu.edu Tue May 28 16:52:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00869 for ; Tue, 28 May 2002 16:52:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SKKHl10495 for ips-outgoing; Tue, 28 May 2002 16:20:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SKKEw10483 for ; Tue, 28 May 2002 16:20:14 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 0DACECC62; Tue, 28 May 2002 14:20:14 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 6404B135; Tue, 28 May 2002 14:20:13 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 14:20:04 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 14:20:03 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09D55D@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, cbm@rose.hp.com Cc: ips@ece.cmu.edu, mkrikis@yahoo.com Subject: RE: iSCSI: Negotiation clarifications still needed Date: Tue, 28 May 2002 14:19:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-76321f87-348c-4ebc-bc14-aed7789d0735" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-76321f87-348c-4ebc-bc14-aed7789d0735 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20685.0A3D4600" ------_=_NextPart_001_01C20685.0A3D4600 Content-Type: text/plain; charset="iso-8859-1" Julian, Thinking about the subject of long keys and short PDUs, I realized that all keys are either: Not allowed in full feature phase; Sorter than 512 (the minimum size of maxRecvPDUlengt); or Declartive. In security negotiation and login negotiation the default of 8196 is used for PDU size so very short PDUs do not affect those keys that are not allowed in full feature phase. If one was willing to check that a key-value string would fit in the PDU before commiting to start it in the PDU, then there is no need to allow non-declaritive key-value pairs to span PDUs. Declaritive key-value pairs can span PDUs because they don't enter into the decision on what keys can be originated by the other side. One might still allow non-declaritive key-value pairs to straddle PDU boundaries because one doesn't want to check that the next key-value fits in the PDU before starting to place it there or because one doesn't want the rule to be different for declaritive and non-declaritive PDUs but I don't think that decision is forced upon us by very short PDUs. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, May 24, 2002 10:10 PM To: Mallikarjun C. Cc: ips@ece.cmu.edu; Martins Krikis Subject: Re: iSCSI: Negotiation clarifications still needed I agree with Mallikarjun on all but one point - requiring a key not to straddle PDU boundaries. This list had a long debate on the subject. We thought (initially) that not having any pair straddle PD boundaries is the best thing to do and we had it untill it became obvious that we have to support very short PDUs. The we went for allowing spanning and the scheme we had in mind was a sender preparing its strings and chopping them into PDUs without any parsing and state. What you suggest now is parsing at send and that may add unnecessary complexity - and I really don't see why. Julo "Mallikarjun C." 05/25/2002 02:49 AM Please respond to "Mallikarjun C." To: "Martins Krikis" , Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: iSCSI: Negotiation clarifications still needed Martins, Comments in the same order. 1. Julian may be adding wording for this. 2. Seems to me that we need to stipulate that only key values may straddle PDU boundaries - key names (ideally inclusive of "=") shall not. That should avoid requiring blank PDUs. 3. I don't have a strong opinion on this. I don't believe this can cause interoperability problems; OTOH, I don't care if the responder isn't that liberal. 4. Julian and I discussed this scenario a while ago. As you precisely described, only a non-stop dialogue can be reliable and we can't afford a non-stop dialogue. I suppose one can recover the StatSN with a SNACK in FFP, or terminate the connection upon a timeout. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Martins Krikis" To: "Julian Satran" Cc: Sent: Friday, May 24, 2002 12:38 PM Subject: iSCSI: Negotiation clarifications still needed > The previous thread went on too long, but since it > has now quieted down, I'll conjecture that the > following are the aspects that still need to be > addressed. > > 1. Not everybody seemed to have noticed that it is > NOT legal to send the same key again, if it > has once been negotiated (including negotiations > that end with a reserved value (Reject, > Irrelevant or NotUnderstood). > > I think it would benefit the draft to add the > sentence that Pat proposed to paragraph 5 or page > 72 in 12-92: "Sending the key again would be a > re-negotiation". That I think would make it crystal > clear. > > 2. When the key=value pairs that Originator is > sending are broken across multiple PDUs, it > is not clear whether the Responder may start > responding to the keys as soon as it receives > them or whether it should send blank PDUs back > (as in the example on page 164 of 12-92) until > it gets a PDU, the data part of which ends in > a NUL byte (thus signaling that there are no > broken key=value pairs at the end of it). > > I am proposing that the draft should make it explicit > that only blank PDUs are to be sent. This allows > decoupling of key=value generation from > their encapsulation in PDUs (i.e., the generating > logic need not worry about whether a key=value > pair will fit and go out in this PDU or has to > be retained to go out in the next). I can explain > in detail why this is important (it has to do > with teh possibility of receiving the "just-about > outgoing" keys) but I'm keeping this "brief". > > Furthermore, it is my feeling that instead of > checking the last bytes of a PDU for NUL, it > would be better if the end-of-data was marked by > a flag in the header. This way encapsulation will > be simpler---just put as much data in the PDU as > fits there and raise the flag if it isn't all, > instead of checking whether it ends in a NUL and > possibly shortening data to make it not end like > that. > > 3. There is an opinion that on page 73 of 12-92, > the phrase that says "or the responder may > select an admissible value" is in contradiction > to the very next sentence. There is also an > opinion that this phrase is entirely unnecessary > and detrimental to achieving broad > interoperability (I call it "cutting slack to > misbehaving or incompatible originators"). > > I don't have a suggestion since I consider the > "feature" that this phrase allows of little > importance to a properly built iSCSI node. > > 4. This is new. When doing Text Request/Response > negotiations (i.e., in FFP), it seems > that the Initiator commits to the new values > when it receives a response from the Target with > the F bit set. It is unclear when the Target should > commit. Should it switch to using the new values > as soon as it sends its response with the F-bit > set, or should it do so only when it knows that > the Initiator received its response? > > Commiting right away is simpler and since responses > with F-bits set have TTT=0xffffffff and thus > may not be reset, sounds plausible. If the > values have importance on the next reception, > it may also be important to commit timely. However, > what if the Initiator doesn't get this response? > Target now has committed, Initiator hasn't. Committing > later puts the burden on Initiator to send something > effectively telling "I've received your final > response". Otherwise the Target will time out and > not commit. This response can get lost too. > > Basically, it is beginning to look a bit like > (what was it called?) "distributed consensus problem"? > I think it goes like this: > > Two generals that are on oposite sides of the > enemy want to synchronize their attack, and > start sending messengers through with messages > like > "attack at dawn->", > "<-ok, attack at dawn", > "I know you know we attack at dawn->", > "<-, I know you know I know we attack at dawn", > etc., etc., ... > But at no point can they commit yet... > > Is anybody else worried about this? > Anyway, so when should a target commit? Page 83 > of 12-92 is the relevant reference. > > Thanks, > > Martins Krikis > > Disclaimer: these opinions are my own and may > not be those of my employer. > > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > ------_=_NextPart_001_01C20685.0A3D4600 Content-Type: text/html; charset="iso-8859-1"
 
Julian,
 
Thinking about the subject of long keys and short PDUs, I realized that all keys are either:
 
Not allowed in full feature phase;
Sorter than 512 (the minimum size of maxRecvPDUlengt); or
Declartive.
 
In security negotiation and login negotiation the default of 8196 is used for PDU size so
very short PDUs do not affect those keys that are not allowed in full feature phase.
 
If one was willing to check that a key-value string would fit in the PDU before commiting
to start it in the PDU, then there is no need to allow non-declaritive key-value pairs to span
PDUs. Declaritive key-value pairs can span PDUs because they don't enter into the decision
on what keys can be originated by the other side. 
 
One might still allow non-declaritive key-value pairs to straddle PDU boundaries because
one doesn't want to check that the next key-value fits in the PDU before starting to place it there
or because one doesn't want the rule to be different for declaritive and non-declaritive PDUs but
I don't think that decision is forced upon us by very short PDUs.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, May 24, 2002 10:10 PM
To: Mallikarjun C.
Cc: ips@ece.cmu.edu; Martins Krikis
Subject: Re: iSCSI: Negotiation clarifications still needed


I agree with Mallikarjun on all but one point - requiring a key not to straddle PDU boundaries.
This list had a long debate on the subject. We thought (initially) that not having any pair straddle PD boundaries is the best thing to do and we had it untill it became obvious that we have to support very short PDUs.
The we went for allowing spanning and the scheme we had in  mind was a sender preparing its strings and chopping them into PDUs without any parsing and state. What you suggest now is parsing at send and that may add unnecessary complexity - and I really don't see why.

Julo


"Mallikarjun C." <cbm@rose.hp.com>

05/25/2002 02:49 AM
Please respond to "Mallikarjun C."

       
        To:        "Martins Krikis" <mkrikis@yahoo.com>, Julian Satran/Haifa/IBM@IBMIL
        cc:        <ips@ece.cmu.edu>
        Subject:        Re: iSCSI: Negotiation clarifications still needed

       


Martins,

Comments in the same order.

1. Julian may be adding wording for this.

2. Seems to me that we need to stipulate that only key values
   may straddle PDU boundaries - key names (ideally inclusive
   of "=") shall not.  That should avoid requiring blank PDUs.

3. I don't have a strong opinion on this.  I don't believe this can
   cause interoperability problems; OTOH, I don't care if the responder
   isn't that liberal.

4. Julian and I discussed this scenario a while ago.  As you precisely
   described, only a non-stop dialogue can be reliable and we can't
   afford a non-stop dialogue.  I suppose one can recover the StatSN
   with a SNACK in FFP, or terminate the connection upon a timeout.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com


----- Original Message -----
From: "Martins Krikis" <mkrikis@yahoo.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, May 24, 2002 12:38 PM
Subject: iSCSI: Negotiation clarifications still needed


> The previous thread went on too long, but since it
> has now quieted down, I'll conjecture that the
> following are the aspects that still need to be
> addressed.
>
> 1. Not everybody seemed to have noticed that it is
>    NOT legal to send the same key again, if it
>    has once been negotiated (including negotiations
>    that end with a reserved value (Reject,
>    Irrelevant or NotUnderstood).
>
> I think it would benefit the draft to add the
> sentence that Pat proposed to paragraph 5 or page
> 72 in 12-92: "Sending the key again would be a
> re-negotiation". That I think would make it crystal
> clear.
>
> 2. When the key=value pairs that Originator is
>    sending are broken across multiple PDUs, it
>    is not clear whether the Responder may start
>    responding to the keys as soon as it receives
>    them or whether it should send blank PDUs back
>    (as in the example on page 164 of 12-92) until
>    it gets a PDU, the data part of which ends in
>    a NUL byte (thus signaling that there are no
>    broken key=value pairs at the end of it).
>
> I am proposing that the draft should make it explicit
> that only blank PDUs are to be sent. This allows
> decoupling of key=value generation from
> their encapsulation in PDUs (i.e., the generating
> logic need not worry about whether a key=value
> pair will fit and go out in this PDU or has to
> be retained to go out in the next). I can explain
> in detail why this is important (it has to do
> with teh possibility of receiving the "just-about
> outgoing" keys) but I'm keeping this "brief".
>
> Furthermore, it is my feeling that instead of
> checking the last bytes of a PDU for NUL, it
> would be better if the end-of-data was marked by
> a flag in the header. This way encapsulation will
> be simpler---just put as much data in the PDU as
> fits there and raise the flag if it isn't all,
> instead of checking whether it ends in a NUL and
> possibly shortening data to make it not end like
> that.
>
> 3. There is an opinion that on page 73 of 12-92,
>    the phrase that says "or the responder may
>    select an admissible value" is in contradiction
>    to the very next sentence. There is also an
>    opinion that this phrase is entirely unnecessary
>    and detrimental to achieving broad
>    interoperability (I call it "cutting slack to
>    misbehaving or incompatible originators").
>
> I don't have a suggestion since I consider the
> "feature" that this phrase allows of little
> importance to a properly built iSCSI node.
>
> 4. This is new. When doing Text Request/Response
> negotiations (i.e., in FFP), it seems
> that the Initiator commits to the new values
> when it receives a response from the Target with
> the F bit set. It is unclear when the Target should
> commit. Should it switch to using the new values
> as soon as it sends its response with the F-bit
> set, or should it do so only when it knows that
> the Initiator received its response?
>
> Commiting right away is simpler and since responses
> with F-bits set have TTT=0xffffffff and thus
> may not be reset, sounds plausible. If the
> values have importance on the next reception,
> it may also be important to commit timely. However,
> what if the Initiator doesn't get this response?
> Target now has committed, Initiator hasn't. Committing
> later puts the burden on Initiator to send something
> effectively telling "I've received your final
> response". Otherwise the Target will time out and
> not commit. This response can get lost too.
>
> Basically, it is beginning to look a bit like
> (what was it called?) "distributed consensus problem"?
> I think it goes like this:
>
> Two generals that are on oposite sides of the
> enemy want to synchronize their attack, and
> start sending messengers through with messages
> like
>   "attack at dawn->",
>   "<-ok, attack at dawn",
>   "I know you know we attack at dawn->",
>   "<-, I know you know I know we attack at dawn",
>   etc., etc., ...
> But at no point can they commit yet...
>
> Is anybody else worried about this?
> Anyway, so when should a target commit? Page 83
> of 12-92 is the relevant reference.
>
> Thanks,
>
>   Martins Krikis
>
> Disclaimer: these opinions are my own and may
>             not be those of my employer.
>
>
> __________________________________________________
> Do You Yahoo!?
> LAUNCH - Your Yahoo! Music Experience
> http://launch.yahoo.com
>



------_=_NextPart_001_01C20685.0A3D4600-- ------=_NextPartTM-000-76321f87-348c-4ebc-bc14-aed7789d0735-- From owner-ips@ece.cmu.edu Tue May 28 16:59:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01042 for ; Tue, 28 May 2002 16:59:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SJrbW08295 for ips-outgoing; Tue, 28 May 2002 15:53:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SJrZw08288 for ; Tue, 28 May 2002 15:53:35 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 488A0C6C0; Tue, 28 May 2002 13:53:31 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 06979492; Tue, 28 May 2002 13:53:31 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 13:53:28 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 13:53:28 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09D54C@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Julian Satran , "Mallikarjun C." Cc: ips@ece.cmu.edu, Martins Krikis Subject: RE: iSCSI: Negotiation clarifications still needed Date: Tue, 28 May 2002 13:53:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-abad9ebe-7258-11d6-ac7e-009027aa5b50" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-abad9ebe-7258-11d6-ac7e-009027aa5b50 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20681.540F1E60" ------_=_NextPart_001_01C20681.540F1E60 Content-Type: text/plain; charset="iso-8859-1" Julian, The sender cannot do exactly what you describe. It cannot prepare a string of key-value pairs then chop them into PDUs to send because the response to the first PDUs may contain offers of keys that were not sent in the first PDU. The sender could: prepare key-value pairs and put them into a PDU until the PDU overflowed, send that PDU wait to receive a negotiation PDU form the next PDU starting with any overflowed tail from the last PDU followed by responses and any new offers until that PDU overflows repeat until done Or the sender could do the following which seems rather awkward to implement: prepare a complete string of all the key-value pairs it wants to offer send the first PDU worth of that string wait to receive a negotiation PDU search the string for any keys were offered in the received PDU and remove them or change them to responses to the offers repeat until done Because of the request-response nature of negotiation plus the flexibility of allowing either side to make an offer plus the simplification that a negotiation is at most one offer and one response, the negotiation has to be PDU boundary aware. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, May 24, 2002 10:10 PM To: Mallikarjun C. Cc: ips@ece.cmu.edu; Martins Krikis Subject: Re: iSCSI: Negotiation clarifications still needed I agree with Mallikarjun on all but one point - requiring a key not to straddle PDU boundaries. This list had a long debate on the subject. We thought (initially) that not having any pair straddle PD boundaries is the best thing to do and we had it untill it became obvious that we have to support very short PDUs. The we went for allowing spanning and the scheme we had in mind was a sender preparing its strings and chopping them into PDUs without any parsing and state. What you suggest now is parsing at send and that may add unnecessary complexity - and I really don't see why. Julo "Mallikarjun C." 05/25/2002 02:49 AM Please respond to "Mallikarjun C." To: "Martins Krikis" , Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: iSCSI: Negotiation clarifications still needed Martins, Comments in the same order. 1. Julian may be adding wording for this. 2. Seems to me that we need to stipulate that only key values may straddle PDU boundaries - key names (ideally inclusive of "=") shall not. That should avoid requiring blank PDUs. 3. I don't have a strong opinion on this. I don't believe this can cause interoperability problems; OTOH, I don't care if the responder isn't that liberal. 4. Julian and I discussed this scenario a while ago. As you precisely described, only a non-stop dialogue can be reliable and we can't afford a non-stop dialogue. I suppose one can recover the StatSN with a SNACK in FFP, or terminate the connection upon a timeout. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Martins Krikis" To: "Julian Satran" Cc: Sent: Friday, May 24, 2002 12:38 PM Subject: iSCSI: Negotiation clarifications still needed > The previous thread went on too long, but since it > has now quieted down, I'll conjecture that the > following are the aspects that still need to be > addressed. > > 1. Not everybody seemed to have noticed that it is > NOT legal to send the same key again, if it > has once been negotiated (including negotiations > that end with a reserved value (Reject, > Irrelevant or NotUnderstood). > > I think it would benefit the draft to add the > sentence that Pat proposed to paragraph 5 or page > 72 in 12-92: "Sending the key again would be a > re-negotiation". That I think would make it crystal > clear. > > 2. When the key=value pairs that Originator is > sending are broken across multiple PDUs, it > is not clear whether the Responder may start > responding to the keys as soon as it receives > them or whether it should send blank PDUs back > (as in the example on page 164 of 12-92) until > it gets a PDU, the data part of which ends in > a NUL byte (thus signaling that there are no > broken key=value pairs at the end of it). > > I am proposing that the draft should make it explicit > that only blank PDUs are to be sent. This allows > decoupling of key=value generation from > their encapsulation in PDUs (i.e., the generating > logic need not worry about whether a key=value > pair will fit and go out in this PDU or has to > be retained to go out in the next). I can explain > in detail why this is important (it has to do > with teh possibility of receiving the "just-about > outgoing" keys) but I'm keeping this "brief". > > Furthermore, it is my feeling that instead of > checking the last bytes of a PDU for NUL, it > would be better if the end-of-data was marked by > a flag in the header. This way encapsulation will > be simpler---just put as much data in the PDU as > fits there and raise the flag if it isn't all, > instead of checking whether it ends in a NUL and > possibly shortening data to make it not end like > that. > > 3. There is an opinion that on page 73 of 12-92, > the phrase that says "or the responder may > select an admissible value" is in contradiction > to the very next sentence. There is also an > opinion that this phrase is entirely unnecessary > and detrimental to achieving broad > interoperability (I call it "cutting slack to > misbehaving or incompatible originators"). > > I don't have a suggestion since I consider the > "feature" that this phrase allows of little > importance to a properly built iSCSI node. > > 4. This is new. When doing Text Request/Response > negotiations (i.e., in FFP), it seems > that the Initiator commits to the new values > when it receives a response from the Target with > the F bit set. It is unclear when the Target should > commit. Should it switch to using the new values > as soon as it sends its response with the F-bit > set, or should it do so only when it knows that > the Initiator received its response? > > Commiting right away is simpler and since responses > with F-bits set have TTT=0xffffffff and thus > may not be reset, sounds plausible. If the > values have importance on the next reception, > it may also be important to commit timely. However, > what if the Initiator doesn't get this response? > Target now has committed, Initiator hasn't. Committing > later puts the burden on Initiator to send something > effectively telling "I've received your final > response". Otherwise the Target will time out and > not commit. This response can get lost too. > > Basically, it is beginning to look a bit like > (what was it called?) "distributed consensus problem"? > I think it goes like this: > > Two generals that are on oposite sides of the > enemy want to synchronize their attack, and > start sending messengers through with messages > like > "attack at dawn->", > "<-ok, attack at dawn", > "I know you know we attack at dawn->", > "<-, I know you know I know we attack at dawn", > etc., etc., ... > But at no point can they commit yet... > > Is anybody else worried about this? > Anyway, so when should a target commit? Page 83 > of 12-92 is the relevant reference. > > Thanks, > > Martins Krikis > > Disclaimer: these opinions are my own and may > not be those of my employer. > > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > ------_=_NextPart_001_01C20681.540F1E60 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
The sender cannot do exactly what you describe. It cannot prepare a string of
key-value pairs then chop them into PDUs to send because the response to
the first PDUs may contain offers of keys that were not sent in the first PDU.
 
The sender could:
prepare key-value pairs and put them into a PDU until the PDU overflowed,
send that PDU
wait to receive a negotiation PDU
form the next PDU starting with any overflowed tail from the last PDU
  followed by responses and any new offers until that PDU overflows
repeat until done
 
Or the sender could do the following which seems rather awkward to implement:
prepare a complete string of all the key-value pairs it wants to offer
send the first PDU worth of that string
wait to receive a negotiation PDU
search the string for any keys were offered in the received PDU and
  remove them or change them to responses to the offers
repeat until done
 
Because of the request-response nature of negotiation plus the
flexibility of allowing either side to make an offer plus the simplification
that a negotiation is at most one offer and one response, the negotiation
has to be PDU boundary aware.
 
Pat
 
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, May 24, 2002 10:10 PM
To: Mallikarjun C.
Cc: ips@ece.cmu.edu; Martins Krikis
Subject: Re: iSCSI: Negotiation clarifications still needed


I agree with Mallikarjun on all but one point - requiring a key not to straddle PDU boundaries.
This list had a long debate on the subject. We thought (initially) that not having any pair straddle PD boundaries is the best thing to do and we had it untill it became obvious that we have to support very short PDUs.
The we went for allowing spanning and the scheme we had in  mind was a sender preparing its strings and chopping them into PDUs without any parsing and state. What you suggest now is parsing at send and that may add unnecessary complexity - and I really don't see why.

Julo


"Mallikarjun C." <cbm@rose.hp.com>

05/25/2002 02:49 AM
Please respond to "Mallikarjun C."

       
        To:        "Martins Krikis" <mkrikis@yahoo.com>, Julian Satran/Haifa/IBM@IBMIL
        cc:        <ips@ece.cmu.edu>
        Subject:        Re: iSCSI: Negotiation clarifications still needed

       


Martins,

Comments in the same order.

1. Julian may be adding wording for this.

2. Seems to me that we need to stipulate that only key values
   may straddle PDU boundaries - key names (ideally inclusive
   of "=") shall not.  That should avoid requiring blank PDUs.

3. I don't have a strong opinion on this.  I don't believe this can
   cause interoperability problems; OTOH, I don't care if the responder
   isn't that liberal.

4. Julian and I discussed this scenario a while ago.  As you precisely
   described, only a non-stop dialogue can be reliable and we can't
   afford a non-stop dialogue.  I suppose one can recover the StatSN
   with a SNACK in FFP, or terminate the connection upon a timeout.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com


----- Original Message -----
From: "Martins Krikis" <mkrikis@yahoo.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, May 24, 2002 12:38 PM
Subject: iSCSI: Negotiation clarifications still needed


> The previous thread went on too long, but since it
> has now quieted down, I'll conjecture that the
> following are the aspects that still need to be
> addressed.
>
> 1. Not everybody seemed to have noticed that it is
>    NOT legal to send the same key again, if it
>    has once been negotiated (including negotiations
>    that end with a reserved value (Reject,
>    Irrelevant or NotUnderstood).
>
> I think it would benefit the draft to add the
> sentence that Pat proposed to paragraph 5 or page
> 72 in 12-92: "Sending the key again would be a
> re-negotiation". That I think would make it crystal
> clear.
>
> 2. When the key=value pairs that Originator is
>    sending are broken across multiple PDUs, it
>    is not clear whether the Responder may start
>    responding to the keys as soon as it receives
>    them or whether it should send blank PDUs back
>    (as in the example on page 164 of 12-92) until
>    it gets a PDU, the data part of which ends in
>    a NUL byte (thus signaling that there are no
>    broken key=value pairs at the end of it).
>
> I am proposing that the draft should make it explicit
> that only blank PDUs are to be sent. This allows
> decoupling of key=value generation from
> their encapsulation in PDUs (i.e., the generating
> logic need not worry about whether a key=value
> pair will fit and go out in this PDU or has to
> be retained to go out in the next). I can explain
> in detail why this is important (it has to do
> with teh possibility of receiving the "just-about
> outgoing" keys) but I'm keeping this "brief".
>
> Furthermore, it is my feeling that instead of
> checking the last bytes of a PDU for NUL, it
> would be better if the end-of-data was marked by
> a flag in the header. This way encapsulation will
> be simpler---just put as much data in the PDU as
> fits there and raise the flag if it isn't all,
> instead of checking whether it ends in a NUL and
> possibly shortening data to make it not end like
> that.
>
> 3. There is an opinion that on page 73 of 12-92,
>    the phrase that says "or the responder may
>    select an admissible value" is in contradiction
>    to the very next sentence. There is also an
>    opinion that this phrase is entirely unnecessary
>    and detrimental to achieving broad
>    interoperability (I call it "cutting slack to
>    misbehaving or incompatible originators").
>
> I don't have a suggestion since I consider the
> "feature" that this phrase allows of little
> importance to a properly built iSCSI node.
>
> 4. This is new. When doing Text Request/Response
> negotiations (i.e., in FFP), it seems
> that the Initiator commits to the new values
> when it receives a response from the Target with
> the F bit set. It is unclear when the Target should
> commit. Should it switch to using the new values
> as soon as it sends its response with the F-bit
> set, or should it do so only when it knows that
> the Initiator received its response?
>
> Commiting right away is simpler and since responses
> with F-bits set have TTT=0xffffffff and thus
> may not be reset, sounds plausible. If the
> values have importance on the next reception,
> it may also be important to commit timely. However,
> what if the Initiator doesn't get this response?
> Target now has committed, Initiator hasn't. Committing
> later puts the burden on Initiator to send something
> effectively telling "I've received your final
> response". Otherwise the Target will time out and
> not commit. This response can get lost too.
>
> Basically, it is beginning to look a bit like
> (what was it called?) "distributed consensus problem"?
> I think it goes like this:
>
> Two generals that are on oposite sides of the
> enemy want to synchronize their attack, and
> start sending messengers through with messages
> like
>   "attack at dawn->",
>   "<-ok, attack at dawn",
>   "I know you know we attack at dawn->",
>   "<-, I know you know I know we attack at dawn",
>   etc., etc., ...
> But at no point can they commit yet...
>
> Is anybody else worried about this?
> Anyway, so when should a target commit? Page 83
> of 12-92 is the relevant reference.
>
> Thanks,
>
>   Martins Krikis
>
> Disclaimer: these opinions are my own and may
>             not be those of my employer.
>
>
> __________________________________________________
> Do You Yahoo!?
> LAUNCH - Your Yahoo! Music Experience
> http://launch.yahoo.com
>



------_=_NextPart_001_01C20681.540F1E60-- ------=_NextPartTM-000-abad9ebe-7258-11d6-ac7e-009027aa5b50-- From owner-ips@ece.cmu.edu Tue May 28 17:35:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01799 for ; Tue, 28 May 2002 17:35:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SKsgO13439 for ips-outgoing; Tue, 28 May 2002 16:54:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SKsew13432 for ; Tue, 28 May 2002 16:54:40 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 0D5DF30706; Tue, 28 May 2002 16:54:40 -0400 (EDT) Date: Tue, 28 May 2002 13:52:43 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: , , Subject: RE: iSCSI: Negotiation clarifications still needed In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C09D519@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 28 May 2002 pat_thaler@agilent.com wrote: > Bill, > > I don't think that we need to prevent that case. If the initiatior chooses to > not initiate a key-value pair when it has received a partial key-value pair > (or a partial key) and it doesn't have any keys to respond to, then it can > continue the negotiation by sending a PDU with the tail of the partial key-value > that it sent. Even if it doesn't have a partial key-value to send it can send > a PDU with a blank text field. Either way, the target can then send another > PDU finishing its partial key-value. > > This isn't broken so we don't have to change it to make iSCSI robust. You are correct. Negotiations will continue, and login will converge. The concern is the target has to be more complex. While it can be done, the more complex things are, the harder it is to make them robust. This portion of the thread has been more, does everyone understand the complexity (amount of state) lurking in the current spec? If everyone does, then ok. Pat, I think you probably do. But some of the questions I've seen don't fill me with confidence that everyone does. Those comments are especially concerning given the, "let's get through last call" pressures some folks are applying. While getting through last-call is GOOD and IMPORTANT, it's also scarry to push into last-call a protocol with not-well-understood parts (i.e. hidden login complexity) in things folks think are well-understood. If the WG wants it this way, so be it. I look forward to seeing text in the next draft that better explains how PDU-spanning negotiations will work. Especially helpful would be sample algorythms, since I forsee this area is one that is easy to get wrong, and the current text is (obviously :-) not getting new readers onto the same page as the WG. :-) Take care, Bill From owner-ips@ece.cmu.edu Tue May 28 17:35:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01813 for ; Tue, 28 May 2002 17:35:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SKxMg13807 for ips-outgoing; Tue, 28 May 2002 16:59:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SKxKw13802 for ; Tue, 28 May 2002 16:59:20 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 16:59:19 -0400 Message-ID: From: Eddy Quicksall To: "julian_satran@il. ibm. com (E-mail)" Cc: "ips@ece. cmu. edu (E-mail)" Subject: iSCSI: digest diagram Date: Tue, 28 May 2002 16:59:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2068A.883D2FC0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2068A.883D2FC0 Content-Type: text/plain; charset="iso-8859-1" Julian, Would it make sense to break out the AHS and digest in the diagrams? I.e., for SCSI Command, the current diagram looks like this: +---------------+---------------+---------------+---------------+ 48| AHS (if any), Header Digest (if any) | +---------------+---------------+---------------+---------------+ / (DataSegment, Command Data + Data Digest (if any))(optional) / +/ / +---------------+---------------+---------------+---------------+ It would seem clearer if it looked like this: +---------------+---------------+---------------+---------------+ 48| AHS (if any) +---------------+---------------+---------------+---------------+ +/ Header Digest (if any) | +---------------+---------------+---------------+---------------+ / DataSegment - Command Data (if any) / +---------------+---------------+---------------+---------------+ +/ Data Digest (if any) / +---------------+---------------+---------------+---------------+ ------_=_NextPart_001_01C2068A.883D2FC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Julian,
 
Would = it make sense=20 to break out the AHS and digest in the diagrams? I.e., for SCSI = Command, the=20 current diagram looks like this:
 
 =20 +---------------+---------------+---------------+---------------+=
48| AHS (if any), = Header Digest=20 (if any)        &nb= sp;           &nb= sp;    =20 |
 =20 +---------------+---------------+---------------+---------------+=
  / (DataSegment, Command Data + = Data=20 Digest (if any))(optional) =20 /
 +/        &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;     =20 /
 =20 +---------------+---------------+---------------+---------------+=
 
It would seem clearer if it looked like = this:
 
 =20 +---------------+---------------+---------------+---------------+=
48| AHS (if any)
 =20 +---------------+---------------+---------------+---------------+=
 +/=20 Header Digest (if any)        &nb= sp;           &nb= sp;           &nb= sp;      =20 |
 =20 +---------------+---------------+---------------+---------------+=
  /=20 DataSegment - Command Data (if=20 any)        =20             =       /
 =20 +---------------+---------------+---------------+---------------+=
 +/=20 Data Digest (if any)       &nb= sp;           &nb= sp;           &nb= sp;       =20   /
 =20 +---------------+---------------+---------------+---------------+=
------_=_NextPart_001_01C2068A.883D2FC0-- From owner-ips@ece.cmu.edu Tue May 28 17:40:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01939 for ; Tue, 28 May 2002 17:40:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SKpcX13198 for ips-outgoing; Tue, 28 May 2002 16:51:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SKpbw13193 for ; Tue, 28 May 2002 16:51:37 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 4DFE1C815; Tue, 28 May 2002 14:51:36 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 2453C14E; Tue, 28 May 2002 14:51:36 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 14:51:35 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 14:51:35 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09D59A@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, cbm@rose.hp.com Cc: ips@ece.cmu.edu, mkrikis@yahoo.com, pat_thaler@agilent.com Subject: RE: iSCSI: Negotiation clarifications still needed Date: Tue, 28 May 2002 14:51:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-a16fa049-11b8-4184-8b32-8ffae51101ad" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-a16fa049-11b8-4184-8b32-8ffae51101ad Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20689.73FD46E0" ------_=_NextPart_001_01C20689.73FD46E0 Content-Type: text/plain; charset="iso-8859-1" Julian, The problem is that the text you propose says "incomplete key text" and everywhere else the key is just called "key" so one isn't sure whether "key text" means key or the whole key-value pair. Therefore, "key text" should probably be "key". > Key=value pairs may span PDU boundaries. A responder having a received > partial key text MUST refrain from originating any new key=value > negotiations until it has no incomplete key text. This way one avoids > having both negotiating entities assuming the originator role in a > negotiation. > One could add after the second sentence "It may send key-value responses and declarations." Also, I think there could be a clearer tie between the 4.2 text on declarations and the keys in 11. I suggest adding before: "Keys marked as "declarative" may appear also in the SecurityNegotiation stage while all other keys described in this chapter are operational keys." the sentence: "Keys which are subject to declaration rather than negotiation are marked declarative." This ignores sendTargets which is an odd kind of declaration. It isn't a negotiation but it causes the target to respond with declaritive keys and it is FFPO. Ideally one would use different labels to indicate that a key was subject to declaration and that it could be sent in SecurityNegotiation stage. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, May 28, 2002 12:34 PM To: Mallikarjun C. Cc: ips@ece.cmu.edu; mkrikis@yahoo.com; pat_thaler@agilent.com Subject: Re: iSCSI: Negotiation clarifications still needed Mallikarjun, Thhe current text and your proposed text say basically the same think. If you feel that originating does not convey the meaning of originator I will rephrase it. I will not consider key-name and text-value as they would require a long re-reading of the text. Julo "Mallikarjun C." 05/28/2002 10:02 PM Please respond to "Mallikarjun C." To: , Julian Satran/Haifa/IBM@IBMIL cc: , Subject: Re: iSCSI: Negotiation clarifications still needed Julian, I generally agree with the intent of the wording. A couple of comments - - I assume you meant "text-value of a received key-name" by "key text" (the only occurrence of "key text" is here). I suggest we use the definitions on pages 68 & 69. [ This is somewhat unrelated. But with the advent of formal terminology now, I'd actually recommend that we replace all "key=value" usages in the text with "key-name=text-value".] - IMHO (if my above assumption is true), the proposed rule is overly constraining. o The originator would only have to refrain from originating new keys if a partial *key-name* is received. IOW, doesn't have to wait for the entire text-value to arrive (though it may). o The "no incomplete key text" should not imply that the responder is also forbidden from responding to other (complete) text-value offers that it had already received. As a pathological case, if every PDU begins from the middle of one text-value and concludes in the middle of the next text-value, the responder should not be required to sit out until all the proposals are received in full (though it may). Here's a strawman with some wordsmithing. Key=value pairs may span PDU boundaries. A responder having a received partial key-name or not received the following "=" in a PDU MUST refrain from originating any new key=value negotiations until it had received the key-name in full and the following "=" . In this case, the receiving entity can only assume the role of a responder for this key. This way one avoids having both negotiating entities assuming the originator role in a negotiation. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Cc: ; Sent: Friday, May 24, 2002 10:26 PM Subject: RE: iSCSI: Negotiation clarifications still needed > Pat your proposed 2b may be what we are looking for - i.e. a responder may > not originate a key if it has an incomplete key text. > > The text we may want to add to section 4.2 is: > > Key=value pairs may span PDU boundaries. A responder having a received > partial key text MUST refrain from originating any new key=value > negotiations until it has no incomplete key text. This way one avoids > having both negotiating entities assuming the originator role in a > negotiation. > > > Julo > > > > > pat_thaler@agilent.com > 05/25/2002 12:16 AM > Please respond to pat_thaler > > > To: mkrikis@yahoo.com, Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: Negotiation clarifications still needed > > > > Martins, > > Comments referenced by the same items Martins used. > > 1. Julian sent an email saying he would put the text > I proposed in (though the text you quoted is not the > whole text). > > 2. I think that the principle we have been using on > text negotiation was that each key negotion is a > separate item. Your proposal would be counter to that > and I don't think it would be an improvement. The > target should be allowed to respond to any complete > key-value pair it has received. When a key-value > pair is straddling the PDU bondary, then it shouldn't > respond to that key until the complete key-value pair > has been received. > > There is one potential corner case issue that should > to be covered. Targets can initiate keys. If key-value > pairs didn't straddle PDU boundaries, then ensuring > that there is a clear originator for each offered key > is easy. You can originate any key that you haven't > received an offer of from your partner. But now keys > can straddle PDUs. If the text between the last separater > and the end of the PDU is Ma, then you don't know what > key your partner has started to offer. If the partner > was starting to offer MaxBurstSize and you offer it in > the next PDU of the exchange, both sides may think they > are originator. > > I suggest one of the following > a) don't allow keys to straddle PDU boundaries. > b) don't allow originating a key when the last login > PDU ended in a partial key. > c) don't allow offering a key where the start of the key > matches a partial key at the end of the last login > PDU. > > 3. Yes, we noticed a little while ago that losing a > packet at the end of negotiation could hang things up > though the concern is mainly for a full feature phase > negotiation. Looking at 6.8, any timeout during > negotiation causes the login and its TCP connection to > be terminated. The whole negotiation process (see the > point about origninators in 2) depends upon a one-by-one > exchange of PDUs. PDU loss has to terminate it. > > Therefore, the target commits to the end of login > as described for T5 target. It has sent the final > login response with a status of zero. Moves to S5. > If the login response doesn't get to the initiator, > then either the initiator will close the connection > due to the timeout. Since the target is in S4, loss > of the transport connection will cause it to go to > S8 and R1 of the cleanup state machine. It presumably > will not take the M2 transition because the intiator > isn't going to do cleanup for a connection it thinks > wasn't in full feature phase. It will take M1 due to > timeout - not elegant but good enough. > > The concern was Full Feature Phase negotation. Until > negotiation ends, it can be reset and no values change. > When the target sends the last Text Response PDU, then > it thinks negotiation has ended and it applies the > new values. If that PDU doesn't reach the initiatior, > then it terminates the entire negotiation and continues > to use the old values. The two ends are using different > values. > > We decided to not raise this as an issue because it is > such a corner case - we are operating over a reliable > connection so PDUs shouldn't be lost (unless the whole > path goes down in which case it doesn't matter). Also, > there are few values exchanged during full feature so > it isn't worthwhile to add complexity. > > Regards, > Pat > > > -----Original Message----- > From: Martins Krikis [mailto:mkrikis@yahoo.com] > Sent: Friday, May 24, 2002 12:39 PM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: iSCSI: Negotiation clarifications still needed > > > The previous thread went on too long, but since it > has now quieted down, I'll conjecture that the > following are the aspects that still need to be > addressed. > > 1. Not everybody seemed to have noticed that it is > NOT legal to send the same key again, if it > has once been negotiated (including negotiations > that end with a reserved value (Reject, > Irrelevant or NotUnderstood). > > I think it would benefit the draft to add the > sentence that Pat proposed to paragraph 5 or page > 72 in 12-92: "Sending the key again would be a > re-negotiation". That I think would make it crystal > clear. > > 2. When the key=value pairs that Originator is > sending are broken across multiple PDUs, it > is not clear whether the Responder may start > responding to the keys as soon as it receives > them or whether it should send blank PDUs back > (as in the example on page 164 of 12-92) until > it gets a PDU, the data part of which ends in > a NUL byte (thus signaling that there are no > broken key=value pairs at the end of it). > > I am proposing that the draft should make it explicit > that only blank PDUs are to be sent. This allows > decoupling of key=value generation from > their encapsulation in PDUs (i.e., the generating > logic need not worry about whether a key=value > pair will fit and go out in this PDU or has to > be retained to go out in the next). I can explain > in detail why this is important (it has to do > with teh possibility of receiving the "just-about > outgoing" keys) but I'm keeping this "brief". > > Furthermore, it is my feeling that instead of > checking the last bytes of a PDU for NUL, it > would be better if the end-of-data was marked by > a flag in the header. This way encapsulation will > be simpler---just put as much data in the PDU as > fits there and raise the flag if it isn't all, > instead of checking whether it ends in a NUL and > possibly shortening data to make it not end like > that. > > 3. There is an opinion that on page 73 of 12-92, > the phrase that says "or the responder may > select an admissible value" is in contradiction > to the very next sentence. There is also an > opinion that this phrase is entirely unnecessary > and detrimental to achieving broad > interoperability (I call it "cutting slack to > misbehaving or incompatible originators"). > > I don't have a suggestion since I consider the > "feature" that this phrase allows of little > importance to a properly built iSCSI node. > > 4. This is new. When doing Text Request/Response > negotiations (i.e., in FFP), it seems > that the Initiator commits to the new values > when it receives a response from the Target with > the F bit set. It is unclear when the Target should > commit. Should it switch to using the new values > as soon as it sends its response with the F-bit > set, or should it do so only when it knows that > the Initiator received its response? > > Commiting right away is simpler and since responses > with F-bits set have TTT=0xffffffff and thus > may not be reset, sounds plausible. If the > values have importance on the next reception, > it may also be important to commit timely. However, > what if the Initiator doesn't get this response? > Target now has committed, Initiator hasn't. Committing > later puts the burden on Initiator to send something > effectively telling "I've received your final > response". Otherwise the Target will time out and > not commit. This response can get lost too. > > Basically, it is beginning to look a bit like > (what was it called?) "distributed consensus problem"? > I think it goes like this: > > Two generals that are on oposite sides of the > enemy want to synchronize their attack, and > start sending messengers through with messages > like > "attack at dawn->", > "<-ok, attack at dawn", > "I know you know we attack at dawn->", > "<-, I know you know I know we attack at dawn", > etc., etc., ... > But at no point can they commit yet... > > Is anybody else worried about this? > Anyway, so when should a target commit? Page 83 > of 12-92 is the relevant reference. > > Thanks, > > Martins Krikis > > Disclaimer: these opinions are my own and may > not be those of my employer. > > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > > > ------_=_NextPart_001_01C20689.73FD46E0 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
The problem is that the text you propose says "incomplete key text" and
everywhere else the key is just called "key" so one isn't sure whether
"key text" means key or the whole key-value pair. Therefore, "key text"
should probably be "key".
 
> Key=value pairs may span PDU boundaries. A responder having a received
> partial key text MUST refrain from originating any new key=value
> negotiations until it has no incomplete key text. This way one avoids
> having both negotiating entities assuming the originator role in a
> negotiation.
>
One could add after the second sentence "It may send key-value responses
and declarations."
 
Also, I think there could be a clearer tie between the 4.2 text on
declarations and the keys in 11. I suggest adding before:
"Keys marked as "declarative" may appear also in the SecurityNegotiation
stage while all other keys described in this chapter are operational
keys."
 
the sentence:
"Keys which are subject to declaration rather than negotiation are marked declarative."
 
This ignores sendTargets which is an odd kind of declaration. It isn't a negotiation but it causes
the target to respond with declaritive keys and it is FFPO. Ideally one would use different labels to
indicate that a key was subject to declaration and that it could be sent in SecurityNegotiation stage.
 
Regards,
Pat
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, May 28, 2002 12:34 PM
To: Mallikarjun C.
Cc: ips@ece.cmu.edu; mkrikis@yahoo.com; pat_thaler@agilent.com
Subject: Re: iSCSI: Negotiation clarifications still needed


Mallikarjun,

Thhe current text and your proposed text say basically the same think. If you feel that originating does not convey the meaning of originator I will rephrase it.

I will not consider key-name and text-value as they would require a long re-reading of the text.

Julo


"Mallikarjun C." <cbm@rose.hp.com>

05/28/2002 10:02 PM
Please respond to "Mallikarjun C."

       
        To:        <pat_thaler@agilent.com>, Julian Satran/Haifa/IBM@IBMIL
        cc:        <ips@ece.cmu.edu>, <mkrikis@yahoo.com>
        Subject:        Re: iSCSI: Negotiation clarifications still needed

       


Julian,

I generally agree with the intent of the wording.  A couple of comments -

- I assume you meant "text-value of a received key-name" by "key text"
 (the only occurrence of "key text" is here).   I suggest we use the definitions
 on pages 68 & 69.

 [ This is somewhat unrelated.  But with the advent of formal terminology now,
    I'd actually recommend that we replace all "key=value" usages in the text with
    "key-name=text-value".]

- IMHO (if my above assumption is true), the proposed rule is overly constraining.
   o The originator would only have to refrain from originating new keys if a partial
      *key-name* is received.  IOW, doesn't have to wait for the entire text-value
      to arrive (though it may).

   o The "no incomplete key text" should not imply that the responder is also
      forbidden from responding to other (complete) text-value offers that it had
      already received.  As a pathological case, if every PDU begins from the middle
      of one text-value and concludes in the middle of the next text-value, the responder
      should not be required to sit out until all the proposals are received in full
      (though it may).

Here's a strawman with some wordsmithing.

Key=value pairs may span PDU boundaries. A responder having a received partial key-name or not received the
following "=" in a PDU MUST refrain from originating any new key=value negotiations until it had received the
key-name in full and the following "=" . In this case, the receiving entity can only assume the role of a
responder for this key.  This way one avoids having both negotiating entities assuming the originator role in
a negotiation.

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com


----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <pat_thaler@agilent.com>
Cc: <ips@ece.cmu.edu>; <mkrikis@yahoo.com>
Sent: Friday, May 24, 2002 10:26 PM
Subject: RE: iSCSI: Negotiation clarifications still needed


> Pat your proposed 2b may be what we are looking for - i.e. a responder may
> not originate a key if it has an incomplete key text.
>
> The text we may want to add to section 4.2 is:
>
> Key=value pairs may span PDU boundaries. A responder having a received
> partial key text MUST refrain from originating any new key=value
> negotiations until it has no incomplete key text. This way one avoids
> having both negotiating entities assuming the originator role in a
> negotiation.
>
>
> Julo
>
>
>
>
> pat_thaler@agilent.com
> 05/25/2002 12:16 AM
> Please respond to pat_thaler
>
>
>         To:     mkrikis@yahoo.com, Julian Satran/Haifa/IBM@IBMIL
>         cc:     ips@ece.cmu.edu
>         Subject:        RE: iSCSI: Negotiation clarifications still needed
>
>
>
> Martins,
>
> Comments referenced by the same items Martins used.
>
> 1. Julian sent an email saying he would put the text
> I proposed in (though the text you quoted is not the
> whole text).
>
> 2. I think that the principle we have been using on
> text negotiation was that each key negotion is a
> separate item. Your proposal would be counter to that
> and I don't think it would be an improvement. The
> target should be allowed to respond to any complete
> key-value pair it has received. When a key-value
> pair is straddling the PDU bondary, then it shouldn't
> respond to that key until the complete key-value pair
> has been received.
>
> There is one potential corner case issue that should
> to be covered. Targets can initiate keys. If key-value
> pairs didn't straddle PDU boundaries, then ensuring
> that there is a clear originator for each offered key
> is easy. You can originate any key that you haven't
> received an offer of from your partner. But now keys
> can straddle PDUs. If the text between the last separater
> and the end of the PDU is Ma, then you don't know what
> key your partner has started to offer. If the partner
> was starting to offer MaxBurstSize and you offer it in
> the next PDU of the exchange, both sides may think they
> are originator.
>
> I suggest one of the following
> a) don't allow keys to straddle PDU boundaries.
> b) don't allow originating a key when the last login
> PDU ended in a partial key.
> c) don't allow offering a key where the start of the key
> matches a partial key at the end of the last login
> PDU.
>
> 3. Yes, we noticed a little while ago that losing a
> packet at the end of negotiation could hang things up
> though the concern is mainly for a full feature phase
> negotiation. Looking at 6.8, any timeout during
> negotiation causes the login and its TCP connection to
> be terminated. The whole negotiation process (see the
> point about origninators in 2) depends upon a one-by-one
> exchange of PDUs. PDU loss has to terminate it.
>
> Therefore, the target commits to the end of login
> as described for T5 target. It has sent the final
> login response with a status of zero. Moves to S5.
> If the login response doesn't get to the initiator,
> then either the initiator will close the connection
> due to the timeout. Since the target is in S4, loss
> of the transport connection will cause it to go to
> S8 and R1 of the cleanup state machine. It presumably
> will not take the M2 transition because the intiator
> isn't going to do cleanup for a connection it thinks
> wasn't in full feature phase. It will take M1 due to
> timeout - not elegant but good enough.
>
> The concern was Full Feature Phase negotation. Until
> negotiation ends, it can be reset and no values change.
> When the target sends the last Text Response PDU, then
> it thinks negotiation has ended and it applies the
> new values. If that PDU doesn't reach the initiatior,
> then it terminates the entire negotiation and continues
> to use the old values. The two ends are using different
> values.
>
> We decided to not raise this as an issue because it is
> such a corner case - we are operating over a reliable
> connection so PDUs shouldn't be lost (unless the whole
> path goes down in which case it doesn't matter). Also,
> there are few values exchanged during full feature so
> it isn't worthwhile to add complexity.
>
> Regards,
> Pat
>
>
> -----Original Message-----
> From: Martins Krikis [mailto:mkrikis@yahoo.com]
> Sent: Friday, May 24, 2002 12:39 PM
> To: Julian Satran
> Cc: ips@ece.cmu.edu
> Subject: iSCSI: Negotiation clarifications still needed
>
>
> The previous thread went on too long, but since it
> has now quieted down, I'll conjecture that the
> following are the aspects that still need to be
> addressed.
>
> 1. Not everybody seemed to have noticed that it is
>    NOT legal to send the same key again, if it
>    has once been negotiated (including negotiations
>    that end with a reserved value (Reject,
>    Irrelevant or NotUnderstood).
>
> I think it would benefit the draft to add the
> sentence that Pat proposed to paragraph 5 or page
> 72 in 12-92: "Sending the key again would be a
> re-negotiation". That I think would make it crystal
> clear.
>
> 2. When the key=value pairs that Originator is
>    sending are broken across multiple PDUs, it
>    is not clear whether the Responder may start
>    responding to the keys as soon as it receives
>    them or whether it should send blank PDUs back
>    (as in the example on page 164 of 12-92) until
>    it gets a PDU, the data part of which ends in
>    a NUL byte (thus signaling that there are no
>    broken key=value pairs at the end of it).
>
> I am proposing that the draft should make it explicit
> that only blank PDUs are to be sent. This allows
> decoupling of key=value generation from
> their encapsulation in PDUs (i.e., the generating
> logic need not worry about whether a key=value
> pair will fit and go out in this PDU or has to
> be retained to go out in the next). I can explain
> in detail why this is important (it has to do
> with teh possibility of receiving the "just-about
> outgoing" keys) but I'm keeping this "brief".
>
> Furthermore, it is my feeling that instead of
> checking the last bytes of a PDU for NUL, it
> would be better if the end-of-data was marked by
> a flag in the header. This way encapsulation will
> be simpler---just put as much data in the PDU as
> fits there and raise the flag if it isn't all,
> instead of checking whether it ends in a NUL and
> possibly shortening data to make it not end like
> that.
>
> 3. There is an opinion that on page 73 of 12-92,
>    the phrase that says "or the responder may
>    select an admissible value" is in contradiction
>    to the very next sentence. There is also an
>    opinion that this phrase is entirely unnecessary
>    and detrimental to achieving broad
>    interoperability (I call it "cutting slack to
>    misbehaving or incompatible originators").
>
> I don't have a suggestion since I consider the
> "feature" that this phrase allows of little
> importance to a properly built iSCSI node.
>
> 4. This is new. When doing Text Request/Response
> negotiations (i.e., in FFP), it seems
> that the Initiator commits to the new values
> when it receives a response from the Target with
> the F bit set. It is unclear when the Target should
> commit. Should it switch to using the new values
> as soon as it sends its response with the F-bit
> set, or should it do so only when it knows that
> the Initiator received its response?
>
> Commiting right away is simpler and since responses
> with F-bits set have TTT=0xffffffff and thus
> may not be reset, sounds plausible. If the
> values have importance on the next reception,
> it may also be important to commit timely. However,
> what if the Initiator doesn't get this response?
> Target now has committed, Initiator hasn't. Committing
> later puts the burden on Initiator to send something
> effectively telling "I've received your final
> response". Otherwise the Target will time out and
> not commit. This response can get lost too.
>
> Basically, it is beginning to look a bit like
> (what was it called?) "distributed consensus problem"?
> I think it goes like this:
>
> Two generals that are on oposite sides of the
> enemy want to synchronize their attack, and
> start sending messengers through with messages
> like
>   "attack at dawn->",
>   "<-ok, attack at dawn",
>   "I know you know we attack at dawn->",
>   "<-, I know you know I know we attack at dawn",
>   etc., etc., ...
> But at no point can they commit yet...
>
> Is anybody else worried about this?
> Anyway, so when should a target commit? Page 83
> of 12-92 is the relevant reference.
>
> Thanks,
>
>   Martins Krikis
>
> Disclaimer: these opinions are my own and may
>             not be those of my employer.
>
>
> __________________________________________________
> Do You Yahoo!?
> LAUNCH - Your Yahoo! Music Experience
> http://launch.yahoo.com
>
>
>



------_=_NextPart_001_01C20689.73FD46E0-- ------=_NextPartTM-000-a16fa049-11b8-4184-8b32-8ffae51101ad-- From owner-ips@ece.cmu.edu Tue May 28 17:40:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01956 for ; Tue, 28 May 2002 17:40:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SLKOw15314 for ips-outgoing; Tue, 28 May 2002 17:20:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13705.mail.yahoo.com (web13705.mail.yahoo.com [216.136.175.138]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4SLKMw15309 for ; Tue, 28 May 2002 17:20:22 -0400 (EDT) Message-ID: <20020528212021.23437.qmail@web13705.mail.yahoo.com> Received: from [192.52.58.5] by web13705.mail.yahoo.com via HTTP; Tue, 28 May 2002 14:20:21 PDT Date: Tue, 28 May 2002 14:20:21 -0700 (PDT) From: Martins Krikis Subject: RE: iSCSI: Negotiation clarifications still needed To: "THALER,PAT \(A-Roseville,ex1\)" , Julian Satran , "Mallikarjun C." Cc: ips@ece.cmu.edu, Martins Krikis In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C09D54C@axcs04.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- "THALER,PAT (A-Roseville,ex1)" wrote: > The sender cannot do exactly what you describe. It > cannot prepare a string of > key-value pairs then chop them into PDUs to send > because the response to > the first PDUs may contain offers of keys that were > not sent in the first PDU. This is where my scheme has an advantage. The sender does not have to worry about how much fits in each PDU. It knows that it will be getting no response text until it is done all its sending. Kind of like a speaker knowing that nobody will interrupt it until it has finished the thought. > Because of the request-response nature of > negotiation plus the > flexibility of allowing either side to make an offer > plus the simplification > that a negotiation is at most one offer and one > response, the negotiation > has to be PDU boundary aware. With a requirement for empty PDUs it doesn't. The negotiation is completely PDU boundary agnostic. I know that your scheme works, Pat. It also more efficiently uses the bandwitch and possibly converges faster in the rare case when anything needs to be split at all. However, my scheme is simpler and allows simpler implementations without any harmful effects on the general case when everything does fit. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Tue May 28 18:20:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02934 for ; Tue, 28 May 2002 18:20:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SLfiU16745 for ips-outgoing; Tue, 28 May 2002 17:41:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13705.mail.yahoo.com (web13705.mail.yahoo.com [216.136.175.138]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4SLfgw16741 for ; Tue, 28 May 2002 17:41:42 -0400 (EDT) Message-ID: <20020528214141.26257.qmail@web13705.mail.yahoo.com> Received: from [192.52.58.5] by web13705.mail.yahoo.com via HTTP; Tue, 28 May 2002 14:41:41 PDT Date: Tue, 28 May 2002 14:41:41 -0700 (PDT) From: Martins Krikis Subject: RE: iSCSI: Negotiation clarifications still needed To: pat_thaler@agilent.com, Julian_Satran@il.ibm.com, cbm@rose.hp.com Cc: ips@ece.cmu.edu, mkrikis@yahoo.com, pat_thaler@agilent.com In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C09D59A@axcs04.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- pat_thaler@agilent.com wrote: > One could add after the second sentence "It may send > key-value responses > and declarations." I would rather not involve declarations here. It seems like a good idea to remind that responses may be sent, but I don't like having to start checking key types in order to figure out whether I should send it (or whether I can "nail" the other side for sending it :-)). > the sentence: > "Keys which are subject to declaration rather than > negotiation are marked declarative." This isn't entirely true, because MaxRecvPDUDataSize is subject to declaration but isn't marked declarative at the moment. I actually suggest not involving declarations in the non-spanning issue. Yes, we may end up sending a key or two later than would be possible otherwise, but the property that all keys (whether declarative or not) can be treated the same way by far outweighs this. > Ideally one would use different labels to > indicate that a key was subject to declaration and > that it could be sent in SecurityNegotiation stage. True, but we're getting off-topic. P.S. Just because I'm commenting on this does not mean that I've changed my mind about my own proposal---I still think it is simplest. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Tue May 28 18:21:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02976 for ; Tue, 28 May 2002 18:21:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SM6Mo18393 for ips-outgoing; Tue, 28 May 2002 18:06:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SM6Jw18385 for ; Tue, 28 May 2002 18:06:20 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 20406D5F; Tue, 28 May 2002 16:06:19 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id D25A311B; Tue, 28 May 2002 16:06:18 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 16:06:16 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 16:06:15 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09D5E4@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiation value types and values Date: Tue, 28 May 2002 16:06:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-218dd907-015c-4e79-8057-5c349bf38d34" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-218dd907-015c-4e79-8057-5c349bf38d34 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20693.E2C0A3B0" ------_=_NextPart_001_01C20693.E2C0A3B0 Content-Type: text/plain; charset="iso-8859-1" Julian, We have gone to the trouble of defining value types in 4.1 but then in 11 when we define some of the keys we don't say what value type each key takes. We define boolean-value in 4.1 but keys that take a boolean-value say "key=" in 11. I think they should say boolean-value. We define numerical-value, large-numerical-value and regular-numerical-value but keys in 11 take . (MaxConnections has a typo - "unsigned" is repeated.) They should take regular-numerical-value or numerical-value depending on size. portal-group-tag: 11.8 sends one to Annex D for information about portal-group-tag yet Annex D defines it fairly loosely as numeric, decimal. Target portal group tag (no hyphens) is defined in 11.9 as a 16 bit unsigned integer. Is the portal-group-tag sent as part of TargetAddress required to be in decimal notation or is it any regular-numerical-value or is it really a 16-bit binary string? Does it take the same formats as TargetPortalGroupTag? Which format applies to port? Pat ------_=_NextPart_001_01C20693.E2C0A3B0 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
We have gone to the trouble of defining value types in 4.1 but then in 11 when we define some of the keys we don't say what value type each key takes.
 
We define boolean-value in 4.1 but keys that take a boolean-value say "key=<Yes|No>" in 11. I think they should say boolean-value.
 
We define numerical-value, large-numerical-value and regular-numerical-value but keys in 11 take <unsigned integer-from-x-to-y>. (MaxConnections has a typo - "unsigned" is repeated.) They should take regular-numerical-value or numerical-value depending on size.
 
portal-group-tag: 11.8 sends one to Annex D for information about portal-group-tag yet Annex D defines it fairly loosely as numeric, decimal. Target portal group tag (no hyphens) is defined in 11.9 as a 16 bit unsigned integer. Is the portal-group-tag sent as part of TargetAddress required to be in decimal notation or is it any regular-numerical-value or is it really a 16-bit binary string? Does it take the same formats as TargetPortalGroupTag?
 
Which format applies to port?
 
Pat
------_=_NextPart_001_01C20693.E2C0A3B0-- ------=_NextPartTM-000-218dd907-015c-4e79-8057-5c349bf38d34-- From owner-ips@ece.cmu.edu Tue May 28 18:55:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03561 for ; Tue, 28 May 2002 18:55:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SMHWY19086 for ips-outgoing; Tue, 28 May 2002 18:17:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SMHVw19081 for ; Tue, 28 May 2002 18:17:31 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 34058C82D; Tue, 28 May 2002 16:17:30 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 0450B135; Tue, 28 May 2002 16:17:30 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 16:17:28 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 16:17:28 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09D5EC@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: mkrikis@yahoo.com, pat_thaler@agilent.com, Julian_Satran@il.ibm.com, cbm@rose.hp.com Cc: ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI: Negotiation clarifications still needed Date: Tue, 28 May 2002 16:17:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Martin, You don't have to send a declaration but there is no reason to prohibit you from doing so. If you would rather not check type, then don't send any new keys when one is incomplete. Thank you for pointing out that MaxRecvPDUDataSize isn't marked declaritive. It is subject to declaration so it should be marked declaritive and another label should be used to indicate that the key can be send during SecurityNegotiation stage. I suggest that keys that can be sent during SecurityNegatiation stage should have SN added to Use because use has the other information about when a key can be sent. I think clearly identifying which keys are not subject to negotiation is on topic for clarifying negotiation. Declarations are involved in the spanning/non-spanning issue. When one has gotten only a partial key one doesn't know whether it is a declaration or a negotiation. Pat -----Original Message----- From: Martins Krikis [mailto:mkrikis@yahoo.com] Sent: Tuesday, May 28, 2002 2:42 PM To: pat_thaler@agilent.com; Julian_Satran@il.ibm.com; cbm@rose.hp.com Cc: ips@ece.cmu.edu; mkrikis@yahoo.com; pat_thaler@agilent.com Subject: RE: iSCSI: Negotiation clarifications still needed --- pat_thaler@agilent.com wrote: > One could add after the second sentence "It may send > key-value responses > and declarations." I would rather not involve declarations here. It seems like a good idea to remind that responses may be sent, but I don't like having to start checking key types in order to figure out whether I should send it (or whether I can "nail" the other side for sending it :-)). > the sentence: > "Keys which are subject to declaration rather than > negotiation are marked declarative." This isn't entirely true, because MaxRecvPDUDataSize is subject to declaration but isn't marked declarative at the moment. I actually suggest not involving declarations in the non-spanning issue. Yes, we may end up sending a key or two later than would be possible otherwise, but the property that all keys (whether declarative or not) can be treated the same way by far outweighs this. > Ideally one would use different labels to > indicate that a key was subject to declaration and > that it could be sent in SecurityNegotiation stage. True, but we're getting off-topic. P.S. Just because I'm commenting on this does not mean that I've changed my mind about my own proposal---I still think it is simplest. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Tue May 28 18:58:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03621 for ; Tue, 28 May 2002 18:58:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SMhh820906 for ips-outgoing; Tue, 28 May 2002 18:43:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4SMhfw20900 for ; Tue, 28 May 2002 18:43:41 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 37AAAC6AB; Tue, 28 May 2002 16:43:40 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 5CF3C440; Tue, 28 May 2002 16:43:39 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 16:43:38 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 16:43:38 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C09D5F8@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Martins Krikis , "THALER,PAT (A-Roseville,ex1)" , Julian Satran , "Mallikarjun C." Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiation clarifications still needed Date: Tue, 28 May 2002 16:43:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Martin, I want to make it clear that I am not advocating for any particular scheme. In my experience, negotiation phases of protocols are a frequent cause of the type of interoperability bug that causes total non-operation. My goal is for the negotiation to be described clearly enough that this doesn't happen. I am not trying to optimize bandwidth for negotiation but I am trying to propose ways to clarify the existing protocol that are consistant with the approach the group has already chosen - the smallest changes that fix what is broken. The SecurityNegotiation phase requires going back and forth between initiator and responder so a general approach of the initiator sends all its keys and then the responder sends all its keys doesn't work. Even in the operational parameter negotiation phase, it is possible that keys received from the target will alter some of the later keys offered so one may not want that phase to be initiator sends all the keys it wants to originate then the target sends all the keys it wants to originate. My understanding of earlier reflector discussions is that is the way people want the negotiation to operate. I think the method you propose would work, but it isn't consistant with the kind of negotiation process the group appears to want. Also see one response inserted below. Pat -----Original Message----- From: Martins Krikis [mailto:mkrikis@yahoo.com] Sent: Tuesday, May 28, 2002 2:20 PM To: THALER,PAT (A-Roseville,ex1); Julian Satran; Mallikarjun C. Cc: ips@ece.cmu.edu; Martins Krikis Subject: RE: iSCSI: Negotiation clarifications still needed --- "THALER,PAT (A-Roseville,ex1)" wrote: > The sender cannot do exactly what you describe. It > cannot prepare a string of > key-value pairs then chop them into PDUs to send > because the response to > the first PDUs may contain offers of keys that were > not sent in the first PDU. This is where my scheme has an advantage. The sender does not have to worry about how much fits in each PDU. It knows that it will be getting no response text until it is done all its sending. Kind of like a speaker knowing that nobody will interrupt it until it has finished the thought. > Because of the request-response nature of > negotiation plus the > flexibility of allowing either side to make an offer > plus the simplification > that a negotiation is at most one offer and one > response, the negotiation > has to be PDU boundary aware. With a requirement for empty PDUs it doesn't. The negotiation is completely PDU boundary agnostic. A requirement for empty PDUs doesn't do this. It is a requirement that the target not originate any keys non-declaritive keys until the Initiator has somehow indicated it won't issue any more. In what I wrote above, I really meant "the flexibility of allowing either side to make an offer at any point during the negotiation." I know that your scheme works, Pat. It also more efficiently uses the bandwitch and possibly converges faster in the rare case when anything needs to be split at all. However, my scheme is simpler and allows simpler implementations without any harmful effects on the general case when everything does fit. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Tue May 28 19:05:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03766 for ; Tue, 28 May 2002 19:05:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SMp8821373 for ips-outgoing; Tue, 28 May 2002 18:51:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13704.mail.yahoo.com (web13704.mail.yahoo.com [216.136.175.137]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4SMp6w21369 for ; Tue, 28 May 2002 18:51:06 -0400 (EDT) Message-ID: <20020528225105.24249.qmail@web13704.mail.yahoo.com> Received: from [192.52.58.5] by web13704.mail.yahoo.com via HTTP; Tue, 28 May 2002 15:51:05 PDT Date: Tue, 28 May 2002 15:51:05 -0700 (PDT) From: Martins Krikis Subject: RE: iSCSI: Negotiation clarifications still needed To: pat_thaler@agilent.com, Julian_Satran@il.ibm.com, cbm@rose.hp.com Cc: ips@ece.cmu.edu, pat_thaler@agilent.com In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C09D5EC@axcs04.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- pat_thaler@agilent.com wrote: > You don't have to send a declaration but there is no > reason to > prohibit you from doing so. I know that I don't have to. That's why I said "should" and not "MUST". I should have said "ought", perhaps. But there is a reason to prohibit this. The reason is that then all keys can be treated the same way regarding whether they can be originated (or spanned, or whatever, depending on which variation on this theme we end up with). > If you would rather not > check type, > then don't send any new keys when one is incomplete. I know. But w/o checking type I can't "nail" the other side for breaking the rules :-). > I suggest that keys that can be sent during > SecurityNegatiation stage > should have SN added to Use because use has the > other information > about when a key can be sent. > > I think clearly identifying which keys are not > subject to negotiation > is on topic for clarifying negotiation. This is all very good, but we didn't have to mix this issue with the spanning issue. It is IMHO off-topic w.r.t. the spanning issue, which this thread has migrated into. For clarifying negotiation, yes, very much on topic. > Declarations are involved in the > spanning/non-spanning issue. Not unless you start involving them. > When > one has gotten only a partial key one doesn't know > whether it is > a declaration or a negotiation. OK. And I prefer ignoring whether a key is a declaration or a negotiation even when I have received it complete or am planning to originate it. I have flags telling which sides may use the key, and I have functions for choosing a value. I don't have to care about declarations currently and would love to keep it that way. I think you're just making your own scheme subtly more difficult to describe and slightly more difficult to implement for those that want to take full advantage of the little additional performance benefit that it offers. I see, of course, that it works. And I can implement it, and it probably won't even take too long to do that. The point is that this extra optimization is yet another (very slight) complication in the protocol. You are further optimizing a "corner case", when we really should have opted for the absolute simplicity in this "corner case". Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Tue May 28 20:07:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04622 for ; Tue, 28 May 2002 20:07:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4SNQoB23428 for ips-outgoing; Tue, 28 May 2002 19:26:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13705.mail.yahoo.com (web13705.mail.yahoo.com [216.136.175.138]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4SNQlw23424 for ; Tue, 28 May 2002 19:26:48 -0400 (EDT) Message-ID: <20020528232647.40403.qmail@web13705.mail.yahoo.com> Received: from [192.52.58.5] by web13705.mail.yahoo.com via HTTP; Tue, 28 May 2002 16:26:47 PDT Date: Tue, 28 May 2002 16:26:47 -0700 (PDT) From: Martins Krikis Subject: RE: iSCSI: Negotiation clarifications still needed To: "THALER,PAT \(A-Roseville,ex1\)" , Julian Satran , "Mallikarjun C." Cc: ips@ece.cmu.edu In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C09D5F8@axcs04.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- "THALER,PAT (A-Roseville,ex1)" wrote: > I am not trying to optimize bandwidth for > negotiation but I am trying > to propose ways to clarify the existing protocol > that are consistant > with the approach the group has already chosen - the > smallest changes > that fix what is broken. Then why involve declarations in the issue? And if we classified the brokenness as "arbitrary PDU boundaries imposed on unpredictable amount of data", wouldn't the smallest change be to say "wait, don't send anything until you got all that data"? Also, some people had already understood the existing draft pretty much the way I proposed, i.e., that empty PDUs are required in response to PDUs ending in split pairs. I just realized that it is even cleaner to have a data-end flag. > The SecurityNegotiation phase requires going back > and forth between > initiator and responder so a general approach of the > initiator > sends all its keys and then the responder sends all > its keys doesn't > work. Regardless of the phase at any point one could have a set of keys that it would like to send. With my scheme they all can be sent w/o worrying about which ones will fit in the first PDU and which won't. I don't mean sending every single key defined in the spec. I just mean sending all keys that would be nice to send at this point. Then I'll see what I've received and perhaps send some more. All w/o worrying about PDU boundaries. > Even in the operational parameter negotiation phase, > it is possible > that keys received from the target will alter some > of the > later keys offered so one may not want that phase to > be > initiator sends all the keys it wants to originate > then the target > sends all the keys it wants to originate. My > understanding of earlier > reflector discussions is that is the way people want > the negotiation > to operate. Same as above, i.e., I never did mean sending _absolutely_ _all_ keys. > I think the method you propose would work, but it > isn't consistant > with the kind of negotiation process the group > appears to want. I may be losing out on support numbers but I do have support. Plus, Julian himself said "chopping in PDUs"... And the process I'm proposing is definitely not an "I send, you send, it's over". It can go on in as many rounds as necessary. It is just that I'm not inventing rules to support "limited interruption of the speaker", I'm simply saying "one MAY NOT interrupt the speaker". I'm also not saying "the speaker should say all it can now, 'cause it won't have another chance". > > Because of the request-response nature of > > negotiation plus the > > flexibility of allowing either side to make an > offer > > plus the simplification > > that a negotiation is at most one offer and one > > response, the negotiation > > has to be PDU boundary aware. > > With a requirement for empty PDUs it doesn't. > The negotiation is completely PDU boundary agnostic. > > A requirement for empty PDUs doesn't do this. > It is a requirement that the target not originate > any keys non-declaritive keys until the Initiator > has somehow indicated it won't issue any more. In > what I wrote above, I really meant "the flexibility > of allowing either side to make an offer at any > point during the negotiation." But that's what I proposed---empty PDUs until the data-end flag is set (or, alternatively, more-data flag cleared). So there is such an indication in my scheme. Even without the flag the encapsulator can make sure that every PDU ends in a split pair, except last. And I don't think that it is beneficial to allow the other side the flexibility to make an offer in the middle of my own unfinished-offer... Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Tue May 28 21:40:31 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06106 for ; Tue, 28 May 2002 21:40:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4T11qA28378 for ips-outgoing; Tue, 28 May 2002 21:01:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4T11ow28371 for ; Tue, 28 May 2002 21:01:50 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 5478230706; Tue, 28 May 2002 21:01:49 -0400 (EDT) Date: Tue, 28 May 2002 17:59:52 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "THALER,PAT (A-Roseville,ex1)" Cc: Martins Krikis , Julian Satran , "Mallikarjun C." , Subject: RE: iSCSI: Negotiation clarifications still needed In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C09D5F8@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 28 May 2002, THALER,PAT (A-Roseville,ex1) wrote: > Martin, > > I want to make it clear that I am not advocating for any particular > scheme. In my experience, negotiation phases of protocols are a > frequent cause of the type of interoperability bug that causes total > non-operation. My goal is for the negotiation to be described clearly > enough that this doesn't happen. I would like to say that I am very heartened by the above. While I do advocate a particular way of doing negotiations, I will be happy if we clarify the negotiation description w.r.t. PDU spanning. > I am not trying to optimize bandwidth for negotiation but I am trying > to propose ways to clarify the existing protocol that are consistant > with the approach the group has already chosen - the smallest changes > that fix what is broken. Here I am at a disadvantage. The only source code I have access to at the moment (other than mine :-) are the draft 8 implementations available on the net (UNH, Intel, IBM, and cisco). These implementations bill themselves as reference implementations. Obviously since they are draft 8 and we are draft 12+, they aren't complete. All of these implementations seem happiest dealing with a complete buffer of negotiation data. Sticking the two chunks of code I detailed in pseudo-code, the were-sending-a-big-offer or the there's-more-to-get, was an easy add in front of the current negotiation code, and immediately the non-PDU-savy negotiation code could deal with PDU-spanning negotiation. > The SecurityNegotiation phase requires going back and forth between > initiator and responder so a general approach of the initiator > sends all its keys and then the responder sends all its keys doesn't > work. True. And AFAICT the negotiations that will need BIG keys only have one in flight, in a specific direction, at a time. > Even in the operational parameter negotiation phase, it is possible > that keys received from the target will alter some of the > later keys offered so one may not want that phase to be > initiator sends all the keys it wants to originate then the target > sends all the keys it wants to originate. My understanding of earlier > reflector discussions is that is the way people want the negotiation > to operate. > > I think the method you propose would work, but it isn't consistant > with the kind of negotiation process the group appears to want. Oh, you don't have to send everything at once. :-) If you want to make some offers, see what comes back, and choose from there, you can. > Also see one response inserted below. > > Because of the request-response nature of > > negotiation plus the > > flexibility of allowing either side to make an offer > > plus the simplification > > that a negotiation is at most one offer and one > > response, the negotiation > > has to be PDU boundary aware. > > With a requirement for empty PDUs it doesn't. > The negotiation is completely PDU boundary agnostic. > > A requirement for empty PDUs doesn't do this. > It is a requirement that the target not originate > any keys non-declaritive keys until the Initiator > has somehow indicated it won't issue any more. In > what I wrote above, I really meant "the flexibility > of allowing either side to make an offer at any > point during the negotiation." True. The requirement for empty PDUs is just one way of keeping one side quiet while the other is making offers. Take care, Bill From owner-ips@ece.cmu.edu Tue May 28 21:42:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06142 for ; Tue, 28 May 2002 21:42:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4T0mYe27622 for ips-outgoing; Tue, 28 May 2002 20:48:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4T0mWw27618 for ; Tue, 28 May 2002 20:48:32 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 3FB969E9E; Tue, 28 May 2002 18:48:28 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id E99B9290; Tue, 28 May 2002 18:48:27 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 18:48:27 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 18:48:27 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C35334D@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: wrstuden@wasabisystems.com, Julian_Satran@il.ibm.com Cc: cbm@rose.hp.com, ips@ece.cmu.edu, mkrikis@yahoo.com Subject: RE: iSCSI: Negotiation clarifications still needed Date: Tue, 28 May 2002 18:48:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, My comments are inserted in line bracketed with my initials. Pat -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Tuesday, May 28, 2002 12:13 PM It's to avoid corner cases while doing what you say above, "preparing its strings and chopping them into PDUs." The simplest thing in my mind is to: 1) read the other side's offers into a buffer 2) parse that buffer generating responses to another buffer 3) send the output buffer Does that make sense? You don't have to agree, just does it make sense? The problem I see with what Pat described is that if you are in operational negotiation and have more than 1 PDU worth of data, you will be receiving input while you're in step 3. You have to be able to re-enter steps 1 & 2 before you can finish step 3. I think that is over stating the complexity. During negotiation, the other side can only have one PDU outstanding at a time. That is explictly stated for TextNegotiation PDUs. For LoginPDUs, it isn't explicit but since they are immediate and the initiator can only count on the target having one immediate buffer for the connection it can't send another LoginRequest until it gets the LoginResponse without risking that a PDU will be dropped. Also allowing anything other than one oustanding LoginPDU at a time would open the possibility that both sides offered the same key. Therefore, a target won't get the next PDU until after it sends the response PDU (or vice-versa for an initiator). A PDU won't come in while a PDU is being sent from the outgoing negotiation buffer. Once you send the PDU, there may still be some data left in the output buffer but it doesn't seem complex to switch at that point to waiting to receive and parse the next received PDU. One had better be able to switch from one process to another anyway as most implementations will handle multiple connections which can be in diffent phases. If you are willing to buffer all your output into a buffer and wait to send it until the other side has stopped sending new parameters, then all you need to do to change that to an implementation that sends what it has in the output buffer as it goes along is to have pointer into the buffer that indicates the next byte to be sent. The bit about sending empty PDUs is an effort to avoid that. We are either in a sending-negotiation-text mode, or a parsing mode. We don't have to worry about strings being partially there, since we don't process until they are. We also don't have to worry about if our key/value pairs cross a PDU. The parser/negotiatior is MUCH simpler; it doesn't have to deal with all of that. Letting the target answer while the initiator is trying to send an extended PDU adds the following complications (AFAICT): 1) initiator has to make sure a key and the '=' don't get split on a PDU boundry. One doesn't have to do that anyway. We can chose the rule to not offering a new (non-declarative key) when one has received a partial key which seemed to be acceptable to a number of people. 2) if an initiator fills up a PDU, it has to stop processing & wait for the response. It also has to remember where it is so that it can finish sending that key/value next time. It has to remember where it was and finish the key/value next time anyway as it can't send again until it gets a response. 3) The target has to detect a split key/value pair on in-bound, and a) store the received text, and b) remember not to offer said key or any others. detecting an incomplete key is reasonably easy. And the target can chose to do the simplist thing which is not to offer new keys when a partial key is outstanding. 4) The target ALSO has to make sure ITS response doesn't fill up a PDU. If it does, it has to remember where IT is and that it has more to send. In your approach the target can have a buffer with more than one PDU worth of response in it. Once it starts sending from that buffer it has to remember where it is and that it has more to send. This is not any different. There is a buffer with pointers into for end and last byte sent (or next byte to send). That's a lot of complexity and saved state. At least in my mind. I don't see much complexity difference here. If one wanted to make negotiation as simple as possible, one would make the Initiator the originator and have it solicit declarations with ?. When the group decided it wanted the flexibility of not offering keys if one was going to use the default value and letting the target offer such a key to force the negotiation of it, then a certain amount of complexity was introduced. That's the advantage I see of blank PDUs; we avoid all of the above complications. Truth be told, the corner cases probably don't apply at present. What we have (and are talking about) will work for security negotiation (we have to wait for the key to make it across) and for operational negotiation (since I don't think we have 8k worth of negotiation data). So for now the common case (no large vendor extentions) isn't going to tickle this set of problems. I agree. This means that plug fests probably haven't hit these cases. Does the statement of the perceived problem make sense, even if the opinion of the WG is to not use the empty PDUs? I would feel much comfortable with deciding to not use empty PDUs if folks said they understand the above point and they choose to address the problems differently. I want to point out that there are times in the protocol when one will have to send an empty PDU. For instance, when getting a security key that is longer than a the Max PDU size (or even less than that - the sender isn't required to send Max size PDUs) or when a device has no key-value pairs to send but its partner hasn't set the F bit. The issue is whether to require that there be a process for handing the right to originate keys (or in your proposal to send keys at all) keys from initiator to target and back which adds its own complexity. I think the complexity will be of the same order as the existing situation. Thoughts? Take care, Bill From owner-ips@ece.cmu.edu Tue May 28 21:42:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06155 for ; Tue, 28 May 2002 21:42:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4T1C6R28983 for ips-outgoing; Tue, 28 May 2002 21:12:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4T1C4w28978 for ; Tue, 28 May 2002 21:12:04 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id A36B0ABCC; Tue, 28 May 2002 19:12:03 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 533B0241; Tue, 28 May 2002 19:12:03 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 19:12:02 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 19:12:02 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353352@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: luben@splentec.com, pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: [iSCSI:] Logout request -- reason? Correction Date: Tue, 28 May 2002 19:12:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, I was refering to your statement "I was under the impression that byte 1 in BHS is a flags byte -- i.e. bit values." The BHS is what is defined in the template which says it is opcode specific, not a flags byte. If you want to be able to count on it being a flags byte, than that additional information would need to be added to the template. Some PDU types have 2-bit fields in the first byte (e.g. CSG and NSG), some have 3-bit fields. All these values are described as numeric values (e.g. CSG/NSG is described as having values 0,1 and 3). I don't see how a 2-bit value is okay in that location but a 7-bit value is not okay. I also note that it appears that only 3 bits of the Function field are actually used currently as the As an aside, I don't see that the spec describing a 2 to 8 bit field in decimal, hex or binary makes any difference to what the hardware/software does in processing those bits when the field is just a mapping of a type to a set of bits. It would be different if one was expected to do arithmetic operations on the field. The existing uses of the first byte are all mappings of a meaning to a bit pattern regardless of the representation of that bit pattern in the field. Of course, some day it could be used for a real number. It isn't a sound architectural idea to assume that fields which are OpCode specific will have a consistency of format across opcodes. If it isn't in the template then future OpCodes may be created that use that byte in different ways. I understood what you meant and I don't have to have the same reason to object as other people. Pat -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Tuesday, May 28, 2002 11:24 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: Re: [iSCSI:] Logout request -- reason? Correction pat_thaler@agilent.com wrote: > > Luben, > > I don't see where you got that impression. The BHS layout shows bytes 1 through > 3 as opcode specific fields. The kinds of opcode specific fields will be different > depending upon opcode. Pat, I KNOW about the BHS template. If you had read my mail carefully you'd notice that I mention that putting a bit value _and_ a numeric value in the same octet is not a sound architectural idea. Then you'd deduce that since the F bit is used in _that_ PDU, it'd be a good idea to leave the rest 7 bits be bits (thus making one octet) and use the _next_ _whole_ _empty_ _reserved_ octet for the status/response code. Certainly everyone else understood what I meant. And the objection was _not_ your argument, but the fact that we are running out of time. -- Luben From owner-ips@ece.cmu.edu Tue May 28 22:49:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07694 for ; Tue, 28 May 2002 22:49:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4T1rub01552 for ips-outgoing; Tue, 28 May 2002 21:53:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail2.hd.intel.com (hdfdns02.hd.intel.com [192.52.58.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4T1rsw01547 for ; Tue, 28 May 2002 21:53:54 -0400 (EDT) Received: from mkrikis-laptop (mkrikis-laptop.hd.intel.com [10.127.144.234]) by mail2.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with ESMTP id g4T1rm826116; Wed, 29 May 2002 01:53:49 GMT Received: from martinsk by mkrikis-laptop with local (Exim 3.35 #1 (Debian)) id 17CtaV-0000b9-00; Tue, 28 May 2002 21:53:23 -0500 To: ips@ece.cmu.edu, pat_thaler@agilent.com, wrstuden@wasabisystems.com Subject: RE: iSCSI: Negotiation clarifications still needed Message-Id: From: Martins Krikis Date: Tue, 28 May 2002 21:53:23 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk > It's to avoid corner cases while doing what you say above, "preparing > its > strings and chopping them into PDUs." > > The simplest thing in my mind is to: > > 1) read the other side's offers into a buffer > > 2) parse that buffer generating responses to another buffer > > 3) send the output buffer > > Does that make sense? You don't have to agree, just does it make sense? > > The problem I see with what Pat described is that if you are in > operational negotiation and have more than 1 PDU worth of data, you > will > be receiving input while you're in step 3. You have to be able to > re-enter > steps 1 & 2 before you can finish step 3. > > I think that is over stating the complexity. During negotiation, > the other side can only have one PDU outstanding at a time. That is > explictly > stated for TextNegotiation PDUs. For LoginPDUs, it isn't explicit but > since > they are immediate and the initiator can only count on the target > having one > immediate buffer for the connection it can't send another LoginRequest > until > it gets the LoginResponse without risking that a PDU will be dropped. > Also > allowing anything other than one oustanding LoginPDU at a time would > open > the possibility that both sides offered the same key. Therefore, a > target > won't get the next PDU until after it sends the response PDU (or > vice-versa > for an initiator). A PDU won't come in while a PDU is being sent from > the > outgoing negotiation buffer. Pat, I must interrupt you here. (A subliminal part of this exercise is to show how annoying interruptions are :-).) In order to argue your point I think you're intentionally trying to misunderstand Bill. He didn't talk about getting a new PDU while sending his PDU. He talked about getting an incoming non-empty PDU while sending his data _buffer_. This buffer could be much larger than a PDU. You cannot deny that this may happen with the scheme that you're arguing for. It cannot happen with the scheme that we're proposing, since only empty PDUs would be coming back while we're sending our (possibly much larger than PDUs) data buffers. > Once you send the PDU, there may still be some data left in the output > buffer but it doesn't seem complex to switch at that point to waiting > to > receive and parse the next received PDU. If you have noticed that a PDU is full, it is certainly possible to switch to a receiving mode. Yet it is even simpler not to have to notice. > One had better be able to switch > from one process to another anyway as most implementations will handle > multiple connections which can be in diffent phases. I don't see the relevance of this argument. > If you are willing > to buffer all your output into a buffer and wait to send it until the > other > side has stopped sending new parameters, then all you need to do to > change > that to an implementation that sends what it has in the output buffer > as > it goes along is to have pointer into the buffer that indicates the > next > byte to be sent. Not true, because as I'll start sending it, the other side may send me new offers, thus preempting me from making similar offers myself and instead requiring _responses_. > The bit about sending empty PDUs is an effort to avoid that. We are > either > in a sending-negotiation-text mode, or a parsing mode. We don't have to > worry about strings being partially there, since we don't process until > they are. We also don't have to worry about if our key/value pairs > cross a PDU. The parser/negotiatior is MUCH simpler; it doesn't have to > deal with all of that. > > Letting the target answer while the initiator is trying to send an > extended PDU adds the following complications (AFAICT): > > 1) initiator has to make sure a key and the '=' don't get split on a > PDU > boundry. > > One doesn't have to do that anyway. We can chose the rule to not > offering a new (non-declarative key) when one has received a partial > key > which seemed to be acceptable to a number of people. First I haven't yet seen anybody but you and myself speak about the declarative/non-declarative variation of this theme yet, so I wouldn't call it "acceptable to a number of people" yet, at least not if you include the parenthesized part. Overall, however, a truly aware Sender most likely will check whether a key and = got split or not. Because if it was split, and the other side originates a new key, it is a violation. It would be nice to catch it. And it definitely must check whether key=value fit fully or not. > 2) if an initiator fills up a PDU, it has to stop processing & wait for > the response. It also has to remember where it is so that it can finish > sending that key/value next time. > > It has to remember where it was and finish the key/value next > time > anyway as it can't send again until it gets a response. The difference is that in the scheme we're proposing we'd leave the unsent key=value pairs sitting in the "leftover" buffer, and happily mark all those keys individually as "sent". So we'll consider them processed, even though they may not have been put on the wire yet. With your scheme, you may not mark them as sent, so there is also little point having them stay in the buffer. The only thing that can safely stay in the buffer is the remainder of the last key=value pair, if it was sent partially. > 3) The target has to detect a split key/value pair on in-bound, and a) > store the received text, and b) remember not to offer said key or any > others. > > detecting an incomplete key is reasonably easy. And the target > can > chose to do the simplist thing which is not to offer new keys when a > partial key is outstanding. Yes, easy. Still harder than never dealing with an incomplete key at all. > 4) The target ALSO has to make sure ITS response doesn't fill up a PDU. > If > it does, it has to remember where IT is and that it has more to send. > > In your approach the target can have a buffer with more than > one PDU worth of response in it. Once it starts sending from that > buffer > it has to remember where it is and that it has more to send. This is > not any different. There is a buffer with pointers into for end and > last byte sent (or next byte to send). Yes, it is different, because keys can be marked "sent" and happily wait their physical send-out in the buffer. With your scheme you can't put them in a buffer and forget, because incoming data may force you to go back and start mangling the values you had assigned them... > That's a lot of complexity and saved state. At least in my mind. > > I don't see much complexity difference here. There is quite some difference in complexity, here. I think you're trying not to see it. > I agree. This means that plug fests probably haven't hit these > cases. That's why there is the famous Bill's experiment---set the PDU size to 64 bytes and try negotiating. > Does the statement of the perceived problem make sense, even if the > opinion of the WG is to not use the empty PDUs? I would feel much > comfortable with deciding to not use empty PDUs if folks said they > understand the above point and they choose to address the problems > differently. > > I want to point out that there are times in the protocol when > one will have to send an empty PDU. For instance, when getting a > security key that is longer than a the Max PDU size (or even less > than that - the sender isn't required to send Max size PDUs) or when > a device has no key-value pairs to send but its partner hasn't set > the F bit. The issue is whether to require that there be a process > for handing the right to originate keys (or in your proposal to send > keys at all) keys from initiator to target and back which adds > its own complexity. I think the complexity will be > of the same order as the existing situation. I think in both cases we do have a process to hand the right to originate/send to the other side and back and forth again. We are not trying to take this process away. The question is should the "handing over of the right (to originate/send)" happen after each PDU sent or should it happen after a data _buffer_ (possibly containing more key=value pairs than fit in a PDU) sent? Again a simple comparison to real life... Take the first text in this message written by me. How would you have liked to delete everything beneath it and to send the rest of your comments in a new message? Again, include only as little as there is until my next comment. That's when I'd interrupt you again and potentially mess with what you were planning to say. Pretty frustrating, wouldn't it be? OK, to be fair, I couldn't do it as often as I could want to, since you'd be entitled to one PDU worth of uninterrupted text in iSCSI. But it isn't as clean as "letting the speaker finish" (not the lecture, just the "complete thought"). Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. From owner-ips@ece.cmu.edu Tue May 28 22:50:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07709 for ; Tue, 28 May 2002 22:50:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4T1rjD01531 for ips-outgoing; Tue, 28 May 2002 21:53:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4T1riw01527 for ; Tue, 28 May 2002 21:53:44 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 2952D30706; Tue, 28 May 2002 21:53:39 -0400 (EDT) Date: Tue, 28 May 2002 18:51:42 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: , , , Subject: RE: iSCSI: Negotiation clarifications still needed In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C35334D@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 28 May 2002 pat_thaler@agilent.com wrote: > Bill, > > My comments are inserted in line bracketed with my initials. Thank you. I appreciate the time & attention you're putting into this. > -----Original Message----- > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] > Sent: Tuesday, May 28, 2002 12:13 PM > > > It's to avoid corner cases while doing what you say above, "preparing its > strings and chopping them into PDUs." > > The simplest thing in my mind is to: > > 1) read the other side's offers into a buffer > > 2) parse that buffer generating responses to another buffer > > 3) send the output buffer > > Does that make sense? You don't have to agree, just does it make sense? > > The problem I see with what Pat described is that if you are in > operational negotiation and have more than 1 PDU worth of data, you will > be receiving input while you're in step 3. You have to be able to re-enter > steps 1 & 2 before you can finish step 3. > > I think that is over stating the complexity. During negotiation, > the other side can only have one PDU outstanding at a time. That is explictly > stated for TextNegotiation PDUs. For LoginPDUs, it isn't explicit but since > they are immediate and the initiator can only count on the target having one > immediate buffer for the connection it can't send another LoginRequest until > it gets the LoginResponse without risking that a PDU will be dropped. Also > allowing anything other than one oustanding LoginPDU at a time would open > the possibility that both sides offered the same key. Therefore, a target > won't get the next PDU until after it sends the response PDU (or vice-versa > for an initiator). A PDU won't come in while a PDU is being sent from the > outgoing negotiation buffer. I agree. I didn't meant to imply we'd do something other than one PDU goes each direction at a time. You're right that to do THAT would be VERY messy. > Once you send the PDU, there may still be some data left in the output > buffer but it doesn't seem complex to switch at that point to waiting to > receive and parse the next received PDU. One had better be able to switch > from one process to another anyway as most implementations will handle > multiple connections which can be in diffent phases. If you are willing > to buffer all your output into a buffer and wait to send it until the other > side has stopped sending new parameters, then all you need to do to change > that to an implementation that sends what it has in the output buffer as > it goes along is to have pointer into the buffer that indicates the next > byte to be sent. I guess the question is where were you when you noticed that you had to stop? How much state do you need to save to pick things up at that point. What kind of design permits you to pick things back up at that point? While negotiations spanning PDUs will mean there is always some state to keep, the thing about empty PDUs is that there is no state in the parser code that needs saving; just where are we in the buffer we are sending or receiving. > Letting the target answer while the initiator is trying to send an > extended PDU adds the following complications (AFAICT): > > 1) initiator has to make sure a key and the '=' don't get split on a PDU > boundry. > > One doesn't have to do that anyway. We can chose the rule to not > offering a new (non-declarative key) when one has received a partial key > which seemed to be acceptable to a number of people. Maybe I'm confused. I thought I was talking about the case where the initiator is just realizing that what it wants to send won't fit. i.e. when we first realize, "oh, we're going to need to split this up." This is before the other side realizes the PDU is split. I was sloppy with my use of initiator and target. Sorry. :-( > 3) The target has to detect a split key/value pair on in-bound, and a) > store the received text, and b) remember not to offer said key or any > others. > > detecting an incomplete key is reasonably easy. And the target can > chose to do the simplist thing which is not to offer new keys when a > partial key is outstanding. > > 4) The target ALSO has to make sure ITS response doesn't fill up a PDU. If > it does, it has to remember where IT is and that it has more to send. > > In your approach the target can have a buffer with more than > one PDU worth of response in it. Once it starts sending from that buffer > it has to remember where it is and that it has more to send. This is > not any different. There is a buffer with pointers into for end and > last byte sent (or next byte to send). The one difference is that we could end up having both a partially-full input buffer to parse (because the info sent to us didn't fit a PDU) and a partially-full output buffer (since our output overflowed a PDU too). While you're right that the negotiation phase will work around this, having both buffers open at once is just a bit more complicated. > I don't see much complexity difference here. If one wanted to make > negotiation as simple as possible, one would make the Initiator the > originator and have it solicit declarations with ?. When the group > decided it wanted the flexibility of not offering keys if one was > going to use the default value and letting the target offer such a key > to force the negotiation of it, then a certain amount of complexity > was introduced. To quote code, what I'm envisioning is w/ the Empty PDU idea, things like PARAM_TEXT_PARSE_ELSE() in the intel code, and scan_input_and_process() in the UNH code can be used as-is. Without the empty PDU idea, they need to save more state. Maybe not much, but more. > Truth be told, the corner cases probably don't apply at present. What we > have (and are talking about) will work for security negotiation (we have > to wait for the key to make it across) and for operational negotiation > (since I don't think we have 8k worth of negotiation data). So for now the > common case (no large vendor extentions) isn't going to tickle this set of > problems. > > I agree. This means that plug fests probably haven't hit these > cases. Agreed. That's why I suggested that experiment. Just crank the PDU data size you (and this "you" is the whole list) use in login negotiations to something really small, like 128. Obviously you'd never ship such a thing, but just see what your code does, and what you think of what your code does. You'll find out real quick how well your code does in the case we're talking about here. > Does the statement of the perceived problem make sense, even if the > opinion of the WG is to not use the empty PDUs? I would feel much > comfortable with deciding to not use empty PDUs if folks said they > understand the above point and they choose to address the problems > differently. > > I want to point out that there are times in the protocol when > one will have to send an empty PDU. For instance, when getting a > security key that is longer than a the Max PDU size (or even less > than that - the sender isn't required to send Max size PDUs) or when > a device has no key-value pairs to send but its partner hasn't set > the F bit. The issue is whether to require that there be a process > for handing the right to originate keys (or in your proposal to send > keys at all) keys from initiator to target and back which adds > its own complexity. I think the complexity will be > of the same order as the existing situation. Well, then we have a difference of opinion. :-) So as John puts it we have moved to the personal opinion stage. :-) What do we want to decide? Take care, Bill From owner-ips@ece.cmu.edu Wed May 29 00:29:30 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09479 for ; Wed, 29 May 2002 00:29:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4T45ma08599 for ips-outgoing; Wed, 29 May 2002 00:05:48 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4T45kw08593 for ; Wed, 29 May 2002 00:05:47 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4T45dNU053360; Wed, 29 May 2002 06:05:39 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4T45cb44284; Wed, 29 May 2002 06:05:38 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: Negotiation value types and values X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 29 May 2002 07:05:34 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 29/05/2002 07:05:38, Serialize complete at 29/05/2002 07:05:38 Content-Type: multipart/alternative; boundary="=_alternative 001621C3C2256BC8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001621C3C2256BC8_= Content-Type: text/plain; charset="us-ascii" will fix them. Julo pat_thaler@agilent.com 05/29/2002 01:06 AM Please respond to pat_thaler To: "Julian Satran" cc: ips@ece.cmu.edu Subject: RE: iSCSI: Negotiation value types and values Julian, We have gone to the trouble of defining value types in 4.1 but then in 11 when we define some of the keys we don't say what value type each key takes. We define boolean-value in 4.1 but keys that take a boolean-value say "key=" in 11. I think they should say boolean-value. We define numerical-value, large-numerical-value and regular-numerical-value but keys in 11 take . (MaxConnections has a typo - "unsigned" is repeated.) They should take regular-numerical-value or numerical-value depending on size. portal-group-tag: 11.8 sends one to Annex D for information about portal-group-tag yet Annex D defines it fairly loosely as numeric, decimal. Target portal group tag (no hyphens) is defined in 11.9 as a 16 bit unsigned integer. Is the portal-group-tag sent as part of TargetAddress required to be in decimal notation or is it any regular-numerical-value or is it really a 16-bit binary string? Does it take the same formats as TargetPortalGroupTag? Which format applies to port? Pat --=_alternative 001621C3C2256BC8_= Content-Type: text/html; charset="us-ascii"
will fix them.  Julo


pat_thaler@agilent.com

05/29/2002 01:06 AM
Please respond to pat_thaler

       
        To:        "Julian Satran" <Julian_Satran@il.ibm.com>
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: Negotiation value types and values

       


Julian,
 
We have gone to the trouble of defining value types in 4.1 but then in 11 when we define some of the keys we don't say what value type each key takes.
 
We define boolean-value in 4.1 but keys that take a boolean-value say "key=<Yes|No>" in 11. I think they should say boolean-value.
 
We define numerical-value, large-numerical-value and regular-numerical-value but keys in 11 take <unsigned integer-from-x-to-y>. (MaxConnections has a typo - "unsigned" is repeated.) They should take regular-numerical-value or numerical-value depending on size.
 
portal-group-tag: 11.8 sends one to Annex D for information about portal-group-tag yet Annex D defines it fairly loosely as numeric, decimal. Target portal group tag (no hyphens) is defined in 11.9 as a 16 bit unsigned integer. Is the portal-group-tag sent as part of TargetAddress required to be in decimal notation or is it any regular-numerical-value or is it really a 16-bit binary string? Does it take the same formats as TargetPortalGroupTag?
 
Which format applies to port?
 
Pat

--=_alternative 001621C3C2256BC8_=-- From owner-ips@ece.cmu.edu Wed May 29 00:34:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09535 for ; Wed, 29 May 2002 00:34:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4T3ZWo06974 for ips-outgoing; Tue, 28 May 2002 23:35:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4T3ZUw06969 for ; Tue, 28 May 2002 23:35:30 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4T3ZSqU048584; Tue, 28 May 2002 23:35:29 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4T3ZRo89544; Tue, 28 May 2002 21:35:28 -0600 X-Priority: 1 (High) Importance: Normal Subject: iSCSI:Can each do there own thing? To: Martins Krikis Cc: ips@ece.cmu.edu, pat_thaler@agilent.com, wrstuden@wasabisystems.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Tue, 28 May 2002 20:33:22 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/28/2002 09:35:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I am starting a new thread. I am not sure that I have gotten all the nuances of the various proposals here, but ... I think I read, that if you receive a spanned PDU, that some want to keep some state and continue processing, while other are saying that it is easier if only an empty PDU is returned, until the complete PDU with nothing spanning is received. I may have this wrong, but the focus seems to be on the receiver of the spanned PDU, and the issues it has in keeping state etc. Now the rules we have now in the current draft level 12-94, some seem to say, are workable. But if someone sends empty PDUs, etc., that seems to work too, and some folks (at least 2) think that is a good idea. So are we at a point that says that empty PDUs are OK, and if used, you need to remember less stuff, but if you want to remember state, then go ahead, but be sure you do everything correctly? Let me ask two question then: 1. Is what I summarized correct with respect to the receiver? If not please itemize, the items that are broken, so that we can work on one at a time. 2. Is there an important issue with the offering side, that is not covered with the current spec. and will things work on the offering side if the Null PDU us sent from the receiver? Again, if no, please itemize. I get the feeling, and I maybe wrong here, that the various sides are trying to evangelize each other, even if the other side's approach works. I am not a big fan of evangelizing at this point. I am asking for a compromise that you folks can agree with that says something like, "yea, you can do it that way you silly so & so, but my way works too perhaps better", and the spec covers both implementations. This might not be possible but I am not sure we are converging. And we need to within a day or so. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Martins Krikis @ece.cmu.edu on 05/28/2002 07:53:23 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu, pat_thaler@agilent.com, wrstuden@wasabisystems.com cc: Subject: RE: iSCSI: Negotiation clarifications still needed > It's to avoid corner cases while doing what you say above, "preparing > its > strings and chopping them into PDUs." > > The simplest thing in my mind is to: > > 1) read the other side's offers into a buffer > > 2) parse that buffer generating responses to another buffer > > 3) send the output buffer > > Does that make sense? You don't have to agree, just does it make sense? > > The problem I see with what Pat described is that if you are in > operational negotiation and have more than 1 PDU worth of data, you > will > be receiving input while you're in step 3. You have to be able to > re-enter > steps 1 & 2 before you can finish step 3. > > I think that is over stating the complexity. During negotiation, > the other side can only have one PDU outstanding at a time. That is > explictly > stated for TextNegotiation PDUs. For LoginPDUs, it isn't explicit but > since > they are immediate and the initiator can only count on the target > having one > immediate buffer for the connection it can't send another LoginRequest > until > it gets the LoginResponse without risking that a PDU will be dropped. > Also > allowing anything other than one oustanding LoginPDU at a time would > open > the possibility that both sides offered the same key. Therefore, a > target > won't get the next PDU until after it sends the response PDU (or > vice-versa > for an initiator). A PDU won't come in while a PDU is being sent from > the > outgoing negotiation buffer. Pat, I must interrupt you here. (A subliminal part of this exercise is to show how annoying interruptions are :-).) In order to argue your point I think you're intentionally trying to misunderstand Bill. He didn't talk about getting a new PDU while sending his PDU. He talked about getting an incoming non-empty PDU while sending his data _buffer_. This buffer could be much larger than a PDU. You cannot deny that this may happen with the scheme that you're arguing for. It cannot happen with the scheme that we're proposing, since only empty PDUs would be coming back while we're sending our (possibly much larger than PDUs) data buffers. > Once you send the PDU, there may still be some data left in the output > buffer but it doesn't seem complex to switch at that point to waiting > to > receive and parse the next received PDU. If you have noticed that a PDU is full, it is certainly possible to switch to a receiving mode. Yet it is even simpler not to have to notice. > One had better be able to switch > from one process to another anyway as most implementations will handle > multiple connections which can be in diffent phases. I don't see the relevance of this argument. > If you are willing > to buffer all your output into a buffer and wait to send it until the > other > side has stopped sending new parameters, then all you need to do to > change > that to an implementation that sends what it has in the output buffer > as > it goes along is to have pointer into the buffer that indicates the > next > byte to be sent. Not true, because as I'll start sending it, the other side may send me new offers, thus preempting me from making similar offers myself and instead requiring _responses_. > The bit about sending empty PDUs is an effort to avoid that. We are > either > in a sending-negotiation-text mode, or a parsing mode. We don't have to > worry about strings being partially there, since we don't process until > they are. We also don't have to worry about if our key/value pairs > cross a PDU. The parser/negotiatior is MUCH simpler; it doesn't have to > deal with all of that. > > Letting the target answer while the initiator is trying to send an > extended PDU adds the following complications (AFAICT): > > 1) initiator has to make sure a key and the '=' don't get split on a > PDU > boundry. > > One doesn't have to do that anyway. We can chose the rule to not > offering a new (non-declarative key) when one has received a partial > key > which seemed to be acceptable to a number of people. First I haven't yet seen anybody but you and myself speak about the declarative/non-declarative variation of this theme yet, so I wouldn't call it "acceptable to a number of people" yet, at least not if you include the parenthesized part. Overall, however, a truly aware Sender most likely will check whether a key and = got split or not. Because if it was split, and the other side originates a new key, it is a violation. It would be nice to catch it. And it definitely must check whether key=value fit fully or not. > 2) if an initiator fills up a PDU, it has to stop processing & wait for > the response. It also has to remember where it is so that it can finish > sending that key/value next time. > > It has to remember where it was and finish the key/value next > time > anyway as it can't send again until it gets a response. The difference is that in the scheme we're proposing we'd leave the unsent key=value pairs sitting in the "leftover" buffer, and happily mark all those keys individually as "sent". So we'll consider them processed, even though they may not have been put on the wire yet. With your scheme, you may not mark them as sent, so there is also little point having them stay in the buffer. The only thing that can safely stay in the buffer is the remainder of the last key=value pair, if it was sent partially. > 3) The target has to detect a split key/value pair on in-bound, and a) > store the received text, and b) remember not to offer said key or any > others. > > detecting an incomplete key is reasonably easy. And the target > can > chose to do the simplist thing which is not to offer new keys when a > partial key is outstanding. Yes, easy. Still harder than never dealing with an incomplete key at all. > 4) The target ALSO has to make sure ITS response doesn't fill up a PDU. > If > it does, it has to remember where IT is and that it has more to send. > > In your approach the target can have a buffer with more than > one PDU worth of response in it. Once it starts sending from that > buffer > it has to remember where it is and that it has more to send. This is > not any different. There is a buffer with pointers into for end and > last byte sent (or next byte to send). Yes, it is different, because keys can be marked "sent" and happily wait their physical send-out in the buffer. With your scheme you can't put them in a buffer and forget, because incoming data may force you to go back and start mangling the values you had assigned them... > That's a lot of complexity and saved state. At least in my mind. > > I don't see much complexity difference here. There is quite some difference in complexity, here. I think you're trying not to see it. > I agree. This means that plug fests probably haven't hit these > cases. That's why there is the famous Bill's experiment---set the PDU size to 64 bytes and try negotiating. > Does the statement of the perceived problem make sense, even if the > opinion of the WG is to not use the empty PDUs? I would feel much > comfortable with deciding to not use empty PDUs if folks said they > understand the above point and they choose to address the problems > differently. > > I want to point out that there are times in the protocol when > one will have to send an empty PDU. For instance, when getting a > security key that is longer than a the Max PDU size (or even less > than that - the sender isn't required to send Max size PDUs) or when > a device has no key-value pairs to send but its partner hasn't set > the F bit. The issue is whether to require that there be a process > for handing the right to originate keys (or in your proposal to send > keys at all) keys from initiator to target and back which adds > its own complexity. I think the complexity will be > of the same order as the existing situation. I think in both cases we do have a process to hand the right to originate/send to the other side and back and forth again. We are not trying to take this process away. The question is should the "handing over of the right (to originate/send)" happen after each PDU sent or should it happen after a data _buffer_ (possibly containing more key=value pairs than fit in a PDU) sent? Again a simple comparison to real life... Take the first text in this message written by me. How would you have liked to delete everything beneath it and to send the rest of your comments in a new message? Again, include only as little as there is until my next comment. That's when I'd interrupt you again and potentially mess with what you were planning to say. Pretty frustrating, wouldn't it be? OK, to be fair, I couldn't do it as often as I could want to, since you'd be entitled to one PDU worth of uninterrupted text in iSCSI. But it isn't as clean as "letting the speaker finish" (not the lecture, just the "complete thought"). Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. From owner-ips@ece.cmu.edu Wed May 29 01:16:26 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10128 for ; Wed, 29 May 2002 01:16:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4T4S8h10241 for ips-outgoing; Wed, 29 May 2002 00:28:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailserver.dcmtech.co.in ([203.190.136.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4T4Rvw10222 for ; Wed, 29 May 2002 00:27:59 -0400 (EDT) Received: from localhost.localdomain ([192.9.200.195]) by mailserver.dcmtech.co.in (8.11.6/8.11.6) with SMTP id g4TDthU32659 for ; Wed, 29 May 2002 09:55:45 -0400 Content-Type: text/plain; charset="iso-8859-1" From: nayan garg Reply-To: nayan.garg@dcmtech.co.in Organization: Dcm Technologies To: ips@ece.cmu.edu Subject: Remove Date: Wed, 29 May 2002 09:53:46 +0530 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <0205290953460F.01271@localhost.localdomain> Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Remove From owner-ips@ece.cmu.edu Wed May 29 01:18:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10170 for ; Wed, 29 May 2002 01:18:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4T4P7k10081 for ips-outgoing; Wed, 29 May 2002 00:25:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4T4P4w10071 for ; Wed, 29 May 2002 00:25:04 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4T4Ow9D049010; Wed, 29 May 2002 06:24:58 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4T4Ovo22106; Wed, 29 May 2002 06:24:57 +0200 To: Eddy Quicksall Cc: "ips@ece. cmu. edu (E-mail)" MIME-Version: 1.0 Subject: Re: iSCSI: digest diagram X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 29 May 2002 07:24:52 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 29/05/2002 07:24:57, Serialize complete at 29/05/2002 07:24:57 Content-Type: multipart/alternative; boundary="=_alternative 001758D3C2256BC8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001758D3C2256BC8_= Content-Type: text/plain; charset="us-ascii" OK - Julo Eddy Quicksall 05/28/2002 11:59 PM Please respond to Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: "ips@ece. cmu. edu (E-mail)" Subject: iSCSI: digest diagram Julian, Would it make sense to break out the AHS and digest in the diagrams? I.e., for SCSI Command, the current diagram looks like this: +---------------+---------------+---------------+---------------+ 48| AHS (if any), Header Digest (if any) | +---------------+---------------+---------------+---------------+ / (DataSegment, Command Data + Data Digest (if any))(optional) / +/ / +---------------+---------------+---------------+---------------+ It would seem clearer if it looked like this: +---------------+---------------+---------------+---------------+ 48| AHS (if any) +---------------+---------------+---------------+---------------+ +/ Header Digest (if any) | +---------------+---------------+---------------+---------------+ / DataSegment - Command Data (if any) / +---------------+---------------+---------------+---------------+ +/ Data Digest (if any) / +---------------+---------------+---------------+---------------+ --=_alternative 001758D3C2256BC8_= Content-Type: text/html; charset="us-ascii"
OK - Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>

05/28/2002 11:59 PM
Please respond to Eddy Quicksall

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        "ips@ece. cmu. edu (E-mail)" <ips@ece.cmu.edu>
        Subject:        iSCSI: digest diagram

       


Julian,
 
Would it make sense to break out the AHS and digest in the diagrams? I.e., for SCSI Command, the current diagram looks like this:
 
  +---------------+---------------+---------------+---------------+
48| AHS (if any), Header Digest (if any)                          |
  +---------------+---------------+---------------+---------------+
  / (DataSegment, Command Data + Data Digest (if any))(optional)  /
 +/                                                               /
  +---------------+---------------+---------------+---------------+
 
It would seem clearer if it looked like this:
 
  +---------------+---------------+---------------+---------------+
48| AHS (if any)
  +---------------+---------------+---------------+---------------+
 +/ Header Digest (if any)                                        |
  +---------------+---------------+---------------+---------------+
  / DataSegment - Command Data (if any)                           /
  +---------------+---------------+---------------+---------------+
 +/ Data Digest (if any)                                          /
  +---------------+---------------+---------------+---------------+

--=_alternative 001758D3C2256BC8_=-- From owner-ips@ece.cmu.edu Wed May 29 01:19:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10191 for ; Wed, 29 May 2002 01:19:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4T4P5J10073 for ips-outgoing; Wed, 29 May 2002 00:25:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4T4P2w10063 for ; Wed, 29 May 2002 00:25:02 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4T4Or9D005304; Wed, 29 May 2002 06:24:53 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4T4Opo30810; Wed, 29 May 2002 06:24:52 +0200 To: Martins Krikis Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, pat_thaler@agilent.com, wrstuden@wasabisystems.com MIME-Version: 1.0 Subject: RE: iSCSI: Negotiation clarifications still needed X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 29 May 2002 07:24:44 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 29/05/2002 07:24:52, Serialize complete at 29/05/2002 07:24:52 Content-Type: multipart/alternative; boundary="=_alternative 0016C8D8C2256BC8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0016C8D8C2256BC8_= Content-Type: text/plain; charset="us-ascii" Martins & Pat, In going over the list of the arguments for the ongoing negotiation (that we have now) versus. "stop-until-you-have-full-buffer" I think that I am more inclined now to accept that Martins's point about absolute simplicity is valid and we should accept it (i.e., stop untill you have a full buffer. AFAIK it will not break any existing implementation as all/most of them are rudimentary and they are not in silicon (I hope). Regards, Julo Martins Krikis Sent by: owner-ips@ece.cmu.edu 05/29/2002 05:53 AM Please respond to Martins Krikis To: ips@ece.cmu.edu, pat_thaler@agilent.com, wrstuden@wasabisystems.com cc: Subject: RE: iSCSI: Negotiation clarifications still needed > It's to avoid corner cases while doing what you say above, "preparing > its > strings and chopping them into PDUs." > > The simplest thing in my mind is to: > > 1) read the other side's offers into a buffer > > 2) parse that buffer generating responses to another buffer > > 3) send the output buffer > > Does that make sense? You don't have to agree, just does it make sense? > > The problem I see with what Pat described is that if you are in > operational negotiation and have more than 1 PDU worth of data, you > will > be receiving input while you're in step 3. You have to be able to > re-enter > steps 1 & 2 before you can finish step 3. > > I think that is over stating the complexity. During negotiation, > the other side can only have one PDU outstanding at a time. That is > explictly > stated for TextNegotiation PDUs. For LoginPDUs, it isn't explicit but > since > they are immediate and the initiator can only count on the target > having one > immediate buffer for the connection it can't send another LoginRequest > until > it gets the LoginResponse without risking that a PDU will be dropped. > Also > allowing anything other than one oustanding LoginPDU at a time would > open > the possibility that both sides offered the same key. Therefore, a > target > won't get the next PDU until after it sends the response PDU (or > vice-versa > for an initiator). A PDU won't come in while a PDU is being sent from > the > outgoing negotiation buffer. Pat, I must interrupt you here. (A subliminal part of this exercise is to show how annoying interruptions are :-).) In order to argue your point I think you're intentionally trying to misunderstand Bill. He didn't talk about getting a new PDU while sending his PDU. He talked about getting an incoming non-empty PDU while sending his data _buffer_. This buffer could be much larger than a PDU. You cannot deny that this may happen with the scheme that you're arguing for. It cannot happen with the scheme that we're proposing, since only empty PDUs would be coming back while we're sending our (possibly much larger than PDUs) data buffers. > Once you send the PDU, there may still be some data left in the output > buffer but it doesn't seem complex to switch at that point to waiting > to > receive and parse the next received PDU. If you have noticed that a PDU is full, it is certainly possible to switch to a receiving mode. Yet it is even simpler not to have to notice. > One had better be able to switch > from one process to another anyway as most implementations will handle > multiple connections which can be in diffent phases. I don't see the relevance of this argument. > If you are willing > to buffer all your output into a buffer and wait to send it until the > other > side has stopped sending new parameters, then all you need to do to > change > that to an implementation that sends what it has in the output buffer > as > it goes along is to have pointer into the buffer that indicates the > next > byte to be sent. Not true, because as I'll start sending it, the other side may send me new offers, thus preempting me from making similar offers myself and instead requiring _responses_. > The bit about sending empty PDUs is an effort to avoid that. We are > either > in a sending-negotiation-text mode, or a parsing mode. We don't have to > worry about strings being partially there, since we don't process until > they are. We also don't have to worry about if our key/value pairs > cross a PDU. The parser/negotiatior is MUCH simpler; it doesn't have to > deal with all of that. > > Letting the target answer while the initiator is trying to send an > extended PDU adds the following complications (AFAICT): > > 1) initiator has to make sure a key and the '=' don't get split on a > PDU > boundry. > > One doesn't have to do that anyway. We can chose the rule to not > offering a new (non-declarative key) when one has received a partial > key > which seemed to be acceptable to a number of people. First I haven't yet seen anybody but you and myself speak about the declarative/non-declarative variation of this theme yet, so I wouldn't call it "acceptable to a number of people" yet, at least not if you include the parenthesized part. Overall, however, a truly aware Sender most likely will check whether a key and = got split or not. Because if it was split, and the other side originates a new key, it is a violation. It would be nice to catch it. And it definitely must check whether key=value fit fully or not. > 2) if an initiator fills up a PDU, it has to stop processing & wait for > the response. It also has to remember where it is so that it can finish > sending that key/value next time. > > It has to remember where it was and finish the key/value next > time > anyway as it can't send again until it gets a response. The difference is that in the scheme we're proposing we'd leave the unsent key=value pairs sitting in the "leftover" buffer, and happily mark all those keys individually as "sent". So we'll consider them processed, even though they may not have been put on the wire yet. With your scheme, you may not mark them as sent, so there is also little point having them stay in the buffer. The only thing that can safely stay in the buffer is the remainder of the last key=value pair, if it was sent partially. > 3) The target has to detect a split key/value pair on in-bound, and a) > store the received text, and b) remember not to offer said key or any > others. > > detecting an incomplete key is reasonably easy. And the target > can > chose to do the simplist thing which is not to offer new keys when a > partial key is outstanding. Yes, easy. Still harder than never dealing with an incomplete key at all. > 4) The target ALSO has to make sure ITS response doesn't fill up a PDU. > If > it does, it has to remember where IT is and that it has more to send. > > In your approach the target can have a buffer with more than > one PDU worth of response in it. Once it starts sending from that > buffer > it has to remember where it is and that it has more to send. This is > not any different. There is a buffer with pointers into for end and > last byte sent (or next byte to send). Yes, it is different, because keys can be marked "sent" and happily wait their physical send-out in the buffer. With your scheme you can't put them in a buffer and forget, because incoming data may force you to go back and start mangling the values you had assigned them... > That's a lot of complexity and saved state. At least in my mind. > > I don't see much complexity difference here. There is quite some difference in complexity, here. I think you're trying not to see it. > I agree. This means that plug fests probably haven't hit these > cases. That's why there is the famous Bill's experiment---set the PDU size to 64 bytes and try negotiating. > Does the statement of the perceived problem make sense, even if the > opinion of the WG is to not use the empty PDUs? I would feel much > comfortable with deciding to not use empty PDUs if folks said they > understand the above point and they choose to address the problems > differently. > > I want to point out that there are times in the protocol when > one will have to send an empty PDU. For instance, when getting a > security key that is longer than a the Max PDU size (or even less > than that - the sender isn't required to send Max size PDUs) or when > a device has no key-value pairs to send but its partner hasn't set > the F bit. The issue is whether to require that there be a process > for handing the right to originate keys (or in your proposal to send > keys at all) keys from initiator to target and back which adds > its own complexity. I think the complexity will be > of the same order as the existing situation. I think in both cases we do have a process to hand the right to originate/send to the other side and back and forth again. We are not trying to take this process away. The question is should the "handing over of the right (to originate/send)" happen after each PDU sent or should it happen after a data _buffer_ (possibly containing more key=value pairs than fit in a PDU) sent? Again a simple comparison to real life... Take the first text in this message written by me. How would you have liked to delete everything beneath it and to send the rest of your comments in a new message? Again, include only as little as there is until my next comment. That's when I'd interrupt you again and potentially mess with what you were planning to say. Pretty frustrating, wouldn't it be? OK, to be fair, I couldn't do it as often as I could want to, since you'd be entitled to one PDU worth of uninterrupted text in iSCSI. But it isn't as clean as "letting the speaker finish" (not the lecture, just the "complete thought"). Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. --=_alternative 0016C8D8C2256BC8_= Content-Type: text/html; charset="us-ascii"
Martins & Pat,

In going over the list of the arguments for the ongoing negotiation (that we have now) versus. "stop-until-you-have-full-buffer" I think that I am more inclined now to accept that Martins's point about absolute simplicity is valid and we should accept it (i.e., stop untill you have a full buffer.
AFAIK it  will not break any existing implementation as all/most of them are rudimentary and they are not in silicon (I hope).

Regards,
Julo


Martins Krikis <mkrikis@yahoo.com>
Sent by: owner-ips@ece.cmu.edu

05/29/2002 05:53 AM
Please respond to Martins Krikis

       
        To:        ips@ece.cmu.edu, pat_thaler@agilent.com, wrstuden@wasabisystems.com
        cc:        
        Subject:        RE: iSCSI: Negotiation clarifications still needed

       


> It's to avoid corner cases while doing what you say above, "preparing
> its
> strings and chopping them into PDUs."
>
> The simplest thing in my mind is to:
>
> 1) read the other side's offers into a buffer
>
> 2) parse that buffer generating responses to another buffer
>
> 3) send the output buffer
>
> Does that make sense? You don't have to agree, just does it make sense?
>
> The problem I see with what Pat described is that if you are in
> operational negotiation and have more than 1 PDU worth of data, you
> will
> be receiving input while you're in step 3. You have to be able to
> re-enter
> steps 1 & 2 before you can finish step 3.
>
> <PAT> I think that is over stating the complexity. During negotiation,
> the other side can only have one PDU outstanding at a time. That is
> explictly
> stated for TextNegotiation PDUs. For LoginPDUs, it isn't explicit but
> since
> they are immediate and the initiator can only count on the target
> having one
> immediate buffer for the connection it can't send another LoginRequest
> until
> it gets the LoginResponse without risking that a PDU will be dropped.
> Also
> allowing anything other than one oustanding LoginPDU at a time would
> open
> the possibility that both sides offered the same key. Therefore, a
> target
> won't get the next PDU until after it sends the response PDU (or
> vice-versa
> for an initiator). A PDU won't come in while a PDU is being sent from
> the
> outgoing negotiation buffer.

Pat, I must interrupt you here. (A subliminal part of this exercise
is to show how annoying interruptions are :-).) In order to argue your
point I think you're intentionally trying to misunderstand Bill.
He didn't talk about getting a new PDU while sending his PDU.
He talked about getting an incoming non-empty PDU while
sending his data _buffer_. This buffer could be much
larger than a PDU. You cannot deny that this may happen
with the scheme that you're arguing for. It cannot happen with the
scheme that we're proposing, since only empty PDUs would be coming
back while we're sending our (possibly much larger than PDUs) data
buffers.

> Once you send the PDU, there may still be some data left in the output
> buffer but it doesn't seem complex to switch at that point to waiting
> to
> receive and parse the next received PDU.

If you have noticed that a PDU is full, it is certainly possible to
switch to a receiving mode. Yet it is even simpler not to have to notice.

> One had better be able to switch
> from one process to another anyway as most implementations will handle
> multiple connections which can be in diffent phases.

I don't see the relevance of this argument.

> If you are willing
> to buffer all your output into a buffer and wait to send it until the
> other
> side has stopped sending new parameters, then all you need to do to
> change
> that to an implementation that sends what it has in the output buffer
> as
> it goes along is to have pointer into the buffer that indicates the
> next
> byte to be sent. <PAT>

Not true, because as I'll start sending it, the other side may
send me new offers, thus preempting me from making similar offers
myself and instead requiring _responses_.

> The bit about sending empty PDUs is an effort to avoid that. We are
> either
> in a sending-negotiation-text mode, or a parsing mode. We don't have to
> worry about strings being partially there, since we don't process until
> they are. We also don't have to worry about if our key/value pairs
> cross a PDU. The parser/negotiatior is MUCH simpler; it doesn't have to
> deal with all of that.
>
> Letting the target answer while the initiator is trying to send an
> extended PDU adds the following complications (AFAICT):
>
> 1) initiator has to make sure a key and the '=' don't get split on a
> PDU
> boundry.
>
> <PAT> One doesn't have to do that anyway. We can chose the rule to not
> offering a new (non-declarative key) when one has received a partial
> key
> which seemed to be acceptable to a number of people. <PAT>

First I haven't yet seen anybody but you and myself speak about the
declarative/non-declarative variation of this theme yet, so I wouldn't
call it "acceptable to a number of people" yet, at least not if
you include the parenthesized part. Overall, however,
a truly aware Sender most likely will check whether a key and =
got split or not. Because if it was split, and the other side
originates a new key, it is a violation. It would be nice to catch it.
And it definitely must check whether key=value fit fully or not.

> 2) if an initiator fills up a PDU, it has to stop processing & wait for
> the response. It also has to remember where it is so that it can finish
> sending that key/value next time.
>
> <PAT> It has to remember where it was and finish the key/value next
> time
> anyway as it can't send again until it gets a response. <PAT>

The difference is that in the scheme we're proposing we'd leave the
unsent key=value pairs sitting in the "leftover" buffer, and happily mark
all those keys individually as "sent". So we'll consider them
processed, even though they may not have been put on the wire yet.
With your scheme, you may not mark them as sent, so there is also
little point having them stay in the buffer. The only thing that
can safely stay in the buffer is the remainder of the last key=value pair,
if it was sent partially.

> 3) The target has to detect a split key/value pair on in-bound, and a)
> store the received text, and b) remember not to offer said key or any
> others.
>
> <PAT> detecting an incomplete key is reasonably easy. And the target
> can
> chose to do the simplist thing which is not to offer new keys when a
> partial key is outstanding. <PAT>

Yes, easy. Still harder than never dealing with an incomplete key at all.

> 4) The target ALSO has to make sure ITS response doesn't fill up a PDU.
> If
> it does, it has to remember where IT is and that it has more to send.
>
> <PAT> In your approach the target can have a buffer with more than
> one PDU worth of response in it. Once it starts sending from that
> buffer
> it has to remember where it is and that it has more to send. This is
> not any different. There is a buffer with pointers into for end and
> last byte sent (or next byte to send). <PAT>

Yes, it is different, because keys can be marked "sent" and happily
wait their physical send-out in the buffer. With your scheme you
can't put them in a buffer and forget, because incoming data may
force you to go back and start mangling the values you had assigned
them...

> That's a lot of complexity and saved state. At least in my mind.
>
> <PAT> I don't see much complexity difference here.

There is quite some difference in complexity, here. I think you're
trying not to see it.

<snip>

> <PAT> I agree. This means that plug fests probably haven't hit these
> cases. <PAT>

That's why there is the famous Bill's experiment---set the PDU size
to 64 bytes and try negotiating.

> Does the statement of the perceived problem make sense, even if the
> opinion of the WG is to not use the empty PDUs? I would feel much
> comfortable with deciding to not use empty PDUs if folks said they
> understand the above point and they choose to address the problems
> differently.
>
> <PAT> I want to point out that there are times in the protocol when
> one will have to send an empty PDU. For instance, when getting a
> security key that is longer than a the Max PDU size (or even less
> than that - the sender isn't required to send Max size PDUs) or when
> a device has no key-value pairs to send but its partner hasn't set
> the F bit. The issue is whether to require that there be a process
> for handing the right to originate keys (or in your proposal to send
> keys at all) keys from initiator to target and back which adds
> its own complexity. I think the complexity will be
> of the same order as the existing situation. <PAT>

I think in both cases we do have a process to hand the right to
originate/send to the other side and back and forth again. We are
not trying to take this process away. The question is should the
"handing over of the right (to originate/send)" happen after
each PDU sent or should it happen after a data _buffer_ (possibly
containing more key=value pairs than fit in a PDU) sent?

Again a simple comparison to real life... Take the first text
in this message written by me. How would you have liked to delete
everything beneath it and to send the rest of your comments
in a new message? Again, include only as little as there is
until my next comment. That's when I'd interrupt you again
and potentially mess with what you were planning to say.
Pretty frustrating, wouldn't it be? OK, to be fair, I couldn't
do it as often as I could want to, since you'd be entitled to one
PDU worth of uninterrupted text in iSCSI. But it isn't as clean
as "letting the speaker finish" (not the lecture, just the
"complete thought").

Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not be those of my employer.

--=_alternative 0016C8D8C2256BC8_=-- From owner-ips@ece.cmu.edu Wed May 29 04:00:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06805 for ; Wed, 29 May 2002 03:59:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4T7DWU18430 for ips-outgoing; Wed, 29 May 2002 03:13:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4T7DVw18425 for ; Wed, 29 May 2002 03:13:31 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4T7DPg5227064 for ; Wed, 29 May 2002 03:13:25 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4T7DOo85468 for ; Wed, 29 May 2002 01:13:24 -0600 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Wed, 29 May 2002 00:11:19 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/29/2002 01:13:23 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, In draft 12-94 the third paragraph under 9.10.4, ends with "...and)." I think something is either missing or something is left in that should be taken out. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Wed May 29 11:05:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20293 for ; Wed, 29 May 2002 11:05:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TE1VV21116 for ips-outgoing; Wed, 29 May 2002 10:01:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TE1Tw21109; Wed, 29 May 2002 10:01:29 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4TE1MAN057234; Wed, 29 May 2002 16:01:22 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4TE1LD09920; Wed, 29 May 2002 16:01:21 +0200 To: "John Hufferd" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 29 May 2002 17:01:17 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 29/05/2002 17:01:21, Serialize complete at 29/05/2002 17:01:21 Content-Type: multipart/alternative; boundary="=_alternative 004C1DACC2256BC8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004C1DACC2256BC8_= Content-Type: text/plain; charset="us-ascii" thanks - julo --=_alternative 004C1DACC2256BC8_= Content-Type: text/html; charset="us-ascii"
thanks - julo --=_alternative 004C1DACC2256BC8_=-- From owner-ips@ece.cmu.edu Wed May 29 11:56:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22193 for ; Wed, 29 May 2002 11:56:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TFCWW26490 for ips-outgoing; Wed, 29 May 2002 11:12:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TFCUw26484 for ; Wed, 29 May 2002 11:12:30 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g4TEB4u18751; Wed, 29 May 2002 10:11:04 -0400 Message-ID: <3CF4EFCB.44461920@splentec.com> Date: Wed, 29 May 2002 11:12:11 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: pat_thaler@agilent.com CC: ips@ece.cmu.edu Subject: Re: [iSCSI:] Logout request -- reason? Correction References: <1BEBA5E8600DD4119A50009027AF54A00C353352@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I see absolutely no point in replying to this. -- Luben pat_thaler@agilent.com wrote: > > Luben, > > I was refering to your statement "I was under the impression that byte 1 in > BHS is a flags byte -- i.e. bit values." The BHS is what is defined in the > template which says it is opcode specific, not a flags byte. If you want to > be able to count on it being a flags byte, than that additional information > would need to be added to the template. > > Some PDU types have 2-bit fields in the first byte (e.g. CSG and NSG), some > have 3-bit fields. All these values are described as numeric values (e.g. > CSG/NSG is described as having values 0,1 and 3). I don't see how a 2-bit > value is okay in that location but a 7-bit value is not okay. I also note > that it appears that only 3 bits of the Function field are actually used > currently as the > > As an aside, I don't see that the spec describing a 2 to 8 bit field in > decimal, hex or binary makes any difference to what the hardware/software > does in processing those bits when the field is just a mapping of a type to > a set of bits. It would be different if one was expected to do arithmetic > operations on the field. The existing uses of the first byte are all > mappings of a meaning to a bit pattern regardless of the representation of > that bit pattern in the field. Of course, some day it could be used for a > real number. > > It isn't a sound architectural idea to assume that fields which are OpCode > specific will have a consistency of format across opcodes. If it isn't in > the template then future OpCodes may be created that use that byte in > different ways. > > I understood what you meant and I don't have to have the same reason to > object as other people. From owner-ips@ece.cmu.edu Wed May 29 13:02:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24925 for ; Wed, 29 May 2002 13:02:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TGaAJ02792 for ips-outgoing; Wed, 29 May 2002 12:36:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TGa7w02784; Wed, 29 May 2002 12:36:07 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4TGZs9D047684; Wed, 29 May 2002 18:35:54 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4TGZoT09860; Wed, 29 May 2002 18:35:51 +0200 To: Paul Koning Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Confusing wording in description of Status-Class X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 29 May 2002 19:35:48 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 29/05/2002 19:35:53, Serialize complete at 29/05/2002 19:35:53 Content-Type: multipart/alternative; boundary="=_alternative 005A79F0C2256BC8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005A79F0C2256BC8_= Content-Type: text/plain; charset="us-ascii" I will say exception but not MUST as you may not to follow redirection before consulting an oracle :-) (only partly joking). Julo Paul Koning Sent by: owner-ips@ece.cmu.edu 05/29/2002 07:14 PM Please respond to Paul Koning To: ips@ece.cmu.edu cc: Subject: iSCSI: Confusing wording in description of Status-Class We have run into misinterpretations of the description of Status-Class (section 9.13.5). As written, it can be misread to say that Redirection (Status-Class = 1) is an error, and initiators can treat a redirection response from a target by failing the I/O rather than by following the redirection pointer. The current wording is: A non-zero Status-Class indicates an exception. In this case, Status- Class is sufficient for a simple initiator to use when handling errors, without having to look at the Status-Detail. The Status- Detail allows finer-grained error recovery for more sophisticated initiators, as well as better information for error logging. ... 1 - Redirection - indicates that the initiator must take further action to complete the request. This is usually due to the target moving to a different address. ... I would propose the following rewording: A non-zero Status-Class indicates an exception. In this case, Status- Class is sufficient for a simple initiator to use when handling exceptionss, without having to look at the Status-Detail. The Status- Detail allows finer-grained exception handling for more sophisticated initiators, as well as better information for error logging. ... 1 - Redirection - indicates that the initiator MUST take further action to complete the request. This is usually due to the target moving to a different address. ... The wording changes are: replace "error" by "exception" in the first paragraph, since redirects are not errors, and use "MUST" rather than "must" in the description of redirect. paul --=_alternative 005A79F0C2256BC8_= Content-Type: text/html; charset="us-ascii"
I will say exception but not MUST as you may not to follow redirection before consulting an oracle :-) (only partly joking).

Julo


Paul Koning <ni1d@arrl.net>
Sent by: owner-ips@ece.cmu.edu

05/29/2002 07:14 PM
Please respond to Paul Koning

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: Confusing wording in description of Status-Class

       


We have run into misinterpretations of the description of Status-Class
(section 9.13.5).  As written, it can be misread to say that
Redirection (Status-Class = 1) is an error, and initiators can treat a
redirection response from a target by failing the I/O rather than by
following the redirection pointer.

The current wording is:

    A non-zero Status-Class indicates an exception. In this case, Status-
    Class is sufficient for a simple initiator to use when handling
    errors, without having to look at the Status-Detail.  The Status-
    Detail allows finer-grained error recovery for more sophisticated
    initiators, as well as better information for error logging.
    ...
      1 - Redirection - indicates that the initiator must take further
           action to complete the request. This is usually due to the
           target moving to a different address. ...

I would propose the following rewording:

    A non-zero Status-Class indicates an exception. In this case, Status-
    Class is sufficient for a simple initiator to use when handling
    exceptionss, without having to look at the Status-Detail.  The Status-
    Detail allows finer-grained exception handling for more sophisticated
    initiators, as well as better information for error logging.
    ...
      1 - Redirection - indicates that the initiator MUST take further
           action to complete the request. This is usually due to the
           target moving to a different address. ...

The wording changes are: replace "error" by "exception" in the first
paragraph, since redirects are not errors, and use "MUST" rather than
"must" in the description of redirect.

      paul

--=_alternative 005A79F0C2256BC8_=-- From owner-ips@ece.cmu.edu Wed May 29 13:06:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25106 for ; Wed, 29 May 2002 13:06:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TGEpm01281 for ips-outgoing; Wed, 29 May 2002 12:14:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4TGEmw01267 for ; Wed, 29 May 2002 12:14:48 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4TGEgp25170 for ; Wed, 29 May 2002 12:14:42 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4TGEfc25164 for ; Wed, 29 May 2002 12:14:41 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g4TGEfX26963 for ; Wed, 29 May 2002 12:14:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15604.65137.364510.500030@pkoning.dev.equallogic.com> Date: Wed, 29 May 2002 12:14:41 -0400 From: Paul Koning To: ips@ece.cmu.edu Subject: iSCSI: Confusing wording in description of Status-Class X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit We have run into misinterpretations of the description of Status-Class (section 9.13.5). As written, it can be misread to say that Redirection (Status-Class = 1) is an error, and initiators can treat a redirection response from a target by failing the I/O rather than by following the redirection pointer. The current wording is: A non-zero Status-Class indicates an exception. In this case, Status- Class is sufficient for a simple initiator to use when handling errors, without having to look at the Status-Detail. The Status- Detail allows finer-grained error recovery for more sophisticated initiators, as well as better information for error logging. ... 1 - Redirection - indicates that the initiator must take further action to complete the request. This is usually due to the target moving to a different address. ... I would propose the following rewording: A non-zero Status-Class indicates an exception. In this case, Status- Class is sufficient for a simple initiator to use when handling exceptionss, without having to look at the Status-Detail. The Status- Detail allows finer-grained exception handling for more sophisticated initiators, as well as better information for error logging. ... 1 - Redirection - indicates that the initiator MUST take further action to complete the request. This is usually due to the target moving to a different address. ... The wording changes are: replace "error" by "exception" in the first paragraph, since redirects are not errors, and use "MUST" rather than "must" in the description of redirect. paul From owner-ips@ece.cmu.edu Wed May 29 13:43:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26438 for ; Wed, 29 May 2002 13:43:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TH11Z04765 for ips-outgoing; Wed, 29 May 2002 13:01:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TH0ww04754; Wed, 29 May 2002 13:00:58 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id B471FAF7D; Wed, 29 May 2002 11:00:46 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 3101B492; Wed, 29 May 2002 11:00:30 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 29 May 2002 11:00:27 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 11:00:27 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C3534B8@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, ni1d@arrl.net Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: Confusing wording in description of Status-Class Date: Wed, 29 May 2002 11:00:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-40660d73-fed1-4ae5-a373-4b2c2a38054f" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-40660d73-fed1-4ae5-a373-4b2c2a38054f Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20732.532CCF40" ------_=_NextPart_001_01C20732.532CCF40 Content-Type: text/plain; charset="iso-8859-1" Julian, I agree that there are valid reasons to chose not to follow redirection and not complete the connection. Therefore the must should stay lower case. For instance, if the TargetAddress indicated an external domain one might not choose to follow it or the TargetAddress might be a port to which one already has a connection open. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, May 29, 2002 9:36 AM To: Paul Koning Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: Confusing wording in description of Status-Class I will say exception but not MUST as you may not to follow redirection before consulting an oracle :-) (only partly joking). Julo Paul Koning Sent by: owner-ips@ece.cmu.edu 05/29/2002 07:14 PM Please respond to Paul Koning To: ips@ece.cmu.edu cc: Subject: iSCSI: Confusing wording in description of Status-Class We have run into misinterpretations of the description of Status-Class (section 9.13.5). As written, it can be misread to say that Redirection (Status-Class = 1) is an error, and initiators can treat a redirection response from a target by failing the I/O rather than by following the redirection pointer. The current wording is: A non-zero Status-Class indicates an exception. In this case, Status- Class is sufficient for a simple initiator to use when handling errors, without having to look at the Status-Detail. The Status- Detail allows finer-grained error recovery for more sophisticated initiators, as well as better information for error logging. ... 1 - Redirection - indicates that the initiator must take further action to complete the request. This is usually due to the target moving to a different address. ... I would propose the following rewording: A non-zero Status-Class indicates an exception. In this case, Status- Class is sufficient for a simple initiator to use when handling exceptionss, without having to look at the Status-Detail. The Status- Detail allows finer-grained exception handling for more sophisticated initiators, as well as better information for error logging. ... 1 - Redirection - indicates that the initiator MUST take further action to complete the request. This is usually due to the target moving to a different address. ... The wording changes are: replace "error" by "exception" in the first paragraph, since redirects are not errors, and use "MUST" rather than "must" in the description of redirect. paul ------_=_NextPart_001_01C20732.532CCF40 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
I agree that there are valid reasons to chose not to follow redirection and not complete the connection. Therefore the
must should stay lower case. For instance, if the TargetAddress indicated an external domain one might not
choose to follow it or the TargetAddress might be a port to which one already has a connection open.
 
Regards,
Pat
 
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, May 29, 2002 9:36 AM
To: Paul Koning
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: Confusing wording in description of Status-Class


I will say exception but not MUST as you may not to follow redirection before consulting an oracle :-) (only partly joking).

Julo


Paul Koning <ni1d@arrl.net>
Sent by: owner-ips@ece.cmu.edu

05/29/2002 07:14 PM
Please respond to Paul Koning

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: Confusing wording in description of Status-Class

       


We have run into misinterpretations of the description of Status-Class
(section 9.13.5).  As written, it can be misread to say that
Redirection (Status-Class = 1) is an error, and initiators can treat a
redirection response from a target by failing the I/O rather than by
following the redirection pointer.

The current wording is:

    A non-zero Status-Class indicates an exception. In this case, Status-
    Class is sufficient for a simple initiator to use when handling
    errors, without having to look at the Status-Detail.  The Status-
    Detail allows finer-grained error recovery for more sophisticated
    initiators, as well as better information for error logging.
    ...
      1 - Redirection - indicates that the initiator must take further
           action to complete the request. This is usually due to the
           target moving to a different address. ...

I would propose the following rewording:

    A non-zero Status-Class indicates an exception. In this case, Status-
    Class is sufficient for a simple initiator to use when handling
    exceptionss, without having to look at the Status-Detail.  The Status-
    Detail allows finer-grained exception handling for more sophisticated
    initiators, as well as better information for error logging.
    ...
      1 - Redirection - indicates that the initiator MUST take further
           action to complete the request. This is usually due to the
           target moving to a different address. ...

The wording changes are: replace "error" by "exception" in the first
paragraph, since redirects are not errors, and use "MUST" rather than
"must" in the description of redirect.

      paul



------_=_NextPart_001_01C20732.532CCF40-- ------=_NextPartTM-000-40660d73-fed1-4ae5-a373-4b2c2a38054f-- From owner-ips@ece.cmu.edu Wed May 29 14:25:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27856 for ; Wed, 29 May 2002 14:25:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4THug009153 for ips-outgoing; Wed, 29 May 2002 13:56:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4THudw09148 for ; Wed, 29 May 2002 13:56:40 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 5B98830706; Wed, 29 May 2002 13:56:39 -0400 (EDT) Date: Wed, 29 May 2002 10:54:41 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: John Hufferd Cc: Martins Krikis , , Subject: Re: iSCSI:Can each do there own thing? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 28 May 2002, John Hufferd wrote: > I am starting a new thread. Ok. :-) > I am not sure that I have gotten all the nuances of the various proposals > here, but ... > > I think I read, that if you receive a spanned PDU, that some want to keep > some state and continue processing, while other are saying that it is > easier if only an empty PDU is returned, until the complete PDU with > nothing spanning is received. I think that is a fair assessment. Well, we all agree some state will be needed, it's a matter of how much state. > I may have this wrong, but the focus seems to be on the receiver of the > spanned PDU, and the issues it has in keeping state etc. For me, the focus is on both. You are right that the receiver is easy to fix; just send empty PDUs and process at the end. The one thing we would need to add to the spec is a sentance saying you can't nail the other side for a negotiation error (for not answering keys) if you sent a split PDU or they sent a split PDU. The other messy part (not hard, just messy) is for the sender. And this part is why I personally favor empty PDUs. The sender has to be able to process new input packets before it has finished sending everything. i.e. it has to be able to deal with the other side interrupting it while it is speaking. If we forbid the receiver from originating new keys when it has received a split PDU, we make life easier on the sender, but it still has to be interruptable. > Now the rules we have now in the current draft level 12-94, some seem to > say, are workable. But if someone sends empty PDUs, etc., that seems to > work too, and some folks (at least 2) think that is a good idea. > > So are we at a point that says that empty PDUs are OK, and if used, you > need to remember less stuff, but if you want to remember state, then go > ahead, but be sure you do everything correctly? > > Let me ask two question then: > > 1. Is what I summarized correct with respect to the receiver? If not > please itemize, the items that are broken, so that we can work on one at a > time. I believe that is correct with respect to the receiver. The one thing new I mentioned is the fact you can't claim negotiation error when not all the keys you offered were returned *if* eithe you or the other side sent a split PDU. i.e. if one or both sides are still talking, you can't tell yet. > 2. Is there an important issue with the offering side, that is not covered > with the current spec. and will things work on the offering side if the > Null PDU us sent from the receiver? Again, if no, please itemize. As above, I think it's more what has to be in the sender if the receiver can send a non-empty PDU. > I get the feeling, and I maybe wrong here, that the various sides are > trying to evangelize each other, even if the other side's approach works. > I am not a big fan of evangelizing at this point. I'm trying to not evangelize. :-) > I am asking for a compromise that you folks can agree with that says > something like, "yea, you can do it that way you silly so & so, but my way > works too perhaps better", and the spec covers both implementations. This > might not be possible but I am not sure we are converging. And we need to > within a day or so. I think with the adjustments above (no offers when you got a split PDU and wait until no split PDUs to determine if a lack of replies is an error) would be sufficient. I think sending empty PDUs would be easier, but the above would suffice. Take care, Bill From owner-ips@ece.cmu.edu Wed May 29 14:29:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27962 for ; Wed, 29 May 2002 14:29:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4THiZJ08178 for ips-outgoing; Wed, 29 May 2002 13:44:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4THiVw08173; Wed, 29 May 2002 13:44:32 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4THiQp26692; Wed, 29 May 2002 13:44:26 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4THiPc26680; Wed, 29 May 2002 13:44:25 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g4THiPf30055; Wed, 29 May 2002 13:44:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15605.4985.305171.597146@pkoning.dev.equallogic.com> Date: Wed, 29 May 2002 13:44:25 -0400 From: Paul Koning To: pat_thaler@agilent.com Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI: Confusing wording in description of Status-Class References: <1BEBA5E8600DD4119A50009027AF54A00C3534B8@axcs04.cos.agilent.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "pat" == pat thaler writes: pat> Julian, I agree that there are valid reasons to chose not to pat> follow redirection and not complete the connection. Therefore pat> the must should stay lower case. For instance, if the pat> TargetAddress indicated an external domain one might not choose pat> to follow it or the TargetAddress might be a port to which one pat> already has a connection open. Thanks, that explanation helps. What I was looking for was agreement that simply saying "Redirect is an error, I don't ever do redirect, I just fail the I/O" is not right. paul > -----Original Message----- From: Julian Satran > I will say exception but not MUST as you may not to follow > redirection before consulting an oracle :-) (only partly > joking). > Julo pat> Paul Koning Sent by: owner-ips@ece.cmu.edu pat> 05/29/2002 07:14 PM Please respond to Paul Koning pat> To: ips@ece.cmu.edu cc: Subject: iSCSI: Confusing wording in pat> description of Status-Class pat> We have run into misinterpretations of the description of pat> Status-Class (section 9.13.5). As written, it can be misread to pat> say that Redirection (Status-Class = 1) is an error, and pat> initiators can treat a redirection response from a target by pat> failing the I/O rather than by following the redirection pat> pointer. pat> The current wording is: pat> A non-zero Status-Class indicates an exception. In this case, pat> Status- Class is sufficient for a simple initiator to use when pat> handling errors, without having to look at the Status-Detail. pat> The Status- Detail allows finer-grained error recovery for more pat> sophisticated initiators, as well as better information for pat> error logging. ... 1 - Redirection - indicates that the pat> initiator must take further action to complete the request. This pat> is usually due to the target moving to a different address. ... pat> I would propose the following rewording: pat> A non-zero Status-Class indicates an exception. In this case, pat> Status- Class is sufficient for a simple initiator to use when pat> handling exceptionss, without having to look at the pat> Status-Detail. The Status- Detail allows finer-grained pat> exception handling for more sophisticated initiators, as well as pat> better information for error logging. ... 1 - Redirection - pat> indicates that the initiator MUST take further action to pat> complete the request. This is usually due to the target moving pat> to a different address. ... pat> The wording changes are: replace "error" by "exception" in the pat> first paragraph, since redirects are not errors, and use "MUST" pat> rather than "must" in the description of redirect. pat> paul pat> pat> pat> pat>
size=2>Julian,
class=155254816-29052002> size=2> 
class=155254816-29052002>I agree that pat> there are valid reasons to chose not to follow redirection and pat> not complete the connection. Therefore the
pat>
must pat> should stay lower case. For instance, if the TargetAddress pat> indicated an external domain one might not
pat>
size=2>choose to follow it or the TargetAddress might be a port pat> to which one already has a connection open.
pat>
size=2> 
class=155254816-29052002> size=2>Regards,
class=155254816-29052002> size=2>Pat
class=155254816-29052002> size=2> 
class=155254816-29052002> size=2> 
class=OutlookMessageHeader dir=ltr align=left> size=2>-----Original Message-----
From: Julian Satran pat> [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, May pat> 29, 2002 9:36 AM
To: Paul Koning
Cc: pat> ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: pat> iSCSI: Confusing wording in description of pat> Status-Class


size=2>I will say exception but not MUST as you may not to pat> follow redirection before consulting an oracle :-) (only partly pat> joking).

Julo pat>


pat> Paul Koning pat> <ni1d@arrl.net>
size=1>Sent by: owner-ips@ece.cmu.edu

face=sans-serif size=1>05/29/2002 07:14 PM
face=sans-serif size=1>Please respond to Paul Koning pat>

        pat>
      pat>   To:        ips@ece.cmu.edu pat>
        cc: pat>        
size=1>        Subject:       pat>  iSCSI: Confusing wording in description of pat> Status-Class

  pat>      


face="Courier New" size=2>We have run into misinterpretations of pat> the description of Status-Class
(section 9.13.5).  As pat> written, it can be misread to say that
Redirection pat> (Status-Class = 1) is an error, and initiators can treat pat> a
redirection response from a target by failing the I/O pat> rather than by
following the redirection pointer.

The pat> current wording is:

    A non-zero Status-Class pat> indicates an exception. In this case, Status-
    pat> Class is sufficient for a simple initiator to use when handling pat>
    errors, without having to look at the pat> Status-Detail.  The Status-
    Detail allows pat> finer-grained error recovery for more sophisticated
  pat>   initiators, as well as better information for error pat> logging.
    ...
      1 - pat> Redirection - indicates that the initiator must take further pat>
           action to complete pat> the request. This is usually due to the
      pat>      target moving to a different pat> address. ...

I would propose the following pat> rewording:

    A non-zero Status-Class pat> indicates an exception. In this case, Status-
    pat> Class is sufficient for a simple initiator to use when handling pat>
    exceptionss, without having to look at the pat> Status-Detail.  The Status-
    Detail allows pat> finer-grained exception handling for more sophisticated pat>
    initiators, as well as better information for pat> error logging.
    ...
      1 - pat> Redirection - indicates that the initiator MUST take further pat>
           action to complete pat> the request. This is usually due to the
    pat>        target moving to a different pat> address. ...

The wording changes are: replace "error" by pat> "exception" in the first
paragraph, since redirects are not pat> errors, and use "MUST" rather than
"must" in the description pat> of redirect.

      pat> paul



From owner-ips@ece.cmu.edu Wed May 29 15:51:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01095 for ; Wed, 29 May 2002 15:51:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TJEci15335 for ips-outgoing; Wed, 29 May 2002 15:14:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TJEXw15324 for ; Wed, 29 May 2002 15:14:34 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 2594D68B3; Wed, 29 May 2002 13:14:33 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id DF734D5; Wed, 29 May 2002 13:14:32 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 29 May 2002 13:14:32 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 13:14:32 -0600 Message-ID: <9F8400020EC5D311AF62009027C396160902C3EE@axcs09.cos.agilent.com> From: "LEMAY,KEVIN (A-Roseville,ex1)" To: "'ips@ece.cmu.edu'" Cc: "'Julian_Satran@il.ibm.com'" Subject: ISCSI: Error Recovery Level 0 Date: Wed, 29 May 2002 13:14:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I have the following question on error Recovery level 0. On page 105, v12, it says that error recovery level 0 must perform Session recovery as described in 6.12.4. This seems to imply that: If I have a multi-connection session were one connection experiences a digest error, then I must close all connections on the session, even killing IOs over the good connection. This is absurd! Why not just close the one connection that has a problem and allow the IO to be restarted on one of the other live connections? There is nothing wrong with the session, only a single connection. I guess I am calling for a level 0.5, so that I can abort only the troublesome connection. This would allow for a much faster IO recovery without adding hardly any coding complexity that is required for level 1. Comments? Kevin Lemay From owner-ips@ece.cmu.edu Wed May 29 17:56:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04971 for ; Wed, 29 May 2002 17:56:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TLBFZ24503 for ips-outgoing; Wed, 29 May 2002 17:11:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TLBDw24498; Wed, 29 May 2002 17:11:13 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id BFBEB30714; Wed, 29 May 2002 17:11:12 -0400 (EDT) Date: Wed, 29 May 2002 14:09:14 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Martins Krikis , , , Subject: RE: iSCSI: Negotiation clarifications still needed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 29 May 2002, Julian Satran wrote: > Martins & Pat, > > In going over the list of the arguments for the ongoing negotiation (that > we have now) versus. "stop-until-you-have-full-buffer" I think that I am > more inclined now to accept that Martins's point about absolute simplicity > is valid and we should accept it (i.e., stop untill you have a full > buffer. > AFAIK it will not break any existing implementation as all/most of them > are rudimentary and they are not in silicon (I hope). If there is intereste, I'm willing to help write suggested algorithms to implement this, a la appendix E. Take care, Bill From owner-ips@ece.cmu.edu Wed May 29 17:56:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05015 for ; Wed, 29 May 2002 17:56:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TLAc424447 for ips-outgoing; Wed, 29 May 2002 17:10:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TLAbw24443 for ; Wed, 29 May 2002 17:10:37 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4TLAY29033674; Wed, 29 May 2002 17:10:35 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4TLAXi140080; Wed, 29 May 2002 15:10:33 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: ISCSI: Error Recovery Level 0 To: "LEMAY,KEVIN (A-Roseville,ex1)" Cc: "'ips@ece.cmu.edu'" , "Julian Satran" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Wed, 29 May 2002 14:06:34 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/29/2002 03:10:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Kevin, What you are asking for is Level 2, connection level recovery. We agreed on these levels at a Face to Face meeting, since folks ask us to make the spec. simpler. We all agreed on only having official levels 0,1 & 2. Level 2 has all you want, even if you do not want to have anything to do with level 1 (within command recovery) you can always terminate and recover the connection. If you attempt to make level 1 a "no-op" level, you still have to field the SNACK on the Target Side, but you can decide to react with a connection recovery. Likewise on the Initiator side, you can decide to Logout the connection instead of sending a SNACK. Everything will work, but for the sake of your customers you need to state that you do not do within command recovery, even if you generally act at recovery level 2. In any event, within command-recovery is fairly simple, and you should try your best, then punt with a connection logout. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "LEMAY,KEVIN (A-Roseville,ex1)" @ece.cmu.edu on 05/29/2002 12:14:30 PM Sent by: owner-ips@ece.cmu.edu To: "'ips@ece.cmu.edu'" cc: Julian Satran/Haifa/IBM@IBMIL Subject: ISCSI: Error Recovery Level 0 I have the following question on error Recovery level 0. On page 105, v12, it says that error recovery level 0 must perform Session recovery as described in 6.12.4. This seems to imply that: If I have a multi-connection session were one connection experiences a digest error, then I must close all connections on the session, even killing IOs over the good connection. This is absurd! Why not just close the one connection that has a problem and allow the IO to be restarted on one of the other live connections? There is nothing wrong with the session, only a single connection. I guess I am calling for a level 0.5, so that I can abort only the troublesome connection. This would allow for a much faster IO recovery without adding hardly any coding complexity that is required for level 1. Comments? Kevin Lemay From owner-ips@ece.cmu.edu Wed May 29 18:06:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05263 for ; Wed, 29 May 2002 18:06:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TLRA725684 for ips-outgoing; Wed, 29 May 2002 17:27:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TLR7w25678 for ; Wed, 29 May 2002 17:27:07 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id ED615B98A; Wed, 29 May 2002 15:27:05 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 3D5982D2; Wed, 29 May 2002 15:26:59 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 29 May 2002 15:26:55 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 15:26:55 -0600 Message-ID: <9F8400020EC5D311AF62009027C396160902C3F0@axcs09.cos.agilent.com> From: kevin_lemay@agilent.com To: hufferd@us.ibm.com Cc: ips@ece.cmu.edu, Julian_Satran@il.ibm.com Subject: RE: ISCSI: Error Recovery Level 0 Date: Wed, 29 May 2002 15:26:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Level 2 is not what I want at all! In order to support level 2, I have to support level 1 plus support IO re-assignment too. I think that the data retransmission may not be worth the effort for all implementations. It is a hierarchy after all. Level 0 is too simple - Very big hammer. Proposed 0.5 - Simple and smaller hammer Level 1 - Complex and for the number of expected errors, maybe not worth the effort. You may have had a face to face, but I sure didn't. I don't think that the current scheme provides what I want. I understand the level 0 is for simple devices. I think that there is room for something between level 0 and 1 that is still easy to implement, but does not take the performance hit of bringing the entire session down. Modifing level 0 to only drop the troublesome connection would be OK too. Retransmission is easy or hard depending on whether you are allowed to access the data more than once. Kevin Lemay -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Wednesday, May 29, 2002 2:07 PM To: LEMAY,KEVIN (A-Roseville,ex1) Cc: 'ips@ece.cmu.edu'; Julian Satran Subject: Re: ISCSI: Error Recovery Level 0 Kevin, What you are asking for is Level 2, connection level recovery. We agreed on these levels at a Face to Face meeting, since folks ask us to make the spec. simpler. We all agreed on only having official levels 0,1 & 2. Level 2 has all you want, even if you do not want to have anything to do with level 1 (within command recovery) you can always terminate and recover the connection. If you attempt to make level 1 a "no-op" level, you still have to field the SNACK on the Target Side, but you can decide to react with a connection recovery. Likewise on the Initiator side, you can decide to Logout the connection instead of sending a SNACK. Everything will work, but for the sake of your customers you need to state that you do not do within command recovery, even if you generally act at recovery level 2. In any event, within command-recovery is fairly simple, and you should try your best, then punt with a connection logout. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "LEMAY,KEVIN (A-Roseville,ex1)" @ece.cmu.edu on 05/29/2002 12:14:30 PM Sent by: owner-ips@ece.cmu.edu To: "'ips@ece.cmu.edu'" cc: Julian Satran/Haifa/IBM@IBMIL Subject: ISCSI: Error Recovery Level 0 I have the following question on error Recovery level 0. On page 105, v12, it says that error recovery level 0 must perform Session recovery as described in 6.12.4. This seems to imply that: If I have a multi-connection session were one connection experiences a digest error, then I must close all connections on the session, even killing IOs over the good connection. This is absurd! Why not just close the one connection that has a problem and allow the IO to be restarted on one of the other live connections? There is nothing wrong with the session, only a single connection. I guess I am calling for a level 0.5, so that I can abort only the troublesome connection. This would allow for a much faster IO recovery without adding hardly any coding complexity that is required for level 1. Comments? Kevin Lemay From owner-ips@ece.cmu.edu Wed May 29 18:33:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05813 for ; Wed, 29 May 2002 18:33:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TLjvF26952 for ips-outgoing; Wed, 29 May 2002 17:45:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TLjtw26947 for ; Wed, 29 May 2002 17:45:55 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id 56DA2600912 for ; Wed, 29 May 2002 14:45:49 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id OAA21981 for ; Wed, 29 May 2002 14:47:36 -0700 (PDT) Message-ID: <001201c2075a$316e2bb0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: References: <9F8400020EC5D311AF62009027C396160902C3EE@axcs09.cos.agilent.com> Subject: Re: ISCSI: Error Recovery Level 0 Date: Wed, 29 May 2002 14:45:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Kevin, From: "LEMAY,KEVIN (A-Roseville,ex1)" > I have the following question on error Recovery level 0. > > On page 105, v12, it says that error recovery level 0 must perform Session recovery as described in 6.12.4. I can't find it. It's only saying that the minimally expected error recovery capabilities for level 0 are as described in 6.12.4, not that session recovery must be performed for every error.... If you look in 6.12.4, it specifically states that session recovery is done only if all other recovery attempts fail. > > This seems to imply that: > If I have a multi-connection session were one connection experiences a digest error, then I must close all connections on the session, even killing IOs over the good connection. > > This is absurd! Indeed it would be if so implemented (even while it's legal). >Why not just close the one connection that has a problem and allow the IO to be restarted on one of the other live connections? There is nothing wrong with the session, only a single connection. That's a reasonable recovery strategy (if it's a SCSI restart). -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com > > I guess I am calling for a level 0.5, so that I can abort only the troublesome connection. This would allow for a much faster IO recovery without adding hardly any coding complexity that is required for level 1. > > Comments? > > Kevin Lemay > From owner-ips@ece.cmu.edu Wed May 29 18:33:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05841 for ; Wed, 29 May 2002 18:33:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TLeIi26597 for ips-outgoing; Wed, 29 May 2002 17:40:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TLeFw26587 for ; Wed, 29 May 2002 17:40:15 -0400 (EDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 29 May 2002 14:40:09 -0700 Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 29 May 2002 14:40:08 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 29 May 2002 14:40:08 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 29 May 2002 14:40:08 -0700 Received: from win-msg-03.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.198]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Wed, 29 May 2002 14:40:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: iSCSI: CRC32C Table generation Date: Wed, 29 May 2002 14:40:07 -0700 Message-ID: Thread-Topic: iSCSI: CRC32C Table generation thread-index: AcIHUT0JnUR0oRKHSriMEkJcuO/CiQABrhug From: "Lakshmi Ramasubramanian" To: , X-OriginalArrivalTime: 29 May 2002 21:40:08.0166 (UTC) FILETIME=[67050060:01C20759] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g4TLeFw26589 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit In the code given in RFC-1952 for generating the table for CRC32 algorithm, the constant 0xedb88320 is used. Since this constant is derived from the polynomial, it's different than 0xedb88320 for iSCSI. It took some effort to find out the steps to arrive at the constant from the given CRC32 polynomial. May I suggest we include this conversion steps in an appendix in the spec? thanks! -lakshmi From owner-ips@ece.cmu.edu Wed May 29 18:33:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05869 for ; Wed, 29 May 2002 18:33:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TM3u028168 for ips-outgoing; Wed, 29 May 2002 18:03:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail1.hd.intel.com (hdfdns01.hd.intel.com [192.52.58.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TM3tw28164 for ; Wed, 29 May 2002 18:03:55 -0400 (EDT) Received: from mkrikis-laptop (mkrikis-laptop.hd.intel.com [10.127.144.234]) by mail1.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with ESMTP id g4TM3lL10567; Wed, 29 May 2002 22:03:47 GMT Received: from martinsk by mkrikis-laptop with local (Exim 3.35 #1 (Debian)) id 17DCTP-0000mG-00; Wed, 29 May 2002 18:03:19 -0500 To: hufferd@us.ibm.com, ips@ece.cmu.edu, pat_thaler@agilent.com, wrstuden@wasabisystems.com Subject: Re: iSCSI:Can each do there own thing? Message-Id: From: Martins Krikis Date: Wed, 29 May 2002 18:03:19 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk This isn't a very interesting reply, but the next mail is a a very important read, IMHO. Please read that one carefully, a compromise is included there. > > I may have this wrong, but the focus seems to be on the receiver of the > > spanned PDU, and the issues it has in keeping state etc. > > For me, the focus is on both. Yes, in particular, I think sending is harder to implement w/o the guarantee of only empty PDUs coming back. > You are right that the receiver is easy to > fix; just send empty PDUs and process at the end. The one thing we would > need to add to the spec is a sentance saying you can't nail the other side > for a negotiation error (for not answering keys) if you sent a split PDU > or they sent a split PDU. I don't think that there is a requirement to answer all received keys as soon as possible. They may not all fit, so this is not even possible in general. And split PDUs may be unavoidable, too. What we need added to the draft is some restrictions that would make it impossible for both sides to feel like they originated a key. Currently, if one side sends part of the key, it may feel well entitled to consider that key as sent, but the other side is not mandated to consider this partially received key as received, so it may send it too---with disastrous results for the negotiation. > The other messy part (not hard, just messy) is for the sender. And this > part is why I personally favor empty PDUs. The sender has to be able to > process new input packets before it has finished sending everything. i.e. > it has to be able to deal with the other side interrupting it while it is > speaking. Yes, and for this reason it cannot simply do what many consider the simplest aproach---create all the key=value pairs that would be nice to process in one batch, and pass them down to the encapsulation layer without worrying how many will fit in the first PDU. > If we forbid the receiver from originating new keys when it has received a > split PDU, we make life easier on the sender, but it still has to be > interruptable. By forbidding origination on split PDUs we avoid the possibility of both sides feeling like originators. It is a step in the right direction. In order to deal with interruptability, we need to forbid sending anything until the other side hasn't finished. (For better definitions please see the next mail from me.) > > Now the rules we have now in the current draft level 12-94, some seem to > > say, are workable. Well, there is not enough of those rules, hence the above mentioned possibility of both sides feeling like originators for the same key. But there is work in progress here, so 12-95 may have the missing rule(s). > > But if someone sends empty PDUs, etc., that seems to > > work too, and some folks (at least 2) think that is a good idea. Guarantee of receiving only empty PDUs is more important than ability to send them (that already exists). > > So are we at a point that says that empty PDUs are OK, and if used, you > > need to remember less stuff, but if you want to remember state, then go > > ahead, but be sure you do everything correctly? Without guarantees of empty PDUs there is more work at sending even for an implementation which is "empty-PDU-favoring". > > Let me ask two question then: > > > > 1. Is what I summarized correct with respect to the receiver? If not > > please itemize, the items that are broken, so that we can work on one at a > > time. > > I believe that is correct with respect to the receiver. So do I. Receiver is not the hard part, because it is easy to be "polite towards the sender" and send only empty PDUs. And with any scheme you have to notice that you're forbidden to do something. > The one thing new I mentioned is the fact you can't claim negotiation > error when not all the keys you offered were returned *if* eithe you or > the other side sent a split PDU. i.e. if one or both sides are still > talking, you can't tell yet. Again, I don't think it is an error to send a belated (many PDUs later) response to a key, as long as it is sent in the same negotiation sequence. It is also not an error to send empty PDUs (as many times as one wants w/o any reason whatsoever). And both these things are fine in my eyes, so I may not be understanding the issue here... > > 2. Is there an important issue with the offering side, that is not covered > > with the current spec. and will things work on the offering side if the > > Null PDU us sent from the receiver? Again, if no, please itemize. > > As above, I think it's more what has to be in the sender if the receiver > can send a non-empty PDU. True. The sender has to be aware of whether each new key=value pair fits in the PDU completely, partially or not at all. It cannot work on a batch of pairs and not worry about PDU boundaries. > > I get the feeling, and I maybe wrong here, that the various sides are > > trying to evangelize each other, even if the other side's approach works. > > I am not a big fan of evangelizing at this point. I'm religiously illiterate, so I don't even know (or care to know) what I was just accused of doing, but I'm rather sure I was doing it. In my eyes, however, I was simply defending a simpler scheme. But in order to try to be fair I have composed an analysis of all schemes. Read the next mail please, this is long as it is. > > I am asking for a compromise that you folks can agree with that says > > something like, "yea, you can do it that way you silly so & so, but my way > > works too perhaps better", and the spec covers both implementations. This > > might not be possible but I am not sure we are converging. And we need to > > within a day or so. I think the way spec gets clarified/restricted will pretty much tell whether the simpler batch-processing approach is possible. But with a minor change in what is called a split-PDU there actually is a hope for batch-processing implementations even with the scheme that seemed to prohibit them, so there is a hope for a compromise. > I think with the adjustments above (no offers when you got a split PDU and > wait until no split PDUs to determine if a lack of replies is an error) > would be sufficient. I think sending empty PDUs would be easier, but the > above would suffice. I don't understand why lack of replies would be considered an error under any conditions. Take care, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer From owner-ips@ece.cmu.edu Wed May 29 18:34:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05901 for ; Wed, 29 May 2002 18:33:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TM54I28235 for ips-outgoing; Wed, 29 May 2002 18:05:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail1.hd.intel.com (hdfdns01.hd.intel.com [192.52.58.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TM52w28229 for ; Wed, 29 May 2002 18:05:02 -0400 (EDT) Received: from mkrikis-laptop (mkrikis-laptop.hd.intel.com [10.127.144.234]) by mail1.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with ESMTP id g4TM4uL10586; Wed, 29 May 2002 22:04:56 GMT Received: from martinsk by mkrikis-laptop with local (Exim 3.35 #1 (Debian)) id 17DCUV-0000mJ-00; Wed, 29 May 2002 18:04:27 -0500 To: hufferd@us.ibm.com, ips@ece.cmu.edu, Julian_Satran@il.ibm.com, pat_thaler@agilent.com, wrstuden@wasabisystems.com Subject: Re: iSCSI:Can each do there own thing? Message-Id: From: Martins Krikis Date: Wed, 29 May 2002 18:04:27 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk Let me try to analyze how I understand the possibilities. Please note that I have included what I consider a compromise. So, please read on. Currently (12-94) there is no text explaining when a key=value pair is considered "sent". Thus, a side may consider it sent when it has sent the first byte of the key. The other side need not consider such a key received (it only has the first byte) and may also send it. Both sides feel like originators. Furthermore, each side has to be ready to receive new key=value pairs after each PDU sent, so preparing more key=value pairs than fit in one PDU is impractical. This prohibits the "batch- processing" of keys, defined below. One of the new proposals, we'll call it "no-origination on split-key scheme" is such: we mandate that if one side receives a PDU ending with a "partial key" (start of key, but no '=') (note that this is not the same as "partial key=value pair", which is defined by lack of terminating '\0'), then it may not originate any new keys, but may send responses to the keys (not necesarily key=value pairs) that it has received fully. There is a possible "twist" on this scheme, where it is also allowed to originate new keys that are declarations. The competing proposal, we'll call it "empty PDUs until end-of-data scheme" is such: we mandate that until a node has seen the (new, to be added to header) "data-end flag" from the other side (which signals that the whole batch of key=value pairs that the other side wanted to negotiate at the moment has been received), it MUST send only empty PDU-s (ones with nothing in the DataSegment). This proposal enables the "batch-processing" of keys, defined about as follows: Prepare all key=value pairs you'd like to send; Send them with the peace of mind knowing that no text will come back until you've finished sending them completely; Receive all key=value pairs that the other side would like you to process together (sending only empty PDUs back meanwhile); Process all the received data. Repeat if necessary. Note that the negotiation logic is PDU boundary agnostic, it is only the sending layer that does something like that: if (have leftover) prepend leftover to current data chop off as much as fits in one PDU from the current data send the part just chopped off save the remainder in leftover This, IMHO, is as simple as it gets. However, we ideally need a new flag. While having the flag would be the cleanest, there is a way to get by without it as follows (we'll call this "empty PDU on split-pair scheme"): we mandate that if one side receives a PDU ending with a partial key=value pair (i.e., not having '\0' at the end), it MUST send an empty PDU. Thus, the presence or absence of the '\0' at the end of the last key=value pair works as the "end-of-data" flag. The batch-processing of keys approach works here as well, however, the sending layer needs to do a little more trickery. Namely, if there is more data remaining to be sent in the subsequent PDUs, it must make sure that the current PDU does NOT end in a '\0'. It needs to chop off the '\0' if necessary and leave that for later as well. Padding makes the task a tad more complicated, i.e., it may have to chop off (from the tail end) some more bytes to have the PDU-end be properly aligned and have no '\0' at the end, but it is possible. The batch-processing approach does not work with the "no-origination on split-key scheme", with the twist or without. If the last key and '=' has fully fit in the PDU, the other side may start originating keys, affecting what our side may have wanted to originate itself. It isn't necessarily possible to force a key-split in the sending layer, because the keys are of relatively short length, and in fact (the remaining) data may consist of value alone. Thus, the sending layer modification described in "empty PDUs on split-pair scheme" does not work here. However, and here I come to the possibility of a compromise---we can modify the "no-origination on split-key scheme" into a "no-originatio on split-pair scheme" as follows: we mandate that if one side receives a PDU ending with a "partial key=value pair" (no '\0' at the end) then it may not originate any new keys, but may send responses to the key=value pairs that it has received fully. Again, the twist allowing to originate declarations is possible and functionally harmless. If this were the case, then the following modified batch-processing of keys approach would work: Prepare all key=value pairs you'd like to send; Send them with the peace of mind knowing that no keys (with the possible exception of harmless declarations) will be originated by the other side until you've finished sending them completely; Meanwhile keep concatenating and buffering whatever the other side is sending back, but don't process yet. Receive any more data that the other side would like you to process at this point (sending only empty PDUs back meanwhile); Process all the received data. Repeat if necessary. The sending layer needs the modification where it ensures that if all data didn't fit, then the current PDU doesn't end with a '\0', thus prohibiting the other side from originating keys. This is IMHO very close to what Pat was proposing, yet does allow a variant of "batch processing". It also allows a more agressive processing for those who like it. This could be our compromise. Summary: 1. "no-originating on split-key scheme" 2. "no-originating (except declarations) on split-key scheme" 3. "no-originating on split-pair scheme" 4. "no-originating (except declarations) on split-pair scheme" 5. "empty-PDUs until end-of-data scheme" 6. "empty-PDU on split-pair scheme" 2 is the least restrictive, however to take advantage of the permission to originate declarations when negotiations may not be originated, one has to look at key types. Thus, to take advantage of this, it requires the most complicated implementations. It is also longer to describe than 1. Otherwise, it has the same properties as 1. 1 is what people seemed to be leaning towards yesterday. This scheme does not allow "batch-processing" of keys, since the sender has to be very PDU-boundary aware and leave the processing of keys that don't fit for later. It utilizes the bandwidth better than 5 or 6, but none of these schemes are considered for a very likely or performace critical case(s). The relation of 4 to 3 is the same as the one of 2 to 1. 3 is a modification of 1 where a "split PDU" is clarified as not one with a split-key, but one with a split-pair at the end. This enables the sending side to effectively force no-origination, hence allowing modified but reasonably simple batch-processing of keys. It also still allows more agressive modifications to not do batch processing and send key responses sooner than a batch-processing implementation would. 5 is the absolutely simplest scheme to implement and most restrictive in terms of what the protocol allows. It welcomes batch-processing of keys in its simplest form. Requires a new flag-bit in the PDU header for Text/Login Request/Response PDUs (4 total). 6 is a modification of 5 that does not need the new flag in the header. Still allows very simple batch processing; only the sending layer needs a hack, allowing to force the other side to send only empty PDUs. Does this description seem accurate? My order of preference for these schemes would be: 5, 6, 3, 4, 1, 2 Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer From owner-ips@ece.cmu.edu Wed May 29 18:34:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05935 for ; Wed, 29 May 2002 18:34:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TMBl028664 for ips-outgoing; Wed, 29 May 2002 18:11:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from imail.atlp.com ([64.94.220.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TLvhw27758 for ; Wed, 29 May 2002 17:57:43 -0400 (EDT) Received: from atlp.com (post.atlp.com [192.168.3.8]) by imail.atlp.com (Switch-2.1.4/Switch-2.1.0) with SMTP id g4TLtMI29234 for ; Wed, 29 May 2002 14:55:23 -0700 (PDT) Received: from atlp-exch.atlp.com by atlp.com (SMI-8.6/SMI-SVR4) id OAA29390; Wed, 29 May 2002 14:57:22 -0700 Received: by atlp-exch.atlp with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 14:57:21 -0700 Message-ID: <7C769A0EFE7BD411B8A300508BAED11B5135D1@atlp-exch.atlp> From: Mike Donohoe To: "'ips@ece.cmu.edu'" Subject: iSCSI: Numeric Ranges Date: Wed, 29 May 2002 14:57:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I am unclear on how to select a value when given a Numeric Range. O-> MaxConnections=2~5 As the Responder I want 3. The "selection rule" for MaxConnections says "the lower of the 2 values". So one value is 2~5 the other is 3. Thus the min of those is 2....?.? If this is the case, I'm not seeing the necessity or added value of "numeric ranges". The initiator could just send the min value in the possible range (when the key's selection rule is min()). Thanks. Mike Donohoe From owner-ips@ece.cmu.edu Wed May 29 18:35:25 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05970 for ; Wed, 29 May 2002 18:35:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TM2mb28092 for ips-outgoing; Wed, 29 May 2002 18:02:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TM2hw28082 for ; Wed, 29 May 2002 18:02:44 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4TM2XAN076234 for ; Thu, 30 May 2002 00:02:33 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4TM2Xx36706 for ; Thu, 30 May 2002 00:02:33 +0200 Subject: iSCSI-12-95 To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Thu, 30 May 2002 01:01:42 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 30/05/2002 01:02:32 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk 12-95 is out. It has the latest wording on security and text negotiation (including the spanning). Still to go - text fixes in chapter 11. Julo From owner-ips@ece.cmu.edu Wed May 29 18:40:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06016 for ; Wed, 29 May 2002 18:40:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TMBPP28630 for ips-outgoing; Wed, 29 May 2002 18:11:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TMBNw28625 for ; Wed, 29 May 2002 18:11:23 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id A669DFF9; Wed, 29 May 2002 16:11:22 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 74E32272; Wed, 29 May 2002 16:11:22 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 29 May 2002 16:11:22 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 16:11:22 -0600 Message-ID: <9F8400020EC5D311AF62009027C396160902C3F2@axcs09.cos.agilent.com> From: kevin_lemay@agilent.com To: cbm@rose.hp.com, ips@ece.cmu.edu Subject: RE: ISCSI: Error Recovery Level 0 Date: Wed, 29 May 2002 16:11:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk But devices supporting level 0 are not allowed to attempt any of the other recovery methods. It appears from reading the text for digest recovery, if a header disgest error occurs, that I just throw away the PDU. If the pduLength was corrupted, then I am now out of sync. Do I wait for the initiator to drop the connection? The flow for a data PDU is simple enough. So the error recovery, "incremental requirement description" is misleading.... no real data PDU transmissions are required. The target can just request logout.... Correct? Kevin -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Wednesday, May 29, 2002 2:46 PM To: ips@ece.cmu.edu Subject: Re: ISCSI: Error Recovery Level 0 Kevin, From: "LEMAY,KEVIN (A-Roseville,ex1)" > I have the following question on error Recovery level 0. > > On page 105, v12, it says that error recovery level 0 must perform Session recovery as described in 6.12.4. I can't find it. It's only saying that the minimally expected error recovery capabilities for level 0 are as described in 6.12.4, not that session recovery must be performed for every error.... If you look in 6.12.4, it specifically states that session recovery is done only if all other recovery attempts fail. > > This seems to imply that: > If I have a multi-connection session were one connection experiences a digest error, then I must close all connections on the session, even killing IOs over the good connection. > > This is absurd! Indeed it would be if so implemented (even while it's legal). >Why not just close the one connection that has a problem and allow the IO to be restarted on one of the other live connections? There is nothing wrong with the session, only a single connection. That's a reasonable recovery strategy (if it's a SCSI restart). -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com > > I guess I am calling for a level 0.5, so that I can abort only the troublesome connection. This would allow for a much faster IO recovery without adding hardly any coding complexity that is required for level 1. > > Comments? > > Kevin Lemay > From owner-ips@ece.cmu.edu Wed May 29 18:41:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06061 for ; Wed, 29 May 2002 18:41:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TMJS429133 for ips-outgoing; Wed, 29 May 2002 18:19:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TMJRw29129 for ; Wed, 29 May 2002 18:19:27 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 92EAC6DB; Wed, 29 May 2002 16:19:26 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 448F610B; Wed, 29 May 2002 16:19:26 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 29 May 2002 16:19:26 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 16:19:26 -0600 Message-ID: <9F8400020EC5D311AF62009027C396160902C3F3@axcs09.cos.agilent.com> From: kevin_lemay@agilent.com To: Mike.Donohoe@quantum.com, ips@ece.cmu.edu Subject: RE: iSCSI: Numeric Ranges Date: Wed, 29 May 2002 16:19:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Ranges are only allowed on the marker intervals (see A.3.2, page 214, v12). Ranges are not allowed unless specifically stated by the spec. Kevin -----Original Message----- From: Mike Donohoe [mailto:Mike.Donohoe@quantum.com] Sent: Wednesday, May 29, 2002 2:57 PM To: 'ips@ece.cmu.edu' Subject: iSCSI: Numeric Ranges I am unclear on how to select a value when given a Numeric Range. O-> MaxConnections=2~5 As the Responder I want 3. The "selection rule" for MaxConnections says "the lower of the 2 values". So one value is 2~5 the other is 3. Thus the min of those is 2....?.? If this is the case, I'm not seeing the necessity or added value of "numeric ranges". The initiator could just send the min value in the possible range (when the key's selection rule is min()). Thanks. Mike Donohoe From owner-ips@ece.cmu.edu Wed May 29 18:55:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06425 for ; Wed, 29 May 2002 18:55:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TMMXC29368 for ips-outgoing; Wed, 29 May 2002 18:22:33 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TMMSw29363 for ; Wed, 29 May 2002 18:22:29 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4TMM7NU024256; Thu, 30 May 2002 00:22:08 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4TMM7x49620; Thu, 30 May 2002 00:22:07 +0200 To: Bill Studenmund Cc: ips@ece.cmu.edu, Martins Krikis , owner-ips@ece.cmu.edu, pat_thaler@agilent.com MIME-Version: 1.0 Subject: RE: iSCSI: Negotiation clarifications still needed X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 30 May 2002 01:22:05 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 30/05/2002 01:22:08, Serialize complete at 30/05/2002 01:22:08 Content-Type: multipart/alternative; boundary="=_alternative 0079C687C2256BC8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0079C687C2256BC8_= Content-Type: text/plain; charset="us-ascii" it is already there - thank you. Julo Bill Studenmund 05/30/2002 12:09 AM Please respond to Bill Studenmund To: Julian Satran/Haifa/IBM@IBMIL cc: Martins Krikis , , , Subject: RE: iSCSI: Negotiation clarifications still needed On Wed, 29 May 2002, Julian Satran wrote: > Martins & Pat, > > In going over the list of the arguments for the ongoing negotiation (that > we have now) versus. "stop-until-you-have-full-buffer" I think that I am > more inclined now to accept that Martins's point about absolute simplicity > is valid and we should accept it (i.e., stop untill you have a full > buffer. > AFAIK it will not break any existing implementation as all/most of them > are rudimentary and they are not in silicon (I hope). If there is intereste, I'm willing to help write suggested algorithms to implement this, a la appendix E. Take care, Bill --=_alternative 0079C687C2256BC8_= Content-Type: text/html; charset="us-ascii"
it is already there - thank you. Julo


Bill Studenmund <wrstuden@wasabisystems.com>

05/30/2002 12:09 AM
Please respond to Bill Studenmund

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        Martins Krikis <mkrikis@yahoo.com>, <ips@ece.cmu.edu>, <owner-ips@ece.cmu.edu>, <pat_thaler@agilent.com>
        Subject:        RE: iSCSI: Negotiation clarifications still needed

       


On Wed, 29 May 2002, Julian Satran wrote:

> Martins & Pat,
>
> In going over the list of the arguments for the ongoing negotiation (that
> we have now) versus. "stop-until-you-have-full-buffer" I think that I am
> more inclined now to accept that Martins's point about absolute simplicity
> is valid and we should accept it (i.e., stop untill you have a full
> buffer.
> AFAIK it  will not break any existing implementation as all/most of them
> are rudimentary and they are not in silicon (I hope).

If there is intereste, I'm willing to help write suggested algorithms to
implement this, a la appendix E.

Take care,

Bill

--=_alternative 0079C687C2256BC8_=-- From owner-ips@ece.cmu.edu Wed May 29 19:12:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06930 for ; Wed, 29 May 2002 19:12:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TMZYo00190 for ips-outgoing; Wed, 29 May 2002 18:35:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([65.68.235.70]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TMZRw00169 for ; Wed, 29 May 2002 18:35:28 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Disposition-Notification-To: "Lee Xing" Subject: iSCSI: iSCSI Analyzers Date: Wed, 29 May 2002 17:35:16 -0500 Message-ID: Thread-Topic: ISCSI: CmdSN in non-leading login Thread-Index: AcH4iSCSl/CU3TLATQ2/wepcQUZwXgO19m0g From: "Lee Xing" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g4TMZUw00171 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Dear iSCSI colleagues, Please forgive me if this post is a bit off-topic. I'm looking for information on iSCSI analyzers, and would appreciate it if you could tell me which iSCSI analyzer you are using, and what you like/don't like? Thanks. Lee From owner-ips@ece.cmu.edu Wed May 29 19:14:36 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07010 for ; Wed, 29 May 2002 19:14:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TMMQo29361 for ips-outgoing; Wed, 29 May 2002 18:22:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TMMIw29350 for ; Wed, 29 May 2002 18:22:19 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4TMM7AN019224; Thu, 30 May 2002 00:22:07 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4TMM7x17354; Thu, 30 May 2002 00:22:07 +0200 To: kevin_lemay@agilent.com Cc: ips@ece.cmu.edu, "John Hufferd" MIME-Version: 1.0 Subject: RE: ISCSI: Error Recovery Level 0 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 30 May 2002 01:22:03 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 30/05/2002 01:22:07, Serialize complete at 30/05/2002 01:22:07 Content-Type: multipart/alternative; boundary="=_alternative 0079A265C2256BC8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0079A265C2256BC8_= Content-Type: text/plain; charset="us-ascii" Kevin, Before you get too angry on this I suggest you consider all the mechanism required and what you want to achieve. If you don't want reassignment for commands - just bring down a connection and recover the lost commands at SCSI level you can certainly do this with what you have. Julo kevin_lemay@agilent.com 05/30/2002 12:26 AM Please respond to kevin_lemay To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL Subject: RE: ISCSI: Error Recovery Level 0 Level 2 is not what I want at all! In order to support level 2, I have to support level 1 plus support IO re-assignment too. I think that the data retransmission may not be worth the effort for all implementations. It is a hierarchy after all. Level 0 is too simple - Very big hammer. Proposed 0.5 - Simple and smaller hammer Level 1 - Complex and for the number of expected errors, maybe not worth the effort. You may have had a face to face, but I sure didn't. I don't think that the current scheme provides what I want. I understand the level 0 is for simple devices. I think that there is room for something between level 0 and 1 that is still easy to implement, but does not take the performance hit of bringing the entire session down. Modifing level 0 to only drop the troublesome connection would be OK too. Retransmission is easy or hard depending on whether you are allowed to access the data more than once. Kevin Lemay -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Wednesday, May 29, 2002 2:07 PM To: LEMAY,KEVIN (A-Roseville,ex1) Cc: 'ips@ece.cmu.edu'; Julian Satran Subject: Re: ISCSI: Error Recovery Level 0 Kevin, What you are asking for is Level 2, connection level recovery. We agreed on these levels at a Face to Face meeting, since folks ask us to make the spec. simpler. We all agreed on only having official levels 0,1 & 2. Level 2 has all you want, even if you do not want to have anything to do with level 1 (within command recovery) you can always terminate and recover the connection. If you attempt to make level 1 a "no-op" level, you still have to field the SNACK on the Target Side, but you can decide to react with a connection recovery. Likewise on the Initiator side, you can decide to Logout the connection instead of sending a SNACK. Everything will work, but for the sake of your customers you need to state that you do not do within command recovery, even if you generally act at recovery level 2. In any event, within command-recovery is fairly simple, and you should try your best, then punt with a connection logout. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "LEMAY,KEVIN (A-Roseville,ex1)" @ece.cmu.edu on 05/29/2002 12:14:30 PM Sent by: owner-ips@ece.cmu.edu To: "'ips@ece.cmu.edu'" cc: Julian Satran/Haifa/IBM@IBMIL Subject: ISCSI: Error Recovery Level 0 I have the following question on error Recovery level 0. On page 105, v12, it says that error recovery level 0 must perform Session recovery as described in 6.12.4. This seems to imply that: If I have a multi-connection session were one connection experiences a digest error, then I must close all connections on the session, even killing IOs over the good connection. This is absurd! Why not just close the one connection that has a problem and allow the IO to be restarted on one of the other live connections? There is nothing wrong with the session, only a single connection. I guess I am calling for a level 0.5, so that I can abort only the troublesome connection. This would allow for a much faster IO recovery without adding hardly any coding complexity that is required for level 1. Comments? Kevin Lemay --=_alternative 0079A265C2256BC8_= Content-Type: text/html; charset="us-ascii"
Kevin,

Before you get too angry on this I suggest you consider all the mechanism required and what you want to achieve.
If you don't want reassignment for commands - just bring down a connection and recover the lost commands at SCSI level
you can certainly do this with what you have.

Julo


kevin_lemay@agilent.com

05/30/2002 12:26 AM
Please respond to kevin_lemay

       
        To:        John Hufferd/San Jose/IBM@IBMUS
        cc:        ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL
        Subject:        RE: ISCSI: Error Recovery Level 0

       


Level 2 is not what I want at all!

In order to support level 2, I have to support level 1 plus support IO re-assignment too. I think that the data retransmission may not be worth the effort for all implementations. It is a hierarchy after all.

Level 0 is too simple - Very big hammer.
Proposed 0.5 - Simple and smaller hammer
Level 1 - Complex and for the number of expected errors, maybe not worth the effort.

You may have had a face to face, but I sure didn't.

I don't think that the current scheme provides what I want. I understand the level 0 is for simple devices. I think that there is room for something between level 0 and 1 that is still easy to implement, but does not take the performance hit of bringing the entire session down. Modifing level 0 to only drop the troublesome connection would be OK too.

Retransmission is easy or hard depending on whether you are allowed to access the data more than once.

Kevin Lemay

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Wednesday, May 29, 2002 2:07 PM
To: LEMAY,KEVIN (A-Roseville,ex1)
Cc: 'ips@ece.cmu.edu'; Julian Satran
Subject: Re: ISCSI: Error Recovery Level 0



Kevin,
What you are asking for is Level 2, connection level recovery.  We agreed
on these levels at a Face to Face meeting, since folks ask us to make the
spec. simpler.   We all agreed on only having official levels 0,1 & 2.

Level 2 has all you want, even if you do not want to have anything to do
with level 1 (within command recovery) you can always terminate and recover
the connection.

If you attempt to make level 1 a "no-op" level, you still have to field the
SNACK on the Target Side, but you can decide to react with a connection
recovery.   Likewise on the Initiator side, you can decide to Logout the
connection instead of sending a SNACK.  Everything will work, but for the
sake of your customers you need to state that you do not do within command
recovery, even if you generally act at recovery level 2.

In any event, within command-recovery is fairly simple, and you should try
your best, then punt with a connection logout.



.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


"LEMAY,KEVIN (A-Roseville,ex1)" <kevin_lemay@agilent.com>@ece.cmu.edu on
05/29/2002 12:14:30 PM

Sent by:    owner-ips@ece.cmu.edu


To:    "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
cc:    Julian Satran/Haifa/IBM@IBMIL
Subject:    ISCSI: Error Recovery Level 0



I have the following question on error Recovery level 0.

On page 105, v12, it says that error recovery level 0 must perform Session
recovery as described in 6.12.4.

This seems to imply that:
If I have a multi-connection session were one connection experiences a
digest error, then I must close all connections on the session, even
killing IOs over the good connection.

This is absurd! Why not just close the one connection that has a problem
and allow the IO to be restarted on one of the other live connections?
There is nothing wrong with the session, only a single connection.

I guess I am calling for a level 0.5, so that I can abort only the
troublesome connection. This would allow for a much faster IO recovery
without adding hardly any coding complexity that is required for level 1.

Comments?

Kevin Lemay

--=_alternative 0079A265C2256BC8_=-- From owner-ips@ece.cmu.edu Wed May 29 19:48:49 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07773 for ; Wed, 29 May 2002 19:48:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TNAL802249 for ips-outgoing; Wed, 29 May 2002 19:10:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13706.mail.yahoo.com (web13706.mail.yahoo.com [216.136.175.139]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4TNAJw02245 for ; Wed, 29 May 2002 19:10:19 -0400 (EDT) Message-ID: <20020529231018.85454.qmail@web13706.mail.yahoo.com> Received: from [192.55.52.2] by web13706.mail.yahoo.com via HTTP; Wed, 29 May 2002 16:10:18 PDT Date: Wed, 29 May 2002 16:10:18 -0700 (PDT) From: Martins Krikis Subject: Re: iSCSI-12-95 To: Julian Satran , ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Julian Satran wrote: > 12-95 is out. > It has the latest wording on security and text > negotiation (including the > spanning). Julian, I like very much what I see there. But I think we need the C-bit for Login Requests/Responses, too. Also, the example on page 165 could show the use of the C-bit. Finally, my apologies for saying that 12-94 had nothing on the subject. It did, I just hadn't noticed. But 12-95 is much better since it uses the simplest of all the schemes I mentioned. Thank you very much, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Wed May 29 19:49:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07790 for ; Wed, 29 May 2002 19:49:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TNFpl02634 for ips-outgoing; Wed, 29 May 2002 19:15:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TNFnw02630 for ; Wed, 29 May 2002 19:15:49 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id D4875B4E3; Wed, 29 May 2002 17:15:48 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id B0FE222D; Wed, 29 May 2002 17:15:48 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 29 May 2002 17:15:48 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 17:15:48 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353622@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: hufferd@us.ibm.com, mkrikis@yahoo.com Cc: ips@ece.cmu.edu, pat_thaler@agilent.com, wrstuden@wasabisystems.com Subject: RE: iSCSI:Can each do there own thing? Date: Wed, 29 May 2002 17:15:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk John, 1. Yes there is one item that is broken: It is offers that require a choice one way or the other. One could build a buffer blindly of responses and declarations and either partition it into PDUs and start sending or wait until one thought one had received all the offers from the other side. If one wants to be able to build a buffer that includes offers, chop it into PDUs and send, one needs everyone to use a mechanism to pass the offer token back and forth. One could say that an implementation without the offer token MAY send PDUs with declarations and responses to offers. (Aside: Am I the only one who thinks it invites confusion to have "response" mean a PDU type and a key-value pair type that may be in either PDU type?) It isn't clear to me whether the mechanism should be a new flag or whether modifying the meaning of the T bit could be used. I think the former would be cleaner and there is no reason to scrimp on a bit. I would like to go over proposed text to the draft for that before we commit. I don't think that the last receive PDU ending in a partial key-value pair should be used for the hand-off because it would require the sender to be careful where it chops when breaking the buffer into PDUs. People didn't want to have to ensure that they didn't break a key-name and this would be the same type of thing. 2. Null PDUs are not a problem. With the current protocol, one may get null PDUs and there are even times when one has to respond with null PDUs - receiving a long security key, receiving the response to a SendTargets and any time one has nothing to send but the received PDU doesn't have T set. Therefore null PDUs have to be tolerated regardless of what we do here. I think there is little technical difference between the two implementation choices (assuming that the hand-off process for the offer token doesn't get messy) but for interoperability one needs to make a choice between them for offers. Pat -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, May 28, 2002 8:33 PM To: Martins Krikis Cc: ips@ece.cmu.edu; pat_thaler@agilent.com; wrstuden@wasabisystems.com Subject: iSCSI:Can each do there own thing? I am starting a new thread. I am not sure that I have gotten all the nuances of the various proposals here, but ... I think I read, that if you receive a spanned PDU, that some want to keep some state and continue processing, while other are saying that it is easier if only an empty PDU is returned, until the complete PDU with nothing spanning is received. I may have this wrong, but the focus seems to be on the receiver of the spanned PDU, and the issues it has in keeping state etc. Now the rules we have now in the current draft level 12-94, some seem to say, are workable. But if someone sends empty PDUs, etc., that seems to work too, and some folks (at least 2) think that is a good idea. So are we at a point that says that empty PDUs are OK, and if used, you need to remember less stuff, but if you want to remember state, then go ahead, but be sure you do everything correctly? Let me ask two question then: 1. Is what I summarized correct with respect to the receiver? If not please itemize, the items that are broken, so that we can work on one at a time. 2. Is there an important issue with the offering side, that is not covered with the current spec. and will things work on the offering side if the Null PDU us sent from the receiver? Again, if no, please itemize. I get the feeling, and I maybe wrong here, that the various sides are trying to evangelize each other, even if the other side's approach works. I am not a big fan of evangelizing at this point. I am asking for a compromise that you folks can agree with that says something like, "yea, you can do it that way you silly so & so, but my way works too perhaps better", and the spec covers both implementations. This might not be possible but I am not sure we are converging. And we need to within a day or so. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Martins Krikis @ece.cmu.edu on 05/28/2002 07:53:23 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu, pat_thaler@agilent.com, wrstuden@wasabisystems.com cc: Subject: RE: iSCSI: Negotiation clarifications still needed > It's to avoid corner cases while doing what you say above, "preparing > its > strings and chopping them into PDUs." > > The simplest thing in my mind is to: > > 1) read the other side's offers into a buffer > > 2) parse that buffer generating responses to another buffer > > 3) send the output buffer > > Does that make sense? You don't have to agree, just does it make sense? > > The problem I see with what Pat described is that if you are in > operational negotiation and have more than 1 PDU worth of data, you > will > be receiving input while you're in step 3. You have to be able to > re-enter > steps 1 & 2 before you can finish step 3. > > I think that is over stating the complexity. During negotiation, > the other side can only have one PDU outstanding at a time. That is > explictly > stated for TextNegotiation PDUs. For LoginPDUs, it isn't explicit but > since > they are immediate and the initiator can only count on the target > having one > immediate buffer for the connection it can't send another LoginRequest > until > it gets the LoginResponse without risking that a PDU will be dropped. > Also > allowing anything other than one oustanding LoginPDU at a time would > open > the possibility that both sides offered the same key. Therefore, a > target > won't get the next PDU until after it sends the response PDU (or > vice-versa > for an initiator). A PDU won't come in while a PDU is being sent from > the > outgoing negotiation buffer. Pat, I must interrupt you here. (A subliminal part of this exercise is to show how annoying interruptions are :-).) In order to argue your point I think you're intentionally trying to misunderstand Bill. He didn't talk about getting a new PDU while sending his PDU. He talked about getting an incoming non-empty PDU while sending his data _buffer_. This buffer could be much larger than a PDU. You cannot deny that this may happen with the scheme that you're arguing for. It cannot happen with the scheme that we're proposing, since only empty PDUs would be coming back while we're sending our (possibly much larger than PDUs) data buffers. > Once you send the PDU, there may still be some data left in the output > buffer but it doesn't seem complex to switch at that point to waiting > to > receive and parse the next received PDU. If you have noticed that a PDU is full, it is certainly possible to switch to a receiving mode. Yet it is even simpler not to have to notice. > One had better be able to switch > from one process to another anyway as most implementations will handle > multiple connections which can be in diffent phases. I don't see the relevance of this argument. > If you are willing > to buffer all your output into a buffer and wait to send it until the > other > side has stopped sending new parameters, then all you need to do to > change > that to an implementation that sends what it has in the output buffer > as > it goes along is to have pointer into the buffer that indicates the > next > byte to be sent. Not true, because as I'll start sending it, the other side may send me new offers, thus preempting me from making similar offers myself and instead requiring _responses_. > The bit about sending empty PDUs is an effort to avoid that. We are > either > in a sending-negotiation-text mode, or a parsing mode. We don't have to > worry about strings being partially there, since we don't process until > they are. We also don't have to worry about if our key/value pairs > cross a PDU. The parser/negotiatior is MUCH simpler; it doesn't have to > deal with all of that. > > Letting the target answer while the initiator is trying to send an > extended PDU adds the following complications (AFAICT): > > 1) initiator has to make sure a key and the '=' don't get split on a > PDU > boundry. > > One doesn't have to do that anyway. We can chose the rule to not > offering a new (non-declarative key) when one has received a partial > key > which seemed to be acceptable to a number of people. First I haven't yet seen anybody but you and myself speak about the declarative/non-declarative variation of this theme yet, so I wouldn't call it "acceptable to a number of people" yet, at least not if you include the parenthesized part. Overall, however, a truly aware Sender most likely will check whether a key and = got split or not. Because if it was split, and the other side originates a new key, it is a violation. It would be nice to catch it. And it definitely must check whether key=value fit fully or not. > 2) if an initiator fills up a PDU, it has to stop processing & wait for > the response. It also has to remember where it is so that it can finish > sending that key/value next time. > > It has to remember where it was and finish the key/value next > time > anyway as it can't send again until it gets a response. The difference is that in the scheme we're proposing we'd leave the unsent key=value pairs sitting in the "leftover" buffer, and happily mark all those keys individually as "sent". So we'll consider them processed, even though they may not have been put on the wire yet. With your scheme, you may not mark them as sent, so there is also little point having them stay in the buffer. The only thing that can safely stay in the buffer is the remainder of the last key=value pair, if it was sent partially. > 3) The target has to detect a split key/value pair on in-bound, and a) > store the received text, and b) remember not to offer said key or any > others. > > detecting an incomplete key is reasonably easy. And the target > can > chose to do the simplist thing which is not to offer new keys when a > partial key is outstanding. Yes, easy. Still harder than never dealing with an incomplete key at all. > 4) The target ALSO has to make sure ITS response doesn't fill up a PDU. > If > it does, it has to remember where IT is and that it has more to send. > > In your approach the target can have a buffer with more than > one PDU worth of response in it. Once it starts sending from that > buffer > it has to remember where it is and that it has more to send. This is > not any different. There is a buffer with pointers into for end and > last byte sent (or next byte to send). Yes, it is different, because keys can be marked "sent" and happily wait their physical send-out in the buffer. With your scheme you can't put them in a buffer and forget, because incoming data may force you to go back and start mangling the values you had assigned them... > That's a lot of complexity and saved state. At least in my mind. > > I don't see much complexity difference here. There is quite some difference in complexity, here. I think you're trying not to see it. > I agree. This means that plug fests probably haven't hit these > cases. That's why there is the famous Bill's experiment---set the PDU size to 64 bytes and try negotiating. > Does the statement of the perceived problem make sense, even if the > opinion of the WG is to not use the empty PDUs? I would feel much > comfortable with deciding to not use empty PDUs if folks said they > understand the above point and they choose to address the problems > differently. > > I want to point out that there are times in the protocol when > one will have to send an empty PDU. For instance, when getting a > security key that is longer than a the Max PDU size (or even less > than that - the sender isn't required to send Max size PDUs) or when > a device has no key-value pairs to send but its partner hasn't set > the F bit. The issue is whether to require that there be a process > for handing the right to originate keys (or in your proposal to send > keys at all) keys from initiator to target and back which adds > its own complexity. I think the complexity will be > of the same order as the existing situation. I think in both cases we do have a process to hand the right to originate/send to the other side and back and forth again. We are not trying to take this process away. The question is should the "handing over of the right (to originate/send)" happen after each PDU sent or should it happen after a data _buffer_ (possibly containing more key=value pairs than fit in a PDU) sent? Again a simple comparison to real life... Take the first text in this message written by me. How would you have liked to delete everything beneath it and to send the rest of your comments in a new message? Again, include only as little as there is until my next comment. That's when I'd interrupt you again and potentially mess with what you were planning to say. Pretty frustrating, wouldn't it be? OK, to be fair, I couldn't do it as often as I could want to, since you'd be entitled to one PDU worth of uninterrupted text in iSCSI. But it isn't as clean as "letting the speaker finish" (not the lecture, just the "complete thought"). Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. From owner-ips@ece.cmu.edu Wed May 29 19:49:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07805 for ; Wed, 29 May 2002 19:49:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TNG3002659 for ips-outgoing; Wed, 29 May 2002 19:16:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TNFxw02642 for ; Wed, 29 May 2002 19:15:59 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id D4A76B00; Wed, 29 May 2002 17:15:58 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id A684122D; Wed, 29 May 2002 17:15:58 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 29 May 2002 17:15:58 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 17:15:58 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353623@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: wrstuden@wasabisystems.com, pat_thaler@agilent.com Cc: Julian_Satran@il.ibm.com, cbm@rose.hp.com, ips@ece.cmu.edu, mkrikis@yahoo.com Subject: RE: iSCSI: Negotiation clarifications still needed Date: Wed, 29 May 2002 17:15:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk From: Bill Studenmund What do we want to decide? Bill, As I mention in the response to John, I would like to see proposed text for specifying the hand-off. I think one could approach this by handing back and forth the right to make negotiation offers and leave to the implementations whether they send empty text negotiations or responses and declarations when they don't have the right to make negotiation offers. I think the hand-off should be based on a bit flag rather than based on whether the last PDU received ended in a complete key-value pair. Once people have had a chance to see the proposal, I would like to hear opinions beyond those of the few people who have been active in this discussion. Regards, Pat From owner-ips@ece.cmu.edu Wed May 29 19:49:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07819 for ; Wed, 29 May 2002 19:49:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TN5wK01948 for ips-outgoing; Wed, 29 May 2002 19:05:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TN5uw01942 for ; Wed, 29 May 2002 19:05:56 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id EB61F30716; Wed, 29 May 2002 19:05:55 -0400 (EDT) Date: Wed, 29 May 2002 16:03:58 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Martins Krikis Cc: , , , Subject: Re: iSCSI:Can each do there own thing? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 29 May 2002, Martins Krikis wrote: [very large snip] > Summary: > > 1. "no-originating on split-key scheme" > 2. "no-originating (except declarations) on split-key scheme" > 3. "no-originating on split-pair scheme" > 4. "no-originating (except declarations) on split-pair scheme" > 5. "empty-PDUs until end-of-data scheme" > 6. "empty-PDU on split-pair scheme" My vote is for 5 along with adding a 'C' bit to login and logout PDUs. Then we will have login negotiation working the same as text negotiation as per 12-95. Take care, Bill From owner-ips@ece.cmu.edu Wed May 29 19:51:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07853 for ; Wed, 29 May 2002 19:51:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TNT9A03470 for ips-outgoing; Wed, 29 May 2002 19:29:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TNT6w03462 for ; Wed, 29 May 2002 19:29:06 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id AA799C00498; Wed, 29 May 2002 16:29:00 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id QAA04916; Wed, 29 May 2002 16:30:48 -0700 (PDT) Message-ID: <004201c20768$9bd78060$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , References: <9F8400020EC5D311AF62009027C396160902C3F2@axcs09.cos.agilent.com> Subject: Re: ISCSI: Error Recovery Level 0 Date: Wed, 29 May 2002 16:28:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit From: > But devices supporting level 0 are not allowed to attempt any of the other recovery methods. It is absolutely acceptable for an iSCSI entity to drop a connection on seeing a digest error. Regardless of the negotiated error recovery level, both entities must deal with TCP exceptions as a fact of life - as the state diagrams show. To reiterate, the ErrorRecoveryLevel key specifies what each side is promising to minimally support. This promise provides the guarantee to the initiator to resort to a sophisticated error recovery. Negotiation of 0 *does not* mean that the entities must drop session on every error. > > It appears from reading the text for digest recovery, if a header disgest error occurs, that I just throw away the PDU. If the pduLength was corrupted, then I am now out of sync. Do I wait for the initiator to drop the connection? No, you (target) may drop on your own. Please note that *connection recovery* (requires ErrorRecoveryLevel=2) is different from a simple *connection drop* (any recovery level). Please also refer to an earlier thread initiated by Ken Sandars on this topic a couple of weeks ago. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Wednesday, May 29, 2002 2:46 PM > To: ips@ece.cmu.edu > Subject: Re: ISCSI: Error Recovery Level 0 > > > Kevin, > > From: "LEMAY,KEVIN (A-Roseville,ex1)" > > I have the following question on error Recovery level 0. > > > > On page 105, v12, it says that error recovery level 0 must perform Session recovery as described in 6.12.4. > > I can't find it. > > It's only saying that the minimally expected error recovery capabilities for level 0 are as described > in 6.12.4, not that session recovery must be performed for every error.... > > If you look in 6.12.4, it specifically states that session recovery is done only if all other recovery > attempts fail. > > > > > This seems to imply that: > > If I have a multi-connection session were one connection experiences a digest error, then I must close all > connections on the session, even killing IOs over the good connection. > > > > This is absurd! > > Indeed it would be if so implemented (even while it's legal). > > >Why not just close the one connection that has a problem and allow the IO to be restarted on one of the other > live connections? There is nothing wrong with the session, only a single connection. > > That's a reasonable recovery strategy (if it's a SCSI restart). > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > > > > I guess I am calling for a level 0.5, so that I can abort only the troublesome connection. This would allow > for a much faster IO recovery without adding hardly any coding complexity that is required for level 1. > > > > Comments? > > > > Kevin Lemay > > > From owner-ips@ece.cmu.edu Wed May 29 19:52:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07882 for ; Wed, 29 May 2002 19:52:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TN6Yd01989 for ips-outgoing; Wed, 29 May 2002 19:06:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gatekeeper2.sanvalley.com ([63.170.126.67]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TMcuw00379 for ; Wed, 29 May 2002 18:38:57 -0400 (EDT) Received: from webmail.sanvalley.com (webmail [10.128.0.100]) by gatekeeper2.sanvalley.com (Netscape Messaging Server 4.15) with ESMTP id GWW9RB00.DRQ; Wed, 29 May 2002 15:42:47 -0700 Received: by webmail.sanvalley.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 May 2002 15:38:48 -0700 Message-ID: <73DE11092C445F478CB3629910B2F494B8A47E@webmail.sanvalley.com> From: charissa.willard@sanvalley.com To: "'Keith McCloghrie'" , arvindp@cisco.com Cc: ips@ece.cmu.edu, smoffett@cisco.com, sriramnj@cisco.com, nramesh@cisco.com, gklee@cisco.com Subject: RE: FC Mgmt mib Date: Wed, 29 May 2002 15:38:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Keith, > > 3. A new table for 'tunnel' ports > > - I'd rather not add a new table unless it's absolutely necessary. > How about I just broaden the scope of the fcmEPortTable so that > it applies not only to E_Ports but also to 'tunnel' ports ?? > > The MIB will also need a new group for devices supporting 'tunnel' > functionality, which will contain just fcmEPortClassFCredit > and fcmEPortClassFDataFieldSize, right ?? For FC over IP a port can be either a B_port or an E_port. A B_port supports Class F frames and thus could at least use the Class F BB_Credit object that you specified in fcmEPortTable. The MIB defines the FcUnitFunction type of 'bridge' as "encapsulates FC frames within another protocol". Doesn't this imply "tunneling"? Since a B_port is transparent to the Fabric, just providing a table for B_Ports may provide a solution for other devices/ports that are transparent to the Fabric and need an object for BB_Credit. Thanks, Charissa From owner-ips@ece.cmu.edu Wed May 29 19:52:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07895 for ; Wed, 29 May 2002 19:52:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TN3Ho01794 for ips-outgoing; Wed, 29 May 2002 19:03:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TN3Ew01786; Wed, 29 May 2002 19:03:14 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 68EED30706; Wed, 29 May 2002 19:01:24 -0400 (EDT) Date: Wed, 29 May 2002 15:59:26 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: , Martins Krikis , , Subject: RE: iSCSI: Negotiation clarifications still needed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 30 May 2002, Julian Satran wrote: > it is already there - thank you. Julo Thank you. I had not seen 12-95 was available. The use of the 'C' bit in Text Request and Response cleanly implememnts what Martins was suggesting. However I did not see where we state that login negotiations use a comparable mechanism. Actually, it looks like the text indicating login negotiations can span PDUs was removed. Was that the desired effect? > On Wed, 29 May 2002, Julian Satran wrote: > > > Martins & Pat, > > > > In going over the list of the arguments for the ongoing negotiation > (that > > we have now) versus. "stop-until-you-have-full-buffer" I think that I am > > more inclined now to accept that Martins's point about absolute > simplicity > > is valid and we should accept it (i.e., stop untill you have a full > > buffer. > > AFAIK it will not break any existing implementation as all/most of them > > are rudimentary and they are not in silicon (I hope). > > If there is intereste, I'm willing to help write suggested algorithms to > implement this, a la appendix E. > > Take care, > > Bill > > > > From owner-ips@ece.cmu.edu Wed May 29 20:31:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08575 for ; Wed, 29 May 2002 20:31:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4TNjNB04557 for ips-outgoing; Wed, 29 May 2002 19:45:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4TNjLw04549 for ; Wed, 29 May 2002 19:45:21 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 1969DB7B1; Wed, 29 May 2002 17:45:21 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id CFEFF166; Wed, 29 May 2002 17:45:20 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 29 May 2002 17:45:20 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 17:45:20 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353638@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: wrstuden@wasabisystems.com, hufferd@us.ibm.com Cc: mkrikis@yahoo.com, ips@ece.cmu.edu, pat_thaler@agilent.com Subject: RE: iSCSI:Can each do there own thing? Date: Wed, 29 May 2002 17:45:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill Studemund wrote: The one thing new I mentioned is the fact you can't claim negotiation error when not all the keys you offered were returned *if* eithe you or the other side sent a split PDU. i.e. if one or both sides are still talking, you can't tell yet. Bill, I don't think you can currently call it a negotiation error if the other side doesn't respond in the next PDU to a key you offered regardless of whether the key is split, the PDU is full or anything else. Our protocol does not require that an implementation to respond immediately to offers and this is not listed as an error in the negotiation failures section. It would be an error if the Target set the T bit when it still hadn't responded to offers though I don't think this is explicitly called out as a negotiation failure. The same probably applies to the Target setting the T bit when it has made offers that haven't been responded to yet. Other than that, I think there is no requirement on where in a negotiation the response to a particular offer is placed. Regards, Pat From owner-ips@ece.cmu.edu Wed May 29 20:35:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08696 for ; Wed, 29 May 2002 20:35:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4U0GHa06296 for ips-outgoing; Wed, 29 May 2002 20:16:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4U0GFw06292 for ; Wed, 29 May 2002 20:16:15 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4U0GD29048800; Wed, 29 May 2002 20:16:13 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4U0GC5226216; Wed, 29 May 2002 18:16:12 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: ISCSI: Error Recovery Level 0 To: kevin_lemay@agilent.com Cc: ips@ece.cmu.edu, "Julian Satran" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Wed, 29 May 2002 17:14:06 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/29/2002 06:16:12 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Kevin, If you are going to reply, read my whole note carefully. You response does not fit what I said to you. Mallikarjun is telling you the same thing. Please reread my response. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com kevin_lemay@agilent.com@ece.cmu.edu on 05/29/2002 02:26:54 PM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL Subject: RE: ISCSI: Error Recovery Level 0 Level 2 is not what I want at all! In order to support level 2, I have to support level 1 plus support IO re-assignment too. I think that the data retransmission may not be worth the effort for all implementations. It is a hierarchy after all. Level 0 is too simple - Very big hammer. Proposed 0.5 - Simple and smaller hammer Level 1 - Complex and for the number of expected errors, maybe not worth the effort. You may have had a face to face, but I sure didn't. I don't think that the current scheme provides what I want. I understand the level 0 is for simple devices. I think that there is room for something between level 0 and 1 that is still easy to implement, but does not take the performance hit of bringing the entire session down. Modifing level 0 to only drop the troublesome connection would be OK too. Retransmission is easy or hard depending on whether you are allowed to access the data more than once. Kevin Lemay -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Wednesday, May 29, 2002 2:07 PM To: LEMAY,KEVIN (A-Roseville,ex1) Cc: 'ips@ece.cmu.edu'; Julian Satran Subject: Re: ISCSI: Error Recovery Level 0 Kevin, What you are asking for is Level 2, connection level recovery. We agreed on these levels at a Face to Face meeting, since folks ask us to make the spec. simpler. We all agreed on only having official levels 0,1 & 2. Level 2 has all you want, even if you do not want to have anything to do with level 1 (within command recovery) you can always terminate and recover the connection. If you attempt to make level 1 a "no-op" level, you still have to field the SNACK on the Target Side, but you can decide to react with a connection recovery. Likewise on the Initiator side, you can decide to Logout the connection instead of sending a SNACK. Everything will work, but for the sake of your customers you need to state that you do not do within command recovery, even if you generally act at recovery level 2. In any event, within command-recovery is fairly simple, and you should try your best, then punt with a connection logout. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "LEMAY,KEVIN (A-Roseville,ex1)" @ece.cmu.edu on 05/29/2002 12:14:30 PM Sent by: owner-ips@ece.cmu.edu To: "'ips@ece.cmu.edu'" cc: Julian Satran/Haifa/IBM@IBMIL Subject: ISCSI: Error Recovery Level 0 I have the following question on error Recovery level 0. On page 105, v12, it says that error recovery level 0 must perform Session recovery as described in 6.12.4. This seems to imply that: If I have a multi-connection session were one connection experiences a digest error, then I must close all connections on the session, even killing IOs over the good connection. This is absurd! Why not just close the one connection that has a problem and allow the IO to be restarted on one of the other live connections? There is nothing wrong with the session, only a single connection. I guess I am calling for a level 0.5, so that I can abort only the troublesome connection. This would allow for a much faster IO recovery without adding hardly any coding complexity that is required for level 1. Comments? Kevin Lemay From owner-ips@ece.cmu.edu Wed May 29 21:08:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09630 for ; Wed, 29 May 2002 21:08:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4U0RPM06908 for ips-outgoing; Wed, 29 May 2002 20:27:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4U0RNw06903 for ; Wed, 29 May 2002 20:27:23 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 6A93D30706; Wed, 29 May 2002 20:27:22 -0400 (EDT) Date: Wed, 29 May 2002 17:25:25 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Lee Xing Cc: Subject: Re: iSCSI: iSCSI Analyzers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 29 May 2002, Lee Xing wrote: > Dear iSCSI colleagues, > > Please forgive me if this post is a bit off-topic. > > I'm looking for information on iSCSI analyzers, and would appreciate > it if you could tell me which iSCSI analyzer you are using, and what > you like/don't like? Ethereal, www.ethereal.com. It's very nice. The latest (CVS) version supports drafts 8, 9, 11, and 12. Not sure if draft 12 support made most recent release. Take care, Bill From owner-ips@ece.cmu.edu Wed May 29 21:09:41 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09657 for ; Wed, 29 May 2002 21:09:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4U0WYQ07236 for ips-outgoing; Wed, 29 May 2002 20:32:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4U0WWw07232 for ; Wed, 29 May 2002 20:32:32 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id DD81830706; Wed, 29 May 2002 20:32:31 -0400 (EDT) Date: Wed, 29 May 2002 17:30:34 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: , , Subject: RE: iSCSI:Can each do there own thing? In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C353638@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 29 May 2002 pat_thaler@agilent.com wrote: > Bill, > > I don't think you can currently call it a negotiation error if the other > side doesn't respond in the next PDU to a key you offered regardless of > whether the key is split, the PDU is full or anything else. Our protocol > does not require that an implementation to respond immediately to offers > and this is not listed as an error in the negotiation failures section. > > It would be an error if the Target set the T bit when it still hadn't > responded to offers though I don't think this is explicitly called > out as a negotiation failure. The same probably applies to the Target > setting the T bit when it has made offers that haven't been responded > to yet. Other than that, I think there is no requirement on where in > a negotiation the response to a particular offer is placed. Oh, Ok. Then consider my suggestion withdrawn. :-) Take care, Bill From owner-ips@ece.cmu.edu Thu May 30 00:05:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13098 for ; Thu, 30 May 2002 00:05:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4U3PJq16790 for ips-outgoing; Wed, 29 May 2002 23:25:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4U3PHw16786 for ; Wed, 29 May 2002 23:25:17 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4U3PBg5116376; Wed, 29 May 2002 23:25:11 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4U3P8i153624; Wed, 29 May 2002 21:25:08 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: Negotiation clarifications still needed To: pat_thaler@agilent.com Cc: wrstuden@wasabisystems.com, pat_thaler@agilent.com, "Julian Satran" , cbm@rose.hp.com, ips@ece.cmu.edu, mkrikis@yahoo.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Wed, 29 May 2002 20:23:02 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/29/2002 09:25:09 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I take it that we are all happy with the current C bit stuff (if it also is in Login). I think that is the hand off token. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com pat_thaler@agilent.com@ece.cmu.edu on 05/29/2002 04:15:57 PM Sent by: owner-ips@ece.cmu.edu To: wrstuden@wasabisystems.com, pat_thaler@agilent.com cc: Julian Satran/Haifa/IBM@IBMIL, cbm@rose.hp.com, ips@ece.cmu.edu, mkrikis@yahoo.com Subject: RE: iSCSI: Negotiation clarifications still needed From: Bill Studenmund What do we want to decide? Bill, As I mention in the response to John, I would like to see proposed text for specifying the hand-off. I think one could approach this by handing back and forth the right to make negotiation offers and leave to the implementations whether they send empty text negotiations or responses and declarations when they don't have the right to make negotiation offers. I think the hand-off should be based on a bit flag rather than based on whether the last PDU received ended in a complete key-value pair. Once people have had a chance to see the proposal, I would like to hear opinions beyond those of the few people who have been active in this discussion. Regards, Pat From owner-ips@ece.cmu.edu Thu May 30 00:06:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13116 for ; Thu, 30 May 2002 00:06:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4U3r6V18276 for ips-outgoing; Wed, 29 May 2002 23:53:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4U3r3w18272 for ; Wed, 29 May 2002 23:53:04 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4U3qsAN088914; Thu, 30 May 2002 05:52:55 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4U3qsT25220; Thu, 30 May 2002 05:52:54 +0200 To: Bill Studenmund Cc: ips@ece.cmu.edu, Martins Krikis , owner-ips@ece.cmu.edu, pat_thaler@agilent.com MIME-Version: 1.0 Subject: RE: iSCSI: Negotiation clarifications still needed X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 30 May 2002 06:52:51 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 30/05/2002 06:52:53, Serialize complete at 30/05/2002 06:52:53 Content-Type: multipart/alternative; boundary="=_alternative 00148D7CC2256BC9_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00148D7CC2256BC9_= Content-Type: text/plain; charset="us-ascii" Login is coming - I just wanted to get the list off this topic and look at Security! - Julo Bill Studenmund Sent by: owner-ips@ece.cmu.edu 05/30/2002 01:59 AM Please respond to Bill Studenmund To: Julian Satran/Haifa/IBM@IBMIL cc: , Martins Krikis , , Subject: RE: iSCSI: Negotiation clarifications still needed On Thu, 30 May 2002, Julian Satran wrote: > it is already there - thank you. Julo Thank you. I had not seen 12-95 was available. The use of the 'C' bit in Text Request and Response cleanly implememnts what Martins was suggesting. However I did not see where we state that login negotiations use a comparable mechanism. Actually, it looks like the text indicating login negotiations can span PDUs was removed. Was that the desired effect? > On Wed, 29 May 2002, Julian Satran wrote: > > > Martins & Pat, > > > > In going over the list of the arguments for the ongoing negotiation > (that > > we have now) versus. "stop-until-you-have-full-buffer" I think that I am > > more inclined now to accept that Martins's point about absolute > simplicity > > is valid and we should accept it (i.e., stop untill you have a full > > buffer. > > AFAIK it will not break any existing implementation as all/most of them > > are rudimentary and they are not in silicon (I hope). > > If there is intereste, I'm willing to help write suggested algorithms to > implement this, a la appendix E. > > Take care, > > Bill > > > > --=_alternative 00148D7CC2256BC9_= Content-Type: text/html; charset="us-ascii"
Login is coming - I just wanted to get the list off this topic and look at Security! - Julo


Bill Studenmund <wrstuden@wasabisystems.com>
Sent by: owner-ips@ece.cmu.edu

05/30/2002 01:59 AM
Please respond to Bill Studenmund

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        <ips@ece.cmu.edu>, Martins Krikis <mkrikis@yahoo.com>, <owner-ips@ece.cmu.edu>, <pat_thaler@agilent.com>
        Subject:        RE: iSCSI: Negotiation clarifications still needed

       


On Thu, 30 May 2002, Julian Satran wrote:

> it is already there - thank you. Julo

Thank you. I had not seen 12-95 was available.

The use of the 'C' bit in Text Request and Response cleanly implememnts
what Martins was suggesting.

However I did not see where we state that login negotiations use a
comparable mechanism. Actually, it looks like the text indicating login
negotiations can span PDUs was removed. Was that the desired effect?

> On Wed, 29 May 2002, Julian Satran wrote:
>
> > Martins & Pat,
> >
> > In going over the list of the arguments for the ongoing negotiation
> (that
> > we have now) versus. "stop-until-you-have-full-buffer" I think that I am
> > more inclined now to accept that Martins's point about absolute
> simplicity
> > is valid and we should accept it (i.e., stop untill you have a full
> > buffer.
> > AFAIK it  will not break any existing implementation as all/most of them
> > are rudimentary and they are not in silicon (I hope).
>
> If there is intereste, I'm willing to help write suggested algorithms to
> implement this, a la appendix E.
>
> Take care,
>
> Bill
>
>
>
>

--=_alternative 00148D7CC2256BC9_=-- From owner-ips@ece.cmu.edu Thu May 30 00:10:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13197 for ; Thu, 30 May 2002 00:10:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4U3SaZ16960 for ips-outgoing; Wed, 29 May 2002 23:28:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4U3SWw16955; Wed, 29 May 2002 23:28:33 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4U3SP9D003836; Thu, 30 May 2002 05:28:25 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4U3SPT74992; Thu, 30 May 2002 05:28:25 +0200 To: Mike Donohoe Cc: "'ips@ece.cmu.edu'" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Numeric Ranges X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 30 May 2002 06:28:22 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 30/05/2002 06:28:25, Serialize complete at 30/05/2002 06:28:25 Content-Type: multipart/alternative; boundary="=_alternative 0012D815C2256BC9_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0012D815C2256BC9_= Content-Type: text/plain; charset="us-ascii" Mike, The example is unfortunate. MaxConnection has o use a numeric-value and not a numeric-range. Numeric ranges are used in Appendix A for marker intervals as an example - in which case the originator indicates a range it can support and the responder selects a value. Julo Mike Donohoe Sent by: owner-ips@ece.cmu.edu 05/30/2002 12:57 AM Please respond to Mike Donohoe To: "'ips@ece.cmu.edu'" cc: Subject: iSCSI: Numeric Ranges I am unclear on how to select a value when given a Numeric Range. O-> MaxConnections=2~5 As the Responder I want 3. The "selection rule" for MaxConnections says "the lower of the 2 values". So one value is 2~5 the other is 3. Thus the min of those is 2....?.? If this is the case, I'm not seeing the necessity or added value of "numeric ranges". The initiator could just send the min value in the possible range (when the key's selection rule is min()). Thanks. Mike Donohoe --=_alternative 0012D815C2256BC9_= Content-Type: text/html; charset="us-ascii"
Mike,

The example is unfortunate. MaxConnection has o use a numeric-value and not a numeric-range.
Numeric ranges are used in Appendix A for marker intervals as an example - in which case the originator indicates a range it can support and the responder selects a value.

Julo



Mike Donohoe <Mike.Donohoe@quantum.com>
Sent by: owner-ips@ece.cmu.edu

05/30/2002 12:57 AM
Please respond to Mike Donohoe

       
        To:        "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: Numeric Ranges

       


I am unclear on how to select a value when given a Numeric Range.

O-> MaxConnections=2~5

As the Responder I want 3.  The "selection rule" for MaxConnections says
"the lower of the 2 values".  So one value is 2~5 the other is 3.  Thus the
min of those is 2....?.?

If this is the case, I'm not seeing the necessity or added value of "numeric
ranges".  The initiator could just send the min value in the possible range
(when the key's selection rule is min()).

Thanks.

Mike Donohoe

--=_alternative 0012D815C2256BC9_=-- From owner-ips@ece.cmu.edu Thu May 30 00:42:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13774 for ; Thu, 30 May 2002 00:42:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4U45Mk18976 for ips-outgoing; Thu, 30 May 2002 00:05:22 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4U45Lw18972 for ; Thu, 30 May 2002 00:05:21 -0400 (EDT) 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 g4U45BNU019296; Thu, 30 May 2002 06:05:11 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4U45AT36918; Thu, 30 May 2002 06:05:10 +0200 To: "Lakshmi Ramasubramanian" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: CRC32C Table generation X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 30 May 2002 07:05:07 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 30/05/2002 07:05:10, Serialize complete at 30/05/2002 07:05:10 Content-Type: multipart/alternative; boundary="=_alternative 00159991C2256BC9_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00159991C2256BC9_= Content-Type: text/plain; charset="us-ascii" Lakshmi, Those steps are widely described in literature. The iSCSI draft is overly large and IMHO overly burdened with explanations. I am afraid that I must answer negatively your request. Julo "Lakshmi Ramasubramanian" 05/30/2002 12:40 AM Please respond to "Lakshmi Ramasubramanian" To: , "Julian Satran" cc: Subject: iSCSI: CRC32C Table generation In the code given in RFC-1952 for generating the table for CRC32 algorithm, the constant 0xedb88320 is used. Since this constant is derived from the polynomial, it's different than 0xedb88320 for iSCSI. It took some effort to find out the steps to arrive at the constant from the given CRC32 polynomial. May I suggest we include this conversion steps in an appendix in the spec? thanks! -lakshmi --=_alternative 00159991C2256BC9_= Content-Type: text/html; charset="us-ascii"
Lakshmi,

Those steps are widely described in literature.
The iSCSI draft is overly large and IMHO overly burdened with explanations.
I am afraid that I must answer negatively your request.

Julo


"Lakshmi Ramasubramanian" <nramas@windows.microsoft.com>

05/30/2002 12:40 AM
Please respond to "Lakshmi Ramasubramanian"

       
        To:        <ips@ece.cmu.edu>, "Julian Satran" <Julian_Satran@il.ibm.com>
        cc:        
        Subject:        iSCSI: CRC32C Table generation

       


In the code given in RFC-1952 for generating the table
for CRC32 algorithm, the constant 0xedb88320 is used.
Since this constant is derived from the polynomial,
it's different than 0xedb88320 for iSCSI. It took
some effort to find out the steps to arrive at the constant
from the given CRC32 polynomial.

May I suggest we include this conversion steps in an appendix
in the spec?

thanks!
-lakshmi

--=_alternative 00159991C2256BC9_=-- From owner-ips@ece.cmu.edu Thu May 30 09:13:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02885 for ; Thu, 30 May 2002 09:13:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4UCUeq24376 for ips-outgoing; Thu, 30 May 2002 08:30:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4UBRPw20853 for ; Thu, 30 May 2002 07:27:25 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29217; Thu, 30 May 2002 07:26:58 -0400 (EDT) Message-Id: <200205301126.HAA29217@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-fcovertcpip-10.txt,.pdf Date: Thu, 30 May 2002 07:26:58 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Fibre Channel Over TCP/IP (FCIP) Author(s) : M. Rajagopal, e. Rodriguez, R. Weber Filename : draft-ietf-ips-fcovertcpip-10.txt,.pdf Pages : 67 Date : 29-May-02 Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcovertcpip-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-fcovertcpip-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-fcovertcpip-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020529140338.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcovertcpip-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcovertcpip-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020529140338.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu May 30 12:51:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12790 for ; Thu, 30 May 2002 12:51:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4UG3oj09935 for ips-outgoing; Thu, 30 May 2002 12:03:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4UG3lw09928; Thu, 30 May 2002 12:03:47 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 2605230706; Thu, 30 May 2002 12:03:47 -0400 (EDT) Date: Thu, 30 May 2002 09:01:50 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: , Martins Krikis , , Subject: RE: iSCSI: Negotiation clarifications still needed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 30 May 2002, Julian Satran wrote: > Login is coming - I just wanted to get the list off this topic and look at > Security! - Julo Thank you! Sounds good, and I eagerly await your results. :-) Take care, Bill From owner-ips@ece.cmu.edu Thu May 30 14:23:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16326 for ; Thu, 30 May 2002 14:23:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4UHh2417508 for ips-outgoing; Thu, 30 May 2002 13:43:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4UHh0w17504 for ; Thu, 30 May 2002 13:43:01 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id DDC06BD63; Thu, 30 May 2002 11:42:59 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 5D17114E; Thu, 30 May 2002 11:42:59 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 30 May 2002 11:42:59 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 May 2002 11:42:59 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353753@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: hufferd@us.ibm.com, pat_thaler@agilent.com Cc: wrstuden@wasabisystems.com, pat_thaler@agilent.com, Julian_Satran@il.ibm.com, cbm@rose.hp.com, ips@ece.cmu.edu, mkrikis@yahoo.com Subject: RE: iSCSI: Negotiation clarifications still needed Date: Thu, 30 May 2002 11:42:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I was in a meeting all yesterday so I haven't had a chance to check it yet. I expect to have an answer later today. Pat -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Wednesday, May 29, 2002 8:23 PM To: pat_thaler@agilent.com Cc: wrstuden@wasabisystems.com; pat_thaler@agilent.com; Julian Satran; cbm@rose.hp.com; ips@ece.cmu.edu; mkrikis@yahoo.com Subject: RE: iSCSI: Negotiation clarifications still needed I take it that we are all happy with the current C bit stuff (if it also is in Login). I think that is the hand off token. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com pat_thaler@agilent.com@ece.cmu.edu on 05/29/2002 04:15:57 PM Sent by: owner-ips@ece.cmu.edu To: wrstuden@wasabisystems.com, pat_thaler@agilent.com cc: Julian Satran/Haifa/IBM@IBMIL, cbm@rose.hp.com, ips@ece.cmu.edu, mkrikis@yahoo.com Subject: RE: iSCSI: Negotiation clarifications still needed From: Bill Studenmund What do we want to decide? Bill, As I mention in the response to John, I would like to see proposed text for specifying the hand-off. I think one could approach this by handing back and forth the right to make negotiation offers and leave to the implementations whether they send empty text negotiations or responses and declarations when they don't have the right to make negotiation offers. I think the hand-off should be based on a bit flag rather than based on whether the last PDU received ended in a complete key-value pair. Once people have had a chance to see the proposal, I would like to hear opinions beyond those of the few people who have been active in this discussion. Regards, Pat From owner-ips@ece.cmu.edu Thu May 30 14:25:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16403 for ; Thu, 30 May 2002 14:25:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4UI0WL18860 for ips-outgoing; Thu, 30 May 2002 14:00:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4UI0Uw18855 for ; Thu, 30 May 2002 14:00:31 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 26225BC1B; Thu, 30 May 2002 12:00:30 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id C379B10B; Thu, 30 May 2002 12:00:29 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 30 May 2002 12:00:29 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 May 2002 12:00:29 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C35375F@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: wrstuden@wasabisystems.com, mkrikis@yahoo.com Cc: hufferd@us.ibm.com, ips@ece.cmu.edu, Julian_Satran@il.ibm.com, pat_thaler@agilent.com Subject: RE: iSCSI:Can each do there own thing? Date: Thu, 30 May 2002 12:00:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 29 May 2002, Martins Krikis wrote: [very large snip] > Summary: > > 1. "no-originating on split-key scheme" > 2. "no-originating (except declarations) on split-key scheme" > 3. "no-originating on split-pair scheme" > 4. "no-originating (except declarations) on split-pair scheme" > 5. "empty-PDUs until end-of-data scheme" > 6. "empty-PDU on split-pair scheme" 7. "no-originating until end-of-data scheme" (I added 7) My preference is for 5 or 7. I think having to check for a split key or pair before making the decision on what to send is undesireable. However, I would also like to point out that 5 is almost equivalent to allowing an unlimited PDU size (or a PDU size up to the buffer size at the end of 4.1) during negotiation. The only difference is that the receiver can pace the arrival of the data by sending blank PDUs with 5 but it is not clear to me that that makes much implementation difference when one must be able to buffer the whole negotiation. Regards, Pat From owner-ips@ece.cmu.edu Thu May 30 15:44:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18542 for ; Thu, 30 May 2002 15:44:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4UJ19V23914 for ips-outgoing; Thu, 30 May 2002 15:01:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4UJ14w23900 for ; Thu, 30 May 2002 15:01:05 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 257C230706; Thu, 30 May 2002 15:01:04 -0400 (EDT) Date: Thu, 30 May 2002 11:58:59 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: , , , Subject: RE: iSCSI:Can each do there own thing? In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C35375F@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 30 May 2002 pat_thaler@agilent.com wrote: > On Wed, 29 May 2002, Martins Krikis wrote: > > [very large snip] > > > Summary: > > > > 1. "no-originating on split-key scheme" > > 2. "no-originating (except declarations) on split-key scheme" > > 3. "no-originating on split-pair scheme" > > 4. "no-originating (except declarations) on split-pair scheme" > > 5. "empty-PDUs until end-of-data scheme" > > 6. "empty-PDU on split-pair scheme" > 7. "no-originating until end-of-data scheme" > > (I added 7) > My preference is for 5 or 7. > > I think having to check for a split key or pair before making > the decision on what to send is undesireable. Agreed. > However, I would also like to point out that 5 is almost > equivalent to allowing an unlimited PDU size (or a PDU size up to > the buffer size at the end of 4.1) during negotiation. The only > difference is that the receiver can pace the arrival of the > data by sending blank PDUs with 5 but it is not clear to me > that that makes much implementation difference when one must be > able to buffer the whole negotiation. I agree that with 5 you do have to be able to buffer the whole negotiation payload. But that size only has to be 16k if you don't do the long-key cryptographic techniques, and 64k if you do. If an extended negotiation payload weighs in at over 64k, I think it's fair to indicate an error (if you're the target) and close the connection. If you aren't doing long-key crypto negotiation (kerberos and SPKM AFAIK), it would be fine to stop after 16k. Thoughts? Take care, Bill From owner-ips@ece.cmu.edu Thu May 30 15:44:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18570 for ; Thu, 30 May 2002 15:44:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4UJGfS24993 for ips-outgoing; Thu, 30 May 2002 15:16:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4UJGdw24988 for ; Thu, 30 May 2002 15:16:39 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 6F0F6B924; Thu, 30 May 2002 13:16:38 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 115271B2; Thu, 30 May 2002 13:16:38 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 30 May 2002 13:16:38 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 May 2002 13:16:37 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C3537A6@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Bill Studenmund , "THALER,PAT (A-Roseville,ex1)" Cc: mkrikis@yahoo.com, hufferd@us.ibm.com, ips@ece.cmu.edu, Julian_Satran@il.ibm.com Subject: RE: iSCSI:Can each do there own thing? Date: Thu, 30 May 2002 13:16:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill Studenmund wrote: > However, I would also like to point out that 5 is almost > equivalent to allowing an unlimited PDU size (or a PDU size up to > the buffer size at the end of 4.1) during negotiation. The only > difference is that the receiver can pace the arrival of the > data by sending blank PDUs with 5 but it is not clear to me > that that makes much implementation difference when one must be > able to buffer the whole negotiation. I agree that with 5 you do have to be able to buffer the whole negotiation payload. But that size only has to be 16k if you don't do the long-key cryptographic techniques, and 64k if you do. If an extended negotiation payload weighs in at over 64k, I think it's fair to indicate an error (if you're the target) and close the connection. If you aren't doing long-key crypto negotiation (kerberos and SPKM AFAIK), it would be fine to stop after 16k. Thoughts? So one could deal with this by making the max PDU data size during login negotiations 16k increasing to 64k when support for long-key cryptographic techniques is indicated, not add the C bit and not allow key-value pairs to be split. During full-feature phase negotiation, one would either need to not negotiate for longer sets of key-value pairs than fit in the maxPDURcvDataSize or one would still need the C bit. Regards, Pat From owner-ips@ece.cmu.edu Thu May 30 15:46:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18600 for ; Thu, 30 May 2002 15:46:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4UJYiV26430 for ips-outgoing; Thu, 30 May 2002 15:34:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4UJYbw26411 for ; Thu, 30 May 2002 15:34:37 -0400 (EDT) Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4UJYVPI026812 for ; Thu, 30 May 2002 12:34:31 -0700 (PDT) Received: from DAPW2K3 (dhcp-161-44-68-152.cisco.com [161.44.68.152]) by sponge.cisco.com (Mirapoint) with SMTP id AAX10659; Thu, 30 May 2002 14:34:30 -0500 (CDT) From: "Dave Peterson" To: "Ips@Ece. Cmu. Edu" Subject: iSCSI: SCSI Asynchronous Event clarification, reference to [SPC3] and [SAM] Date: Thu, 30 May 2002 14:34:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Howdy All, Clause 9.9.1 in Rev 12-95 currently states: "The sending of a SCSI Event (Asynchronous Event Notification in SCSI terminology) is controlled by a SCSI Control Mode Page bit." The notion of "Asynchronous Event Notification" is now obsolete in SAM-2 (and SPC-3). Instead, it is coined asynchronous event reporting (AER). And the sending of a SCSI async event is actually enabled by three bits in the SCSI Control mode page: RAERP - ready AER permission UAAERP - unit attention AER permission EAERP - error AER permission So I think the sentence should be reworded to something like: "If the target supports SCSI asynchronous event reporting (see SAM-2) as indicated in the standard INQUIRY data (see SPC-3), its use may be enabled by parameters in the SCSI Control mode page (see SPC-3)." Also, the reference [SPC3] is not quite correct and may be misleading. [SPC3]T10/1416-D, SCSI-3 Primary Commands (SPC). s/b [SPC3]T10/1416-D, SCSI Primary Commands - 3 (SPC-3). Lastly, all references to [SAM] should be replaced with [SAM2]. ...dap From owner-ips@ece.cmu.edu Thu May 30 15:47:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18622 for ; Thu, 30 May 2002 15:47:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4UJ8gb24475 for ips-outgoing; Thu, 30 May 2002 15:08:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4UJ8dw24470 for ; Thu, 30 May 2002 15:08:40 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 164C6C616; Thu, 30 May 2002 13:08:39 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 7C518241; Thu, 30 May 2002 13:08:35 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 30 May 2002 13:07:55 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 May 2002 13:07:53 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C3537A0@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: hufferd@us.ibm.com Cc: wrstuden@wasabisystems.com, Julian_Satran@il.ibm.com, cbm@rose.hp.com, ips@ece.cmu.edu, mkrikis@yahoo.com Subject: RE: iSCSI: Negotiation clarifications still needed Date: Thu, 30 May 2002 13:07:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I can't parse (on page 68): A value is whatever follows the = that follows the key-name up to a zero-byte delimiter that separates a key=value pair from the next or up to the end of data (for the last key=value pair if the PDU C flag bit is set to 0). I think I know what he meant but I can't get the text to parse clearly. It is trying to do too much in one sentence. How about: A value is whatever follows the = that follows the key-name up to a zero-byte delimiter. The zero-byte delimiter separates a key=value pair from the next and follows the last key=value pair when the PDU C flag bit is set to 0. The text on the bottom of page 72 is sufficient to produce the behavior we want but it doesn't make clear the reason for having the C bit. We don't need the C bit to know that the last value was incomplete. We need it to allow us to prepare a multi-PDU buffer of key-value pairs for transmission. How about: Key=value pairs may span PDU boundaries. The C flag bit allows an initiator or target to prepare a set of key values larger than the PDU size for transmission and send the set in multiple PDUs ensuring that it will not receive key-value pairs while those PDUs are being transmitted. An initiator or target wishing to do this indicates that more text follows by setting the C flag bit in the Text Request or Text Response to 1. A target or initiator receiving a Text Request or Text Response, respectively, with the C flag bit set to 1 MUST answer with a Text Response or Text Request with no data segment (DataSegmentLength 0). A Text Request or Text Response PDU having the C flag bit set to 1 MUST NOT have the F bit set to 1. In 4 the bit is called the C flag bit. In 9.10 and 9.11, it is called the C bit. It should be called the same thing everywhere. Otherwise it becomes hard to search for. As noted earlier the bit also needs to be added to 9.12 and 9.13. With that done, I am content with the text though much the same thing could be accomplished by enlarging PDU size during negotiation. The C bit just builds a super-PDU with pacing by the partner. Regards, Pat -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Wednesday, May 29, 2002 8:23 PM To: pat_thaler@agilent.com Cc: wrstuden@wasabisystems.com; pat_thaler@agilent.com; Julian Satran; cbm@rose.hp.com; ips@ece.cmu.edu; mkrikis@yahoo.com Subject: RE: iSCSI: Negotiation clarifications still needed I take it that we are all happy with the current C bit stuff (if it also is in Login). I think that is the hand off token. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com pat_thaler@agilent.com@ece.cmu.edu on 05/29/2002 04:15:57 PM Sent by: owner-ips@ece.cmu.edu To: wrstuden@wasabisystems.com, pat_thaler@agilent.com cc: Julian Satran/Haifa/IBM@IBMIL, cbm@rose.hp.com, ips@ece.cmu.edu, mkrikis@yahoo.com Subject: RE: iSCSI: Negotiation clarifications still needed From: Bill Studenmund What do we want to decide? Bill, As I mention in the response to John, I would like to see proposed text for specifying the hand-off. I think one could approach this by handing back and forth the right to make negotiation offers and leave to the implementations whether they send empty text negotiations or responses and declarations when they don't have the right to make negotiation offers. I think the hand-off should be based on a bit flag rather than based on whether the last PDU received ended in a complete key-value pair. Once people have had a chance to see the proposal, I would like to hear opinions beyond those of the few people who have been active in this discussion. Regards, Pat From owner-ips@ece.cmu.edu Thu May 30 16:42:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19579 for ; Thu, 30 May 2002 16:42:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4UK1iD28617 for ips-outgoing; Thu, 30 May 2002 16:01:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4UK1ew28607 for ; Thu, 30 May 2002 16:01:40 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id BF4A930706; Thu, 30 May 2002 16:01:38 -0400 (EDT) Date: Thu, 30 May 2002 12:59:39 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "THALER,PAT (A-Roseville,ex1)" Cc: , , , Subject: RE: iSCSI:Can each do there own thing? In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C3537A6@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 30 May 2002, THALER,PAT (A-Roseville,ex1) wrote: > So one could deal with this by making the max PDU data size during > login negotiations 16k increasing to 64k when support for long-key cryptographic > techniques is indicated, not add the C bit and not allow key-value pairs > to be split. During full-feature phase negotiation, one would either need to > not negotiate for longer sets of key-value pairs than fit in the maxPDURcvDataSize > or one would still need the C bit. That option would work for login, but I think we'd still need the C bit around for FFP negotiations for all the reasons the WG previously considered when coming up with the multi-PDU support in Text messages. While we could make the login PDU size larger for login, I'd say stick with the C bit technique. I think we need it for FFP, so we might as well use it for login. Take care, Bill From owner-ips@ece.cmu.edu Thu May 30 16:45:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19653 for ; Thu, 30 May 2002 16:45:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4UK6Fc29001 for ips-outgoing; Thu, 30 May 2002 16:06:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4UK6Dw28997 for ; Thu, 30 May 2002 16:06:13 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 60FBF30706; Thu, 30 May 2002 16:06:13 -0400 (EDT) Date: Thu, 30 May 2002 13:04:14 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: , , , , Subject: RE: iSCSI: Negotiation clarifications still needed In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C3537A0@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 30 May 2002 pat_thaler@agilent.com wrote: > I can't parse (on page 68): > > A value is whatever follows the = that follows the key-name up to a > zero-byte delimiter that separates a key=value pair from the next or > up to the end of data (for the last key=value pair if the PDU C flag > bit is set to 0). > > I think I know what he meant but I can't get the text to parse clearly. > It is trying to do too much in one sentence. > How about: > A value is whatever follows the = that follows the key-name up to a > zero-byte delimiter. The zero-byte delimiter separates a key=value > pair from the next and follows the last key=value pair when the PDU C flag > bit is set to 0. > > The text on the bottom of page 72 is sufficient to produce the behavior > we want but it doesn't make clear the reason for having the C bit. We > don't need the C bit to know that the last value was incomplete. We need > it to allow us to prepare a multi-PDU buffer of key-value pairs for > transmission. > How about: > Key=value pairs may span PDU boundaries. > > The C flag bit allows an initiator or target to prepare a set of > key values larger than the PDU size for transmission and send the set in > multiple > PDUs ensuring that it will not receive key-value pairs while those PDUs are > being transmitted. An initiator or target wishing to do this indicates that > more > text follows by setting the C flag bit in the Text Request or Text > Response to 1. A target or initiator receiving a Text Request or > Text Response, respectively, with the C flag bit set to 1 MUST answer with a > Text Response or Text Request with no data segment (DataSegmentLength > 0). A Text Request or Text Response PDU having the C flag > bit set to 1 MUST NOT have the F bit set to 1. Sounds good. I like the new wording. Take care, Bill From owner-ips@ece.cmu.edu Thu May 30 18:37:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21321 for ; Thu, 30 May 2002 18:37:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4ULqFa06364 for ips-outgoing; Thu, 30 May 2002 17:52:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4ULqDw06359 for ; Thu, 30 May 2002 17:52:13 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 85E1CBEC0; Thu, 30 May 2002 15:52:12 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 8C66F10B; Thu, 30 May 2002 15:52:11 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 30 May 2002 15:52:11 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 May 2002 15:52:11 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353827@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Julian Satran , ips@ece.cmu.edu Subject: RE: iSCSI-12-95 Date: Thu, 30 May 2002 15:52:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, I am having two problems with the second MUST in the following paragraph from iSCSI-12-95 7.2.1: If CHAP is used with a secret that has less than 96 random bits then IPsec encryption (according to the implementation requirements in Section 7.3.2 Confidentiality) MUST be used to protect the connection. Moreover, in this case IKE authentication with group pre-shared keys MUST NOT be used. When CHAP is used with secret shorter than 96 bits, a compliant implementation MUST NOT continue with the login unless it can verify that IPsec encryption is being used to protect the connection. Who or what does the requirement apply to? Is the iSCSI implementation expected to check whether IKE is using pre-shared keys or is this a requirement on the person setting up the security? It isn't clear to me that an iSCSI implementation has access to that information. Secondly, it isn't clear to me why it is required. I'm assuming the concern is that a member of a group with preshared keys could use an off-line dictionary attack to crack the CHAP secret of another member of the group but it seems to me that there are situations where this is not a threat. For instance, one could have a group that was a host and multiple equally secure disk arrays. If one isn't concerned about one of the arrays trying to impersonate another there isn't a danger in allowing them to authenticate with CHAP protected by IPsec enryption with a group pre-shared key. Could the MUST be made a SHOULD with a statement that ignoring the SHOULD means that one member of the group could crack the CHAP secret of another member? Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, May 29, 2002 3:02 PM To: ips@ece.cmu.edu Subject: iSCSI-12-95 12-95 is out. It has the latest wording on security and text negotiation (including the spanning). Still to go - text fixes in chapter 11. Julo From owner-ips@ece.cmu.edu Thu May 30 20:08:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22525 for ; Thu, 30 May 2002 20:08:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4UNLPM11860 for ips-outgoing; Thu, 30 May 2002 19:21:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from stargate-1.corp.iready.com ([65.115.68.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4UNDWw11430 for ; Thu, 30 May 2002 19:13:32 -0400 (EDT) Received: from MikeS8100Laptop (dhcp1-104.corp.iready.com [192.168.1.104]) by stargate-1.corp.iready.com (8.9.3/8.9.3) with SMTP id QAA24729; Thu, 30 May 2002 16:09:56 -0700 Message-ID: <002c01c2082f$8ef744d0$6801a8c0@MikeS8100Laptop> From: "Michael J. S. Smith \(iReady\)" To: , , Cc: References: Subject: iSCSI: A list of all normative sentences Date: Thu, 30 May 2002 16:13:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I wrote a Perl script to extract a list of all sentences from an RFC/draft that contain the normative words: MUST, SHOULD, and so on. Such a list seems more useful than the concordances that I have been sharing so far (it was actually a suggestion John made a while back). Parsing the text is not as easy as it sounds and I am still improving things. The current tool works pretty well on the text Internet drafts, and is still useful on the PDF from Julo's website (http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-12-95.pdf). Here (below) is the output for12-95. This information is useful (to me anyway) in order to focus on the areas where the draft is normative. I'll try and include some more useful things like section numbers and so forth, but it seemed like time was of the essence to get the draft cleaned up going in to last call - so I included what I currently have. Ignore the HTML markup (we just use that internally). Mike Smith CTO, iReady NumberOfMUSTsFound = 331
@SentencesWithMUSTs : The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. -IPsec transport mode is MAY and authentication MUST be used when encryption is used. -Padding bytes SHOULD be sent as 0 (instead of MUST be 0). -All specified keys except X-* MUST be accepted (2.8.3). MAY be discarded" into MUST be discarded. iSCSI targets and initiators MUST support at least one TCP connec-tion and MAY support several connections in a session. For this reason the task management command MUST carry the current CmdSN as a marker of their position in the stream of commands. An iSCSI target MUST be able to handle at least one immediate task management command and one immediate non-taskmanagement iSCSI request per connection at any time. With the exception of the commands marked for immediate delivery, the iSCSI target layer MUST deliver the commands for execution in the order specified by CmdSN. On any given connection, the iSCSI initiator MUST send the commands in increasing order of CmdSN, except for commands that are retransmitted due to digest error recovery and connection recovery. Comparisons and arithmetic on ExpCmdSN and MaxCmdSN MUST use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_ BITS =. The target MUST NOT transmit a MaxCmdSN that is less than ExpCmdSN-1. The target MUST silently ignore any non-immediate command outside of this range or non-immediate duplicates within the range. iSCSI initiators and targets MUST support the command numbering scheme. If an initiator issues a command retry for a command with CmdSN R on a connection when the session CmdSN register is Q, it MUST NOT advance the CmdSN past R + 2** 31 -1 unless a different non-immediate command with CmdSN equal or greater than Q was issued on the same connection if the connection is still operational, and the reception of the command is acknowledged by the target (see Section 8.4 Command Retry and Cleaning Old Command Instances). The second non-immediate command when sent, MUST be sent in-order after the retried command on the same connection. A target MUST NOT issue a command response or DATA-In PDU with sta-tus before acknowledging the command. Initiators and Targets MUST support the response-numbering scheme. Data and R2T PDUs, transferred as part of some command execution, MUST be sequenced. For any given write command, a target MUST issue less than 2** 32 R2Ts. Any input or output data sequence MUST contain less than 2** 32 numbered PDUs. Any other PDU, when received at initiator or target, is a protocol error and MUST result in the connection being terminated. Login requests and responses MUST be used exclusively during Login. On any connection the login phase MUST immediately succeed TCP connection establishment and a single Login Phase is allowed before tearing down a connection. For an iSCSI request issued over a TCP connection, the corresponding response and/ or requested PDU( s) MUST be sent over the same connection. For SCSI commands that require data and/ or a parameter transfer, the (optional) data and the status for the command MUST be sent over the same TCP connection to which the SCSI command is currently alle-giant, illustrating the above rule. Thus, if an initiator issues a READ command, the target MUST send the requested data, if any, followed by the status to the initiator over the same TCP connection that was used to deliver the SCSI command. If an initiator issues a WRITE command, the initiator MUST send the data, if any, for that command over the same TCP connection that was used to deliver the SCSI command. The target MUST return Ready To Transfer (R2T), if any, and the status over the same TCP connection that was used to deliver the SCSI command. Retransmission requests (SNACK PDUs) and the data and status that they generate MUST also use the same connection. iSCSI initiators and targets MUST also enforce some ordering rules. Unsolicited data MUST be sent on every connection in the same order in which commands were sent. Each iSCSI node, whether an initiator or target, MUST have an iSCSI name. Initiators and targets MUST support the receipt of iSCSI names of up to the maximum length of 255 bytes. The initiator MUST present both its iSCSI Initiator Name and the iSCSI Target Name to which it wishes to connect in the first login request of a new session or connection. An iSCSI name MUST be a UTF-8 encoding of a string of Unicode characters, with the following properties: -it is in Normalization Form C (see "Unicode Normalization Forms" [UNICODE]) -it contains only the following characters:. One of these two type strings MUST be used when constructing an iSCSI name; any type string not listed here is not allowed, as they cannot be guaranteed to be unique. This date MUST be a date during which the naming authority owned the domain name used in this format, and SHOULD be the date on which the domain name was acquired by this naming authority. If a specific implementation performs PDU delivery to the Sync and Steering layer through multiple operations, it MUST bracket an operation set used to deliver a single PDU in a manner that the Sync and Steering Layer can understand. The Sync and Steering Layer (which is OPTIONAL) MUST retain the PDU end address within the stream for every delivered iSCSI PDU. To enable the Sync and Steering operation to perform Steering, additional information, including identifying tags and buffer offsets, MUST also be retained for every sent PDU. On the outgoing path, the Sync and Steering layer MUST map the outgoing stream addresses from iSCSI stream addresses to TCP stream sequence numbers. However, Sync and Steering MUST take into account the additional data inserted in the stream by UFL. When used in SCSI parameter data, the SCSI port name MUST be encoded as:. After being selected the same TSIH value MUST be used whenever initiator or target refer to the given session and a TSIH is required. The following definitions will be used in the rest of this document: key-name: a string of one or more characters consisting of letters, digits, dot, minus, plus, commercial at, and underscore, A key-name MUST begin with a capital letter an must not exceed 63 characters. Any iSCSI target or initiator MUST support receiving at least 16384 bytes of key= value data in a negotiation sequence except when indicating support for very long authentication items by offering or selecting authentication methods such as public key certificates in which case they MUST support receiving at least 64 kilobytes of key= value data. All negotiations are explicit (i.e., the result MUST be based only on newly exchanged or declared values). However, the Text Response for a key not understood MUST be key= NotUnderstood. All keys in Chapter 11, except for the X-extension format, MUST be supported by iSCSI initiators and targets and MUST NOT be answered with NotUnderstood. A target or initiator receiving a Text Request respective Text Response with the C flag bit set to 1 MUST answer with a Text Response or Text Request with no data segment (DataSegmentLength 0). A Text Request or Text Response PDU having the C flag bit set to 1 MUST NOT have the F bit set to 1. The responding party MUST respond with the same key and select first value that it supports (and is allowed to use for the specific originator) selected from the originator list. The constant "None" MUST always be used to indicate a missing function. If a responder does not understand any particular value in a list it MUST ignore it. For simple-value negotiations, the responding party MUST respond with the same key. For boolean negotiations (keys taking the values Yes or No), the responding party MUST respond with the same key and the result of the negotiation when the received value does not determine that result by itself. The initial login request of any connection MUST include the InitiatorName key= value pair. For any connection within a session whose type is not "Discovery", the first login request MUST also include the TargetName key= value pair. The Login Phase MAY include a SecurityNegotiation stage and a LoginOperationalNegotiation stage and MUST include at least one of them, but the included stage MAY be empty except for the mandatory names. If both stages are used, the SecurityNegotiation MUST precede the LoginOperationalNegotiation. Security MUST be completely negotiated within the Login Phase. During this exchange, the next stage is selected by the target and MUST NOT exceed the value stated by the initiator. Targets MUST NOT submit parameters that require an additional initiator login request in a login response with the T bit set to 1. The Login Final-Response that accepts a Login Command can come only as a response to a Login command with the T bit set to 1, and both the command and response MUST have FullFeaturePhase in the NSG field. If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection. If the iSCSI target implementation supports altering the portal group configuration (including adding, deleting, and swapping of portals in a portal group), it MUST return the TargetPortalGroupTag key carrying the tag value of the servicing portal group. If the reconfiguration of iSCSI portal groups is a concern in a given environment, the iSCSI initiator MUST use this key to ascertain that it had indeed initiated the Login Phase with the intended target portal group. -The target MUST reply with the first option in the list it supports and is allowed to use for the specific initiator unless it does not support any in which case it MUST answer with "Reject" (see also Section 4.2 Text Mode Negotiation). -The initiator must be aware of the imminent completion of the SecurityNegotiation stage and MUST set the T bit to 1 and the NSG to what it would like the next stage to be. If the next stage is FullFeaturePhase, the target MUST respond with a Login Response with the Session ID and the protocol version. If the security negotiation fails at the target, then the target MUST send the appropriate Login Response PDU. The initiator MUST indicate its intent to terminate the negotiation by setting the T bit to 1; the target sets the T bit to 1 on the last response. Whenever parameter action or acceptance are dependent on other parameters, the dependent parameters MUST be sent after the parameters on which they depend. Thus, the TSIH in the Login PDU MUST be non-zero and CID does not change during a connection reinstatement. The initiator connection state MUST be CLEANUP_ WAIT (section 5.1) for attempting a connection reinstatement. Thus, the TSIH in the Login PDU MUST be zero to signal ses-sion reinstatement. The initiator session state MUST be FAILED (Section 5.3 Session State Diagrams) for attempting a session reinstatement. The initiator MUST indicate its intent to terminate the negotiation by setting the F bit to 1; the target sets the F bit to 1 on the last response. Targets MUST NOT submit parameters that require an additional initiator text request in a text response with the F bit set to 1. Whenever parameter action or acceptance is dependent on other parameters, the dependent parameters MUST be sent after the parameters on which they depend; if sent within the same command, a response for a parameter might imply responses for others. Whenever the target responds with the F bit set to 0, it MUST set the Target Transfer Tag to a value other than the default 0xffffffff. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. Retry MUST NOT be used for reasons other than plugging command sequence gaps. If initiators, as part of plugging command sequence gaps as described above, inadvertently issue retries for allegiant commands already in progress (i.e., targets did not see the discontinuities in CmdSN ordering), targets MUST silently discard the duplicate requests if the CmdSN window had not advanced by then. Targets MUST support the retry functionality described above. When an iSCSI command is retried, the command PDU MUST carry the original Initiator Task Tag and the original operational attributes (e.g., flags, function names, LUN, CDB etc.) as well as the original CmdSN. The command being retried MUST be sent on the same connection as the original command unless the original connection was already successfully logged out. When a target does not support allegiance reassignment, it MUST respond with a task management response code of "Task failover not supported". If allegiance reassignment is supported by the target, but the task is still allegiant to a different connection, the target MUST respond with a task management response code of "Task still allegiant". Targets MUST NOT implicitly terminate an active task by sending a Reject PDU for any PDU exchanged during the life of the task. The CmdSN of the rejected command PDU (if it carried one) MUST NOT be considered received by the target (i.e., a command sequence gap must be assumed for the CmdSN), even though the CmdSN can be reliably ascertained in this case. When a data PDU is rejected and its DataSN can be ascertained, a target MUST advance ExpDataSN for the current data burst if a recovery R2T is being generated. When a target or an initiator receives an iSCSI PDU with a format error, it MUST immediately terminate all transport connections in the session either with a connection close or with a connection reset and escalate the format error to session recovery (see Section 6.12.4 Session Recovery). When a target receives any iSCSI PDU with a header digest error, it MUST silently discard the PDU. When a target receives any iSCSI PDU with a payload digest error, it MUST answer with a Reject iSCSI PDU with a Reason-code of DataDigest-Error and discard the PDU. -If the discarded PDU is a solicited or unsolicited iSCSI data PDU (for immediate data in a command PDU, non-data PDU rule below applies), the target MUST do one of the following: a) Request retransmission with a recovery R2T. If the target chooses to implement this option, it MUST wait to receive all the data (signaled by a Data PDU with the final bit set for all outstanding R2Ts) before sending the response PDU. When an initiator receives any iSCSI PDU with a header digest error, it MUST discard the PDU. When an initiator receives any iSCSI PDU with a payload digest error, it MUST discard the PDU. -If the discarded PDU is an iSCSI data PDU, the initiator MUST do one of the following: a) Request the desired data PDU through SNACK. In its turn, the target MUST either resend the data PDU or, reject the SNACK with a Reject PDU with a reason-code of "SNACK Reject" in which case: i) if the status had not already been sent for the com-mand, the target MUST terminate the command with an iSCSI response reason( Section 9.4.3 Response) of "SNACK rejected". Initiator in this case MUST inter-nally signal the completion with the "SNACK rejected" reason (Section 9.4.3 Response) disregarding any received status PDU, but must wait for the status to be received before doing so. -If the discarded PDU is a response PDU, the initiator MUST do one of the following: a) Request PDU retransmission with a status SNACK. The initiator MUST address these implied digest errors as described in Section 6.5 Digest Errors. Target MUST address these implied digest errors as described in Section 6. When an initiator receives an iSCSI status PDU with an out-of-order StatSN that implies missing responses, it MUST address the one or more missing status PDUs as described in Section 6.5 Digest Errors. If the initiator wants to recover the missing data for a command, it MUST NOT acknowledge the received responses that start from the StatSN of the interested command, until it has completed receiving all the data PDUs of the command. When an initiator receives duplicate R2TSNs (due to proactive retransmission of R2Ts by the target) or duplicate DataSNs (due to proactive SNACKs by the initiator), it MUST discard the duplicates. On a ULP timeout for a command (that carried a CmdSN of n), the iSCSI initiator MUST abort the command by either using the Abort Task task management function request, or a "close the connection" Logout if it intends to continue the session. If the abort request is received and the original command is miss-ing, targets MUST consider the original command with that RefCmdSN to be received and issue a task management response with the response code: "Function Complete". -During Login, any failure in negotiation MUST be considered a login process failure and the Login Phase must be terminated, and with it the connection. The operational parameters of the session or the connection MUST continue to be the values agreed upon during an earlier successful negotiation (i.e., any partial results of this unsuccessful negotiation must be undone). On connection failure, the initiator and target MUST do one of the following:. Either side may choose to escalate to session recovery, and the other side MUST give it precedence. On a connection failure, a target MUST terminate and/ or discard all the active immediate commands regard-less of which of the above options is used (i.e., immediate commands are not recoverable across connection failures). Use of within-connection and within-command recovery classes MUST NOT be attempted before the connection is in Full Feature Phase. The initiator MUST close the connec-tion. It then MUST either Logout the failed connection, or Login with an implied Logout, and reassign connection alle-giance for all commands still in progress associated with the failed connection on another connection (that MAY be a newly established connection) using the "Task reassign" task management function (see Section 9.5.1 Function). The initiator MUST handle it as a TCP connection failure for the connec-tion( s) referred to in the Message. The target MUST close the connection and if more than one connection is available, the target SHOULD send an Asynchronous Message that indicates it has dropped the connection. iSCSI implementations MUST provide means of protection against active attacks (e.g., pretending to be another identity, message insertion, deletion, modification, and replaying) and passive attacks (e.g., eavesdropping, gaining advantage by analyzing the data sent over the line). Whenever an iSCSI initiator gets a response whose keys, or their values, are not according to the step definition, it MUST abort the connection. Whenever an iSCSI target gets a response whose keys, or their values, are not according to the step definition, it MUST answer with a Login reject with the "Initiator Error" or "Missing Parameter" status (these statuses are not intended for cryptographically incorrect value, e.g., the CHAP response, for which "Authentication Failure" status MUST be specified). Compliant iSCSI implementation MUST implement the CHAP authentication method [RFC1994] (according to Section 10.5 Challenge Handshake. Implementations MUST support use of up to 128 bits random CHAP secrets, including the means to generate such secrets and to accept them from an external generation source. Implementations MUST NOT provide secret generation (or expansion) means other than random generation. 3.2 Confidentiality) MUST be used to protect the connection. Moreover, in this case IKE authentication with group pre-shared keys MUST NOT be used. When CHAP is used with secret shorter than 96 bits, a compliant implementation MUST NOT continue with the login unless it can verify that IPsec encryption is being used to protect the connection. Originators MUST NOT reuse the CHAP challenge sent by the Responder for the other direction of a bi-directional authentication. Responders MUST check for this condition and close the iSCSI TCP connection if it occurs. In iSCSI authentication, the prime modulus N MUST be at least 768 bits. Upon receiving N and g from the Target, the Initiator MUST verify that they match a well-known group that satisfies the above requirements and abort the connection if they do not match. An iSCSI compliant initiator or target MUST provide data integrity and authentication by implementing IPsec [RFC2401] with ESP [RFC2406] in tunnel mode and MAY provide data integrity and authentication by implementing IPsec with ESP in transport mode. The IPsec implementation MUST fulfill the following iSCSI specific requirements:. -HMAC-SHA1 MUST be implemented [RFC2404]. The ESP anti-replay service MUST also be implemented. When confidentiality is used it MUST be accompanied by data integrity and authentication to provide comprehensive protection against eavesdropping, message insertion, deletion, modification, and replaying. An iSCSI compliant initiator or target MUST provide confidentiality by implementing IPsec [RFC2401] with ESP [RFC2406] in tunnel mode and MAY provide confidentiality by implementing IPsec with ESP in transport mode. with the following iSCSI specific requirements: -3DES in CBC mode MUST be implemented [RFC2451]. The NULL encryption algorithm MUST also be implemented. A compliant iSCSI implementation MUST meet the key management requirements of the IPsec protocol suite. Authentication, security association negotiation, and key management MUST be provided by implementing IKE [RFC2409] using the IPsec DOI [RFC2407] with the following iSCSI specific requirements:. -Peer authentication using a pre-shared key MUST be sup-ported. -Both IKE Main Mode and Aggressive Mode MUST be supported. -In the IKE Phase 2 Quick Mode exchanges for creating the Phase 2 SA, the Identity Payload fields MUST be present. ID_ IPV4_ ADDR, ID_ IPV6_ ADDR (if the protocol stack supports IPv6) and ID_ FQDN Identity payloads MUST be supported; ID_ USER_ FQDN MAY be supported. The ID_ KEY_ ID Identity Payload MUST NOT be used. Manual keying MUST NOT be used because it does not provide the necessary re-keying support. iSCSI initiators and targets MUST support autosense. All commands that change the state of the device (as in SPACE com-mands for sequential access devices, and EXCHANGE MEDIUM for medium changer device), MUST be issued as non-immediate commands for deter-ministic and in order delivery to iSCSI targets. Any compliant sender MUST set all bits not defined and all reserved fields to zero unless specified otherwise. Any compliant receiver MUST ignore any bit not defined and all reserved fields unless specified otherwise. Initiators MUST NOT use target opcodes and targets MUST NOT use initiator opcodes. The TotalAHSLength is used only in PDUs that have an AHS and MUST be 0 in all other PDUs. The DataSegmentLength MUST be 0 whenever the PDU has no data segment. While a task exists, this tag MUST uniquely identify the task session-wide. For bidirectional operations, an additional header segment MUST be present in the header sequence that indicates the Bidirectional Read Expected Data Transfer Length. In this case, the F bit MUST be set to 1. If the Expected Data Transfer Length is higher than the FirstBurst-Size (the negotiated maximum amount of unsolicited data the target will accept), the initiator MUST send the maximum size of unsolic-ited data OR ONLY the immediate data. MUST be used to contain the CDB spillover. For a response other than "Command Completed at Target" bits 3-6 MUST be 0. If a SCSI device error is detected while data from the initiator is still expected (the command PDU did not contain all the data and the target has not received a Data PDU with the final bit Set), the tar-get MUST wait until it receives a Data PDU with the F bit set in the last expected sequence before sending the Response PDU. iSCSI targets MUST support and enable autosense. In the case of responses sent due to a retransmis-sion request, the StatSN MUST be the same as the first time the PDU was sent unless the connection has since been restarted. When MaxCmdSN changes at the target while the target has no pending PDUs to convey this information to the initiator, it MUST generate a NOP-IN to carry the new MaxCmdSN. For all these functions, the Task Management Function Response MUST be returned as detailed in Section 9.6 Task Management Function Response. According to [SAM2] for all the tasks covered by the task management response (i.e., with CmdSN not higher than the task management command CmdSN), additional responses MUST NOT be delivered to the SCSI layer after the task management response. The iSCSI target MUST ensure that no responses for the tasks covered by a task management function are delivered to the iSCSI initiator after the task management response. For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST continue to respond to all valid target transfer tags (received via R2T, Text Response, NOP-In, or SCSI Data-in PDUs) related to the affected task set, even after issuing the task management request. The target on its part MUST wait for responses on all affected target transfer tags before acting on either of these two task management requests. If the connection is still active (it is not undergoing an implicit or explicit logout), ABORT TASK MUST be issued on the same connection to which the task to be aborted is allegiant at the time the Task Management Request is issued. For the LOGICAL UNIT RESET function, the target MUST behave as dictated by the Logical Unit Reset function in [SAM2]. In addition, for the TARGET COLD RESET, the target MUST then termi-nate all of its TCP connections to all initiators (all sessions are terminated). TASK REASSIGN MUST be received by the target ONLY after the connection on which the command was previously executing has been successfully logged-out. TASK REASSIGN MUST be issued as an immediate command. For all the other functions this field MUST be set to the reserved value 0xffffffff. For the ABORT TASK function, initiators MUST always set this to the CmdSN of the task identified by the Initiator Task Tag field. The initiator MUST discard any discontiguous data PDUs from the previous execution and the target MUST retransmit all data previously transmitted in Data-in PDUs (if any) starting with ExpDataSN. For the TARGET COLD RESET function, the target MUST then close all of its TCP connections to all initiators (terminates all sessions). The response to ABORT TASK SET and CLEAR TASK SET MUST be issued by the target only after all the commands affected have been received by the target, the corresponding task management functions have been executed by the SCSI target and the delivery of all responses delivered until the task management function completion have been con-firmed (acknowledged through ExpStatSN) by the initiator on all connections of this session. Although targets MAY choose to send even non-exception status in separate responses, initiators MUST support non-exception status in Data-In PDUs. DataSegmentLength MUST not exceed MaxRecvPDUDataSize for the direc-tion it is sent and the total of all the DataSegmentLength of all PDUs in a sequence MUST not exceed MaxBurstSize (or FirstBurstSize for unsolicited data). The target should use the A bit moderately; it MAY set the A bit to 1 only once every MaxBurstSize bytes or on the last Data-In PDU that concludes the entire requested read data transfer for the task from the target's perspective, and MUST NOT do so more frequently than this. On receiving a Data-In PDU with the A bit set to 1, if there are no holes in the read data until that Data-In PDU, the initiator MUST issue a SNACK of type DataACK except when it is able to acknowledge the status for the task immediately via ExpStatSN on other outbound PDUs if the status for the task is also received; in this latter case (acknowledgement through ExpStatSN) sending a SNACK of type DataACK in response to the A bit is not mandatory but if it is done it must not be sent after the status acknowledgement through ExpStatSN. If the initiator has detected holes in the read data until that Data-In PDU, it MUST postpone issuing the SNACK of type DataACK until the holes are filled. An initiator also MUST NOT acknowledge the status for the task before those holes are filled. On incoming data, the Target Transfer Tag MUST be provided by the target if the A bit is set to 1. If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command; otherwise, the LUN field is reserved. This field MUST ONLY be set if the S bit is set to 1. Any input or output data sequence MUST contain less than 2** 32 numbered PDUs. The sending of 0 length data segments should be avoided, but initiators and targets MUST be able to properly receive 0 length data segments. If the command is completed with an error, then the response and sense data MUST be sent in a SCSI Response PDU (i.e., MUST NOT be sent in a SCSI Data packet). For Bidirectional commands, the status MUST be sent in a SCSI Response PDU. If this bit is set to 1 the F bit MUST also be set to 1. In order to allow write operations without an explicit initial R2T, the initiator and target MUST have negotiated the key InitialR2T to No during Login. If an R2T is answered with a single Data-out PDU, the Buffer Offset in the Data PDU MUST be the same as the one specified by the R2T and the data length of the Data PDU MUST be the same as the Desired Data Transfer Length specified in the R2T. If the R2T is answered with a sequence of Data PDUs, the Buffer Offset and Length MUST be within the range of those specified by R2T, and the last PDU MUST have the F bit set to 1. If DataPDUInOrder is set to Yes, the Buffer Offsets and Lengths for consecutive PDUs MUST form a continuous non-overlapping range and the PDUs MUST be sent in increasing offset order. Within a connection, outstanding R2Ts MUST be fulfilled by the initiator in the order in which they were received. The number of R2Ts in a command MUST be less than 2** 32-1. The Desired Data Transfer Length MUST NOT be 0 and MUST not exceed MaxBurstSize. There is no protocol rule about the Target Transfer Tag except that the value 0xffffffff is reserved and MUST never be sent by a target in an R2T. This Async Message MUST be sent on the same connection as the one requesting to be logged out. The initiator MUST honor this request by issuing a Logout as early as possible, but no later than Parameter3 seconds. Initiator MUST send a Logout with a reason code of "Close the connection" (if not the only connection) OR "Close the session" to close all the connections (if using multiple connec-tions). An initiator MUST have at most one outstanding Text Request on a connection at any given time. If the command is sent as part of a sequence of text requests and responses, the Initiator Task Tag MUST be the same for all the requests within the sequence (similar to linked SCSI commands). It MUST do so whenever it sets the F bit to 0 in the response. The initiator MUST ignore the Target Transfer Tag in the Text Response when the F bit is set to 1. If the Target Transfer Tag is not 0xffffffff the LUN field MUST be the one sent by the target in the Text Response. The data lengths of a text request MUST NOT exceed the iSCSI target MaxRecvPDUDataSize (a per connection and per direction negotiated parameter). A Text Response with the F bit set to 1 MUST NOT contain key= value pairs that may require additional answers from the initiator. A Text Response with the F bit set to 1 MUST have a Target Transfer Tag field set to the reserved value of 0xffffffff. A Text Response with the F bit set to 0 MUST have a Target Transfer Tag field set to a value other than the reserved 0xffffffff. When a target has more work to do (e.g., cannot transfer all the remaining text data in a single Text Response or has to continue the negotiation) and has enough resources to proceed, it MUST set the Target Transfer Tag to a value other than the reserved value of 0xffffffff. Otherwise the Target Transfer Tag MUST be set to 0xffffffff. The initiator MUST copy the Target Transfer Tag and LUN in its next request to indicate that it wants the rest of the data. The data lengths of a text request MUST NOT exceed the iSCSI initia-tor MaxRecvPDUDataSize (a per connection and per direction negotiated parameter). After establishing a TCP connection between an initiator and a tar-get, the initiator MUST start a Login Phase to gain further access to the target's resources. All Login requests within the Login Phase MUST carry the same Ver-sion-max. The target MUST use the value presented with the first login request. All Login requests within the Login Phase MUST carry the same Ver-sion-min. The target MUST use the value presented with the first login request. A vendor or organization with one or more OUIs, or one or more Enterprise Numbers, MUST use at least one of these numbers and select the appropriate value for the T field when its components generate ISIDs. An OUI or EN MUST be set in the corresponding fields in network byte order (byte big-endian). If the ISID is derived from something assigned to a hardware adapter or interface by a vendor, as a preset default value, it MUST be configurable to a value assigned according to the SCSI port behavior desired by the system in which it is installed (see Section 8.1.1 Conservative Reuse of ISIDs and Section 8.1.2 iSCSI Name, ISID and TPGT Use) and the resultant ISID MUST also be persistent over power cycles, reboot, card swap etc. The reserved value 0 MUST be used on the first connection for a new session. Otherwise the TSIH sent by the target at the conclusion of successful login of the first connection for this session MUST be used. All Login requests within a Login Phase MUST carry the same TSIH. The target MUST check the value presented with the first login request and act as specified in Section 4.3.1 Login Phase Start. All Login requests within the Login Phase MUST carry the same CID. The target MUST use the value presented with the first login request. If the login request is a leading login request the target MUST use the value presented in CmdSN as the target value for ExpCmdSN. All keys in Chapter 11, except for the X-extension format, MUST be supported by iSCSI initiators and targets. All Login responses within the Login Phase MUST carry the same Version-max. The initiator MUST use the value presented as a response to the first login request. All Login responses within the Login Phase MUST carry the same Version-active. The initiator MUST use the value presented as a response to the first login request. For a new session, the target MUST generate a non-zero TSIH and return it in the Login Final-Response (see Section 4.3 Login Phase). All of the redirec-tion status class responses MUST return one or more text key parameters of the type "TargetAddress", which indicates the target's new address. If the Status Class is not 0, the initiator and target MUST close the TCP connection. A login response with a T bit set to 1 MUST NOT contain key= value pairs that may require additional answers from the initiator within the same stage. If the status class is 0, the T bit MUST NOT be set to 1 if the T bit in the request was set to 0. All keys in Chapter 11, except for the X-extension format, MUST be supported by iSCSI initiators and targets. After sending the Logout PDU, an initiator MUST NOT send any new iSCSI commands on the closing connection. If the Logout is intended to close the session, new iSCSI commands MUST NOT be sent on any of the connections participating in the session. When receiving a Logout request with the reason code of "close the connection" or "close the session", the target MUST abort all pending commands, whether acknowledged or not, on that connection or session respectively. When receiving a Logout request with the reason code "remove connection for recovery", the target MUST discard all requests not yet acknowledged that were issued on the specified connection and suspend all data/ status/ R2T transfers on behalf of pending commands on the specified connection. After receiving the Logout response and attempting to receive the FIN (if still possible), the initiator MUST completely close the loggingout connection. If an initiator intends to start recovery for a failing connection, it MUST use either the Logout command to "clean-up" the target end of a failing connection and enable recovery to start, or use the Login command with a non-zero TSIH and the same CID on a new connection for the same effect (see Section 9.14.2 CID). If the tasks terminated in any of the above cases are SCSI tasks, they MUST be internally terminated with CHECK CONDITION status with a sense key of unit attention and ASC/ ASCQ values of 0x6E/ 0x00 (COMMAND TO LOGICAL UNIT FAILED). After Logout, the TCP connection referred by the CID MUST be closed at both ends (or all connections must be closed if the logout reason was session close). The numbered-response( s) or R2T( s), requested by a SNACK, MUST be delivered as exact replicas of the ones the initiator missed except for the fields ExpCmdSN, MaxCmdSN and ExpDataSN which MUST carry the current values. The numbered Data-In PDUs, requested by a SNACK with a RunLength different from 0, MUST be delivered as exact replicas of the ones the initiator missed except the fields ExpCmdSN and MaxCmdSN which MUST carry the current values. Any SNACK that requests a numbered-response, Data, or R2T that was not sent by the target MUST be rejected with a reason code of "Protocol error". Data/ R2T SNACK for a command MUST precede status acknowledgement for the given command. For Status SNACK and DataACK, the Initiator Task Tag MUST be set to the reserved value 0xffffffff. In all other cases, the Initiator Task Tag field MUST be set to the Initiator Task Tag of the referenced command. In all other cases, the Target Transfer Tag field MUST be set to the reserved value of 0xffffffff. If the target supports recovery within connection, it MAY reject the SNACK after which it MUST issue an Asynchronous Message PDU with an iSCSI event that indicates "Request Logout". If an initiator operates at ErrorRecoveryLevel 1 or higher, it MUST issue a SNACK of type DataACK after receiving a Data-In PDU with the A bit set to 1. However, if the initiator has detected holes in the input sequence, it MUST postpone issuing the SNACK of type DataACK until the holes are filled. The RunLength MUST also be 0 for a DataACK SNACK. The first data SNACK issued after initiator's MaxRecvPDUDataSize decreased, for a command issued on the same connection before the change in MaxRecvPDUDataSize, MUST use RunLength "0" to request retransmission of any number of PDUs (including one). In all the cases in which a pre-instantiated SCSI task is terminated because of the reject, the target MUST issue a proper SCSI command response with CHECK CONDITION as described in Section 9.4.3 Response. If the error is detected while data from the initiator is still expected (the command PDU did not contain all the data and the target has not received a Data-out PDU with the Final bit 1), the target MUST wait until it receives the Data-out PDU with the F bit set to 1 before sending the Response PDU. When used as a ping command, the Initiator Task Tag MUST be set to a valid value (not the reserved 0xffffffff). Upon receipt of a NOP-In with the Target Transfer Tag set to a valid value (not the reserved 0xffffffff), the initiator MUST respond with a NOP-Out. In this case, the NOP-Out Target Transfer Tag MUST con-tain a copy of the NOP-In Target Transfer Tag. When a target receives the NOP-Out with a valid Initiator Task Tag, it MUST respond with a Nop-In Response (see NOP-In). The NOP-Out MUST have the Target Transfer Tag set only if it is issued in response to a NOP-In with a valid Target Transfer Tag. When the Target Transfer Tag is set, the LUN field MUST also be cop-ied from the NOP-In. When a target receives the NOP-Out with a valid Initiator Task Tag (not the reserved value 0xffffffff), it MUST respond with a NOP-In with the same Initiator Task Tag that was provided in the NOP-Out Command. It MUST also duplicate up to the first MaxRecvPDUDataSize bytes of the initiator provided Ping Data. For such a response, the Target Transfer Tag MUST be 0xffffffff. When a target sends a NOP-In with the Initiator Task Tag set to 0xffffffff) it MUST NOT send any data in the data segment (DataSegmentLength MUST be 0). If the target is initiating a NOP-In without wanting to receive a corresponding NOP-Out, this field MUST hold the reserved value of 0xffffffff. A LUN MUST be set to a correct value when the Target Transfer Tag is valid (not the reserved value 0xffffffff). The initiator and target MUST implement CHAP. For KRB5 (Kerberos V5) [RFC1510], the initiator MUST use:. If the initiator authentication fails, the target MUST respond with a Login reject with "Authentication Failure" status. Otherwise, if the initiator has selected the mutual authentication option (by setting MUTUAL-REQUIRED in the ap-options field of the KRB_ AP_ REQ), the target MUST reply with: KRB_ AP_ REP=< KRB_ AP_ REP> where KRB_ AP_ REP is the server's response message as defined in [RFC1510]. If mutual authentication was selected and target authentication fails, the initiator MUST close the connection. KRB_ AP_ REQ and KRB_ AP_ REP are large-binary-values and their binary length (not the length of the character string that represents them in encoded form) MUST not exceed 65536 bytes. For SPKM1 and SPKM2 [RFC2025], the initiator MUST use: SPKM_ REQ=< SPKM-REQ> where SPKM-REQ is the first initiator token as defined in [RFC2025]. If the initiator authentication fails, the target MUST return an error. Otherwise, if the AuthMethod is SPKM1 or if the initiator has selected the mutual authentication option (by setting mutual-state bit in the options field of the REQ-TOKEN in the SPKM-REQ), the tar-get MUST reply with: SPKM_ REP_ TI=< SPKM-REP-TI> where SPKM-REP-TI is the target token as defined in [RFC2025]. If mutual authentication was selected and target authentication fails, the initiator MUST close the connection. Otherwise, if the AuthMethod is SPKM1, the initiator MUST continue with: SPKM_ REP_ IT=< SPKM-REP-IT> where SPKM-REP-IT is the second initiator token as defined in [RFC2025]. If the initiator authentication fails, the target MUST answer with a Login reject with "Authentication Failure" status. All the SPKM-* tokens are large-binary-values and their binary length (not the length of the character string that represents them in encoded form) MUST not exceed 65536 bytes. For SRP [RFC2945], the initiator MUST use: SRP_ U=< user> TargetAuth= Yes /* or TargetAuth= No */ The target MUST answer with a Login reject with the "Authorization Failure" status or reply with:. SRP_ N=< N> SRP_ g=< g> SRP_ s=< s> The initiator MUST either close the connection or continue with: SRP_ A=< A> The target MUST answer with a Login reject with the "Authentication Failure" status or reply with:. SRP_ B=< B> The initiator MUST close the connection or continue with: SRP_ M=< M> If the initiator authentication fails, the target MUST answer with a Login reject with "Authentication Failure" status. Otherwise, if the initiator sent TargetAuth= Yes in the first message (requiring target authentication), the target MUST reply with:. SRP_ HM=< H( A | M | K)> If the target authentication fails, the initiator MUST close the connection. The length of N, g, s, A, B, M in binary form (not the length of the character string that represents them in encoded form) MUST not exceed 1024 bytes. For CHAP [RFC1994], the initiator MUST use:. The target MUST answer with a Login reject with the "Authentication Failure" status or reply with:. The initiator MUST continue with: CHAP_ N=< N> CHAP_ R=< R> or, if it requires target authentication, with: CHAP_ N=< N> CHAP_ R=< R> CHAP_ I=< I> CHAP_ C=< C> If the initiator authentication fails, the target MUST answer with a Login reject with "Authentication Failure" status. Otherwise, if the initiator required target authentication, the target MUST reply with CHAP_ N=< N> CHAP_ R=< R> If target authentication fails, the initiator MUST close the connection. Where N, (A, A1, A2), I, C, and R are (correspondingly) the Name, Algorithm, Identifier, Challenge, and Response as defined in [RFC1994], N is a text string, A, A1, A2, and I are numbers, and C and R are binaryvalues and their binary length (not the length of the character string that represents them in encoded form) MUST not exceed 1024 bytes. When the Initiator and Target agree on a digest, this digest MUST be used for every PDU in Full Feature Phase. The initiator of the TCP connection MUST provide this key to the remote endpoint in the first login request if the initiator is not establishing a discovery session. host90 InitiatorName= iSCSI The initiator of the TCP connection MUST provide this key to the remote endpoint at the first Login of the Login Phase for every connection. Scope: SW TargetAlias=< iSCSI-local-name-value> Examples: TargetAlias= Bob-s Disk TargetAlias= Database Server 1 Log Disk TargetAlias= Web Server 3 Disk 20 If a target has been configured with a human-readable name or description, this name MUST be communicated to the initiator during a Login Response PDU. If ImmediateData is set to No and InitialR2T is set to Yes, then the initiator MUST NOT send unsolicited data and the target MUST reject unsolicited data with the corresponding response code. If ImmediateData is set to No and InitialR2T is set to No, then the initiator MUST NOT send unsolicited immediate data, but MAY send one unsolicited burst of Data-OUT PDUs. The responder MUST select a value that does not exceed the offered value. FirstBurstSize MUST NOT exceed MaxBurstSize. The responder MUST select a value that does not exceed the offered value. The responder MUST select a value that does not greater the offered value. The responder MUST select a value that does not exceed the offered value. If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence). MaxOustandingR2T MUST be set to 1 in this case. The responder MUST select a value that does not exceed the offered value. When reduced to iSCSI terms, markers MUST indicate the offset to a 4-byte word boundary in the stream. The SendTargets command MUST only be sent during the Full Feature Phase of a normal or discovery session. A system that contains targets MUST support discovery sessions on each of its IP addresses, and MUST support the SendTargets command on the discovery session. A target MUST support the SendTargets com-mand on operational sessions; these will only return address information about the target to which the session is connected, and do not return information about other targets. The text key MUST be SendTargets. This value MUST be supported on a discovery session, and MUST NOT be supported on an operational session. This value MUST be supported on discovery sessions. A discovery session MUST be capable of returning addresses for those targets that would have been returned had value= all been designated. This MUST be supported on operational sessions, and MUST NOT return targets other than the one to which the session is logged in. A SendTargets response MUST NOT not contain target names if there are no targets for the requesting initiator to access. A SendTargets response MUST NOT contain iSCSI default target names.
-----------------------------------------------------------------------
NumberOfSHOULDsFound = 37
@SentencesWithSHOULDs : The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. -ACA is SHOULD. -Changed the FIM SHOULD to should(!). -Padding bytes SHOULD be sent as 0 (instead of MUST be 0). Initiators undertake recovery actions if the difference is greater than an implementation defined constant that SHOULD NOT exceed 2** 31-1. A graceful transport connection shutdown SHOULD be initiated by either party only when the connection is not in iSCSI Full Feature Phase. A target MAY terminate a Full Feature Phase connection on internal exception events, but it SHOULD announce the fact through an Asynchronous Message PDU. This date MUST be a date during which the naming authority owned the domain name used in this format, and SHOULD be the date on which the domain name was acquired by this naming authority. The first Login Response PDU during the Login Phase from the iSCSI target SHOULD return the TargetPortalGroupTag key that contains the tag value of the iSCSI portal group servicing the Login Request PDU. If the security negotiation fails at the initiator, the initiator SHOULD close the connection. In reassigning connection allegiance for a command, the targets SHOULD continue the command from its current state. For example, when reassigning read commands, the target SHOULD take advantage of ExpDataSN field provided by the Task Management Function Request (which must be set to zero if there was no data transfer) and bring the read command to completion by sending the remaining data and sending (or resending) the status. To avoid a race with the target, which may already have a recovery R2T or a termination response on its way, an initiator SHOULD NOT originate a SNACK for an R2T based on its internal timeouts (if any). The target MUST close the connection and if more than one connection is available, the target SHOULD send an Asynchronous Message that indicates it has dropped the connection. Although technically possible, iSCSI SHOULD NOT be configured with-out security. -AES CBC MAC with XCBC extensions SHOULD be implemented [AESCBC]. -AES in Counter mode SHOULD be implemented [AESCTR] (NOTE: This is still subject to the IPsec WG's standardization plans). DES in CBC mode SHOULD NOT be used due to its inherent weakness. Peer authentication using the public key encryption methods outlined in IKE sections 5.2 and 5.3[ 7] SHOULD NOT be used. -When digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload( s) to specify the certificate authority. IKE negotia-tors SHOULD check the pertinent Certificate Revocation List (CRL) before accepting a PKI certificate for use in IKE authentication procedures. IKE main mode with pre-shared key authentication method SHOULD NOT be used when either the initiator or the target uses dynamically assigned IP addresses. The IP Subnet, IP Address Range, ID_ DER_ ASN1_ DN, ID_ DER_ ASN1_ GN formats SHOULD NOT be used. When IPsec is used the receipt of an IKE Phase 2 delete message SHOULD NOT be interpreted as a reason for tearing down the iSCSI TCP connection. As iSCSI can have many commands in-flight between initiator and target, iSCSI initiators and targets SHOULD support ACA. A consideration of the above factors for SCSI tape devices as an example suggests that implementations SHOULD use ErrorRecoveryLevel= 1 when transport connection failure is not a concern, and ErrorRecoveryLevel= 2 when the connection failure is also of high likelihood during a backup/ retrieval. The padding bytes SHOULD be 0. The padding bytes SHOULD be sent as 0. If neither bit is set, the Residual Count field SHOULD be zero. If neither bit is set, the Bidirectional Read Residual Count field SHOULD be zero. The issuing initiator SHOULD however terminate (i.e. by setting the Fbit to 1) these response sequences as quickly as possible, and it is recommended to terminate all responses with no data. The Data Segments of Data-in and Data-out PDUs SHOULD be filled to the integer number of 4 byte words (real payload) unless the F bit is set to 1. If DataSequenceInOrder is Yes, then consecutive R2Ts SHOULD refer to continuous non-overlapping ranges. Once this message is received, the initiator SHOULD NOT issue new iSCSI commands. For the Algorithm, as stated in [RFC1994], one value is required to be implemented: 5 (CHAP with MD5) To guarantee interoperability, initiators SHOULD always offer it as one of the proposed algorithms. This key SHOULD be sent by an initiator within the Login Phase, if available. If a SendTargets response reports an iSCSI address for a target, it SHOULD also report all other addresses in its portal group in the same response.
-----------------------------------------------------------------------
NumberOfSHALLsFound = 1
@SentencesWithSHALLs : The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.
-----------------------------------------------------------------------
NumberOfREQUIREDsFound = 5
@SentencesWithREQUIREDs : The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. Responses are REQUIRED in all other cases, and the value chosen and sent by the responder becomes the outcome of the negotiation. Otherwise, if the initiator has selected the mutual authentication option (by setting MUTUAL-REQUIRED in the ap-options field of the KRB_ AP_ REQ), the target MUST reply with: KRB_ AP_ REP=< KRB_ AP_ REP> where KRB_ AP_ REP is the server's response message as defined in [RFC1510]. I-> Login (CSG, NSG= 0,1 T= 1) KRB_ AP_ REQ=< krb_ ap_ req> (krb_ ap_ req contains the Kerberos V5 ticket and authenticator with MUTUAL-REQUIRED set in the ap-options field) If the authentication is successful, the target proceeds with: T-> Login (CSG, NSG= 0,1 T= 1) KRB_ AP_ REP=< krb_ ap_ rep> (krb_ ap_ rep is the Kerberos V5 mutual authentication reply) If the authentication is successful, the initiator may proceed with:. T-> Login-PR (CSG, NSG= 0,0 T= 0) AuthMethod= KRB5 I-> Login (CSG, NSG= 0,1 T= 1) KRB_ AP_ REQ= krb_ ap_ req (MUTUAL-REQUIRED not set in the ap-options field of krb_ ap_ req) If the authentication is successful, the target proceeds with: T-> Login (CSG, NSG= 0,1 T= 1) I-> Login (CSG, NSG= 1,0 T= 0).
-----------------------------------------------------------------------
NumberOfRECOMMENDEDsFound = 1
@SentencesWithRECOMMENDEDs : The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.
-----------------------------------------------------------------------
NumberOfMAYsFound = 72
@SentencesWithMAYs : The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. -IPsec transport mode is MAY and authentication MUST be used when encryption is used. MAY be discarded" into MUST be discarded. iSCSI targets and initiators MUST support at least one TCP connec-tion and MAY support several connections in a session. To enable command recovery, the target MAY maintain enough state information to enable data and status recovery after a connection failure. As part of the login process, the initiator and target MAY wish to authenticate each other and set a security association protocol for the session. In order to protect the TCP connection, an IPsec security associa-tion MAY be established before the Login request. However, consecutive commands that are part of a SCSI linked commandchain task MAY use different connections. During the iSCSI Full Feature Phase, the initiator and target MAY interleave unrelated SCSI commands, their SCSI Data, and responses over the session. A target that receives data out of order MAY terminate the session. A target MAY terminate a Full Feature Phase connection on internal exception events, but it SHOULD announce the fact through an Asynchronous Message PDU. Sync and Steering MAY also restrict the type of transformations UFL may perform on the stream. b) Discoverysession -a session opened only for target discovery; the target MAY accept only text requests with the SendTar-gets key and a logout request with reason "close the session". A range or a large-numerical-value MAY ONLY be offered if it is explicitly allowed for a key. An offer of a value not admissible (e.g., not within the specified bounds) MAY be answered with the constant "Reject" or the responder MAY select an admissible value. The initial login request of the first connection of a session MAY also include the SessionType key= value pair. The Login Phase MAY include a SecurityNegotiation stage and a LoginOperationalNegotiation stage and MUST include at least one of them, but the included stage MAY be empty except for the mandatory names. The initiator and target MAY want to negotiate authentication parameters. The initiator MAY also send proprietary options. Operational parameter negotiation during the login MAY be done:. Operational parameter negotiation MAY involve several Login requestresponse exchanges started and terminated by the initiator. Some operational parameters MAY be negotiated outside (after) the Login Phase. Operational parameter negotiation MAY involve several text request-response exchanges, which the initiator always starts and terminates and uses the same Initiator Task Tag. An initiator MAY reset an operational parameter negotiation by issu-ing a Text request with the Target Transfer Tag set to the value 0xffffffff after receiving a response with the Target Transfer Tag set to a value other than 0xffffffff. It is also assumed that at the target, incoming data (read data) MAY be kept for recovery or it can be re-read from a device server. However, targets MAY choose to send/ receive the entire data on a reassignment of connection allegiance, and it is not considered an error. The target MAY advance its ExpDataSN if it does not attempt to recover the lost data PDU. An iSCSI initiator MAY attempt to plug a command sequence gap on the target end (in the absence of an acknowledgement of the command by way of ExpCmdSN) before the ULP timeout by retrying the unacknowl-edged command, as described in Section 6.1 Retry and Reassign in Recovery. The latter MAY be used periodically by highly reliable implementations. Initiators and targets MAY also use the keep-alive option on the TCP connection to enable early link failure detection on otherwise idle links. In every case, they detail the lowest class recovery that MAY be attempted. Both the iSCSI target and initiator MAY escalate the error handling to an error recovery class, which impacts a larger number of iSCSI tasks in any of the cases identified in the following discussion. It then MUST either Logout the failed connection, or Login with an implied Logout, and reassign connection alle-giance for all commands still in progress associated with the failed connection on another connection (that MAY be a newly established connection) using the "Task reassign" task management function (see Section 9.5.1 Function). Very simple initiators and targets MAY perform session recovery on all iSCSI errors and therefore place the burden of recovery on the SCSI layer and above. An iSCSI compliant initiator or target MUST provide data integrity and authentication by implementing IPsec [RFC2401] with ESP [RFC2406] in tunnel mode and MAY provide data integrity and authentication by implementing IPsec with ESP in transport mode. An iSCSI compliant initiator or target MUST provide confidentiality by implementing IPsec [RFC2401] with ESP [RFC2406] in tunnel mode and MAY provide confidentiality by implementing IPsec with ESP in transport mode. Certificate-based peer authentication using digital signatures MAY be supported. ID_ IPV4_ ADDR, ID_ IPV6_ ADDR (if the protocol stack supports IPv6) and ID_ FQDN Identity payloads MUST be supported; ID_ USER_ FQDN MAY be supported. MAY follow. The data segment MAY also be followed by a data-digest. It MAY be followed by Additional Header Segments (AHS), a Header-Digest, a Data Segment, and/ or a Data-Digest. The R and W MAY both be 1 when the corresponding Expected Data Transfer Lengths are 0, but they CANNOT both be 0 when the corresponding Expected Data Transfer Length and Bidirectional Read Expected Data Transfer Length are not 0. For some iSCSI responses, the response data segment MAY contain some response related information, (e.g., for a target failure, it may contain a vendor specific detailed description of the failure). The iSCSI initia-tor MAY deliver to the SCSI layer all responses received before the task management response (i.e., it is a matter of implementation if the SCSI responses -received before the task management response but after the task management request was issued -are delivered to the SCSI layer by the iSCSI layer in the initiator). In case all or part of the response sequence is not received (due to digest errors) for a valid TTT, the target MAY treat it as a case of within-command error recovery class (section 6.12.1) if it is supporting ErrorRecoveryLevel >= 1, or alternatively may drop the connection to complete the requested task set function. Target Reset MAY also be subject to SCSI access controls for the requesting initia-tor. Although targets MAY choose to send even non-exception status in separate responses, initiators MUST support non-exception status in Data-In PDUs. It MAY be used as a "change direction" indication for Bidirectional operations that need such a change. The target should use the A bit moderately; it MAY set the A bit to 1 only once every MaxBurstSize bytes or on the last Data-In PDU that concludes the entire requested read data transfer for the task from the target's perspective, and MUST NOT do so more frequently than this. An R2T MAY be answered with one or more SCSI Data-out PDUs with a matching Target Transfer Tag. If the last PDU (marked with the F bit) is received before the Desired Data Transfer Length is transferred, a target MAY choose to Reject that PDU with "Protocol error" reason code. The target MAY reject any new I/ O requests that it receives after this Message with the reason code "Waiting for Logout". The AsyncVCode details the vendor code, and data MAY accompany the report. For an iSCSI Event, additional vendor-unique data MAY accompany the Async event. Initiators MAY ignore the data when not understood while processing the rest of the PDU. A target MAY reset its internal negotiation state if an exchange is stalled by the initiator for a long time or if it is running out of resources. The text response MAY refer to key= value pairs presented in an earlier text request and the text in the request may refer to earlier responses. The initiator MAY provide some basic parameters in order to enable the target to determine if the initiator may use the target's resources and the initial text parameters for the security exchange. This MAY be due to a request for a resource for which the initiator does not have permission. The initiator MAY provide some basic parameters in order to enable the target to determine if the initiator may use the target's resources and the initial text parameters for the security exchange. An initiator MAY use a logout command to remove a connection from a session or to close an entire session. An iSCSI target that does not support recovery within connection MAY reject the status SNACK. If the target supports recovery within connection, it MAY reject the SNACK after which it MUST issue an Asynchronous Message PDU with an iSCSI event that indicates "Request Logout". An initiator MAY ignore the A bit if it deems that the bit is being set aggressively by the target (i.e., before the MaxBurstSize limit is reached). Proprietary algorithms MAY also be negotiated for digests. If ImmediateData is set to No and InitialR2T is set to No, then the initiator MUST NOT send unsolicited immediate data, but MAY send one unsolicited burst of Data-OUT PDUs. If ImmediateData is set to Yes and InitialR2T is set to No, then the initiator MAY send unsolicited immediate data and/ or one unsolicited burst of Data-OUT PDUs. The initiator and target MAY indicate their readiness to receive and/ or send markers during login separately for each connection. If a receiver indicates that it desires a marker, the sender MAY agree (during negotiation) and provide the marker at the desired interval. An initiator MAY make use of the SendTargets as it sees fit. A discovery session MAY respond to a SendTargets request with its complete list of targets, or with a list of targets that is based on the name of the initiator logged in to the session. The initiator MAY keep the session to a default target open, and MAY send subsequently SendTargets commands to discover new targets.
-----------------------------------------------------------------------
NumberOfOPTIONALsFound = 4
@SentencesWithOPTIONALs : The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. The Sync and Steering Layer (which is OPTIONAL) MUST retain the PDU end address within the stream for every delivered iSCSI PDU. Specifically, the two cases in which responses are OPTIONAL are:. The TARGET RESET function (WARM and COLD) implementation is OPTIONAL and when implemented, should act as described below.
-----------------------------------------------------------------------
From owner-ips@ece.cmu.edu Thu May 30 21:08:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23378 for ; Thu, 30 May 2002 21:08:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4V0KhL15222 for ips-outgoing; Thu, 30 May 2002 20:20:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4V0Kfw15217 for ; Thu, 30 May 2002 20:20:41 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id E5EDBB072; Thu, 30 May 2002 18:20:40 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id A6E8510B; Thu, 30 May 2002 18:20:40 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 30 May 2002 18:20:40 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 May 2002 18:20:40 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353877@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI-12-95: header digest error clarification Date: Thu, 30 May 2002 18:20:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, There was a brief discussion of the issues raised by header digest errors, but nothing has made it into 6.5 Digest Errors. 6.5 says that a target or initiator receiving a PDU with a header digest error MUST silently discard the PDU. The problem is that it can't do that. A header digest error means that DataSegmentLength may have been corrupted so the receiver doesn't know where the PDU ends and the next begins. Possible resolutions: If FIM is enabled, silently discard everything from the bad header to the next start of header pointed to by a marker. If FIM is not enabled, chose one (or more of the following): Assume that the DataSegmentLength is correct and check to see if a valid header including a valid header digest and CmdSN begins at the point indicated by the length. If it does, then drop the PDU as indicated by the DataSegmentLength and resume processing the next PDU. If the next header doesn't check, close the connection or use the next technique. Downside: This entails a small risk that the DataSegmentLength was wrong but unluckily pointed into a part of the data stream that looked like a valid header. Also, there may not be a next header to check immediately so one may have to wait for an indeterminate time before closing this out. Search the data stream for a valid header. This gets kind of ugly because headers are 48 bytes long (or longer with AHS) but can start every 4 bytes so one has check overlapping sets of bytes for a correct CRC which either means it will be slow or one will need multiple CRC checkers. Also, this has a significantly higher risk of finding a false valid header. Therefore, this recovery method should not be allowed. Close the connection. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, May 29, 2002 3:02 PM To: ips@ece.cmu.edu Subject: iSCSI-12-95 12-95 is out. It has the latest wording on security and text negotiation (including the spanning). Still to go - text fixes in chapter 11. Julo From owner-ips@ece.cmu.edu Fri May 31 00:19:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26516 for ; Fri, 31 May 2002 00:19:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4V3dar26061 for ips-outgoing; Thu, 30 May 2002 23:39:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4V3dYw26055 for ; Thu, 30 May 2002 23:39:34 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 178DA30706; Thu, 30 May 2002 23:39:34 -0400 (EDT) Date: Thu, 30 May 2002 20:37:35 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Subject: Question about unsolicited data in 12-95 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk I have a question about unsolicited data, and if I understand it correctly, I have some suggestions for text corrections. My concusion stems around if you can send both immediate data and an unsolicited burst of PDUs (assuming negotiations aprove both). I think the answer is yes, as in 11.12 (talking about ImmediateData) there is: If ImmediateData is set to Yes and InitialR2T is set to No, then the initiator MAY send unsolicited immediate data and/or one unsolicited burst of Data-OUT PDUs. The and/or indicates to me that in that case the initiator can send immediate data, an unsolicited burst, or do both. If the above is not correct, please disregard the rest of the note. I had a question, when doing both immediate and an unsolicited burst of Data-OUT PDUs, about if FirstBurstSize included the immediate data or not. The text in section 11.10, talking about the InitialR2T key, indicates that FirstBurstSize does include the immediate data. If all the above is correct, I'd like to suggest the following changes: Paragraph starting at top of page 41: rate iSCSI data PDUs. An initiator may send unsolicited data as imme- diate up to the negotiated maximum PDU size or in a separate PDU sequence (up to the FirstBurstSize). All subsequent data MUST be solicited. The maximum size of an individual data PDU or the immedi- ate-part of the first unsolicited burst MAY be negotiated at login. I suggest we change the first full sentance to: rate iSCSI data PDUs. An initiator may send unsolicited data as imme- diate up to the negotiated maximum PDU size, in a separate PDU sequence (up to the FirstBurstSize), or both. All subsequent data MUST be solicited. ... Third full paragraph of page 41: An iSCSI initiator MAY choose to send no unsolicited data, only imme- diate data or FirstBurstSize bytes of unsolicited data with a com- mand. If any non-immediate unsolicited data are sent, the total unsolicited data MUST be either the negotiated amount or all the data if the total amount is less than the negotiated amount for unsolic- ited data. I suggest something like: An iSCSI initiator MAY choose to send no unsolicited data, only imme- diate data, a burst of unsolicited Data-OUT commands, or both. If any non-immediate unsolicited data are sent, the total unsolicited data MUST be either the negotiated amount or all the data if the total amount is less than the negotiated amount for unsolic- ited data. I also have a question about a paragraph on p136, in section 9.3.4: If the Expected Data Transfer Length is higher than the FirstBurst- Size (the negotiated maximum amount of unsolicited data the target will accept), the initiator MUST send the maximum size of unsolic- ited data OR ONLY the immediate data. Does that mean that if the Expected Data Transfer Length > FirstBurstSize, I can't opt to send no unsolicited data? Or does it mean I can: send none, send 1 immediate PDU, or send FirstBurstSize (optionally with some of that as immediate data)? Take care, Bill From owner-ips@ece.cmu.edu Fri May 31 00:29:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27059 for ; Fri, 31 May 2002 00:29:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4V4Aoo27914 for ips-outgoing; Fri, 31 May 2002 00:10:50 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4V4Alw27909 for ; Fri, 31 May 2002 00:10:47 -0400 (EDT) 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 g4V4AZNU022304; Fri, 31 May 2002 06:10:35 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4V4AY6100266; Fri, 31 May 2002 06:10:34 +0200 To: pat_thaler@agilent.com Cc: cbm@rose.hp.com, ips@ece.cmu.edu, "John Hufferd" , mkrikis@yahoo.com, wrstuden@wasabisystems.com MIME-Version: 1.0 Subject: RE: iSCSI: Negotiation clarifications still needed X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 31 May 2002 07:10:29 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 31/05/2002 07:10:34, Serialize complete at 31/05/2002 07:10:34 Content-Type: multipart/alternative; boundary="=_alternative 0016643AC2256BCA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0016643AC2256BCA_= Content-Type: text/plain; charset="us-ascii" One piece of information that will help you parsing. In fact the fact that convinced me to change position is realizing that adding a 0 byte after the last key=value is not enough to distinguish the last key=value you have to have at least two in the absence of the C bit. As for the rest I will make the text adjustements over (my) weekend. Julo pat_thaler@agilent.com 05/30/2002 10:07 PM Please respond to pat_thaler To: John Hufferd/San Jose/IBM@IBMUS cc: wrstuden@wasabisystems.com, Julian Satran/Haifa/IBM@IBMIL, cbm@rose.hp.com, ips@ece.cmu.edu, mkrikis@yahoo.com Subject: RE: iSCSI: Negotiation clarifications still needed I can't parse (on page 68): A value is whatever follows the = that follows the key-name up to a zero-byte delimiter that separates a key=value pair from the next or up to the end of data (for the last key=value pair if the PDU C flag bit is set to 0). I think I know what he meant but I can't get the text to parse clearly. It is trying to do too much in one sentence. How about: A value is whatever follows the = that follows the key-name up to a zero-byte delimiter. The zero-byte delimiter separates a key=value pair from the next and follows the last key=value pair when the PDU C flag bit is set to 0. The text on the bottom of page 72 is sufficient to produce the behavior we want but it doesn't make clear the reason for having the C bit. We don't need the C bit to know that the last value was incomplete. We need it to allow us to prepare a multi-PDU buffer of key-value pairs for transmission. How about: Key=value pairs may span PDU boundaries. The C flag bit allows an initiator or target to prepare a set of key values larger than the PDU size for transmission and send the set in multiple PDUs ensuring that it will not receive key-value pairs while those PDUs are being transmitted. An initiator or target wishing to do this indicates that more text follows by setting the C flag bit in the Text Request or Text Response to 1. A target or initiator receiving a Text Request or Text Response, respectively, with the C flag bit set to 1 MUST answer with a Text Response or Text Request with no data segment (DataSegmentLength 0). A Text Request or Text Response PDU having the C flag bit set to 1 MUST NOT have the F bit set to 1. In 4 the bit is called the C flag bit. In 9.10 and 9.11, it is called the C bit. It should be called the same thing everywhere. Otherwise it becomes hard to search for. As noted earlier the bit also needs to be added to 9.12 and 9.13. With that done, I am content with the text though much the same thing could be accomplished by enlarging PDU size during negotiation. The C bit just builds a super-PDU with pacing by the partner. Regards, Pat -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Wednesday, May 29, 2002 8:23 PM To: pat_thaler@agilent.com Cc: wrstuden@wasabisystems.com; pat_thaler@agilent.com; Julian Satran; cbm@rose.hp.com; ips@ece.cmu.edu; mkrikis@yahoo.com Subject: RE: iSCSI: Negotiation clarifications still needed I take it that we are all happy with the current C bit stuff (if it also is in Login). I think that is the hand off token. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com pat_thaler@agilent.com@ece.cmu.edu on 05/29/2002 04:15:57 PM Sent by: owner-ips@ece.cmu.edu To: wrstuden@wasabisystems.com, pat_thaler@agilent.com cc: Julian Satran/Haifa/IBM@IBMIL, cbm@rose.hp.com, ips@ece.cmu.edu, mkrikis@yahoo.com Subject: RE: iSCSI: Negotiation clarifications still needed From: Bill Studenmund What do we want to decide? Bill, As I mention in the response to John, I would like to see proposed text for specifying the hand-off. I think one could approach this by handing back and forth the right to make negotiation offers and leave to the implementations whether they send empty text negotiations or responses and declarations when they don't have the right to make negotiation offers. I think the hand-off should be based on a bit flag rather than based on whether the last PDU received ended in a complete key-value pair. Once people have had a chance to see the proposal, I would like to hear opinions beyond those of the few people who have been active in this discussion. Regards, Pat --=_alternative 0016643AC2256BCA_= Content-Type: text/html; charset="us-ascii"
One piece of information that will help you parsing.
In fact the fact that convinced me to change position is realizing that adding a 0 byte after the last key=value
is not enough to distinguish the last key=value you have to have at least two in the absence of the C bit.

As for the rest I will make the text adjustements over (my) weekend.

Julo


pat_thaler@agilent.com

05/30/2002 10:07 PM
Please respond to pat_thaler

       
        To:        John Hufferd/San Jose/IBM@IBMUS
        cc:        wrstuden@wasabisystems.com, Julian Satran/Haifa/IBM@IBMIL, cbm@rose.hp.com, ips@ece.cmu.edu, mkrikis@yahoo.com
        Subject:        RE: iSCSI: Negotiation clarifications still needed

       


I can't parse (on page 68):

A value is whatever follows the = that follows the key-name up to a
zero-byte delimiter that separates a key=value pair from the next or
up to the end of data (for the last key=value pair if the PDU C flag
bit is set to 0).

I think I know what he meant but I can't get the text to parse clearly.
It is trying to do too much in one sentence.
How about:
A value is whatever follows the = that follows the key-name up to a
zero-byte delimiter. The zero-byte delimiter separates a key=value
pair from the next and follows the last key=value pair when the PDU C flag
bit is set to 0.

The text on the bottom of page 72 is sufficient to produce the behavior
we want but it doesn't make clear the reason for having the C bit. We
don't need the C bit to know that the last value was incomplete. We need
it to allow us to prepare a multi-PDU buffer of key-value pairs for
transmission.
How about:
Key=value pairs may span PDU boundaries.

The C flag bit allows an initiator or target to prepare a set of
key values larger than the PDU size for transmission and send the set in
multiple
PDUs ensuring that it will not receive key-value pairs while those PDUs are
being transmitted. An initiator or target wishing to do this indicates that
more
text follows by setting the C flag bit in the Text Request or Text
Response to 1. A target or initiator receiving a Text Request or
Text Response, respectively, with the C flag bit set to 1 MUST answer with a
Text Response or Text Request with no data segment (DataSegmentLength
0). A Text Request or Text Response PDU having the C flag
bit set to 1 MUST NOT have the F bit set to 1.

In 4 the bit is called the C flag bit. In 9.10 and 9.11, it is called the C
bit.
It should be called the same thing everywhere. Otherwise it becomes hard to
search for. As noted earlier the bit also needs to be added to 9.12 and
9.13.

With that done, I am content with the text though much the same thing
could be accomplished by enlarging PDU size during negotiation. The C bit
just builds a super-PDU with pacing by the partner.

Regards,
Pat

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Wednesday, May 29, 2002 8:23 PM
To: pat_thaler@agilent.com
Cc: wrstuden@wasabisystems.com; pat_thaler@agilent.com; Julian Satran;
cbm@rose.hp.com; ips@ece.cmu.edu; mkrikis@yahoo.com
Subject: RE: iSCSI: Negotiation clarifications still needed



I take it that we are all happy with the current C bit stuff (if it also is
in Login).  I think that is the hand off token.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


pat_thaler@agilent.com@ece.cmu.edu on 05/29/2002 04:15:57 PM

Sent by:    owner-ips@ece.cmu.edu


To:    wrstuden@wasabisystems.com, pat_thaler@agilent.com
cc:    Julian Satran/Haifa/IBM@IBMIL, cbm@rose.hp.com, ips@ece.cmu.edu,
       mkrikis@yahoo.com
Subject:    RE: iSCSI: Negotiation clarifications still needed




From: Bill Studenmund
<snip>
What do we want to decide?

Bill,

As I mention in the response to John, I would like to see proposed text for
specifying the hand-off.

I think one could approach this by handing back and forth the right to make
negotiation offers and leave to the implementations whether they send empty
text negotiations or responses and declarations when they don't have the
right to make negotiation offers. I think the hand-off should be based on a
bit flag rather than based on whether the last PDU received ended in a
complete key-value pair.

Once people have had a chance to see the proposal, I would like to hear
opinions beyond those of the few people who have been active in this
discussion.

Regards,
Pat

--=_alternative 0016643AC2256BCA_=-- From owner-ips@ece.cmu.edu Fri May 31 07:59:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12693 for ; Fri, 31 May 2002 07:59:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4VBK9s29441 for ips-outgoing; Fri, 31 May 2002 07:20:09 -0400 (EDT) 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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4VBK7w29435 for ; Fri, 31 May 2002 07:20:08 -0400 (EDT) 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 g4VBJurd017732; Fri, 31 May 2002 13:19:56 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4VBJuF114688; Fri, 31 May 2002 13:19:56 +0200 To: "THALER,PAT (A-Roseville,ex1)" Cc: ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: RE: iSCSI-12-95 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 31 May 2002 14:19:52 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 31/05/2002 14:19:56, Serialize complete at 31/05/2002 14:19:56 Content-Type: multipart/alternative; boundary="=_alternative 0017A5CAC2256BCA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0017A5CAC2256BCA_= Content-Type: text/plain; charset="us-ascii" Pat, Comments in text. Julo "THALER,PAT (A-Roseville,ex1)" 05/31/2002 12:52 AM Please respond to "THALER,PAT (A-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI-12-95 Julian, I am having two problems with the second MUST in the following paragraph from iSCSI-12-95 7.2.1: If CHAP is used with a secret that has less than 96 random bits then IPsec encryption (according to the implementation requirements in Section 7.3.2 Confidentiality) MUST be used to protect the connection. Moreover, in this case IKE authentication with group pre-shared keys MUST NOT be used. When CHAP is used with secret shorter than 96 bits, a compliant implementation MUST NOT continue with the login unless it can verify that IPsec encryption is being used to protect the connection. Who or what does the requirement apply to? Is the iSCSI implementation expected to check whether IKE is using pre-shared keys or is this a requirement on the person setting up the security? It isn't clear to me that an iSCSI implementation has access to that information. +++ the requirement about checking length is an implementation requirement (if you can't check that you have IPsec then you must fail login). The requirement about IKE is for the administrator/manager at least.+++ Secondly, it isn't clear to me why it is required. I'm assuming the concern is that a member of a group with preshared keys could use an off-line dictionary attack to crack the CHAP secret of another member of the group but it seems to me that there are situations where this is not a threat. For instance, one could have a group that was a host and multiple equally secure disk arrays. If one isn't concerned about one of the arrays trying to impersonate another there isn't a danger in allowing them to authenticate with CHAP protected by IPsec enryption with a group pre-shared key. Could the MUST be made a SHOULD with a statement that ignoring the SHOULD means that one member of the group could crack the CHAP secret of another member? +++ this is a fair assessment of the situation and I think that your suggestion makes sense +++ Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, May 29, 2002 3:02 PM To: ips@ece.cmu.edu Subject: iSCSI-12-95 12-95 is out. It has the latest wording on security and text negotiation (including the spanning). Still to go - text fixes in chapter 11. Julo --=_alternative 0017A5CAC2256BCA_= Content-Type: text/html; charset="us-ascii"
Pat,

Comments in text.

Julo


"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>

05/31/2002 12:52 AM
Please respond to "THALER,PAT (A-Roseville,ex1)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI-12-95

       


Julian,

I am having two problems with the second MUST in the following paragraph
from iSCSI-12-95 7.2.1:
If CHAP is used with a secret that has less than 96 random bits then
IPsec encryption (according to the implementation requirements in
Section 7.3.2 Confidentiality) MUST be used to protect the connection.
Moreover, in this case IKE authentication with group pre-shared
keys MUST NOT be used. When CHAP is used with secret shorter than 96
bits, a compliant implementation MUST NOT continue with the login
unless it can verify that IPsec encryption is being used to protect
the connection.

Who or what does the requirement apply to? Is the iSCSI implementation
expected to check whether IKE is using pre-shared keys or is this a
requirement on the person setting up the security? It isn't clear to
me that an iSCSI implementation has access to that information.
+++ the requirement about checking length is an implementation requirement (if you can't check that you have IPsec then you must fail login). The requirement about IKE is for the administrator/manager at least.+++

Secondly, it isn't clear to me why it is required. I'm assuming the
concern is that a member of a group with preshared keys could use
an off-line dictionary attack to crack the CHAP secret of another
member of the group but it seems to me that there are situations
where this is not a threat. For instance, one could have a group that
was a host and multiple equally secure disk arrays. If one isn't
concerned about one of the arrays trying to impersonate another there
isn't a danger in allowing them to authenticate with CHAP protected
by IPsec enryption with a group pre-shared key.

Could the MUST be made a SHOULD with a statement that ignoring the
SHOULD means that one member of the group could crack the CHAP
secret of another member?
+++ this is a fair assessment of the situation and I think that your suggestion makes sense +++

Regards,
Pat

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, May 29, 2002 3:02 PM
To: ips@ece.cmu.edu
Subject: iSCSI-12-95


12-95 is out.
It has the latest wording on security and text negotiation (including the
spanning).

Still to go - text fixes in chapter 11.

Julo

--=_alternative 0017A5CAC2256BCA_=-- From owner-ips@ece.cmu.edu Fri May 31 08:00:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12721 for ; Fri, 31 May 2002 08:00:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4VBt8u01328 for ips-outgoing; Fri, 31 May 2002 07:55:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4VBt6w01323; Fri, 31 May 2002 07:55:06 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4VBspj2015592; Fri, 31 May 2002 13:54:51 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4VBsoL71808; Fri, 31 May 2002 13:54:51 +0200 To: "Dave Peterson" Cc: "Ips@Ece. Cmu. Edu" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: SCSI Asynchronous Event clarification, reference to [SPC3] and [SAM] X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 31 May 2002 14:54:47 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 31/05/2002 14:54:50, Serialize complete at 31/05/2002 14:54:50 Content-Type: multipart/alternative; boundary="=_alternative 0040870BC2256BCA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0040870BC2256BCA_= Content-Type: text/plain; charset="us-ascii" thanks - Julo "Dave Peterson" Sent by: owner-ips@ece.cmu.edu 05/30/2002 10:34 PM Please respond to "Dave Peterson" To: "Ips@Ece. Cmu. Edu" cc: Subject: iSCSI: SCSI Asynchronous Event clarification, reference to [SPC3] and [SAM] Howdy All, Clause 9.9.1 in Rev 12-95 currently states: "The sending of a SCSI Event (Asynchronous Event Notification in SCSI terminology) is controlled by a SCSI Control Mode Page bit." The notion of "Asynchronous Event Notification" is now obsolete in SAM-2 (and SPC-3). Instead, it is coined asynchronous event reporting (AER). And the sending of a SCSI async event is actually enabled by three bits in the SCSI Control mode page: RAERP - ready AER permission UAAERP - unit attention AER permission EAERP - error AER permission So I think the sentence should be reworded to something like: "If the target supports SCSI asynchronous event reporting (see SAM-2) as indicated in the standard INQUIRY data (see SPC-3), its use may be enabled by parameters in the SCSI Control mode page (see SPC-3)." Also, the reference [SPC3] is not quite correct and may be misleading. [SPC3]T10/1416-D, SCSI-3 Primary Commands (SPC). s/b [SPC3]T10/1416-D, SCSI Primary Commands - 3 (SPC-3). Lastly, all references to [SAM] should be replaced with [SAM2]. ...dap --=_alternative 0040870BC2256BCA_= Content-Type: text/html; charset="us-ascii"
thanks - Julo


"Dave Peterson" <dap@cisco.com>
Sent by: owner-ips@ece.cmu.edu

05/30/2002 10:34 PM
Please respond to "Dave Peterson"

       
        To:        "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: SCSI Asynchronous Event clarification, reference to [SPC3] and [SAM]

       


Howdy All,

Clause 9.9.1 in Rev 12-95 currently states:

"The sending of a SCSI Event (Asynchronous Event Notification in SCSI
terminology)
is controlled by a SCSI Control Mode Page bit."

The notion of "Asynchronous Event Notification" is now obsolete in SAM-2
(and SPC-3).
Instead, it is coined asynchronous event reporting (AER).
And the sending of a SCSI async event is actually enabled by three bits in
the SCSI Control mode page:

RAERP - ready AER permission
UAAERP - unit attention AER permission
EAERP - error AER permission

So I think the sentence should be reworded to something like:

"If the target supports SCSI asynchronous event reporting (see SAM-2) as
indicated in the standard INQUIRY data (see SPC-3), its use may be enabled
by parameters in the SCSI Control mode page (see SPC-3)."


Also, the reference [SPC3] is not quite correct and may be misleading.

[SPC3]T10/1416-D, SCSI-3 Primary Commands (SPC).

s/b

[SPC3]T10/1416-D, SCSI Primary Commands - 3 (SPC-3).

Lastly, all references to [SAM] should be replaced with [SAM2].

...dap

--=_alternative 0040870BC2256BCA_=-- From owner-ips@ece.cmu.edu Fri May 31 08:01:24 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12761 for ; Fri, 31 May 2002 08:01:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4VBhjc00716 for ips-outgoing; Fri, 31 May 2002 07:43:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4VBhhw00712 for ; Fri, 31 May 2002 07:43:43 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4VBhYj2017232; Fri, 31 May 2002 13:43:34 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4VBhYL53216; Fri, 31 May 2002 13:43:34 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI-12-95: header digest error clarification X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 31 May 2002 14:43:29 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 31/05/2002 14:43:34, Serialize complete at 31/05/2002 14:43:34 Content-Type: multipart/alternative; boundary="=_alternative 004056F6C2256BCA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004056F6C2256BCA_= Content-Type: text/plain; charset="us-ascii" Pat, I avoided being specific because an earlier format for headers that I suggested and that included separate parity for the length field got rejected (too complex). and I felt that all the solutions that you mention are implementation options. Do you think that we have to be explicit about them? Regards, Julo pat_thaler@agilent.com 05/31/2002 03:20 AM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI-12-95: header digest error clarification Julian, There was a brief discussion of the issues raised by header digest errors, but nothing has made it into 6.5 Digest Errors. 6.5 says that a target or initiator receiving a PDU with a header digest error MUST silently discard the PDU. The problem is that it can't do that. A header digest error means that DataSegmentLength may have been corrupted so the receiver doesn't know where the PDU ends and the next begins. Possible resolutions: If FIM is enabled, silently discard everything from the bad header to the next start of header pointed to by a marker. If FIM is not enabled, chose one (or more of the following): Assume that the DataSegmentLength is correct and check to see if a valid header including a valid header digest and CmdSN begins at the point indicated by the length. If it does, then drop the PDU as indicated by the DataSegmentLength and resume processing the next PDU. If the next header doesn't check, close the connection or use the next technique. Downside: This entails a small risk that the DataSegmentLength was wrong but unluckily pointed into a part of the data stream that looked like a valid header. Also, there may not be a next header to check immediately so one may have to wait for an indeterminate time before closing this out. Search the data stream for a valid header. This gets kind of ugly because headers are 48 bytes long (or longer with AHS) but can start every 4 bytes so one has check overlapping sets of bytes for a correct CRC which either means it will be slow or one will need multiple CRC checkers. Also, this has a significantly higher risk of finding a false valid header. Therefore, this recovery method should not be allowed. Close the connection. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, May 29, 2002 3:02 PM To: ips@ece.cmu.edu Subject: iSCSI-12-95 12-95 is out. It has the latest wording on security and text negotiation (including the spanning). Still to go - text fixes in chapter 11. Julo --=_alternative 004056F6C2256BCA_= Content-Type: text/html; charset="us-ascii"
Pat,

I avoided being specific because an earlier format for headers that I suggested and that included separate parity for the length field got rejected
(too complex). and I felt that all the solutions that you mention are implementation options.
Do you think that we have to be explicit about them?

Regards,
Julo


pat_thaler@agilent.com

05/31/2002 03:20 AM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI-12-95: header digest error clarification

       


Julian,

There was a brief discussion of the issues raised by header digest errors,
but nothing has made it into 6.5 Digest Errors.

6.5 says that a target or initiator receiving a PDU with a header digest
error MUST silently discard the PDU.

The problem is that it can't do that. A header digest error means that
DataSegmentLength may have been corrupted so the receiver doesn't know
where the PDU ends and the next begins.

Possible resolutions:

If FIM is enabled, silently discard everything from the bad header to
the next start of header pointed to by a marker.

If FIM is not enabled, chose one (or more of the following):
Assume that the DataSegmentLength is correct and check to see if a
valid header including a valid header digest and CmdSN begins at the
point indicated by the length. If it does, then drop the PDU as
indicated by the DataSegmentLength and resume processing the next
PDU. If the next header doesn't check, close the connection or use the
next technique.
Downside: This entails a small risk that the DataSegmentLength was wrong
but unluckily pointed into a part of the data stream that looked
like a valid header. Also, there may not be a next header to check
immediately so one may have to wait for an indeterminate time before
closing this out.

Search the data stream for a valid header. This gets kind of ugly
because headers are 48 bytes long (or longer with AHS) but can start
every 4 bytes so one has check overlapping sets of bytes for a
correct CRC which either means it will be slow or one will need
multiple CRC checkers. Also, this has a significantly higher risk
of finding a false valid header. Therefore, this recovery method
should not be allowed.

Close the connection.

Regards,
Pat

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, May 29, 2002 3:02 PM
To: ips@ece.cmu.edu
Subject: iSCSI-12-95


12-95 is out.
It has the latest wording on security and text negotiation (including the
spanning).

Still to go - text fixes in chapter 11.

Julo

--=_alternative 004056F6C2256BCA_=-- From owner-ips@ece.cmu.edu Fri May 31 08:10:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12969 for ; Fri, 31 May 2002 08:10:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4VBt3I01318 for ips-outgoing; Fri, 31 May 2002 07:55:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4VBt1w01313; Fri, 31 May 2002 07:55:01 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4VBsq9D041982; Fri, 31 May 2002 13:54:52 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4VBsqL71812; Fri, 31 May 2002 13:54:52 +0200 To: Bill Studenmund Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Question about unsolicited data in 12-95 X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 31 May 2002 14:54:47 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 31/05/2002 14:54:52, Serialize complete at 31/05/2002 14:54:52 Content-Type: multipart/alternative; boundary="=_alternative 00412CD0C2256BCA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00412CD0C2256BCA_= Content-Type: text/plain; charset="us-ascii" thanks - it would help to outline the changes you suggest especially when (to a tired reader) they look tiny. As for you question - your second answer is the correct one - Julo Bill Studenmund Sent by: owner-ips@ece.cmu.edu 05/31/2002 06:37 AM Please respond to Bill Studenmund To: cc: Subject: Question about unsolicited data in 12-95 I have a question about unsolicited data, and if I understand it correctly, I have some suggestions for text corrections. My concusion stems around if you can send both immediate data and an unsolicited burst of PDUs (assuming negotiations aprove both). I think the answer is yes, as in 11.12 (talking about ImmediateData) there is: If ImmediateData is set to Yes and InitialR2T is set to No, then the initiator MAY send unsolicited immediate data and/or one unsolicited burst of Data-OUT PDUs. The and/or indicates to me that in that case the initiator can send immediate data, an unsolicited burst, or do both. If the above is not correct, please disregard the rest of the note. I had a question, when doing both immediate and an unsolicited burst of Data-OUT PDUs, about if FirstBurstSize included the immediate data or not. The text in section 11.10, talking about the InitialR2T key, indicates that FirstBurstSize does include the immediate data. If all the above is correct, I'd like to suggest the following changes: Paragraph starting at top of page 41: rate iSCSI data PDUs. An initiator may send unsolicited data as imme- diate up to the negotiated maximum PDU size or in a separate PDU sequence (up to the FirstBurstSize). All subsequent data MUST be solicited. The maximum size of an individual data PDU or the immedi- ate-part of the first unsolicited burst MAY be negotiated at login. I suggest we change the first full sentance to: rate iSCSI data PDUs. An initiator may send unsolicited data as imme- diate up to the negotiated maximum PDU size, in a separate PDU sequence (up to the FirstBurstSize), or both. All subsequent data MUST be solicited. ... Third full paragraph of page 41: An iSCSI initiator MAY choose to send no unsolicited data, only imme- diate data or FirstBurstSize bytes of unsolicited data with a com- mand. If any non-immediate unsolicited data are sent, the total unsolicited data MUST be either the negotiated amount or all the data if the total amount is less than the negotiated amount for unsolic- ited data. I suggest something like: An iSCSI initiator MAY choose to send no unsolicited data, only imme- diate data, a burst of unsolicited Data-OUT commands, or both. If any non-immediate unsolicited data are sent, the total unsolicited data MUST be either the negotiated amount or all the data if the total amount is less than the negotiated amount for unsolic- ited data. I also have a question about a paragraph on p136, in section 9.3.4: If the Expected Data Transfer Length is higher than the FirstBurst- Size (the negotiated maximum amount of unsolicited data the target will accept), the initiator MUST send the maximum size of unsolic- ited data OR ONLY the immediate data. Does that mean that if the Expected Data Transfer Length > FirstBurstSize, I can't opt to send no unsolicited data? Or does it mean I can: send none, send 1 immediate PDU, or send FirstBurstSize (optionally with some of that as immediate data)? Take care, Bill --=_alternative 00412CD0C2256BCA_= Content-Type: text/html; charset="us-ascii"
thanks - it would help to outline the changes you suggest especially when (to a tired reader) they look tiny.

As for you question - your second answer is the correct one - Julo


Bill Studenmund <wrstuden@wasabisystems.com>
Sent by: owner-ips@ece.cmu.edu

05/31/2002 06:37 AM
Please respond to Bill Studenmund

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        Question about unsolicited data in 12-95

       


I have a question about unsolicited data, and if I understand it
correctly, I have some suggestions for text corrections.

My concusion stems around if you can send both immediate data and an
unsolicited burst of PDUs (assuming negotiations aprove both).

I think the answer is yes, as in 11.12 (talking about ImmediateData) there
is:

    If ImmediateData is set to Yes and InitialR2T is set to No, then the
    initiator MAY send unsolicited immediate data and/or one unsolicited
    burst of Data-OUT PDUs.

The and/or indicates to me that in that case the initiator can send
immediate data, an unsolicited burst, or do both.

If the above is not correct, please disregard the rest of the note.

I had a question, when doing both immediate and an unsolicited burst of
Data-OUT PDUs,  about if FirstBurstSize included the immediate data or
not. The text in section 11.10, talking about the InitialR2T key,
indicates that FirstBurstSize does include the immediate data.

If all the above is correct, I'd like to suggest the following changes:

Paragraph starting at top of page 41:

    rate iSCSI data PDUs. An initiator may send unsolicited data as imme-
    diate up to the negotiated maximum PDU size or in a separate PDU
    sequence (up to the FirstBurstSize). All subsequent data MUST be
    solicited. The maximum size of an individual data PDU or the immedi-
    ate-part of the first unsolicited burst MAY be negotiated at login.

I suggest we change the first full sentance to:

    rate iSCSI data PDUs. An initiator may send unsolicited data as imme-
    diate up to the negotiated maximum PDU size, in a separate PDU
    sequence (up to the FirstBurstSize), or both. All subsequent data
    MUST be solicited. ...

Third full paragraph of page 41:

    An iSCSI initiator MAY choose to send no unsolicited data, only imme-
    diate data or FirstBurstSize bytes of unsolicited data with a com-
    mand. If any non-immediate unsolicited data are sent, the total
    unsolicited data MUST be either the negotiated amount or all the data
    if the total amount is less than the negotiated amount for unsolic-
    ited data.

I suggest something like:

    An iSCSI initiator MAY choose to send no unsolicited data, only imme-
    diate data, a burst of unsolicited Data-OUT commands, or both.
    If any non-immediate unsolicited data are sent, the total
    unsolicited data MUST be either the negotiated amount or all the data
    if the total amount is less than the negotiated amount for unsolic-
    ited data.

I also have a question about a paragraph on p136, in section 9.3.4:

    If the Expected Data Transfer Length is higher than the FirstBurst-
    Size (the negotiated maximum amount of unsolicited data the target
    will accept), the initiator MUST send the maximum size of unsolic-
    ited data OR ONLY the immediate data.

Does that mean that if the Expected Data Transfer Length > FirstBurstSize,
I can't opt to send no unsolicited data? Or does it mean I can: send none,
send 1 immediate PDU, or send FirstBurstSize (optionally with some of that
as immediate data)?

Take care,

Bill

--=_alternative 00412CD0C2256BCA_=-- From owner-ips@ece.cmu.edu Fri May 31 09:53:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16663 for ; Fri, 31 May 2002 09:53:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4VD64o05140 for ips-outgoing; Fri, 31 May 2002 09:06:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4VD63w05135 for ; Fri, 31 May 2002 09:06:03 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4VD5Wg5238300; Fri, 31 May 2002 09:05:38 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4VD5VA113262; Fri, 31 May 2002 07:05:31 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI-12-95: header digest error clarification To: "Julian Satran" Cc: pat_thaler@agilent.com, ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Fri, 31 May 2002 06:03:20 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/31/2002 07:05:31 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g4VD63w05136 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I agree that these are implementation options, in fact the use other then FIMs is probabilistic in nature, and is inappropriate for this spec. It is however, the secret sauce that each vendor will do better then the others. Two, deterministic ways, FIMs and connection restart, is sufficient for this spec. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 05/31/2002 04:43:29 AM Sent by: owner-ips@ece.cmu.edu To: pat_thaler@agilent.com cc: ips@ece.cmu.edu Subject: RE: iSCSI-12-95: header digest error clarification Pat, I avoided being specific because an earlier format for headers that I suggested and that included separate parity for the length field got rejected (too complex). and I felt that all the solutions that you mention are implementation options. Do you think that we have to be explicit about them? Regards, Julo pat_thaler@a gilent.com         To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu 05/31/2002         cc: 03:20 AM         Subject:        RE: iSCSI-12-95: header Please digest error clarification respond to pat_thaler Julian, There was a brief discussion of the issues raised by header digest errors, but nothing has made it into 6.5 Digest Errors. 6.5 says that a target or initiator receiving a PDU with a header digest error MUST silently discard the PDU. The problem is that it can't do that. A header digest error means that DataSegmentLength may have been corrupted so the receiver doesn't know where the PDU ends and the next begins. Possible resolutions: If FIM is enabled, silently discard everything from the bad header to the next start of header pointed to by a marker. If FIM is not enabled, chose one (or more of the following): Assume that the DataSegmentLength is correct and check to see if a valid header including a valid header digest and CmdSN begins at the point indicated by the length. If it does, then drop the PDU as indicated by the DataSegmentLength and resume processing the next PDU. If the next header doesn't check, close the connection or use the next technique. Downside: This entails a small risk that the DataSegmentLength was wrong but unluckily pointed into a part of the data stream that looked like a valid header. Also, there may not be a next header to check immediately so one may have to wait for an indeterminate time before closing this out. Search the data stream for a valid header. This gets kind of ugly because headers are 48 bytes long (or longer with AHS) but can start every 4 bytes so one has check overlapping sets of bytes for a correct CRC which either means it will be slow or one will need multiple CRC checkers. Also, this has a significantly higher risk of finding a false valid header. Therefore, this recovery method should not be allowed. Close the connection. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, May 29, 2002 3:02 PM To: ips@ece.cmu.edu Subject: iSCSI-12-95 12-95 is out. It has the latest wording on security and text negotiation (including the spanning). Still to go - text fixes in chapter 11. Julo From owner-ips@ece.cmu.edu Fri May 31 14:03:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24874 for ; Fri, 31 May 2002 14:03:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4VHO5R24658 for ips-outgoing; Fri, 31 May 2002 13:24:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4VHO3w24652; Fri, 31 May 2002 13:24:03 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 5742F30706; Fri, 31 May 2002 13:24:02 -0400 (EDT) Date: Fri, 31 May 2002 10:22:01 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: , Subject: Re: Question about unsolicited data in 12-95 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 31 May 2002, Julian Satran wrote: > thanks - it would help to outline the changes you suggest especially when > (to a tired reader) they look tiny. Thanks. Yes, they are tiny. They were however bits of text that got me confused. I'd like to spare a future reader that confusion. :-) > As for you question - your second answer is the correct one - Julo Thank you! Take care, Bill From owner-ips@ece.cmu.edu Fri May 31 14:07:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25072 for ; Fri, 31 May 2002 14:07:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4VHSIR25074 for ips-outgoing; Fri, 31 May 2002 13:28:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4VHSGw25067 for ; Fri, 31 May 2002 13:28:16 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id A5756CF53; Fri, 31 May 2002 11:28:15 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 6ECE4391; Fri, 31 May 2002 11:28:15 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 31 May 2002 11:28:14 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 11:28:14 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353984@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI-12-95: header digest error clarification Date: Fri, 31 May 2002 11:28:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-e2b3db9e-9e13-48a1-abf6-b63c945647f5" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-e2b3db9e-9e13-48a1-abf6-b63c945647f5 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C208C8.8AD98DB0" ------_=_NextPart_001_01C208C8.8AD98DB0 Content-Type: text/plain; charset="iso-8859-1" Julian, I'm not sure how explicit we have to be about the solution, but right now there is a MUST that isn't really achievable. It says one MUST discard the PDU but the implementation doesn't know what the PDU is. One possibility is: ... MUST close the connection or attempt to find a valid header and discard everything from the bad header to the valid header. or ... MUST attempt to discard the PDU. However, if the length field was corrupted, the boundary of the PDU is unclear. If the apparent header following the discarded PDU also has a digest error, the initiator/target MAY close the connection or attempt to find a valid header and discard everything from the bad header to the valid header. This leaves the options open to the implementor but puts the MUST in terms of what can be accomplished. The only reason to get more explicit is concern about data corruption if a false valid header is found in looking for a good header, but that is extremely low probablility. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, May 31, 2002 4:43 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI-12-95: header digest error clarification Pat, I avoided being specific because an earlier format for headers that I suggested and that included separate parity for the length field got rejected (too complex). and I felt that all the solutions that you mention are implementation options. Do you think that we have to be explicit about them? Regards, Julo pat_thaler@agilent.com 05/31/2002 03:20 AM Please respond to pat_thaler To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI-12-95: header digest error clarification Julian, There was a brief discussion of the issues raised by header digest errors, but nothing has made it into 6.5 Digest Errors. 6.5 says that a target or initiator receiving a PDU with a header digest error MUST silently discard the PDU. The problem is that it can't do that. A header digest error means that DataSegmentLength may have been corrupted so the receiver doesn't know where the PDU ends and the next begins. Possible resolutions: If FIM is enabled, silently discard everything from the bad header to the next start of header pointed to by a marker. If FIM is not enabled, chose one (or more of the following): Assume that the DataSegmentLength is correct and check to see if a valid header including a valid header digest and CmdSN begins at the point indicated by the length. If it does, then drop the PDU as indicated by the DataSegmentLength and resume processing the next PDU. If the next header doesn't check, close the connection or use the next technique. Downside: This entails a small risk that the DataSegmentLength was wrong but unluckily pointed into a part of the data stream that looked like a valid header. Also, there may not be a next header to check immediately so one may have to wait for an indeterminate time before closing this out. Search the data stream for a valid header. This gets kind of ugly because headers are 48 bytes long (or longer with AHS) but can start every 4 bytes so one has check overlapping sets of bytes for a correct CRC which either means it will be slow or one will need multiple CRC checkers. Also, this has a significantly higher risk of finding a false valid header. Therefore, this recovery method should not be allowed. Close the connection. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, May 29, 2002 3:02 PM To: ips@ece.cmu.edu Subject: iSCSI-12-95 12-95 is out. It has the latest wording on security and text negotiation (including the spanning). Still to go - text fixes in chapter 11. Julo ------_=_NextPart_001_01C208C8.8AD98DB0 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
I'm not sure how explicit we have to be about the solution, but right now there is a MUST that isn't really achievable. It says one MUST discard the PDU but the implementation doesn't know what the PDU is. One possibility is:
 
... MUST close the connection or attempt to find a valid header and discard everything from the bad header to the valid header.
 
or
 
... MUST attempt to discard the PDU. However, if the length field was corrupted, the boundary of the PDU is unclear. If the apparent header following the discarded PDU also has a digest error, the initiator/target MAY close the connection or attempt to find a valid header and discard everything from the bad header to the valid header.
 
This leaves the options open to the implementor but puts the MUST in terms of what can be accomplished. The only reason to get more explicit is concern about data corruption if a false valid header is found in looking for a good header, but that is extremely low probablility.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, May 31, 2002 4:43 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI-12-95: header digest error clarification


Pat,

I avoided being specific because an earlier format for headers that I suggested and that included separate parity for the length field got rejected
(too complex). and I felt that all the solutions that you mention are implementation options.
Do you think that we have to be explicit about them?

Regards,
Julo


pat_thaler@agilent.com

05/31/2002 03:20 AM
Please respond to pat_thaler

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI-12-95: header digest error clarification

       


Julian,

There was a brief discussion of the issues raised by header digest errors,
but nothing has made it into 6.5 Digest Errors.

6.5 says that a target or initiator receiving a PDU with a header digest
error MUST silently discard the PDU.

The problem is that it can't do that. A header digest error means that
DataSegmentLength may have been corrupted so the receiver doesn't know
where the PDU ends and the next begins.

Possible resolutions:

If FIM is enabled, silently discard everything from the bad header to
the next start of header pointed to by a marker.

If FIM is not enabled, chose one (or more of the following):
Assume that the DataSegmentLength is correct and check to see if a
valid header including a valid header digest and CmdSN begins at the
point indicated by the length. If it does, then drop the PDU as
indicated by the DataSegmentLength and resume processing the next
PDU. If the next header doesn't check, close the connection or use the
next technique.
Downside: This entails a small risk that the DataSegmentLength was wrong
but unluckily pointed into a part of the data stream that looked
like a valid header. Also, there may not be a next header to check
immediately so one may have to wait for an indeterminate time before
closing this out.

Search the data stream for a valid header. This gets kind of ugly
because headers are 48 bytes long (or longer with AHS) but can start
every 4 bytes so one has check overlapping sets of bytes for a
correct CRC which either means it will be slow or one will need
multiple CRC checkers. Also, this has a significantly higher risk
of finding a false valid header. Therefore, this recovery method
should not be allowed.

Close the connection.

Regards,
Pat

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, May 29, 2002 3:02 PM
To: ips@ece.cmu.edu
Subject: iSCSI-12-95


12-95 is out.
It has the latest wording on security and text negotiation (including the
spanning).

Still to go - text fixes in chapter 11.

Julo


------_=_NextPart_001_01C208C8.8AD98DB0-- ------=_NextPartTM-000-e2b3db9e-9e13-48a1-abf6-b63c945647f5-- From owner-ips@ece.cmu.edu Fri May 31 15:11:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27825 for ; Fri, 31 May 2002 15:11:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4VIutj01399 for ips-outgoing; Fri, 31 May 2002 14:56:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4VIurw01392 for ; Fri, 31 May 2002 14:56:53 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 3ED6EBC1C; Fri, 31 May 2002 12:56:52 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id CDE89478; Fri, 31 May 2002 12:56:51 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 31 May 2002 12:56:51 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 12:56:51 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C3539D4@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Paul Koning , "THALER,PAT (A-Roseville,ex1)" Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI-12-95: header digest error clarification Date: Fri, 31 May 2002 12:56:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul, I started to write text like that, but it subtlely disallows some reasonable alternatives. For instance, if you use FIM to find the a header, you haven't determined where the PDU ends and you may be discarding multiple PDUs so the simpler text would require closing the connection. That is why I wrote in terms of finding a valid header and discarding up to the header. Regards, Pat -----Original Message----- From: Paul Koning [mailto:ni1d@arrl.net] Sent: Friday, May 31, 2002 11:29 AM To: pat_thaler@agilent.com Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu Subject: RE: iSCSI-12-95: header digest error clarification >>>>> "pat" == pat thaler writes: pat> Julian, I'm not sure how explicit we have to be about the pat> solution, but right now there is a MUST that isn't really pat> achievable. It says one MUST discard the PDU but the pat> implementation doesn't know what the PDU is. One possibility is: pat> ... MUST close the connection or attempt to find a valid header pat> and discard everything from the bad header to the valid header. pat> or pat> ... MUST attempt to discard the PDU. However, if the length pat> field was corrupted, the boundary of the PDU is unclear. If the pat> apparent header following the discarded PDU also has a digest pat> error, the initiator/target MAY close the connection or attempt pat> to find a valid header and discard everything from the bad pat> header to the valid header. How about a simpler statement: ... MUST either discard the PDU, if it can determine where the PDU ends, or close the connection. paul From owner-ips@ece.cmu.edu Fri May 31 15:11:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27820 for ; Fri, 31 May 2002 15:11:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4VIT2Y29296 for ips-outgoing; Fri, 31 May 2002 14:29:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4VISxw29288 for ; Fri, 31 May 2002 14:28:59 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4VISrp05156 for ; Fri, 31 May 2002 14:28:53 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4VISqc05144; Fri, 31 May 2002 14:28:52 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g4VISqh17191; Fri, 31 May 2002 14:28:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15607.49380.336100.91889@pkoning.dev.equallogic.com> Date: Fri, 31 May 2002 14:28:52 -0400 From: Paul Koning To: pat_thaler@agilent.com Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI-12-95: header digest error clarification References: <1BEBA5E8600DD4119A50009027AF54A00C353984@axcs04.cos.agilent.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "pat" == pat thaler writes: pat> Julian, I'm not sure how explicit we have to be about the pat> solution, but right now there is a MUST that isn't really pat> achievable. It says one MUST discard the PDU but the pat> implementation doesn't know what the PDU is. One possibility is: pat> ... MUST close the connection or attempt to find a valid header pat> and discard everything from the bad header to the valid header. pat> or pat> ... MUST attempt to discard the PDU. However, if the length pat> field was corrupted, the boundary of the PDU is unclear. If the pat> apparent header following the discarded PDU also has a digest pat> error, the initiator/target MAY close the connection or attempt pat> to find a valid header and discard everything from the bad pat> header to the valid header. How about a simpler statement: ... MUST either discard the PDU, if it can determine where the PDU ends, or close the connection. paul From owner-ips@ece.cmu.edu Fri May 31 15:51:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01799 for ; Fri, 31 May 2002 15:51:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4VJ7H602176 for ips-outgoing; Fri, 31 May 2002 15:07:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4VJ7Fw02172 for ; Fri, 31 May 2002 15:07:15 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4VJ79p06160 for ; Fri, 31 May 2002 15:07:09 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g4VJ79c06148; Fri, 31 May 2002 15:07:09 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with SMTP id g4VJ78p18424; Fri, 31 May 2002 15:07:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15607.51676.746962.663369@pkoning.dev.equallogic.com> Date: Fri, 31 May 2002 15:07:08 -0400 From: Paul Koning To: pat_thaler@agilent.com Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI-12-95: header digest error clarification References: <1BEBA5E8600DD4119A50009027AF54A00C3539D4@axcs04.cos.agilent.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Pat" == A-Roseville,ex1 writes: Pat> Paul, I started to write text like that, but it subtlely Pat> disallows some reasonable alternatives. For instance, if you use Pat> FIM to find the a header, you haven't determined where the PDU Pat> ends and you may be discarding multiple PDUs so the simpler text Pat> would require closing the connection. Pat> That is why I wrote in terms of finding a valid header and Pat> discarding up to the header. Good point. With that in mind I prefer your first suggested text. paul ----- pat> Julian, I'm not sure how explicit we have to be about the pat> solution, but right now there is a MUST that isn't really pat> achievable. It says one MUST discard the PDU but the pat> implementation doesn't know what the PDU is. One possibility is: pat> ... MUST close the connection or attempt to find a valid header pat> and discard everything from the bad header to the valid header. pat> or... From owner-ips@ece.cmu.edu Fri May 31 15:51:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01854 for ; Fri, 31 May 2002 15:51:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4VJMqs03294 for ips-outgoing; Fri, 31 May 2002 15:22:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from imail.atlp.com ([64.94.220.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4VI8Xw27837 for ; Fri, 31 May 2002 14:08:33 -0400 (EDT) Received: from atlp.com (post.atlp.com [192.168.3.8]) by imail.atlp.com (Switch-2.1.4/Switch-2.1.0) with SMTP id g4VI66I03080 for ; Fri, 31 May 2002 11:06:07 -0700 (PDT) Received: from atlp-exch.atlp.com by atlp.com (SMI-8.6/SMI-SVR4) id LAA11632; Fri, 31 May 2002 11:08:13 -0700 Received: by atlp-exch.atlp with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 11:08:13 -0700 Message-ID: <7C769A0EFE7BD411B8A300508BAED11B5135DF@atlp-exch.atlp> From: Mike Donohoe To: "'ips@ece.cmu.edu'" Subject: iSCSI: keys/parameter dependence Date: Fri, 31 May 2002 11:08:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk >From 12-95 4.3.3 pg 80 (and also in 4.4 pg 83): Whenever parameter action or acceptance are dependent on other parameters, the dependent parameters MUST be sent after the parameters on which they depend. If they are sent within the same command, a response for a parameter might imply responses for others. Is an example of this FirstBurstSize being dependent on MaxBurstSize (or vis-versa)? So MaxBurstSize MUST come before FirstBurstSize? I don't see any definition of operational parameters. Just in section 11 keys that are not "declarative" are "operational keys". Also, the spec goes back and forth between the terms "keys"/"parameters" and "operational keys"/"operational parameters"/"operational negotiation parameter keys". Is this something that should be cleaned up? Thanks for your help. Mike Donohoe From owner-ips@ece.cmu.edu Fri May 31 15:53:37 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02085 for ; Fri, 31 May 2002 15:53:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4VJdBr04444 for ips-outgoing; Fri, 31 May 2002 15:39:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4VJd8w04434 for ; Fri, 31 May 2002 15:39:08 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel8.hp.com (Postfix) with ESMTP id 5FED9A003BC; Fri, 31 May 2002 15:39:02 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA24338; Fri, 31 May 2002 12:40:49 -0700 (PDT) Message-ID: <00e001c208da$d068b150$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , Cc: References: <1BEBA5E8600DD4119A50009027AF54A00C353984@axcs04.cos.agilent.com> Subject: Re: iSCSI-12-95: header digest error clarification Date: Fri, 31 May 2002 12:39:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, I think I understand your concern that Section 6.5 almost makes it look as if PDU length can be ascertained on header digest errors just as in other cases. Your first formulation is closer to the level of detail I would prefer. I'd however suggest text with a couple of tweaks. "... MUST discard the PDU when its length can be reliably ascertained by other means (such as the operation of a sync and steering layer), or close the connection." This should leave enough room for other implementation options, while pointing out the utility of the sync and steering layer defined in the spec in this error scenario. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: To: ; Cc: Sent: Friday, May 31, 2002 10:28 AM Subject: RE: iSCSI-12-95: header digest error clarification > Julian, > > I'm not sure how explicit we have to be about the solution, but right now > there is a MUST that isn't really achievable. It says one MUST discard the > PDU but the implementation doesn't know what the PDU is. One possibility is: > > ... MUST close the connection or attempt to find a valid header and discard > everything from the bad header to the valid header. > > or > > ... MUST attempt to discard the PDU. However, if the length field was > corrupted, the boundary of the PDU is unclear. If the apparent header > following the discarded PDU also has a digest error, the initiator/target > MAY close the connection or attempt to find a valid header and discard > everything from the bad header to the valid header. > > This leaves the options open to the implementor but puts the MUST in terms > of what can be accomplished. The only reason to get more explicit is concern > about data corruption if a false valid header is found in looking for a good > header, but that is extremely low probablility. > > Regards, > Pat > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, May 31, 2002 4:43 AM > To: pat_thaler@agilent.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI-12-95: header digest error clarification > > > > Pat, > > I avoided being specific because an earlier format for headers that I > suggested and that included separate parity for the length field got > rejected > (too complex). and I felt that all the solutions that you mention are > implementation options. > Do you think that we have to be explicit about them? > > Regards, > Julo > > > > pat_thaler@agilent.com > > > 05/31/2002 03:20 AM > Please respond to pat_thaler > > > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > cc: > Subject: RE: iSCSI-12-95: header digest error clarification > > > > > Julian, > > There was a brief discussion of the issues raised by header digest errors, > but nothing has made it into 6.5 Digest Errors. > > 6.5 says that a target or initiator receiving a PDU with a header digest > error MUST silently discard the PDU. > > The problem is that it can't do that. A header digest error means that > DataSegmentLength may have been corrupted so the receiver doesn't know > where the PDU ends and the next begins. > > Possible resolutions: > > If FIM is enabled, silently discard everything from the bad header to > the next start of header pointed to by a marker. > > If FIM is not enabled, chose one (or more of the following): > Assume that the DataSegmentLength is correct and check to see if a > valid header including a valid header digest and CmdSN begins at the > point indicated by the length. If it does, then drop the PDU as > indicated by the DataSegmentLength and resume processing the next > PDU. If the next header doesn't check, close the connection or use the > next technique. > Downside: This entails a small risk that the DataSegmentLength was wrong > but unluckily pointed into a part of the data stream that looked > like a valid header. Also, there may not be a next header to check > immediately so one may have to wait for an indeterminate time before > closing this out. > > Search the data stream for a valid header. This gets kind of ugly > because headers are 48 bytes long (or longer with AHS) but can start > every 4 bytes so one has check overlapping sets of bytes for a > correct CRC which either means it will be slow or one will need > multiple CRC checkers. Also, this has a significantly higher risk > of finding a false valid header. Therefore, this recovery method > should not be allowed. > > Close the connection. > > Regards, > Pat > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, May 29, 2002 3:02 PM > To: ips@ece.cmu.edu > Subject: iSCSI-12-95 > > > 12-95 is out. > It has the latest wording on security and text negotiation (including the > spanning). > > Still to go - text fixes in chapter 11. > > Julo > > > > From owner-ips@ece.cmu.edu Fri May 31 16:54:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04434 for ; Fri, 31 May 2002 16:54:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4VKFTo06979 for ips-outgoing; Fri, 31 May 2002 16:15:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13705.mail.yahoo.com (web13705.mail.yahoo.com [216.136.175.138]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g4VKFRw06975 for ; Fri, 31 May 2002 16:15:27 -0400 (EDT) Message-ID: <20020531201526.11279.qmail@web13705.mail.yahoo.com> Received: from [192.55.52.2] by web13705.mail.yahoo.com via HTTP; Fri, 31 May 2002 13:15:26 PDT Date: Fri, 31 May 2002 13:15:26 -0700 (PDT) From: Martins Krikis Subject: Re: iSCSI: keys/parameter dependence To: Mike Donohoe , "'ips@ece.cmu.edu'" In-Reply-To: <7C769A0EFE7BD411B8A300508BAED11B5135DF@atlp-exch.atlp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Mike Donohoe wrote: > From 12-95 4.3.3 pg 80 (and also in 4.4 pg 83): > > Whenever parameter action or acceptance are > dependent on other parameters, > the dependent parameters MUST be sent after the > parameters on > which they depend. If they are sent within the same > command, a > response for a parameter might imply responses for > others. I've been ignoring this paraghaph having been convinced that there are no dependencies among the operational parameters (those allowed to be used in the operational stage of login), and that any dependencies for security parameters would be naturally observed by security protocols (i.e., first send me this, I'll send you that, now send this, etc.). However, I think you raised some good questions. I think this paragraph should be removed. Here are the reasons: "(sent) after" isn't defined. It is unclear whether "in higher numbered bytes within the same PDU" qualifies as "after" or whether only "in a PDU sent at a later time" would. It's probably irrelevant, since due to the introduction of the C-bit, parameters can be accumulated and processed one "batch" at a time, without any specific order within the "batch" and they will quite likely not be processed PDU by PDU. Therefore, the text about them being sent in "the same command" is likely irrelevant, too, since many implementation simply won't check that. But what's really dangerous here is that an implementation that perceives some parameters as dependent may take the "might imply" text as an endorsement for sending back less key=value pairs than was received, which could make the other side never commit due to missing responses. We certainly don't want to allow for such a non-interoperability in the specification. So, could we please get rid of this whole paragraph? Thanks, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Fri May 31 18:24:54 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05972 for ; Fri, 31 May 2002 18:24:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4VLe1312547 for ips-outgoing; Fri, 31 May 2002 17:40:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4VLdxw12542 for ; Fri, 31 May 2002 17:39:59 -0400 (EDT) Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4VLdw29030712; Fri, 31 May 2002 17:39:58 -0400 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.17.194.13]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4VLdwf166168; Fri, 31 May 2002 15:39:58 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: keys/parameter dependence To: Martins Krikis Cc: Mike Donohoe , "'ips@ece.cmu.edu'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Fri, 31 May 2002 14:38:14 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9a |January 7, 2002) at 05/31/2002 03:39:58 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I do not see a problem with the Text, the previous key=value pairs are ones that were in previous PDUs or key=value pairs that were scanned previous to the current pair being scanned. It is not clear that we have to write any thing else to help people understand the concept of previous. I think we are straining at a nat here, and it is not worth the effort. I do not see the problem. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Martins Krikis @ece.cmu.edu on 05/31/2002 01:15:26 PM Sent by: owner-ips@ece.cmu.edu To: Mike Donohoe , "'ips@ece.cmu.edu'" cc: Subject: Re: iSCSI: keys/parameter dependence --- Mike Donohoe wrote: > From 12-95 4.3.3 pg 80 (and also in 4.4 pg 83): > > Whenever parameter action or acceptance are > dependent on other parameters, > the dependent parameters MUST be sent after the > parameters on > which they depend. If they are sent within the same > command, a > response for a parameter might imply responses for > others. I've been ignoring this paraghaph having been convinced that there are no dependencies among the operational parameters (those allowed to be used in the operational stage of login), and that any dependencies for security parameters would be naturally observed by security protocols (i.e., first send me this, I'll send you that, now send this, etc.). However, I think you raised some good questions. I think this paragraph should be removed. Here are the reasons: "(sent) after" isn't defined. It is unclear whether "in higher numbered bytes within the same PDU" qualifies as "after" or whether only "in a PDU sent at a later time" would. It's probably irrelevant, since due to the introduction of the C-bit, parameters can be accumulated and processed one "batch" at a time, without any specific order within the "batch" and they will quite likely not be processed PDU by PDU. Therefore, the text about them being sent in "the same command" is likely irrelevant, too, since many implementation simply won't check that. But what's really dangerous here is that an implementation that perceives some parameters as dependent may take the "might imply" text as an endorsement for sending back less key=value pairs than was received, which could make the other side never commit due to missing responses. We certainly don't want to allow for such a non-interoperability in the specification. So, could we please get rid of this whole paragraph? Thanks, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Fri May 31 18:26:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05991 for ; Fri, 31 May 2002 18:26:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4VLwZc13733 for ips-outgoing; Fri, 31 May 2002 17:58:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4VLwXw13728 for ; Fri, 31 May 2002 17:58:33 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id A7CE28052D4; Fri, 31 May 2002 17:58:23 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id PAA08733; Fri, 31 May 2002 15:00:11 -0700 (PDT) Message-ID: <015301c208ee$48148c20$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , Cc: References: <1BEBA5E8600DD4119A50009027AF54A00C353A3E@axcs04.cos.agilent.com> Subject: Re: iSCSI-12-95: header digest error clarification Date: Fri, 31 May 2002 14:58:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, From: To: ; ; Cc: Sent: Friday, May 31, 2002 2:48 PM Subject: RE: iSCSI-12-95: header digest error clarification > Mallikarjun, > > I like it, but it has the same problem I pointed out to Paul. Sync and steering > (at least as in FIM and as in some of the other candidates) doesn't necessarily > allow one to determine PDU length. What it does allow is identifing the start > of a header (which may not be the next header after the bad PDU). > > One could use: > "... MUST either discard the header and all data up to the beginning of a later PDU > when that location can be ascertained by other means (such as the operation > of a sync and steering layer) or close the connection." I see your point. I like this text, but perhaps suggest "reliably" before "ascertained" in the above. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com > > or (to avoid a messy long sentence): > "... MUST either discard the header and all data up to the beginning of a later PDU > or close the connection. Since the digest error indicates that the length field of the > header may have been corrupted, the location of the beginning of a later PDU > needs to be ascertained by other reliable means (such as the operation of a sync and > steering layer)" > > > Pat > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Friday, May 31, 2002 12:39 PM > To: pat_thaler@agilent.com; Julian_Satran@il.ibm.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI-12-95: header digest error clarification > > > Pat, > > I think I understand your concern that Section 6.5 almost makes > it look as if PDU length can be ascertained on header digest errors > just as in other cases. > > Your first formulation is closer to the level of detail I would prefer. > I'd however suggest text with a couple of tweaks. > > "... MUST discard the PDU when its length can be reliably ascertained by other > means (such as the operation of a sync and steering layer), or close the connection." > > This should leave enough room for other implementation options, while > pointing out the utility of the sync and steering layer defined in the spec in > this error scenario. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > > ----- Original Message ----- > From: > To: ; > Cc: > Sent: Friday, May 31, 2002 10:28 AM > Subject: RE: iSCSI-12-95: header digest error clarification > > > > Julian, > > > > I'm not sure how explicit we have to be about the solution, but right now > > there is a MUST that isn't really achievable. It says one MUST discard the > > PDU but the implementation doesn't know what the PDU is. One possibility is: > > > > ... MUST close the connection or attempt to find a valid header and discard > > everything from the bad header to the valid header. > > > > or > > > > ... MUST attempt to discard the PDU. However, if the length field was > > corrupted, the boundary of the PDU is unclear. If the apparent header > > following the discarded PDU also has a digest error, the initiator/target > > MAY close the connection or attempt to find a valid header and discard > > everything from the bad header to the valid header. > > > > This leaves the options open to the implementor but puts the MUST in terms > > of what can be accomplished. The only reason to get more explicit is concern > > about data corruption if a false valid header is found in looking for a good > > header, but that is extremely low probablility. > > > > Regards, > > Pat > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Friday, May 31, 2002 4:43 AM > > To: pat_thaler@agilent.com > > Cc: ips@ece.cmu.edu > > Subject: RE: iSCSI-12-95: header digest error clarification > > > > > > > > Pat, > > > > I avoided being specific because an earlier format for headers that I > > suggested and that included separate parity for the length field got > > rejected > > (too complex). and I felt that all the solutions that you mention are > > implementation options. > > Do you think that we have to be explicit about them? > > > > Regards, > > Julo > > > > > > > > pat_thaler@agilent.com > > > > > > 05/31/2002 03:20 AM > > Please respond to pat_thaler > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > > cc: > > Subject: RE: iSCSI-12-95: header digest error clarification > > > > > > > > > > Julian, > > > > There was a brief discussion of the issues raised by header digest errors, > > but nothing has made it into 6.5 Digest Errors. > > > > 6.5 says that a target or initiator receiving a PDU with a header digest > > error MUST silently discard the PDU. > > > > The problem is that it can't do that. A header digest error means that > > DataSegmentLength may have been corrupted so the receiver doesn't know > > where the PDU ends and the next begins. > > > > Possible resolutions: > > > > If FIM is enabled, silently discard everything from the bad header to > > the next start of header pointed to by a marker. > > > > If FIM is not enabled, chose one (or more of the following): > > Assume that the DataSegmentLength is correct and check to see if a > > valid header including a valid header digest and CmdSN begins at the > > point indicated by the length. If it does, then drop the PDU as > > indicated by the DataSegmentLength and resume processing the next > > PDU. If the next header doesn't check, close the connection or use the > > next technique. > > Downside: This entails a small risk that the DataSegmentLength was wrong > > but unluckily pointed into a part of the data stream that looked > > like a valid header. Also, there may not be a next header to check > > immediately so one may have to wait for an indeterminate time before > > closing this out. > > > > Search the data stream for a valid header. This gets kind of ugly > > because headers are 48 bytes long (or longer with AHS) but can start > > every 4 bytes so one has check overlapping sets of bytes for a > > correct CRC which either means it will be slow or one will need > > multiple CRC checkers. Also, this has a significantly higher risk > > of finding a false valid header. Therefore, this recovery method > > should not be allowed. > > > > Close the connection. > > > > Regards, > > Pat > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Wednesday, May 29, 2002 3:02 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI-12-95 > > > > > > 12-95 is out. > > It has the latest wording on security and text negotiation (including the > > spanning). > > > > Still to go - text fixes in chapter 11. > > > > Julo > > > > > > > > > From owner-ips@ece.cmu.edu Fri May 31 18:28:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06012 for ; Fri, 31 May 2002 18:28:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g4VLm7A13126 for ips-outgoing; Fri, 31 May 2002 17:48:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g4VLm5w13118 for ; Fri, 31 May 2002 17:48:05 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 9A21B130C; Fri, 31 May 2002 15:48:04 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 6329451C; Fri, 31 May 2002 15:48:04 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 31 May 2002 15:48:04 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 15:48:04 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353A3E@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: cbm@rose.hp.com, pat_thaler@agilent.com, Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI-12-95: header digest error clarification Date: Fri, 31 May 2002 15:48:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, I like it, but it has the same problem I pointed out to Paul. Sync and steering (at least as in FIM and as in some of the other candidates) doesn't necessarily allow one to determine PDU length. What it does allow is identifing the start of a header (which may not be the next header after the bad PDU). One could use: "... MUST either discard the header and all data up to the beginning of a later PDU when that location can be ascertained by other means (such as the operation of a sync and steering layer) or close the connection." or (to avoid a messy long sentence): "... MUST either discard the header and all data up to the beginning of a later PDU or close the connection. Since the digest error indicates that the length field of the header may have been corrupted, the location of the beginning of a later PDU needs to be ascertained by other reliable means (such as the operation of a sync and steering layer)" Pat -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Friday, May 31, 2002 12:39 PM To: pat_thaler@agilent.com; Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI-12-95: header digest error clarification Pat, I think I understand your concern that Section 6.5 almost makes it look as if PDU length can be ascertained on header digest errors just as in other cases. Your first formulation is closer to the level of detail I would prefer. I'd however suggest text with a couple of tweaks. "... MUST discard the PDU when its length can be reliably ascertained by other means (such as the operation of a sync and steering layer), or close the connection." This should leave enough room for other implementation options, while pointing out the utility of the sync and steering layer defined in the spec in this error scenario. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: To: ; Cc: Sent: Friday, May 31, 2002 10:28 AM Subject: RE: iSCSI-12-95: header digest error clarification > Julian, > > I'm not sure how explicit we have to be about the solution, but right now > there is a MUST that isn't really achievable. It says one MUST discard the > PDU but the implementation doesn't know what the PDU is. One possibility is: > > ... MUST close the connection or attempt to find a valid header and discard > everything from the bad header to the valid header. > > or > > ... MUST attempt to discard the PDU. However, if the length field was > corrupted, the boundary of the PDU is unclear. If the apparent header > following the discarded PDU also has a digest error, the initiator/target > MAY close the connection or attempt to find a valid header and discard > everything from the bad header to the valid header. > > This leaves the options open to the implementor but puts the MUST in terms > of what can be accomplished. The only reason to get more explicit is concern > about data corruption if a false valid header is found in looking for a good > header, but that is extremely low probablility. > > Regards, > Pat > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, May 31, 2002 4:43 AM > To: pat_thaler@agilent.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI-12-95: header digest error clarification > > > > Pat, > > I avoided being specific because an earlier format for headers that I > suggested and that included separate parity for the length field got > rejected > (too complex). and I felt that all the solutions that you mention are > implementation options. > Do you think that we have to be explicit about them? > > Regards, > Julo > > > > pat_thaler@agilent.com > > > 05/31/2002 03:20 AM > Please respond to pat_thaler > > > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > cc: > Subject: RE: iSCSI-12-95: header digest error clarification > > > > > Julian, > > There was a brief discussion of the issues raised by header digest errors, > but nothing has made it into 6.5 Digest Errors. > > 6.5 says that a target or initiator receiving a PDU with a header digest > error MUST silently discard the PDU. > > The problem is that it can't do that. A header digest error means that > DataSegmentLength may have been corrupted so the receiver doesn't know > where the PDU ends and the next begins. > > Possible resolutions: > > If FIM is enabled, silently discard everything from the bad header to > the next start of header pointed to by a marker. > > If FIM is not enabled, chose one (or more of the following): > Assume that the DataSegmentLength is correct and check to see if a > valid header including a valid header digest and CmdSN begins at the > point indicated by the length. If it does, then drop the PDU as > indicated by the DataSegmentLength and resume processing the next > PDU. If the next header doesn't check, close the connection or use the > next technique. > Downside: This entails a small risk that the DataSegmentLength was wrong > but unluckily pointed into a part of the data stream that looked > like a valid header. Also, there may not be a next header to check > immediately so one may have to wait for an indeterminate time before > closing this out. > > Search the data stream for a valid header. This gets kind of ugly > because headers are 48 bytes long (or longer with AHS) but can start > every 4 bytes so one has check overlapping sets of bytes for a > correct CRC which either means it will be slow or one will need > multiple CRC checkers. Also, this has a significantly higher risk > of finding a false valid header. Therefore, this recovery method > should not be allowed. > > Close the connection. > > Regards, > Pat > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, May 29, 2002 3:02 PM > To: ips@ece.cmu.edu > Subject: iSCSI-12-95 > > > 12-95 is out. > It has the latest wording on security and text negotiation (including the > spanning). > > Still to go - text fixes in chapter 11. > > Julo > > > > From owner-ips@ece.cmu.edu Fri May 31 21:17:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07864 for ; Fri, 31 May 2002 21:17:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5102jr20422 for ips-outgoing; Fri, 31 May 2002 20:02:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g5102hw20417 for ; Fri, 31 May 2002 20:02:43 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id B98D51191; Fri, 31 May 2002 18:02:42 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 69A25305; Fri, 31 May 2002 18:02:42 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 31 May 2002 18:02:41 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 18:02:41 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353A71@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: hufferd@us.ibm.com, mkrikis@yahoo.com Cc: Mike.Donohoe@quantum.com, ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Date: Fri, 31 May 2002 18:02:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk John, The part that might cause interoperability problems is different interpretations of which parameters action or acceptance is dependent on others. For instance, does the sentence mean that InitialR2T should be sent before FirstBurstSize and that FirstBurstSize doesn't need a response when the response to InitialR2T was Yes? If the sentence is left in, then it should be clarified by adding something such as: "The definition of a key specifies whether the key is dependent on any other keys." and if any of our current keys are dependent, add to those keys "This key is dependent on ." If none are currently dependent, it would be reasonable to add to 11 "Currently, no Login/Text Operational keys are dependent." Pat -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Friday, May 31, 2002 2:38 PM To: Martins Krikis Cc: Mike Donohoe; 'ips@ece.cmu.edu' Subject: Re: iSCSI: keys/parameter dependence I do not see a problem with the Text, the previous key=value pairs are ones that were in previous PDUs or key=value pairs that were scanned previous to the current pair being scanned. It is not clear that we have to write any thing else to help people understand the concept of previous. I think we are straining at a nat here, and it is not worth the effort. I do not see the problem. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Martins Krikis @ece.cmu.edu on 05/31/2002 01:15:26 PM Sent by: owner-ips@ece.cmu.edu To: Mike Donohoe , "'ips@ece.cmu.edu'" cc: Subject: Re: iSCSI: keys/parameter dependence --- Mike Donohoe wrote: > From 12-95 4.3.3 pg 80 (and also in 4.4 pg 83): > > Whenever parameter action or acceptance are > dependent on other parameters, > the dependent parameters MUST be sent after the > parameters on > which they depend. If they are sent within the same > command, a > response for a parameter might imply responses for > others. I've been ignoring this paraghaph having been convinced that there are no dependencies among the operational parameters (those allowed to be used in the operational stage of login), and that any dependencies for security parameters would be naturally observed by security protocols (i.e., first send me this, I'll send you that, now send this, etc.). However, I think you raised some good questions. I think this paragraph should be removed. Here are the reasons: "(sent) after" isn't defined. It is unclear whether "in higher numbered bytes within the same PDU" qualifies as "after" or whether only "in a PDU sent at a later time" would. It's probably irrelevant, since due to the introduction of the C-bit, parameters can be accumulated and processed one "batch" at a time, without any specific order within the "batch" and they will quite likely not be processed PDU by PDU. Therefore, the text about them being sent in "the same command" is likely irrelevant, too, since many implementation simply won't check that. But what's really dangerous here is that an implementation that perceives some parameters as dependent may take the "might imply" text as an endorsement for sending back less key=value pairs than was received, which could make the other side never commit due to missing responses. We certainly don't want to allow for such a non-interoperability in the specification. So, could we please get rid of this whole paragraph? Thanks, Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-ips@ece.cmu.edu Fri May 31 21:17:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07886 for ; Fri, 31 May 2002 21:17:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g510csJ22246 for ips-outgoing; Fri, 31 May 2002 20:38:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g510ckw22237; Fri, 31 May 2002 20:38:46 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id D6140B764; Fri, 31 May 2002 18:38:45 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 84730305; Fri, 31 May 2002 18:38:45 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 31 May 2002 18:38:45 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 18:38:45 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00C353A7A@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Julian Satran , Bill Studenmund Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: Question about unsolicited data in 12-95 Date: Fri, 31 May 2002 18:38:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I suggest we change the first full sentance to: rate iSCSI data PDUs. An initiator may send unsolicited data as imme- diate up to the negotiated maximum PDU size, in a separate PDU sequence (up to the FirstBurstSize), or both. All subsequent data MUST be solicited. ... The "or both" implies that when sending both the data sent can total maximum PDU size plus FirstBurstSize which isn't what was wanted. You could fix it by just leaving the description of the length rules to the parameters where they are covered: rate iSCSI data PDUs. An initiator may send unsolicited data as imme- diate, in a separate PDU sequence or both. All subsequent data MUST be solicited. ... or one could write: rate iSCSI data PDUs. An initiator may send unsolicited data up to FirstBurstSize as immediate (up to the negotiated maximum PDU size), in a separate PDU sequence or both. All subsequent data MUST be solicited. ... The same problem occurs in the text you suggested for the third paragraph. The existing text in that paragraph is accurate though it doesn't explicitly mention that sending FirstBurstSize of data may be done with a combination of immediate data and unsolicited data. It could be left as it is. Pat From owner-ips@ece.cmu.edu Fri May 31 22:14:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07865 for ; Fri, 31 May 2002 21:17:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g510uSa23067 for ips-outgoing; Fri, 31 May 2002 20:56:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g510uQw23050; Fri, 31 May 2002 20:56:26 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 91BD530706; Fri, 31 May 2002 20:56:25 -0400 (EDT) Date: Fri, 31 May 2002 17:54:25 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "THALER,PAT (A-Roseville,ex1)" Cc: , Subject: RE: Question about unsolicited data in 12-95 In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C353A7A@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 31 May 2002, THALER,PAT (A-Roseville,ex1) wrote: > > > I suggest we change the first full sentance to: > > rate iSCSI data PDUs. An initiator may send unsolicited data as imme- > diate up to the negotiated maximum PDU size, in a separate PDU > sequence (up to the FirstBurstSize), or both. All subsequent data > MUST be solicited. ... > > The "or both" implies that when sending both the data sent can total > maximum PDU size plus FirstBurstSize which isn't what was wanted. You could > fix it by just leaving the description of the length rules to the parameters > where they are covered: I'd vote for that. > rate iSCSI data PDUs. An initiator may send unsolicited data as imme- > diate, in a separate PDU sequence or both. All subsequent data > MUST be solicited. ... > or one could write: > rate iSCSI data PDUs. An initiator may send unsolicited data up to > FirstBurstSize as immediate (up to the negotiated maximum PDU size), > in a separate PDU sequence or both. All subsequent data > MUST be solicited. ... > > The same problem occurs in the text you suggested for the third paragraph. > The existing text in that paragraph is accurate though it doesn't > explicitly mention that sending FirstBurstSize of data may be done > with a combination of immediate data and unsolicited data. It could be > left as it is. I'd vote we make some change. With the existing text, I was confused about this point until I read section 11.10 & 11.12 (quite a distance from this text) and asked the list. :-) Take care, Bill From owner-ips@ece.cmu.edu Fri May 31 22:58:32 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09813 for ; Fri, 31 May 2002 22:58:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g5128OH26458 for ips-outgoing; Fri, 31 May 2002 22:08:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13709.mail.yahoo.com (web13709.mail.yahoo.com [216.136.175.251]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g5128Mw26454 for ; Fri, 31 May 2002 22:08:22 -0400 (EDT) Message-ID: <20020601020821.61129.qmail@web13709.mail.yahoo.com> Received: from [192.55.52.1] by web13709.mail.yahoo.com via HTTP; Fri, 31 May 2002 19:08:21 PDT Date: Fri, 31 May 2002 19:08:21 -0700 (PDT) From: Martins Krikis Subject: RE: iSCSI: keys/parameter dependence To: pat_thaler@agilent.com, hufferd@us.ibm.com Cc: Mike.Donohoe@quantum.com, ips@ece.cmu.edu In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00C353A71@axcs04.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- pat_thaler@agilent.com wrote: > The part that might cause interoperability problems > is different > interpretations of which parameters action or > acceptance is dependent on > others. For instance, does the sentence mean that > InitialR2T should be sent > before FirstBurstSize and that FirstBurstSize > doesn't need a response when > the response to InitialR2T was Yes? This is exactly why I wrote that leaving this paragraph in the draft is dangerous. I would really hate to have to start checking the dependency graphs of parameters in order to figure out whether I may signal readiness to commit or whether I should keep waiting for a response to some key. Please let's not go down this road. Boolean omissions are relatively easily to deal with compared to what this would entail. > If the sentence is left in, then it should be > clarified by adding something > such as: > "The definition of a key specifies whether the key > is dependent on any other > keys." > and if any of our current keys are dependent, add to > those keys > "This key is dependent on ." > If none are currently dependent, it would be > reasonable to add to 11 "Currently, > no Login/Text Operational keys are dependent." I don't mind them being dependent much, but if values of some may be omitted due to values given to others, it makes the negotiation much more complicated. Let's not do that. "Each key that has been sent should be received" is a nice and simple rule that I'm voting for (boolean omissions are an exception that can be overcome w/o too much effort). > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > > I do not see a problem with the Text, the previous > key=value pairs are ones > that were in previous PDUs or key=value pairs that > were scanned previous to > the current pair being scanned. You just tried to define it, but I don't think that the original meaning of "after" in the draft was anything close to this. Besides, you're talking about "scanning" order. I know that I'll be doing batch processing of keys, i.e., first accumulate them from all the PDUs that have the C-bit set plus the next one that doesn't. So, you're saying that "after" is defined wrt my scanning order? How is the other side supposed to know how I'm planning to "scan" the key=value pairs? I may find it easier to do it from the other end, or sort first, then process, etc. Furthermore, even before the C-bit, there has never been a requirement to answer one key before the next, so specifying that in the case when two dependent keys are sent in one command (PDU?) a response to one might mean something about the other looks very suspicious because logically the same should be true then regardless of how the keys were received. > It is not clear > that we have to write any > thing else to help people understand the concept of > previous. If previous can have two different interpretations, then IMHO a little more precision is appropriate. You just bundled both together and introduced yet another undefined thing called "scan". That isn't much help either. Plus I wasn't shooting for clarification of "after" as much as for getting rid of ordering requirements. > I think we > are straining at a nat here, and it is not worth the > effort. I'm not straining yet, the issue really isn't that difficult here. The key reception order should be irrelevant because there are no requirements on processing order. It should also be irrelevant because there are no dependencies currently for the operational parameters, nor should they be introduced, because they would signifficantly add to complexity. Finally, the last sentence is dangerous because it seems to imply that there could be more legal response omissions than just for booleans, and I doubt that anybody wants that. Therefore I said that I would like the whole paragraph removed. Removing is not much of an effort, AFAIK. > I do not see the problem. I do and I'm getting scared if others don't. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com