Good afternoon,
>From: Hesham Soliman <[EMAIL PROTECTED]>
>Date: 2007/01/04 Thu AM 01:24:59 CST
>To: 'Brian Haberman' <[EMAIL PROTECTED]>,
'Pekka Savola' <[EMAIL PROTECTED]>
>Cc: [email protected]
>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
>
>
>
>
>
>
>
>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 protected]
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
>
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email protected]
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
