Subject: Re: RFC2461(bis): normativeness of protocol constants

From: Brian E Carpenter <[email-masked]>
Date: Mon, 01 Jan 2007 13:24:24 +0100

On 2006-12-28 15:04, Brian Haberman wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Pekka Savola wrote:
>> Hi,
>>
>> Speaking of RFC 2461(bis), some time ago I noticed the following
>> behaviour with a popular router implementation (a support case is open
>> on this): for forwarded packets, it takes up to 24 hours (in recent
>> software versions, up to 20 minutes) for the hardware forwarding to
>> notice that an IP address moved from one link-layer address to another
>> on the same link if unsolicited NAs (section 7.2.6, only an
>> optimization; few host implementations seem to send these) are not sent
>> by the hosts.
>>
>> My reading of the spec is that this is not compliant with RFC2461, where
>> protocol constants are REACHABLE_TIME (30s) and DELAY_FIRST_PROBE_TIME
>> (5s) -- unreachability detection could take about 35 times longer than
>> the spec.
>>
>> However, the spec doesn't say whether the defined protocol constants are
>> normative, and this could be explicitly stated if that's deemed a
>> necessary addition.
>>
>> Any thoughts?
>>
> 
> Given that 2461 (and 2461bis) are DS, I would find it very disturbing if
> implementers did not treat the entire document as normative.  In order
> to be compliant with a spec (any spec), an implementation MUST adhere to
> all aspects including protocol constants.  Otherwise, how would we ever
> have interoperability?  I do not see any benefit in having any
> specification state *which* components of the document are normative.
> 
> Regards,
> Brian

But that is why we have the RFC 2119 keywords; and they do have value
when working out what to test at an interop. I think it would be
safer, even if logically redeundant, to prefix section 10 with a sentence
stating that the listed values MUST be used. Also there are some lower
case "shoulds" in the paragraph about ReachableTime - are those
intended to be normative?

Regards,
Another Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 4 Jan 2007 18:24:59 +1100

Catching up on email..

 >  In order
 > have interoperability?  

=> I agree with this. Pekka himself mentioned that this is not a compliant
behviour according to 2461. A contant is a *contant*, which means it doesn't
change :) ....
Variables are also given max and min values, which by the english meaning of
max and min implies that you can't go outside those boundaries. So I don't
see the gain in adding that "protocol constants MUST be used" or something
like that. 

Hesham

I do not see any benefit in having any
 > -----BEGIN PGP SIGNATURE-----
 > Version: GnuPG v1.4.6 (Darwin)
 > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 > 
 > iD8DBQFFk871FShYTeGgKiYRCPx8AKC8V6OuAVzbTouoPkQcP928EeifYACdEYnR
 > Z4w2IEwW0XV18LLxOWTSlvc=
 > =J1Ds
 > -----END PGP SIGNATURE-----
 >

---

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Jan 2007 00:52:12 +0200 (EET)

> specification state *which* components of the document are normative.

Indeed -- but maybe I was not explicit enough.  I see three things 
here:

  1) With most of these constants, there is no interoperability issue
     if an implementation were to choose different values.  Quickly
     looking, I wasn't able to see any defined constant that the
     current protocol would require to be exactly the way it is for
     interoperability.

     Instead, this is more of an issue of harmonizing protocol
     behaviour across implementations, not so much about
     interoperability.

  2) Strictly speaking, if constants are normative, if an
     implementation has (say) REACHABLE_TIME of 10 seconds (three times
     "faster" than the spec) it should be considered incompliant.

  3) in some other protocols what we have defined as constants could
     very well have been defined as suggested default values (for
     example).

This is more than strictly required for interoperability.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: James Carlson <[email-masked]>
Date: Fri, 5 Jan 2007 08:50:38 -0500

> This is more than strictly required for interoperability.

I think that's the key point.  It's very important to make sure that
the things marked as "MUST" or "MUST NOT" are actually requirements
for interoperability or anticipated development, and not just needless
strictures.

Otherwise, it becomes much more tedious to support enviroments that
require slightly different values or implementations that trade off
simplicity against precision.

(Given that I've encountered test suites that enforce even "MAY"
clauses, I think caution about over-specifying things is warranted.)

-- 
James Carlson, KISS Network                    <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 16 Jan 2007 18:37:38 +0900

>>>>> On Fri, 5 Jan 2007 08:50:38 -0500, 
>>>>> James Carlson <[email-masked]> said:

> simplicity against precision.

FWIW, I agree.  I've not assess whether each of the RFC2461(bis)
constants can be a source of an interoperability issue, but if it's
not, "MUST" or "MUST NOT" is clearly a wrong choice.

Although SHOULD (NOT) might help clarify the intent (and I don't
oppose to adding it in this case), I'm not sure if it has a real
effect; there's always a vendor that misunderstands or even ignores a
particular part of a specification even if it's specified as a MUST.
So we won't be able to eliminate such abnormal implementations by
giving a spec a SHOULD or MUST.  We may be able to convince such a
vendor of fixing their implementation with the specific keywords, but
I personally don't see significant difference for that purpose in this
case, with or without an RFC2119 keyword.

In any case, I have no strong opinion on whether to add an RFC2119
keyword to 2461bis (as long as it's not an unnecessary MUST).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]