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

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 4 Jan 2007 22:01:25 +1100

> => 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 :) ....

=> I obviously meant constant :)

Hesham

 > 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
 >  > specification state *which* components of the document 
 > are normative.
 >  > 
 >  > Regards,
 >  > Brian
 >  > 
 >  > -----BEGIN PGP SIGNATURE-----
 >  > Version: GnuPG v1.4.6 (Darwin)
 >  > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 >  > 
 >  > iD8DBQFFk871FShYTeGgKiYRCPx8AKC8V6OuAVzbTouoPkQcP928EeifYACdEYnR
 >  > Z4w2IEwW0XV18LLxOWTSlvc=
 >  > =J1Ds
 >  > -----END PGP SIGNATURE-----
 >  > 
 >  > 
 > --------------------------------------------------------------------
 >  > IETF IPv6 working group mailing list
 >  > [email-masked]
 >  > Administrative Requests: 
 > https://www1.ietf.org/mailman/listinfo/ipv6
 >  > 
 > --------------------------------------------------------------------
 >  > 

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

---

From: Tim Enos <[email-masked]>
Date: Thu, 04 Jan 2007 11:45:55 -0600 (CST)

Good afternoon,

>From: Hesham Soliman <[email-masked]>
>Date: 2007/01/04 Thu AM 01:24:59 CST
>To: 'Brian Haberman' <[email-masked]>, 
	'Pekka Savola' <[email-masked]>
>Cc: [email-masked]
>Subject: RE: RFC2461(bis): normativeness of protocol constants

>Catching up on email..
>
> > 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?
> > > 
> > 
> >  In order
> > to be compliant with a spec (any spec), an implementation 
> > MUST adhere to
> > all aspects including protocol constants.

I agree.

  Otherwise, how 
> > would we ever
> > 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 :) ....

At least they don't change for implementations on the same link-layer type. 

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

Exactly.

 So I don't
>see the gain in adding that "protocol constants MUST be used" or something
>like that.

Agreed, but explicitly stating it would seem to reduce the likelihood that designers/implementers would stray. I say 'reduce' as opposed to 'eliminate' as in other cases I've seen implementations hard-code variable values where the spec explicitly said they MUST be configurable.

>Hesham

Best Regards,

Tim Enos
Rom 8:28
> > specification state *which* components of the document are normative.
> > 
> > Regards,
> > Brian
> >