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

Alissa Cooper <alissa@cooperw.in> Thu, 22 October 2020 13:18 UTC

Return-Path: <alissa@cooperw.in>
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 B25333A0983; Thu, 22 Oct 2020 06:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=cjYdDWCG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LmG4aSi7
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 6jvw7J5qQRty; Thu, 22 Oct 2020 06:18:45 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67713A08B2; Thu, 22 Oct 2020 06:18:45 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 5FAA6A22; Thu, 22 Oct 2020 09:18:44 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 22 Oct 2020 09:18:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=f nldevfYuDNVLkRumYOUTxBd6t8JT+h+su9dDSQblQ8=; b=cjYdDWCGT+c1HFP6p IytIlzvlC5YxFSwsl1ro8jiAXTjTCSH4KvXq7ttUt+ygztqqR5Qhb6MvErfqmC6O dJSveGyXnLKeb71a/DO58Dbs/seR3iE28YqTsGVwnKSO7AwHWH3ckcHUhlDDYA+K ny6d40jbTDlgR5G1k+iEKga50QSD3StYCs5mxpGSoCpGtsgNoXdilJcVWxlwV9/o r9v24PdF/yUGcnx+Imyl5Nk8Ra8P6FqUYqjmmMPh6YhPh8p98DuABzLwQvC1t2yI 5UXF4ku6SrmWsxlZN4jlRg92MlF0TfuXSNHPfK71D9FR1r7HIB4w2fjPdV1SOaDn Mb28Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=fnldevfYuDNVLkRumYOUTxBd6t8JT+h+su9dDSQbl Q8=; b=LmG4aSi7ygJJpJU5yBU7d0o6yOdw2+57VKdPk1s6biSdWaadhZATIxoOk 5xRfmmoL2vRlvsX6b46KAKFBpw9PFYaCY0XCRu8Rq94utfsu3YAh3t9B1UNjBRBY MIVqe6lOz1dHEfElflGwV3UE8wDrnpqsGNLsGpwmOziH75N5723UooTR56d8Hk4z 4hxDq/VVBtUZEqdb1jPd47KIVJ3ez74KReUFEKFdBoaVBHT0CHIy9Ul/ZNoQHlpR nhGNGtiEmTdN3GZ4/D3syWvOrwptPhSe+WIng2l0a1i11Hx5FpXMBG5TCsOZoRMd 5j+2h/WUj6JEnjxWYfHZRcRVPQgTA==
X-ME-Sender: <xms:s4aRXxfMDAfNksiqDK2kARuDsW7gv4UpDz2ovCXnZ6lkbo-9KAUM4g> <xme:s4aRX_Or-d53HitLqCbcSENrn68iOkTFJxd7LWidpBNVal9M8MmJIvgvSxuywVREq RxN6El0raL72BMSTA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeejgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuggftrfgrth htvghrnhepiedtuefgteehieejudeiheeuffeutedufffggeelgfetjedvleefteehvdej kedtnecuffhomhgrihhnpegvphhishhtvghmvgdrnhgvthdpihgvthhfrdhorhhgnecukf hppedujeefrdefkedruddujedrkedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinh
X-ME-Proxy: <xmx:s4aRX6jgLnZMYG-F38ub656V4988TAolkirLvptdU7uDcrZFyGW2fQ> <xmx:s4aRX68DkH-gz8SlAAm3F23Bcrnhi2Zyje0jfBEllc7gysiIvuY0nw> <xmx:s4aRX9uPOBdNdaS27TVFJz0twDhEwGKY-S2EkjpQKTInmJSzHhnAOg> <xmx:tIaRX1LlC0Xh0jeR2gGCCkJWQWrTPMX14Crjr1d_6S26F7x3QJMgWA>
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.80]) by mail.messagingengine.com (Postfix) with ESMTPA id C084B3064682; Thu, 22 Oct 2020 09:18:42 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <BD967623-7316-45A9-9271-327472F2C107@episteme.net>
Date: Thu, 22 Oct 2020 09:18:41 -0400
Cc: Bernie Volz <volz@cisco.com>, IETF Gen-ART <gen-art@ietf.org>, draft-ietf-v6ops-cpe-slaac-renum.all@ietf.org, v6ops list <v6ops@ietf.org>, last-call@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <80F195D7-9D53-443C-AA43-7CE129CC49D7@cooperw.in>
References: <159968036707.9786.16859070438001357349@ietfa.amsl.com> <8d777075-25b5-1817-5c2a-18162bfb9e71@si6networks.com> <2C9BF3C2-A611-4F18-8F03-104405DD9799@cisco.com> <BD967623-7316-45A9-9271-327472F2C107@episteme.net>
To: Pete Resnick <resnick@episteme.net>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/pS2WSXDkthNRqbNsi5WAjZorjPU>
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: Thu, 22 Oct 2020 13:18:48 -0000

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 <resnick@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 <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 mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art