|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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 ----------------------------------------------------
Home Last updated: Sat Jan 11 13:19:01 2003 12161 messages in chronological order |