It may be of interest that in some cases blocks of parameter values in RFC 9542 and its predecessors back though RFC 5342 are assigned under a policy called, in these RFCs, "IESG Ratification". This provides for Expert Review and then, if the Expert approves or is uncertain, the final decision is made by the IESG. See Section 5.1.2 of https://datatracker.ietf.org/doc/rfc9542/ (https://www.rfc-editor.org/rfc/rfc9542.html#name-expert-review-and-iesg-ratif).
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com On Sat, May 25, 2024 at 5:15 PM Carsten Bormann <c...@tzi.org> wrote: > > On 10. May 2024, at 22:13, Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> wrote: > > > > If you would like time at the meeting to discuss your work or ideas, please > > reply to this email with your request by May 24th. > > I apologize for being a day late (but of course time does not actually > advance during weekends…). > > We have had a longstanding, small but tricky problem with the IANA > registration policies defined in BCP 26: this has policies that involve > designated experts and policies that require some IETF consensus (IETF > review, Standards Action), but no policies that actually combine these > requirements. > > One might think that IETF consensus should be higher-ranking than expert > review, but for some registries there is registry-specific knowledge that may > be required for making a correct registration and that may be concentrated in > the designated experts. IETF consensus based registration sometimes > circumvents that knowledge, which can lead to incorrect registrations or to > emergency actions to avoid such incorrect registrations (which in turn can > lead to port-465-style problems [2]). > > The draft at [0] aims to create pre-made policies that solve this problem by > combining IETF consensus with expert review. > > This has been discussed for almost a decade, probably more during meetings > than on mailing lists. > Finally writing this up was triggered by the specific instance of [1]. > > We would like to discuss this issue (and how well the current draft succeeds > at addressing the issue) on the gendispatch ML, adjust the draft, and then > have it on the agenda of the gendispatch meeting in Vancouver. > > Grüße, Carsten > > > [0]: > https://www.ietf.org/archive/id/draft-bormann-gendispatch-with-expert-review-00.html > > [1]: https://mailarchive.ietf.org/arch/msg/core/BENVbgmF0px40GPW-zlA4nHI8So > > [2]: https://datatracker.ietf.org/doc/html/rfc8314 > (The 465 problem was created by a set of circumstances distinct from the > problem we hope to solve by “…with expert review”, but it is a rather > impressive example for how long unstable registrations can linger if not > addressed heads-on early. > > _______________________________________________ > rtgwg mailing list -- rt...@ietf.org > To unsubscribe send an email to rtgwg-le...@ietf.org _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
