Subject: RE: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments

From: "Sandars, Ken" <[email-masked]>
Date: Fri, 4 Aug 2006 00:11:54 -0700

Hi David,

Comments inline [Ken]

Cheers
Ken 

> -----Original Message-----
> From: David Wysochanski [mailto:[email-masked]] 
> Sent: Friday, 4 August 2006 04:52
> To: Sandars, Ken
> Cc: [email-masked]; William Studenmund
> Subject: Re: [Ips] 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?  

[Ken] No. The idea is to catch the required behaviour. It has to
consider that to the nodes who know, the key is declarative, while for
others the key is negotiated (hence the NotUnderstood response is
legal). Thus the negotiation engine needs to track that once it has
declared the key the other node is only allowed to:
	(1) declare a valid value for the key, or
	(2) send a response of "NotUnderstood", or
	(3) do nothing more with the key.

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

[Ken] It's not a protocol error for a node which doesn't implement this
extension key.
Don't confuse the term 'declare' with 'propose'/'accept'. Nodes which
implement this key know it's a Declarative key; for other
implementations the key is negotiated.

[Ken] The reason it should be considered 'declared' is because it has
been received (parameter negotiation engines tend to get this right). It
will be a protocol error if the other node sends it again (obviously in
error). This applies equally to nodes which are aware of the key and
those which are not. I also wanted to indicate that even if the value of
the received key is not used in the intended logging role (say is
discarded), the parameter negotiation engine still needs to note that
the other node has sent it once and to barf if it sees it again. 

[Ken] For example, consider a broken implementation which thinks it's
cute to declare the key, but doesn't update its reception engine to
recognise the inbound key (because it isn't interested in logging the
info). This is test suite paradise! ;-)

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

[Ken] Fair enough, but what about the option to not send and to not log?
That's why I proposed a different set of words for that part.

> 
> > Thoughts?
> > Ken
> > 
> > -----Original Message-----
> > From: David Wysochanski [mailto:[email-masked]]
> > Sent: Thursday, 3 August 2006 05:56
> > To: William Studenmund
> > Cc: Sandars, Ken; [email-masked]
> > 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-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: Dave Wysochanski <[email-masked]>
Date: Mon, 07 Aug 2006 03:05:44 -0400

>         (3) do nothing more with the key.

I think I understand where you are coming from though I don't think
these last two sentences are necessary - it is an implementation
problem right?  You have a "key type" of declarative or negotiated,
and you have to pick one.  If you pick "declarative", then you have
the problem of recording the "NotUnderstood" value.  But in that case,
the code should always handle "NotUnderstood" as a reserved value,
and not record it, per the spec.  If a node sends a special X# or X-
key, it should always know how to respond to other nodes that don't
implement the key.  When you write the code for the special key you
have to take that case into account, which is why I'd guess this case
came up in Montreal.

Am I on the right track?

> implementations the key is negotiated.
Ok well, by putting in the sentences you were proposing, it read like
people needed to know they couldn't initiate the "NotUnderstood"
declaration.  This should be clear from the original 3720 rules.

> the other node has sent it once and to barf if it sees it again.
Right.  Redeclaration of the key is forbidden, per p. 3 of the ID,
and 3720.  I really think you're stating what should already be clear.
It is good discussion for implementors, but I'm not sure we need to
add more wording.

> info). This is test suite paradise! ;-)

But that's clearly a buggy implementation.  Do we really need to
add more words for that?

> That's why I proposed a different set of words for that part.

Ah - sure that is valid and a reasonable case - you have switches for
sending and logging, and both are off by default.  In that case
you wouldn't send "NotUnderstood" in response to another node's
declaration, but would just silently discard.

Is this case the root of your original post where you suggested
new wording?

If so, I agree that the current wording I have doesn't cover
that case, so let me think some more about it.  Perhaps some
of what you originally proposed is what we want.  But I think
some of the explicit statements about "NotUnderstood" are
redundant and may muddy the water.