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)




    Steve and David,

    I think that Nick has a valid point.   The intent was to avoid having a new player forcing either the new thing or nothing.
    But I think that the same can be achieved by saying "MUST be able to offer" which says that an administrator MAY configure it with an additional
    authentication.

    It looks like being a bit stronger than MUST IMPLEMENT because MUST IMPLEMENT does not require an implementation to offer two authentication methods together.

    I would like to drive this to a conclusion (draft) by the end of this week.

    Thanks,
    Julo


    Black_David@emc.com
    Sent by: owner-ips@ece.cmu.edu

    09/01/03 00:25

    To
    Nick.Martin@hp.com, Black_David@emc.com
    cc
    ips@ece.cmu.edu
    Subject
    RE: iSCSI extension algorithms (was no subject)





    Nick,

    > I agree that an implementation which implements or includes only
    > proprietary extension algorithm Z should be unacceptable.
    > I am only questioning whether this paragraph acomplishes that goal.
    > I am reading "offer" in the negotiation sense, not in the implemented
    > feature set sense.

    You're correct.  The "MUST implement" requirement for CHAP is elsewhere,
    and applies no matter what; this paragraph is about negotiation when a
    proprietary algorithm is involved.

    > Although it makes little sense to me for the target which is configured
    > with no CHAP secrets to "offer" CHAP during negotiation, I can accept it
    > in this situation.  I would prefer to see implementation of CHAP listed
    > as the requirement, rather than offering CHAP when it is not configured
    > to work.

    We'll keep that in mind in working out the final text.

    > It seems now that it is not intended that to "offer" CHAP in negotiation
    > should be interpreted as an indication that CHAP is configured work.
    >
    > I hope an implementation which can "offer" CHAP but does not implement
    > CHAP, or one which can "offer" CHAP but does not allow CHAP to be
    > configured by an administrator will also be unacceptable.

    The former is definitely unacceptable, the latter should be - as far
    as I'm concerned if the code is present but can't be used, it doesn't
    count as implemented because I can't see evidence of the implementation
    on the wire.

    Thanks,
    --David



Home

Last updated: Fri Jan 10 16:19:14 2003
12157 messages in chronological order