Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id h08IL3922328 for ips-outgoing; Wed, 8 Jan 2003 13:21:03 -0500 (EST) 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 h08IKxW22315 for ; Wed, 8 Jan 2003 13:20:59 -0500 (EST) Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 9B2943332; Wed, 8 Jan 2003 12:20:53 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 8 Jan 2003 12:20:53 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B742.AD7E86DD" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: iSCSI extension algorithms (was no subject) Date: Wed, 8 Jan 2003 12:20:52 -0600 Message-ID: <31891B757C09184BBFEC5275F85D5595048BA1BD@cceexc18.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: iSCSI extension algorithms (was no subject) Thread-Index: AcK3CYhWgk4NbPsXQsOIZ1RSa4blfAALyZGg From: "Martin, Nick (Server Storage)" To: "Julian Satran" , "Steve Bellovin" , Cc: X-OriginalArrivalTime: 08 Jan 2003 18:20:53.0461 (UTC) FILETIME=[ADFDC850:01C2B742] Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2B742.AD7E86DD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Julian and All, =20 The "MUST also be offered" is the part I have a problem with. =20 =20 I have always seen a big distinction between what is required to be implemented, versus what is offered during negotiation. We appear to be mandating that a stroage administrator must not be allowed to configure a target to allow authentication Z (an extension) and no other. In the future it may be the case that Z is a site standard and no other is acceptable. =20 =20 If I understand correctly, the intention is that one can not claim iSCSI compliance without implementing (at least one of) the currently specified methods. I think this is a poor way to state/enforce that intention. =20 The administrator of the target should select the preferred and/or acceptable authentication methods (from the list implemented by his vendor) to be offered (allowed to be selected during negotiation) by each target under his administration. The same for initiators. =20 =20 We say other algorithms may be implemented and negotiated. However, we are now saying that an administrator may not decide to offer (allow) neither of the current authentication methods in favor of something else. I think we are also implying targets and initiators must enforce this. =20 The iSCSI spec has to this point avoided prescribing such restrictions on administration. =20 Thanks, Nick =20 -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Wednesday, January 08, 2003 5:18 AM To: Steve Bellovin; Black_David@emc.com Cc: ips@ece.cmu.edu Subject:=20 =09 =09 The intent of the "offending" statement in 11.1 was to have a strong player with a new method forcing everybody into it by not offering anything else.=20 I guess the phrasing was bad. Simply removing None will not do it since None may still remain a valid option if both parties agree:=20 =09 I would suggest the new phrasing to be:=20 =09 Private or public extension algorithms MAY also be negotiated for authentication methods. Whenever a private or public extension algorithm is offered, at least one of the authentication methods defined in this document MUST also be offered as an option.=20 =09 Julo=20 =09 =09 ------_=_NextPart_001_01C2B742.AD7E86DD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Julian=20 and All,
 
The "MUST also be offered" is the part I=20 have a problem with. 
 
I have=20 always seen a big distinction between what is required to=20 be implemented, versus what is offered during negotiation.  We = appear=20 to be mandating that a stroage administrator must not be = allowed to=20 configure a target to allow authentication Z  (an extension) and no = other.  In the future it may be the case that Z is a site = standard and=20 no other is acceptable. 
 
If I=20 understand correctly, the intention is that one can not claim = iSCSI=20 compliance without implementing (at least one of) the = currently specified=20 methods.
I=20 think this is a poor way to state/enforce that=20 intention.
 
The=20 administrator of the target should select the preferred and/or = acceptable=20 authentication methods (from the list implemented by his vendor) to = be offered (allowed to be selected during negotiation) by each = target under=20 his administration.  The same for initiators.  =
 
We say=20 other algorithms may be implemented and negotiated.  = However, we=20 are now saying that an administrator may not decide to offer=20 (allow) neither of the current authentication methods in favor = of=20 something else.  I think we are also implying targets and = initiators=20 must enforce this.
 
The=20 iSCSI spec has to this point avoided prescribing such = restrictions on=20 administration.
 
Thanks,
Nick
 
-----Original Message-----
From: = Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, January = 08, 2003=20 5:18 AM
To: Steve Bellovin; = Black_David@emc.com
Cc:=20 ips@ece.cmu.edu
Subject:


The intent of the "offending" statement in = 11.1 was to=20 have a strong player with a new method forcing everybody into it by = not=20 offering anything else.
I = guess the=20 phrasing was bad.  Simply removing None will not do it since None = may=20 still remain a valid option if both parties agree: =

I would suggest the new phrasing to = be:=20

Private or public = extension algorithms=20 MAY also be negotiated for authentication methods. Whenever a private = or=20 public extension algorithm is offered, at least one of the = authentication=20 methods defined in this document MUST also be offered as an option.=20

Julo=20

=00 ------_=_NextPart_001_01C2B742.AD7E86DD--