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

[Alexandre Petrescu <[e-mail]>]

I support the document and its advancement.

Le 08/11/2019 à 02:28, Jen Linkova a écrit :
> 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.

One can only be happy to see consistency between docs - I am.

And, I can only hope that the better consistency between docs ("Update"
tags, MinRtrAdvInterval) means that PREF64 would be used where Mobile
IPv6 is used.

> 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 ;)

I see what you mean :-)

I dont want that kind of entertaining discussion.

Implementation-wise, I would like to hope that, if I were an open source
implementer, I could implement and test PREF64 in its target environment
without absolutely needing to pay money.

Alex