Re: DRAFT Montreal minutes - X#NodeArchitecture comments

Sandars, Ken wrote:
> 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:
> 
We can certainly clarify the wording.


>     Nodes implementing this key MAY declare the key. Nodes implementing
>     this key MAY discard the key values received from other nodes.
> 
I'm not sure this is clearer than what I had below but maybe someone
else has can chime in.  The "declare" wording may be more consistent
with 3720 though.


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

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

Isn't this last sentence in conflict with the RFC paragraph I mention
below?  Sending "NotUnderstood" in a key value is a protocol
error, so why would a node receiving it be forced to consider the other
node having declared it?

Note also that I added this wording:
    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

to match some of the wording in the security section:
     For the above target, an appropriate implementation might be
     logging of received key values, but no transmission of the key.
     For the initiators, an appropriate implementation might be
     transmission of the key, but no logging of received key values.

I was also thinking from my developer's hat and compartmentalizing
the differing parts of the implementation (which have different
things to think about).  On my end I have two different coding items
to track the transmission of the key vs the logging.


> 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