RE: DRAFT Montreal minutes - X#NodeArchitecture comments

Hi David,

Yes, you've got the angle I'm coming from. It's important to express the
idea that while it is a declared key, the rules for declared keys are
being slightly bent such that it is not a protocol error to receive a
"NotUnderstood" in the context of the other node processing it as an
offered key.

And yes, if you're going to spell out the use cases, I think you need to
cover them all.

As you say, little more wordsmithing and it should be gold!

Cheers
Ken

> -----Original Message-----
> From: Dave Wysochanski [mailto:[email protected]] 
> Sent: Monday, 7 August 2006 17:06
> To: Sandars, Ken
> Cc: [email protected]; William Studenmund
> Subject: Re: [Ips] DRAFT Montreal minutes - 
> X#NodeArchitecture comments
> 
> Sandars, Ken wrote:
> > Hi David,
> > 
> > Comments inline [Ken]
> > 
> > Cheers
> > Ken
> > 
> >  > -----Original Message-----
> >  > From: David Wysochanski [mailto:[email protected]]  > 
> Sent: Friday, 
> > 4 August 2006 04:52  > To: Sandars, Ken  > Cc: 
> [email protected]; 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.
> > 
> 
> 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?
> 
> 
> > 
> >  > 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.
> > 
> 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.
> 
> 
> > [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.
> > 
> 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.
> 
> 
> > [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! ;-)
> > 
> 
> But that's clearly a buggy implementation.  Do we really need 
> to add more words for that?
> 
> > 
> >  > 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.
> > 
> 
> 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.
> 
> 
> >  >
> >  > > 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
> 

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