RE: iSCSI extension algorithms (was no subject)

["Julian Satran" <satran@haifasphere.co.il>]

David,

What I wanted to convey is not a default action but an "ability to
configure" because I thing that this is what we are after. If the
administrator is not forced in configuring it with only the new
auth-method then we are fine. 
I will try again tomorrow (too late in the weekend today :-)).

Regards,
Julo


-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com] 
Sent: 11 January, 2003 18:44
To: satran@haifasphere.co.il; ips@ece.cmu.edu
Subject: RE: iSCSI extension algorithms (was no subject)


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
----------------------------------------------------