RE: iSCSI: not offering a key

[Black_David@emc.com]

> 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.

The problem with this line of reasoning is that it assumes completely
identical state machines at both ends of the negotiation.  We decided
a while ago on this list that there would be no such thing as an
implicit offer, i.e., omitting the key is a decision not to offer it
for negotiation.  This results in a more robust negotiation protocol,
as we have no lack of things that are potentially negotiable, and it's
too easy to make a mistake in setting some of the default values.

> 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.

Only if the state machines are identical.  One simple mistake in setting
a default value, and the assumption that it doesn't need to be negotiated
leads to unpleasant surprises.  The right solution to this is in Eddy's
recent mail and my reply - there are no implicit offers -- if you care
about the value of a key, it's your responsibility to negotiate it.

> 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.

And creates a login process that is significantly more brittle.  
The more robust solution that causes anything that's important to
be negotiated is preferable.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------