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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 08 December 2020 22:41 UTC

Return-Path: <brian.e.carpenter@gmail.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 15C953A12AE for <v6ops@ietfa.amsl.com>; Tue, 8 Dec 2020 14:41:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=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=gmail.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 aS4iEJMWXOvS for <v6ops@ietfa.amsl.com>; Tue, 8 Dec 2020 14:41:47 -0800 (PST)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F613A12AD for <v6ops@ietf.org>; Tue, 8 Dec 2020 14:41:47 -0800 (PST)
Received: by mail-pl1-x62b.google.com with SMTP id v3so68622plz.13 for <v6ops@ietf.org>; Tue, 08 Dec 2020 14:41:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rwNs/9PAOaFs7dpW3Hx64mHMmLvRJIffp4DSVPz6ydo=; b=Li4HaGO/T11t1eDVMzi+cYiwPFzYwzA/HF3/D5a3KjffFhkUJY+R/1jswklE0c+k5K KRi3DavPg5XH6lfuMsi0DZt26BaZJyuLJ4M2os3z7eQvq5UnILVfh3eHJqUtuhYKWnI9 4RtEQmEQaV+ukhmSoj4i4xXytc9+nK2K4RRyYZYPxl9PBZ8IEQoVPhtMxrp+GxMqNxuK Vr7EARzajvQ+MhTEe9MlZy0g0q7f+h5GeyGfNtLUt1zTZvjr1jy7yH92ZaZD12lkASF9 SOKkJogLDDNOgJCJy/LdZEI0IXwNZNJ96DKUFiD/iIOC8kqn1JA0K3PPx1GbxVwl7SrZ jAEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=rwNs/9PAOaFs7dpW3Hx64mHMmLvRJIffp4DSVPz6ydo=; b=fCuA9nIg754AwoYGoAUDaYfhvfNfOPOWxysxOV/GZtW6o6zKlQjY/VNS12u7J2ZyYg HP/AMkpNR6lSzUanEg5TVxzNgpUUTtGxxSMFRrBI8Amzogmb+jShs4Au5/03a1lOYOC3 i5wTkV0eayIZbFXMviw3kr14jyfF5cYPHnyVKm+PCmtd1+hk9xhYTpUfICcjHAhCk1d7 rWclZMe9nQ+WVp2is6RLq3b9qyMh6jIraLOG8k7yK0WCQ43y5UogABjiMKHYgwdJ71Ra oRpP+cpesfyvv3YmVLDlSyU0Hq4zPxxV9TnJU0PvTKTkKfyWx+CdtJUZbV1frOTH+u5u mUUQ==
X-Gm-Message-State: AOAM532TlkL0GZPucyEJk9+st9fD8sjIXKS41F08adE9NCDd/MRyLV4U D5TV9nT5PCHoHWhwFjB8QEQ=
X-Google-Smtp-Source: ABdhPJy7F3gwv3A0k17LpdczCx/+6DR7HZX9VmofloQmC/mnvki3UKS8REdzYuhHFVX0S9MLCymjXA==
X-Received: by 2002:a17:902:c20c:b029:da:b4d4:4f42 with SMTP id 12-20020a170902c20cb02900dab4d44f42mr1163732pll.85.1607467306508; Tue, 08 Dec 2020 14:41:46 -0800 (PST)
Received: from [192.168.220.117] ([131.203.179.213]) by smtp.gmail.com with ESMTPSA id z6sm203542pfj.22.2020.12.08.14.41.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Dec 2020 14:41:45 -0800 (PST)
To: Warren Kumari <warren@kumari.net>, IPv6 Operations <v6ops@ietf.org>, Fernando Gont <fgont@si6networks.com>, "Rob Wilton (rwilton)" <rwilton@cisco.com>
References: <CAHw9_iKr2HF4iZYfDWXTqi59HHKcv3UzpLST7VB_rook3MZMWA@mail.gmail.com> <CAHw9_i+G-j-S8H9VBf=n0L-HFXYzV6Dk0nrRpe1C_eADP+6XMg@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <25f0e7e4-0f8d-aa2c-5b93-ac13e846ed40@gmail.com>
Date: Wed, 9 Dec 2020 11:41:39 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CAHw9_i+G-j-S8H9VBf=n0L-HFXYzV6Dk0nrRpe1C_eADP+6XMg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/7iHR2MZjaTGBPgF_E6TZX_UU1iU>
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 22:41:50 -0000

Option 1 please. BCPs were meant for this. The current "RFC2119 but not really" stuff is confusing (as it is in 7084 IMHO).

Regards
   Brian

On 09-Dec-20 10:13, 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?
> 
> 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?
> 
> 
> There are 2 options here:
> 1: We change Section 2 to use normal RFC2119/RFC8174 language. I send
> it back to the WG and it gets WGLCed as BCP.
> 
> 2: We remove Section 2, and all of the uppercase/lowercase words. I
> send it back to the WG (because of the changes) and it gets WGLCed as
> Informational again.
> 
> I really prefer Option 1 -- to me it reads much more like a BCP,
> documenting Best Current Practices for CPE implementers.
> 
> The last time I sent this, there was only one response[0] and then the
> thread died -- I'd REALLY appreciate clear responses from the WG on
> which option (1 or 2) you prefer...
> 
> W
> 
> [0]: https://mailarchive.ietf.org/arch/msg/v6ops/xVv4f73kB8tRFag3yJCBAraXwXk/
> 
> 
> On Thu, Oct 22, 2020 at 11:53 AM Warren Kumari <warren@kumari.net> wrote:
>>
>> Hi all,
>>
>> draft-ietf-v6ops-cpe-slaac-renum-05 was on today's telechat, and ran
>> into issues.
>>
>> Alissa (based on the Gen ART review) asked why this was not a BCP, and
>> there was general agreement within the IESG that BCP seems like most
>> reasonable status.
>> There was also discussions on the:
>> "Take careful note: Unlike other IETF documents, the key words "MUST",
>> [...]  "OPTIONAL" in this document are not used as described in [RFC2119]."
>> and that this was very confusing.
>>
>> I proposed that we change the status to BCP, and that the terms be
>> used in the normal manner.
>>
>> I'd like to give the WG 2 weeks to object to this proposal, and, if
>> none received, start another IETF LC as BCP.
>>
>> So, please let me know (by Nov 5th) if you strongly object to this
>> becoming a BCP, and the "normal" RFC2119/BCP14 meanings being used for
>> the recommendations **in this document**.
>>
>>
>> W
>>
>> --
>> I don't think the execution is relevant when it was obviously a bad
>> idea in the first place.
>> This is like putting rabid weasels in your pants, and later expressing
>> regret at having chosen those particular rabid weasels and that pair
>> of pants.
>>    ---maf
> 
> 
>