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

Fernando Gont <fgont@si6networks.com> Thu, 10 September 2020 00:45 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589BE3A09BC; Wed, 9 Sep 2020 17:45:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.845
X-Spam-Level:
X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKSwMJGdYx3z; Wed, 9 Sep 2020 17:45:26 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690C23A09B9; Wed, 9 Sep 2020 17:45:25 -0700 (PDT)
Received: from [10.0.0.134] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 09F1A280191; Thu, 10 Sep 2020 00:45:16 +0000 (UTC)
To: Pete Resnick <resnick@episteme.net>, gen-art@ietf.org
Cc: last-call@ietf.org, v6ops@ietf.org, draft-ietf-v6ops-cpe-slaac-renum.all@ietf.org
References: <159968036707.9786.16859070438001357349@ietfa.amsl.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <8d777075-25b5-1817-5c2a-18162bfb9e71@si6networks.com>
Date: Wed, 09 Sep 2020 21:44:30 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <159968036707.9786.16859070438001357349@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/3bOAW68BGmtLETMP3NFGDxG0CWQ>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-v6ops-cpe-slaac-renum-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Sep 2020 00:45:29 -0000

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@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492