SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: invalid key value



    
    I agree with Paul, Steve, Mark Bakke, and I think Eddy.
    
    Unknown values in a list that contain known values should be ignored.  This
    makes things extensible without version changes.
    
    Julian, perhaps it would be useful to add such a statement to the Draft.
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136, Cell: (408) 499-9702
    Internet address: hufferd@us.ibm.com
    
    
    Paul Koning <ni1d@arrl.net>@ece.cmu.edu on 01/25/2002 10:56:26 AM
    
    Sent by:    owner-ips@ece.cmu.edu
    
    
    To:    ips@ece.cmu.edu
    cc:
    Subject:    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.
    
         paul
    
    
    
    
    


Home

Last updated: Sat Jan 26 19:17:56 2002
8503 messages in chronological order