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

["Rob Wilton (rwilton)" <[e-mail]>]

I also agree with Warren that option 1 is best.

Regards,
Rob


> -----Original Message-----
> From: Warren Kumari <[e-mail]>
> Sent: 08 December 2020 21:14
> To: IPv6 Operations <[e-mail]>; Fernando Gont
> <[e-mail]>; Rob Wilton (rwilton) <[e-mail]>
> Subject: Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-
> 05
> 
> [ 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 <[e-mail]> 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