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

Alejandro D'Egidio <adegidio@telecentro.net.ar> Tue, 08 December 2020 22:57 UTC

Return-Path: <adegidio@telecentro.net.ar>
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 2033C3A12E2 for <v6ops@ietfa.amsl.com>; Tue, 8 Dec 2020 14:57:40 -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, 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=telecentro.net.ar
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 YNVvrLPJqPwk for <v6ops@ietfa.amsl.com>; Tue, 8 Dec 2020 14:57:37 -0800 (PST)
Received: from gw2mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9192F3A12DE for <v6ops@ietf.org>; Tue, 8 Dec 2020 14:57:37 -0800 (PST)
Received: from gw2mail.telecentro.local (localhost [127.0.0.1]) by gw2mail.telecentro.net.ar (Postfix) with ESMTP id CB53320024; Tue, 8 Dec 2020 19:57:34 -0300 (-03)
Received: from mail.telecentro.net.ar (unknown [10.4.20.96]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gw2mail.telecentro.net.ar (Postfix) with ESMTPS; Tue, 8 Dec 2020 19:57:33 -0300 (-03)
Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id F0D1032013E3; Tue, 8 Dec 2020 19:57:33 -0300 (-03)
Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Q8DZzESiLwAS; Tue, 8 Dec 2020 19:57:33 -0300 (-03)
Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 1981332014CC; Tue, 8 Dec 2020 19:57:33 -0300 (-03)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar 1981332014CC
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1607468253; bh=0YDXueyptY+tKB28J/bJ6fWpXfeIWWlN8zurz3JLG8U=; h=Date:From:To:Message-ID:MIME-Version; b=euFUO4bexpnf0rbbfASB4dPIGHL9FhTOBHrvqtWgQ+c/MF3r25XDVxZRf/urI85WK 0yumMxRTjYMwyziOhuHBImd1rOw2T+Ntu6cA2w2kBvSkF87Ckpien/gvbUUgO7uY86 J1TLcgrjB4imqlr7DzoTO9+DCArVupiGjCYkya8Wkb+fb64s2JXIjn+71bAPgJet/0 oL3v8MnTcXDPGKJWTZseRTPD/2a3DX6SawksOLIWaZnLvwNQYcVMYnfA5joq83VuH+ kuBNRwhzzyr3VSCgR0rl3VL7NSzIQ2ODR0Cn6HQsoZmYQiRagzxgGsOqKWVywJcEzW FjEUq4a0Qzhaw==
X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local
Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OKLVd2VF7kB1; Tue, 8 Dec 2020 19:57:33 -0300 (-03)
Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 0153F32013E3; Tue, 8 Dec 2020 19:57:33 -0300 (-03)
Date: Tue, 8 Dec 2020 19:57:32 -0300 (ART)
From: Alejandro D'Egidio <adegidio@telecentro.net.ar>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Warren Kumari <warren@kumari.net>, "v6ops@ietf.org list" <v6ops@ietf.org>, Fernando Gont <fgont@si6networks.com>, "Rob Wilton (rwilton)" <rwilton@cisco.com>
Message-ID: <1776978474.35481985.1607468252874.JavaMail.zimbra@telecentro.net.ar>
In-Reply-To: <25f0e7e4-0f8d-aa2c-5b93-ac13e846ed40@gmail.com>
References: <CAHw9_iKr2HF4iZYfDWXTqi59HHKcv3UzpLST7VB_rook3MZMWA@mail.gmail.com> <CAHw9_i+G-j-S8H9VBf=n0L-HFXYzV6Dk0nrRpe1C_eADP+6XMg@mail.gmail.com> <25f0e7e4-0f8d-aa2c-5b93-ac13e846ed40@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.210.50.96]
X-Mailer: Zimbra 8.8.12_GA_3803 (ZimbraWebClient - GC86 (Win)/8.8.12_GA_3794)
Thread-Topic: Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05
Thread-Index: +2GXoyDvGqfhnZKMMSl6DCvC+Lg9DQ==
X-KSMG-Rule-ID: 1
X-KSMG-Message-Action: clean
X-KSMG-AntiSpam-Lua-Profiles: 160462 [Dec 08 2020]
X-KSMG-AntiSpam-Version: 5.9.16.0
X-KSMG-AntiSpam-Envelope-From: adegidio@telecentro.net.ar
X-KSMG-AntiSpam-Auth: dkim=pass header.d=telecentro.net.ar
X-KSMG-AntiSpam-Rate: 0
X-KSMG-AntiSpam-Status: not_detected
X-KSMG-AntiSpam-Method: none
X-KSMG-AntiSpam-Info: LuaCore: 418 418 0543ccf0fa7d0fb1227549dfdef7708d8d092243, {Tracking_content_type, plain}, {Tracking_date, brazil}, {Tracking_subj, underscore}, {Tracking_c_tr_enc, eight_bit}, {Tracking_uf_ne_domains}, {Tracking_from_domain_doesnt_match_to}, d41d8cd98f00b204e9800998ecf8427e.com:7.1.1; 127.0.0.199:7.1.2; mail.telecentro.net.ar:7.1.1; telecentro.net.ar:7.1.1; mailarchive.ietf.org:7.1.1; datatracker.ietf.org:7.1.1; www.ietf.org:7.1.1
X-MS-Exchange-Organization-SCL: -1
X-KSMG-AntiSpam-Interceptor-Info: scan successful
X-KSMG-AntiPhishing: Clean, bases: 2020/12/08 21:47:00
X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 1.1.2.12, bases: 2020/12/08 09:54:00 #15812285
X-KSMG-AntiVirus-Status: Clean, skipped
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/rDts3GsbEVen3CXeTAAsVdBigKc>
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:57:40 -0000

Hello,

This document states a real and known issue and describes Best Practices to solve or minimize it.
So, I agree with Option 1.



Regards,
Alejandro


----- Mensaje original -----
De: "Brian E Carpenter" <brian.e.carpenter@gmail.com>
Para: "Warren Kumari" <warren@kumari.net>et>, "v6ops@ietf.org list" <v6ops@ietf.org>rg>, "Fernando Gont" <fgont@si6networks.com>om>, "Rob Wilton (rwilton)" <rwilton@cisco.com>
Enviados: Martes, 8 de Diciembre 2020 19:41:39
Asunto: Re: [v6ops] Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05

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

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops