Subject: [v6ops] Genart last call review of draft-ietf-v6ops-cpe-slaac-renum-04

From: Pete Resnick via Datatracker <[email-masked]>
Date: Wed, 09 Sep 2020 12:39:27 -0700

Reviewer: Pete Resnick
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-v6ops-cpe-slaac-renum-04
Reviewer: Pete Resnick
Review Date: 2020-09-09
IETF LC End Date: 2020-09-09
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with one process issue, and some assorted nits.

Major issues: None

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. 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.

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:

---

From: Fernando Gont <[email-masked]>
Date: Wed, 9 Sep 2020 21:44:30 -0300

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:
> 
> 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.
> form is weird and isn't in 2119.

Fair enough. I'll apply the suggested edit unless I hear otherwise from 
others.

>     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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 10 Sep 2020 00:50:23 +0000

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,
> 
> 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.
> 
> 
> 
> Fair enough. I'll apply the suggested edit unless I hear otherwise from others.
> 
> 
> 
> 
>> In 3.3, it says:
> 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

---

From: "Pete Resnick" <[email-masked]>
Date: Fri, 11 Sep 2020 18:51:39 -0500

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
>
>> 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.
>>
>> storage. But there are valid reasons for which a device might be 
>> unable to (e.g., economical, if you wish).
>>

-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best