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

From: Warren Kumari <[email-masked]>
Date: Tue, 8 Dec 2020 16:13:45 -0500

[ 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 <[email-masked]> 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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 8 Dec 2020 18:59:51 -0300

On 8/12/20 18:13, Warren Kumari wrote:
[....]
> documenting Best Current Practices for CPE implementers.

FWIW, I agree that option 1 is the way forward.

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 9 Dec 2020 11:41:39 +1300

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

---

From: Alejandro D'Egidio <[email-masked]>
Date: Tue, 8 Dec 2020 19:57:32 -0300 (ART)

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" <[email-masked]>
Para: "Warren Kumari" <[email-masked]>, "[email-masked] list" <[email-masked]>, "Fernando Gont" <[email-masked]>, "Rob Wilton (rwilton)" <[email-masked]>
Enviados: Martes, 8 de Diciembre 2020 19:41:39
Asunto: Re: [v6ops] Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05

Regards
   Brian

>> the recommendations **in this document**.

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Dec 2020 18:48:53 -0500

> routers MUST signal stale configuration..." mean if not in the RFC2119

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)

> 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

---

From: Philip Homburg <[email-masked]>
Date: Wed, 09 Dec 2020 13:56:58 +0100

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

In the context of this document I don't see much difference. Changing how
protocol values are set does change the protocol. 

In general, violating a MUST in a protocol means that bad things are likely
to happen. That's the same in this BCP.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 9 Dec 2020 13:54:27 +0000

I also agree with Warren that option 1 is best.

Regards,
Rob

> -----Original Message-----
> From: Warren Kumari <[email-masked]>
> Sent: 08 December 2020 21:14
> To: IPv6 Operations <[email-masked]>; Fernando Gont
> <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>
> Subject: Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-
> 05
> 
> [0]:
> https://mailarchive.ietf.org/arch/msg/v6ops/xVv4f73kB8tRFag3yJCBAraXwXk/
> 
>

---

From: Warren Kumari <[email-masked]>
Date: Fri, 11 Dec 2020 12:17:08 -0500

[ Top post ]

Awesome, thank you everyone.

I'm returning this document to the V6OPS WG, and requesting that it be
updated with:
1: The "normal" RFC2119/RFC8174 language
2: The track to be BCP

Hopefully it can be WGLCed soon, and that the comments are restricted
to just those needed for the above changes.
Once the WG sends it back to me I'll do another IETF LC (required
because of the track change).

Thank you everyone, and sorry for the process wonkey -- changing
status "up" is harder than changing "down" :-)
W

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Dec 2020 14:54:45 -0300

Hi, Warren,

> 1: The "normal" RFC2119/RFC8174 language

Done.

Thanks a lot!

Regards,