[lacnog] Super importante (Fwd: Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05)

[Fernando Gont]

Estimados,

El director de area (AD) está haciendo una pregunta (en el v6ops wg) 
sobre este documento que escribimos.

Personalmente creo que lo correcto es que el documento sea BCP -- que 
coincide con la recomendación del AD.

Pero para que ello sea posible, es necesario los comentarios del grupo.

P.S.: El documento en cuestión apunta a solucionar un problema que 
padecen, entre otros, ISPs de la región.

Saludos, y gracias!
Fernando




-------- Forwarded Message --------
Subject: Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05
Date: Tue, 8 Dec 2020 16:13:45 -0500
From: Warren Kumari <warren en kumari.net>
To: IPv6 Operations <v6ops en ietf.org>, Fernando Gont 
<fgont en si6networks.com>, Rob Wilton (rwilton) <rwilton en cisco.com>

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



-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
   -- E. W. Dijkstra