Thanks for your review, Pete. Fernando, thanks for making updates. I entered a DISCUSS ballot to get the document status straightened out.
Alissa > On Sep 11, 2020, at 7:51 PM, Pete Resnick <resn...@episteme.net> wrote: > > I missed that. And indeed the Last Call went out for Proposed Standard. > Warren should probably look into this before it goes to the IESG. > > pr > > On 9 Sep 2020, at 19:50, Bernie Volz (volz) wrote: > >> 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 <fg...@si6networks.com> 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: fg...@si6networks.com >>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >>> >>> >>> >>> > > > -- > Pete Resnick https://www.episteme.net/ > All connections to the world are tenuous at best > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
