[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

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]

Add to Google Powered by Linux