Re: [v6ops] Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05

Keith Moore <moore@network-heretics.com> Tue, 08 December 2020 23:48 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2863A1374 for <v6ops@ietfa.amsl.com>; Tue, 8 Dec 2020 15:48:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=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=messagingengine.com
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 zkPoQoPxgZKD for <v6ops@ietfa.amsl.com>; Tue, 8 Dec 2020 15:48:55 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694973A1373 for <v6ops@ietf.org>; Tue, 8 Dec 2020 15:48:55 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 927A25C00FB for <v6ops@ietf.org>; Tue, 8 Dec 2020 18:48:54 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 08 Dec 2020 18:48:54 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=sGZTbr E58EChVOQexjDLOtvy5nd4Yc19ElCDQAFcTf0=; b=SlYPy0xciaxdLt3iQ6b3EC 8U7Z/sLdeMKYNLYJ1cqijFg7ktW9meyIiDUpDsNcNSyS8PAHpGjVW5S6pbhDsVOV zwz72BH5n18R4liAV2msf2gkOsIglghVpQ704fHvFrVdJ72p0T3671Lb5uLycOD/ 3iRJRCFq2Epg3urYKteN7qIf+C+xw2NWd4HGpL1qCP48kDHWqagrhWZcwPVWNMXs S5wLlzGPKriTgQqauNhr07P5r0+9fQs0P9brEcSbTQtuUCo8TZi9HsuOytknT2DV Cnb+PtLPtp+msNYi9Oq3Q/BTgRkkZLhgCRXuw5qb9X7ZJ0ZBHIqxByzj62a+hjdg ==
X-ME-Sender: <xms:5hDQX9TNT-trPqTRAHDAul5I2UbwBbi0v4jDkZH4yclMMYAXPX26-A> <xme:5hDQX2w3TcMOCro0D04vndm69Tt3u_xnfd-Kt5QyXgsLR0WKJXOAHB4ItbN4otvyV yGBM2B97BT77A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejjedgudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepudetfeekveevfe eltdekffeigeelkefgudevgedtvdehjefggffglefhvdeuudeinecuffhomhgrihhnpehi vghtfhdrohhrghenucfkphepuddtkedrvddvuddrudektddrudehnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhrvgesnhgvthifohhr khdqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:5hDQXy35mz5smpQFyxf-3CenUb9nnOMKApCeMNpjG6WEo4RjnSOVcA> <xmx:5hDQX1Dypsp98sgzgoBUJRsGUbwS1kCOnn04Vn4v9XIk9YhENsQ6XQ> <xmx:5hDQX2jQzERH_9Eldcp4miT1zGlrLC0-GxUTfROKCLbzdniWulIySQ> <xmx:5hDQXxRy7kk9bkDxvU1ozDcjxp6jw1bhdztDTom1udcG-eLLOJrGHQ>
Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id F264824005D for <v6ops@ietf.org>; Tue, 8 Dec 2020 18:48:53 -0500 (EST)
To: v6ops@ietf.org
References: <CAHw9_iKr2HF4iZYfDWXTqi59HHKcv3UzpLST7VB_rook3MZMWA@mail.gmail.com> <CAHw9_i+G-j-S8H9VBf=n0L-HFXYzV6Dk0nrRpe1C_eADP+6XMg@mail.gmail.com>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <10364e4c-c037-bc7f-6db3-e69ef42d05a1@network-heretics.com>
Date: Tue, 8 Dec 2020 18:48:53 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CAHw9_i+G-j-S8H9VBf=n0L-HFXYzV6Dk0nrRpe1C_eADP+6XMg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------D6AA91BBDFD1699414E85994"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/3786BMWLhdXQNOludyOgxGgY9pM>
Subject: Re: [v6ops] Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2020 23:48:58 -0000

On 12/8/20 4:13 PM, Warren Kumari wrote:

> [ Subject edited to start new thread ]
> Hello again all,
>
> I started this thread back in October, and then didn't really follow-up; sorry.
>
> This document went through WGLC as Informational, but uses
> "pseudo-RFC2119" language
> (https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/,
> Section 2). This section says things like (cribbed from RFC7084):
> " Take careful note: Unlike other IETF documents, the key words "MUST",
>     "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
>     "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as
>     described in [RFC2119].  This document uses these keywords not
>     strictly for the purpose of interoperability, but rather for the
>     purpose of establishing industry-common baseline functionality. "
>
> This caused confusion during IESG eval -- what does the MUST in "CE
> routers MUST signal stale configuration..." mean if not in the RFC2119
> sense?

