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