RE: iSCSI: not offering a key

[Paul Koning <ni1d@arrl.net>]

Excerpt of message (sent 26 January 2002) by Black_David@emc.com:
> > Maybe I don't understand the sentence. I interpret it to mean that if the
> > default value is acceptable to me then not offering it is somehow
> different
> > than the default ... and that confuses me (well, actually it makes me
> wonder
> > if the sentence is trying to say something else).
>  
> Here are two examples of how it's different:
>  ...
> (2) If the other party wants to negotiate the value and
>     both offer the same default value, not offering the default
>     results in an additional step before the negotiation can
>     conclude, viz:
>  
>     -> Nothing        -> Key=Default
>     <- Key=Default    <- Key=Default
>     -> Key=Default

But that's an artifact of a peculiar design approach for a negotiation
algorithm.  The obvious design approach says that there are two ways
to *encode* a key having the default value: by sending the key with
that value, and by omitting that key.  Those two encodings should have
the same effect on the negotiation state machine.

That approach is far easier to understand and implement.  Given that
approach, there cannot possibly be an extra message resulting from one
encoding or the other, because the state machine reacts the same.

What we see now is reasoning backwards from the design.  In other
words: the starting position was to make the two encodings mean
different things; the state machine was constructed in such a way that
one results in more messages than the other; finally, that property is
used as an argument for why the distinction has to exist.  But that's
circular reasoning: do away with the distinction, and reduce the state
machine to the shorter of the two cases, and the whole problem goes
away.

	paul