My take - Either a standards-track document or a BCP document should be 
able to use 2119 keywords in a non-2119 way, but only if it provides 
prominent and explicit definitions of the meanings of the words as used 
in the document.

Having said that I am starting to dislike use of 2119 definitions for 
keywords in in BCPs, because they inherently need to mean different 
things in the context of a BCP, than in the context of a protocol 
specification.   For example:

In a BCP - MUST NOT presumably means "doing this violates what we 
consider best current practice".
In a protocol specification - MUST NOT means "a protocol implementation 
violates the standard if it does this"

Though 2026 definitions could be said to apply equally to either kind of 
document, I've come to believe that it's easy for readers to confuse the 
two cases.   e.g. a BCP should not constrain behavior of a protocol 
implementation, since an operator may always have valid reasons for not 
configuring a protocol implementation to adhere to "best" practice and 
may need the flexibility to use an implementation that doesn't strictly 
enforce "best" practice.

IMO, regardless of intended status, you should have more explicit 
definitions for those keywords than you do in the -05 draft.   And 
though I can think of valid reasons for an Informational document to use 
2119 keywords, in general I think it's confusing if they do so.

(hope that's clear)

> Also, much of the document reads like a BCP - Alissa specifically
> called this out in her DISCUSS, but there were quite a few others who
> agreed.
>
> As an example, is it not a Best Current Practice that e.g: "CE routers
> SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon reboot
> events."? If not, what does this document mean for an implementer?

My litmus test for BCP vs. standards-track is this:  A protocol 
specification says how to implement a protocol in a way to produce some 
desired behavior and also to interoperate with other implementations of 
that protocol.   Standards track is intended for protocol 
specifications.   If it's meaningless to test an implementation of a 
specification for interoperability with other implementations, it's 
probably not appropriate for standards track.

This is not usually a problem with a BCP.   Similarly, BCP isn't 
intended for protocol specifications, it's intended for (usually but not 
always operational) practices.   Of course poorly chosen operational 
practices /can/ harm interoperability, but I don't think we test BCPs 
for interoperability in the way that we test implementations of protocol 
specifications.

Sometimes standards-track protocol specifications also make 
recommendations for operational practice, which is not a problem as long 
as the two kinds of recommendations are clearly distinguished.   
Generally, when evaluating such a specification for advancement only the 
protocol implementations are tested for interoperability.

As for the document at hand:

To me draft-ietf-v6ops-cpe-slaac-renum-05 reads more like a protocol 
specification than a recommendation for operational practice.  As I 
understand it, its intent is to constrain implementations of IPv6 edge 
routers (at least, those that get upstream prefixes using DHCPv6) rather 
than merely to recommend how such routers be configured.    I think 
implementations of this specification could reasonably be tested for 
interoperability, at least when DHCPv6 is used to obtain the upstream 
prefix.   If you can get IETF consensus on these recommendations I 
wonder why you're not requesting Proposed Standard.

So my recommendation is: figure out what kind of document you really 
want, and revise the document (not just the keyword definitions) to be 
consistent with that intended status.   If you want standards-track, 
write it with a router implementer in mind; if you want BCP; write it 
with an operator in mind who is going to be adjusting settings on 
routers.   If you want to both constrain implementations and make 
operational recommendations, standards-track with a non-normative 
section on operational recommendations sounds about right.

(And if you can get consensus around Informational but not around 
Proposed, I wonder what the gap is about, but I'm thinking in that case 
you should avoid absolutes like MUST or MUST NOT.)

FWIW I've never really believed it would be feasible in general to 
seamlessly renumber IPv6 subnets of significant size, and I still 
don't.   But for the specific scenario envisioned by this document, I 
think its recommendations make sense.  So I expect I would support 
publication of a revised version of this document once the intended 
status is ironed out and the language is revised to be consistent with 
that status.

Keith

[*]. for any IESG folks watching I'd make the same statement about 
draft-ietf-tls-oldversions-deprecate use of 2119 keywords - will send a 
separate message on that in response to that LC