Re: iSCSI: invalid key value

["John Hufferd" <hufferd@us.ibm.com>]

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