On Thu, Dec 31, 2020 at 5:14 AM S Moonesamy <sm+ietf@xxxxxxxxxxxx> 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 > last-call@xxxxxxxx > 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
