[ipv6hackers] MItigating slaac-renum problems at CPE routers (Fwd: Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05)

[Fernando Gont]

Folks,

You're probably aware about the problems that can arise in SLAAC 
deployments as a result of renumbering (see 
https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum for the proble 
statement)

In order to mitigate this problem at CPE routers, we published 
https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum . The 
document was targeting the "Informational" track because the document it 
was trying to update (RFC7084) was also informational.

However, during IESG review, it was noted that the document should 
probably be BCP instead.

So our AD (Warren) is asking the v6ops working group whether to make the 
document BCP (IMO, the right way forward), or keep the document 
"Informational" and remove terms IN CAPS ("SHOULD", etc.).

Please see his request for comments below (also: 
https://mailarchive.ietf.org/arch/msg/v6ops/dgtr_QKH3x29WY2DSHYhrMztL5I/), 
and, if you can, please weigh in at the v6ops wg mailing list 
(https://www.ietf.org/mailman/listinfo/v6ops)

Thanks!

Regards,
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 at kumari.net>
To: IPv6 Operations <v6ops at ietf.org>, Fernando Gont 
<fgont at si6networks.com>, Rob Wilton (rwilton) <rwilton at 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 at 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