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
<alexandre.petrescu@xxxxxxxxx> 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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
