SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [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