RE: DRAFT Montreal minutes - X#NodeArchitecture comments

Hi David,

It might be clearer to rephrase the paragraph to cover the node's
obligations when declaring the key, and when receiving it. Something
like:

    Nodes implementing this key MAY declare the key. Nodes implementing
    this key MAY discard the key values received from other nodes.

    Each node which declares the key MUST be prepared to handle the
    response of [RFC3720] compliant nodes that do not understand the
    key ([RFC3720] states that compliant nodes MUST respond with
    X#NodeArchitecture=NotUnderstood).  In addition, a node which
    implements this key MUST NOT declare "NotUnderstood" as its
    value.

    A node which receives the value "NotUnderstood" for this key SHOULD
    discard the value. Regardless of whether the received value is
    discarded, the key MUST be considered to have been declared. 
 
Thoughts?
Ken

-----Original Message-----
From: David Wysochanski [mailto:[email protected]] 
Sent: Thursday, 3 August 2006 05:56
To: William Studenmund
Cc: Sandars, Ken; [email protected]
Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments

William Studenmund wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Aug 2, 2006, at 12:15 AM, Sandars, Ken wrote:
> 
>  > Hi David,
>  >
>  > Making an extension key 'Declarative' seems problematic.
>  >
>  > Implementations which do not recognise the key will reply with  > 
> X<blah>=NotUnderstood. This may upset the proposer since  > 
> "NotUnderstood"
>  > is unlikely to be an acceptable use of the new key.
>  >
>  > "NotUnderstood" could be treated as a special case, but do we 
> really  > want a special case?
> 
> We talked about this in Montreal. Or I tried to a bit.
> 
> At this point, I think we have to accept "NotUnderstood" as a valid 
> response to the key, indicating that the other side doesn't 
> understand. We can't do anything different.
> 
> We thus should state that "NotUnderstood" is an invalid 
> X#NodeArchitecture value (you MUST never attempt to assert that it's 
> your architecture value), and its presence in a response should be 
> taken to mean the responder doesn't understand the key.
> 

Ah, thanks for pointing out that last part.

I think RFC3720 already handles usage of "NotUnderstood" as a value for
any key.  I can add an explicit sentence forbidding its use as you've
stated, but I didn't get that was what was desired from the final
minutes.

Here's the section from 3720, p. 54 I'm referring to:

    The constants "None", "Reject", "Irrelevant", and "NotUnderstood"
are
    reserved and MUST ONLY be used as described here.  Violation of this
    rule is a protocol error (in particular the use of "Reject",
    "Irrelevant", and "NotUnderstood" as proposed values).


Here's what the final minutes had:

         - Document behavior of RFC 3720-compliant implementation that
                 receives this new key and does not understand it, and
how
                 the other side deals with the resulting response.


Finally, some new proposed text with the explicit forbidding of
"NotUnderstood" (see the last sentence).

    Nodes implementing this key may choose to only transmit the
    key, only log the key values received from other nodes, or both
    transmit and log the key values.  Each node choosing to implement
    transmission of the key values MUST be prepared to handle the
    response of [RFC3720] compliant nodes that do not understand the
    key ([RFC3720] states that compliant nodes MUST respond with
    X#NodeArchitecture=NotUnderstood).  In addition, a node implementing
    transmission MUST NOT transmit "NotUnderstood" as its value,
    as this is a reserved value for all keys [RFC3720].


_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips