[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: invalid key value

    I think the statement in the spec that "proprietary digest algorithms
    may also be negotiated" settles the matter for the case of the digest
    negotiation: an unrecognized value means a proprietary algorithm you
    don't know of, and clearly you have to keep scanning for another value
    that you *do* support.  You can't just quit immediately, because that
    would conflict with the rule permitting proprietary key values.
    For other keys, that reasoning doesn't necessarily apply (i.e., if
    proprietary key values aren't explicitly listed as legal).
    You can then do one of two things:
    1. Insist that the receiver should be extremely picky.  If so, then
    you will *force* a version number change for every tiny change in the
    set of allowed values.  
    2. Expect the receiver to ignore values it doesn't understand, and not
    complain so long as one of the alternatives offered is one it *does*
    both understand and support.
    This is an application of the protocol design principle "be strict in
    what you send, lenient in what you receive".  It's not an absolute
    rule, but as a design guideline it has served well for many decades.
    One reason why is that it eliminates the need to change version
    numbers except when you make "large" changes to the protocol.
    Nitpicking changes like adding new alternatives for keys are not
    changes that require version number incrementing, provided that you
    use this rule.
    Having had to deal with both approaches, I am strongly of the opinion
    that #1 is a bad idea and #2 is the only correct approach.


Last updated: Fri Jan 25 14:17:55 2002
8482 messages in chronological order