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

Alissa Cooper <> Thu, 22 October 2020 13:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B25333A0983; Thu, 22 Oct 2020 06:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.101
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: (amavisd-new); dkim=pass (2048-bit key) header.b=cjYdDWCG; dkim=pass (2048-bit key) header.b=LmG4aSi7
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6jvw7J5qQRty; Thu, 22 Oct 2020 06:18:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A67713A08B2; Thu, 22 Oct 2020 06:18:45 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 5FAA6A22; Thu, 22 Oct 2020 09:18:44 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute3.internal (MEProxy); Thu, 22 Oct 2020 09:18:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=; 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 (unknown []) by (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.\))
From: Alissa Cooper <>
In-Reply-To: <>
Date: Thu, 22 Oct 2020 09:18:41 -0400
Cc: Bernie Volz <>, IETF Gen-ART <>,, v6ops list <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Pete Resnick <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-v6ops-cpe-slaac-renum-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


> On Sep 11, 2020, at 7:51 PM, Pete Resnick <> 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 <> 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:
>>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> -- 
> Pete Resnick
> All connections to the world are tenuous at best
> _______________________________________________
> Gen-art mailing list