Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C73B@corpmx14.us.dg.com>
From: Black_David@emc.com
To: satran@haifasphere.co.il, ips@ece.cmu.edu
Subject: RE: iSCSI extension algorithms (was no subject)
Date: Sat, 11 Jan 2003 11:43:33 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Julian,

> 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).

I don't think that's going to be sufficient.

Keep in mind that interoperability is also a goal.  Everyone has to
implement CHAP, so saying "CHAP SHOULD be listed in the absence of
explicit administrator action" does not add any implementation burden,
and yields better interoperability if no administrative steps are taken.
I'm concerned that the above text would allow an implementation to
offer by default an extension algorithm (Z) plus one of the standard
methods that has little to no presence in other implementations,
without running afoul of any MUST or SHOULD - that strikes me as
coming uncomfortably close to the "me (Z) or none" situation that
we're trying to avoid.

It also appears to me that the above text allows an implementation to
be configured to offer only Z by default - that has to require explicit
administrator action, but I don't see a problem with such administrative
action resulting in only offering Z.  How about:

   Private or public extension algorithms MAY also be negotiated for
   authentication methods. Whenever a private or public extension
   algorithm is offered, at least one additional authentication
   method defined in this document MUST be offered as an alternative
   unless an administrator has taken explicit action to change
   this, and one of the offered alternatives SHOULD be "CHAP".
   Administrators MAY configure whatever algorithms are appropriate
   to offer in their environments; the foregoing requirements in
   this paragraph apply only to default behavior in the absence
   of explicit action by an administrator.

For example, an implementation that wants to default to offering
Z and one of the SPKM methods can do this, but has to have understood
and carefully weighed the full implications of having disregarded
the SHOULD (paraphrased from RFC 2119), including the interoperability
problems it will have in its default configuration with other
implementations that support neither Z nor SPKM - such problems
are clearly the responsibility of the implementer who disregarded
the SHOULD.

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
----------------------------------------------------