Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-v6ops-cpe-slaac-renum-04
Pete Resnick <resnick@episteme.net> Fri, 11 September 2020 23:51 UTC
Return-Path: <resnick@episteme.net>
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 30A6E3A0A53; Fri, 11 Sep 2020 16:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1HsVFtPb_0Ie; Fri, 11 Sep 2020 16:51:46 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B7A3A091F; Fri, 11 Sep 2020 16:51:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 68898BC4C1A0; Fri, 11 Sep 2020 18:51:41 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1-VUBL6tzKP; Fri, 11 Sep 2020 18:51:39 -0500 (CDT)
Received: from [172.16.1.6] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 8F359BC4C191; Fri, 11 Sep 2020 18:51:39 -0500 (CDT)
From: Pete Resnick <resnick@episteme.net>
To: Bernie Volz <volz@cisco.com>
Cc: Fernando Gont <fgont@si6networks.com>, gen-art@ietf.org, last-call@ietf.org, v6ops@ietf.org, draft-ietf-v6ops-cpe-slaac-renum.all@ietf.org
Date: Fri, 11 Sep 2020 18:51:39 -0500
X-Mailer: MailMate (1.13.1r5706)
Message-ID: <BD967623-7316-45A9-9271-327472F2C107@episteme.net>
In-Reply-To: <2C9BF3C2-A611-4F18-8F03-104405DD9799@cisco.com>
References: <159968036707.9786.16859070438001357349@ietfa.amsl.com> <8d777075-25b5-1817-5c2a-18162bfb9e71@si6networks.com> <2C9BF3C2-A611-4F18-8F03-104405DD9799@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/OZ0wuYMLL5_80gUqa8cKOKhjrzg>
Subject: Re: [Gen-art] [Last-Call] 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: Fri, 11 Sep 2020 23:51:48 -0000
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 <fgont@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: fgont@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] Genart last call review of draft-ietf-v… Pete Resnick via Datatracker
- Re: [Gen-art] Genart last call review of draft-ie… Fernando Gont
- Re: [Gen-art] Genart last call review of draft-ie… Bernie Volz (volz)
- Re: [Gen-art] [Last-Call] Genart last call review… Pete Resnick
- Re: [Gen-art] [Last-Call] Genart last call review… Alissa Cooper