Subject: Re: [v6ops] [Gen-art] [Last-Call] Genart last call review of draft-ietf-v6ops-cpe-slaac-renum-04

From: Alissa Cooper <[email-masked]>
Date: Thu, 22 Oct 2020 09:18:41 -0400

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 <[email-masked]> 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 <[email-masked]> 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: [email-masked]
>>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art