RE: DRAFT Montreal minutes - X#NodeArchitecture comments
>>>>> "Mallikarjun" == Mallikarjun C <cb_mallikarjun@xxxxxxxxx> writes:
Mallikarjun> Hi Paul, I am still not sure I see the "bug" in 3720.
Mallikarjun> The text you cite is immediately preceded by this
Mallikarjun> sentence in 3720:
Mallikarjun> "However, the answer for a key not understood MUST be
Mallikarjun> key=NotUnderstood."
Mallikarjun> This applies to *all* keys, negotiated or declarative.
Mallikarjun> The "as described here" text you cite is reinforcing
Mallikarjun> this universal applicability.
Consider the top of page 53.
For declarative keys, there IS no response. An occurrence of a
declarative key is always taken to be a declaration. And declarations
are not allowed to contain the value "NotUnderstood".
The sentence you quoted ("the answer for a key not understood..."
implies that a not-understood key is assumed to be a proposal, not a
declaration, which matches my point 1.
The issue is that the rule at the top of page 53 is incomplete,
because it doesn't cover the case of a not-understood key. For those,
a reply may appear though it wasn't expected (the protocol says that
there is no reply to declarations). And that reply will have a
NotUnderstood value, which isn't a legal declarer-value.
Mallikarjun> Regarding your proposed #2, I am not sure a proposer
Mallikarjun> should ever "silently ignore" a a "NotUnderstood"
Mallikarjun> response. A NotUnderstood response always has a
Mallikarjun> semantic requirement on the proposer: not to use
Mallikarjun> protocol behavior associated with the key within the
Mallikarjun> scope of the key (connection/session).
True for negotiations, but I don't see how declarative keys,
especially optional ones, can have a semantic effect on the sender
that depends on whether they are understood or not. Certainly the
X#NodeArchitecture key doesn't. I'd argue that a key that has
semantic effects at the sending end must necessarily be a negotiation
key, not a declarative key, because declarations by definition can
only affect actions taken by the recipient.
paul
_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips
[IETF]
[Linux iSCSI]
[Linux SCSI]
[Linux Resources]
[Yosemite News]
[IETF Announcements]
[IETF Discussion]
[SCSI]