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

From: "Sandars, Ken" <[email-masked]>
Date: Thu, 3 Aug 2006 00:23:40 -0700

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-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: David Wysochanski <[email-masked]>
Date: Thu, 03 Aug 2006 14:51:45 -0400

> obligations when declaring the key, and when receiving it. Something
We can certainly clarify the wording.

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

>     implements this key MUST NOT declare "NotUnderstood" as its
Seems fine.

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

---

From: Paul Koning <[email-masked]>
Date: Thu, 3 Aug 2006 15:04:08 -0400

>>>>> "David" == David Wysochanski <[email-masked]> writes:

 >> implements this key MUST NOT declare "NotUnderstood" as its value.
 >> 
 David> Seems fine.

Those are just the standard 3720 rules, right?  It seems confusing to
restate them explicitly, because it creates the impression that this
key uses rules that are different in some way from the usual rules.
If you do want to state the rules explicitly here, you might include
a comment to the effect that "The normal rules for key handling apply,
which are ..."

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

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

I agree.  The spec says it's a protocol error, the rules for handling
protocol errors are defined already -- don't mess with it.

	 paul

---

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

> a comment to the effect that "The normal rules for key handling apply,
Yes, the more I thought about it, I agree.  It just muddies the water
to explicity state things about how to handle "NotUnderstood", so I'm
going to strike that last sentence.