Return-Path: <owner-ips@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips@ece.cmu.edu>
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id h0B7VeV11760
	for ips-outgoing; Sat, 11 Jan 2003 02:31:40 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from fep2.012.net.il (fep2.goldenlines.net.il [212.117.129.202])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h0B7VcW11755
	for <ips@ece.cmu.edu>; Sat, 11 Jan 2003 02:31:38 -0500 (EST)
Received: from JA31 ([212.199.151.6]) by fep2.012.net.il with ESMTP
          id <20030111073131.KIJY20384.fep2@JA31>;
          Sat, 11 Jan 2003 09:31:31 +0200
From: "Julian Satran" <satran@haifasphere.co.il>
To: <Black_David@emc.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI extension algorithms (was no subject)
Date: Sat, 11 Jan 2003 09:31:31 +0200
Message-ID: <000701c2b943$769ccc50$6401a8c0@JA31>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C734@corpmx14.us.dg.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id h0B7VcW11756
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

David,

That is almost perfect although - as the aim is not to force on the
community a proprietary new method without allowing a standard one - I
would rather choose the following wording:

   Private or public extension algorithms MAY also be negotiated for
   authentication methods. Whenever a private or public extension
   algorithm is offered, the implementer MUST ensure that the
administrator may 
   list at least also one of the authentication methods other than None,
defined
   in this document, as an alternative.  Furthermore with private and
public extensions 
   "None" MUST NOT appear as a single additional choice without explicit
action by the 
   administrator (cannot be the implementer default).

Regards,
Julo


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of
Black_David@emc.com
Sent: 10 January, 2003 22:29
To: ips@ece.cmu.edu
Subject: RE: iSCSI extension algorithms (was no subject)


Last (I hope) word on this topic.  After working through the confusion,
the following text appears to be acceptable to all concerned:

   Private or public extension algorithms MAY also be negotiated for
   authentication methods. Whenever a private or public extension
   algorithm is offered, "CHAP" SHOULD be listed as an option in order
   to guarantee interoperability, unless the administrator has
   explicitly enabled "None".  ("None" MUST NOT appear as a choice
   without explicit action by the administrator.)

This is acceptable to the IESG, it is the basis for what will go into
-20, and I believe it takes care of the "loss of administrative control"
concern raised by Nick Martin and Bill Stundemund.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

