Interesting that the datatracker says the document is "Proposed Standard", but the document has "Intend status: Informational". The two should be made to agree. - Bernie > On Sep 9, 2020, at 8:45 PM, Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote: > > Hello, Pete, > > Thanks a lot for your feedback! In-line.... > > On 9/9/20 16:39, Pete Resnick via Datatracker wrote: > [....] >> Major issues: None >> draft-ietf-v6ops-cpe-slaac-renum >> Minor issues: >> The shepherd writeup says: >> The document so far has been approved by the V6OPS working group >> (successful working group last call). The document does not specify >> new protocol, but rather changes to the default parameters in >> existing protocols. >> However, the document is Informational, as confirmed by the shepherd writeup. >> If this is actually updating default parameters in protocols, that sounds like >> it should either be a Standards Track document or more likely a BCP. As 2026 >> says: >> The BCP subseries of the RFC series is designed to be a way to >> standardize practices and the results of community deliberations. [...] >> ...[G]ood user >> service requires that the operators and administrators of the >> Internet follow some common guidelines for policies and operations. >> While these guidelines are generally different in scope and style >> from protocol standards, their establishment needs a similar process >> for consensus building. >> That sounds like what this is doing, especially with all of the 2119 language >> in here. Maybe this is Informational because 7084 (and 6204 before it) were >> Informational, but perhaps 7084 (and other such document) should be BCP as >> well. Indeed, it sounds like all of these SLAAC operational documents could be >> in one BCP together. > > FWIW, the reason for which this document is informational is because the document it's formally updating (RFC7084) is also informational. -- Me, I'd probably agree with you that both RFC7084 and this document should be BCPs, rather than Informational. I'd like to hear from our AD regarding how to proceed here. > > FWIW, I'm fine with changing the track to BCP, although I'd also note that there's plenty of existing practice of documents of this type published as Informational. > > > > Either way, Informational seems wrong. >> Nits/editorial comments: >> Throughout the document, it says, "This document RECOMMENDS..." or "This >> document also RECOMMENDS" or "Additionally, this document RECOMMENDS". RFC 2119 >> does not use "RECOMMENDS". You can say "CE Routers SHOULD..." or "A Router >> Lifetime of ND_PREFERRED_LIMIT is RECOMMENDED" or if you must "It is >> RECOMMENDED that..." (blech, I hate the passive form), since SHOULD and >> RECOMMENDED are equivalent in 2119, but using the "This document RECOMMENDS..." >> form is weird and isn't in 2119. > > Fair enough. I'll apply the suggested edit unless I hear otherwise from others. > > > > >> In 3.3, it says: >> o Upon changes to the advertised prefixes, and after bootstrapping, >> the CE router advertising prefix information via SLAAC SHOULD >> proceed as follows: >> But then each of the things under there has a SHOULD or a MUST. The SHOULD here >> is confusing. Instead, the sentence could simply be: >> o Upon changes to the advertised prefixes, and after bootstrapping, >> the CE router advertising prefix information via SLAAC proceeds as >> follows: >> Similarly: >> This document RECOMMENDS that if a CE Router provides LAN-side DHCPv6 >> (address assignment or prefix delegation), the following behavior be >> implemented: >> Just make the sentence: >> If a CE Router that provides LAN-side DHCPv6 (address assignment or >> prefix delegation), then: > > FWIW, the motivation for the "SHOULD" in Section 3.3 is that it generally implies that the device records prefixes on non-volatile storage. But there are valid reasons for which a device might be unable to (e.g., economical, if you wish). > > Then, the "MUSTs" elsewhere essentially try to signal how crucial implementation of each specific behavior is. > > Thoughts? > > Thanks! > > Regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@xxxxxxxxxxxxxxx > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
