Subject: Re: [Last-Call] Last Call: <draft-ietf-v6ops-cpe-slaac-renum-06.txt> (Improving the Reaction of Customer Edge Routers to Renumbering Events) to Best Current Practice

From: Warren Kumari <[email-masked]>
Date: Fri, 1 Jan 2021 11:13:12 -0500

On Thu, Dec 31, 2020 at 5:14 AM S Moonesamy <[email-masked]> wrote:
>
> At 04:00 PM 30-12-2020, The IESG wrote:
> >This is the second IETF LC for this document -- it was originally
> >LCed as Informational. IESG Eval suggested that it was more
> >BCP-like, and so the document was returned to the V6OPS WG, and
> >re-WGLCed as BCP. It is now being IETF LCed as BCP, and will then go
> >through IESG Eval again.... and the process-elves rejoice...
>
> What is the meaning of the "process-elves rejoice..." as stated by
> the Internet Engineering Steering Group on this Last Call announcement?

Just the fact that there was this much process needed to move the
document from the original status of "Informational" to "BCP".

The document was originally IETF LCed as Informational on 2020-08-26,
and went through IESG Eval on 2020-10-22.
During IESG Evaluation a number of ADs said that the document seemed
much more like BCP material - it contains best current practices.

"Downgrading" status is easy, but "upgrading" requires lots of process
-- I had to send t the document back to the WG[0] so that it can be
re-WGLCed to confirm that the V6OPS WG agrees with BCP (consensus was
declared) , and then it needs another IETF LC (which is what is
happening now), and then it needs another IESG evaluation, and then it
finally goes to the RFC Editor. This all adds ~4 months of delay...

The "joke" was that there are process elves which feed on process, and
are excited for all of the paper-shuffling, etc required for this
change - sorry that it wasn't clearer...

[0]: https://mailarchive.ietf.org/arch/msg/v6ops/23R_SlJP9l5pdkgFTglDZh1sh7Y/
[1]: https://mailarchive.ietf.org/arch/msg/v6ops/_seai5Rf5bU6AnPwc3bHqbAI_7M/
, https://mailarchive.ietf.org/arch/msg/v6ops/xb4aVGUkkv8ZBxtbeewXjyNq7TQ/

>
> I took a look at draft-ietf-v6ops-cpe-slaac-renum-06 in case it gets
> implemented by service providers.  The draft updates parts of RFC
> 7084.  The requirements in that RFC were for establishing
> industry-common baseline functionality instead of interoperability as
> specified in RFC 2119.  That is different from the Requirements
> language in Section 2 of this draft.  I found it confusing.
>
> The amount of RFC 2119 key words in the draft is
> excessive.  Behavioral requirements are specified in Section 3, and
> re-specified in the later sections of the draft.  I gather that a "CE
> routers MUST NOT advertise prefixes ..." means that the operator or
> the user cannot turn off that option.
>
> I doubt that CPEs for residential scenarios would be worse [1] if the
> intended status of the draft was Informational.
>
> Regards,
> S. Moonesamy
>
> 1. It may happen that the "support" desk tells the reader that
> configuration knobs are disabled for security purposes.
>
> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

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

---

From: S Moonesamy <[email-masked]>
Date: Fri, 01 Jan 2021 10:49:24 -0800

Hi Warren,
>much more like BCP material - it contains best current practices.

The previous Last Call [1] was for the draft to 
be published as a Proposed Standard.

>finally goes to the RFC Editor. This all adds ~4 months of delay...

Ok.

>change - sorry that it wasn't clearer...

There were three Area Directors who filed 
"process objections".  There were some good 
points raised as comments by Éric.  I could not 
find any response to those comments on the mailing list.

Regards,
S. Moonesamy

1. 
https://mailarchive.ietf.org/arch/msg/ietf-announc 
e/_qgHcW0cgtPz29hjQV-1v-MBjI0/

---

From: Fernando Gont <[email-masked]>
Date: Fri, 1 Jan 2021 17:31:54 -0300

Hi, SM,

On 1/1/21 15:49, S Moonesamy wrote:
> The previous Last Call [1] was for the draft to be published as a 
> Proposed Standard.

There was an *error* in how the metadata for the document was set. The 
track of the document had always been "Informational".

> There were three Area Directors who filed "process objections".

I believe that that was indeed the reason for which we've changed the 
track to BCP.

> There 
> were some good points raised as comments by Éric.  I could not find any 
> response to those comments on the mailing list.

I thought we had responded to all, but since we authors are mere 
mortals, it could also be the case that we missed some. I will review 
all received comments (and, in particular, any by Eric) and respond if 
necessary.

That said, the document is being IETF LC'ed (rather than published by 
the RFC-Ed), so we're just in time to address anything that we may have 
missed before.

Thanks!

Regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1