Re: [Last-Call] Last Call: <draft-ietf-6man-ra-pref64-07.txt> (Discovering PREF64 in Router Advertisements) to Proposed Standard - PLC consistency

[Jen Linkova <[e-mail]>]

On Fri, Nov 8, 2019 at 12:40 AM Alexandre Petrescu
<[e-mail]> wrote:
> On one hand, I fully agree: RFC6275 does not formally update RFC4861:
> there is no "Updates:" tag in its front page.  In that sense one might
> think about requesting an Errata for adding such a tag, in the DMM WG.
>
> On another hand, while working with implementation I never cared to
> check whether the RFC formally updates one another.  The software _had_
> to be updated, yes, but not cared about the RFC because once it's an RFC
> one can hardly touch on it.

I'm very surprised. So let's say I'm implementing a router or I have
some other reasons to know what valid ranges for SLAAC
variables/timers are.
I open the spec (namely RFC4861) and I'd read there things like
"MaxRtrAdvInterval MUSTbe no less than 4 seconds and no greater than
1800 seconds" and "AdvDefaultLifetime MUST be either zero or between
MaxRtrAdvInterval and 9000 seconds". Then I'd check the list of
"Updated by:" and would find out that RFC8319 changed those
requirements by updating RFC4861:
"In Section 6.2.1, inside the paragraph that defines
   MaxRtrAdvInterval, change 1800 to 65535 seconds.

   In Section 6.2.1, inside the paragraph that defines
   AdvDefaultLifetime, change 9000 to 65535 seconds.".

So I'd expect that MaxRtrAdvInterval, MUST no less than 4 seconds and
no greater than 65535 seconds., while AdvDefaultLifetime MUST be
either zero or between MaxRtrAdvInterval and  65535 seconds.

I'd have no way to know that RFC6275 recommends MaxRtrAdvInterval
value outside of the allowed range.

I might be wrong but I'm under impression that if a new RFC
contradicts (== clearly violates MUST/MUST NOT) in a previous RFC, the
latter needs to be updated. Otherwise we are going to end up with
conflicting standards. If I'm wrong and it's not how it's supposed to
work that I'm going to enjoy another round of quite entertaining
discussion about inserting IPv6 extension headers, no matter what
RFC8200 says ;)


-- 
SY, Jen Linkova aka Furry