Subject: RE: iSCSI: not offering a key

From: [email-masked]
Date: Tue, 29 Jan 2002 03:23:14 -0500

> 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
[email-masked]         Cell: +1 (978) 394-7754
---------------------------------------------------

---

From: Paul Koning <[email-masked]>
Date: Tue, 29 Jan 2002 09:54:49 -0500

Excerpt of message (sent 29 January 2002) by [email-masked]:
> identical state machines at both ends of the negotiation. 

It seems strange to complexify the algorithms on the grounds that
people will implement things incorrectly, but it looks like I'm
fighting a lost cause here so I'll stop now.

	 paul

---

From: "Robert D. Russell" <[email-masked]>
Date: Tue, 29 Jan 2002 07:39:05 -0500 (EST)

David:

> about the value of a key, it's your responsibility to negotiate it.

It seems to me that your interpretation is adding something new that
is not in the standard and was never intended to be in the standard.
That is that the value of keys that were not negotiated is "unknown"
or uncertain.  On the contrary, the standard is quit explicit that
all keys have default values, and if a key is not negotiated then it
retains its default value on both sides of the connection, initiator
and target.  If this were not the case, then we would be in the
situation of essentially requiring the negotiation of every key,
just to confirm the defaults, and this is clearly contrary to
the whole idea of the negotiation process.

Am I misunderstanding what you are saying?

Thanks,

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774