Hi Warren, On Tue, Oct 17, 2023 at 1:48 PM Warren Kumari via Datatracker < nore...@ietf.org> wrote: > > Warren Kumari has entered the following ballot position for > draft-ietf-intarea-rfc7042bis-10: Discuss > > ... > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Be ye not afraid by this discuss; it's simply a request to have a discussion - > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > > I had initially started writing this as NoObjection ballot, but while doing so > I realized that I was sufficiently concerned that a discuss DISCUSS seemed > appropriate. > > I am uncomfortable about the creation of the "IESG Ratification" type and > process; it feels like lots of additional complexity and over-specification, > and like it is leading the IETF towards much more of a "process driven" (vs "Do > the Right Thing") type organization.
I'm not sure why you say "creation". There have been minor wording changes but this assignment process has been the same and has been called "IESG Ratification" for 15 years, since https://datatracker.ietf.org/doc/html/rfc5342 (which later evolved as 5342->7042->rfc7042bis). To some extent, "complexity" is in the eye of the beholder. Generally speaking, IANA prefers to be told exactly what to do rather than being forced to exercise judgement. This draft has been reviewed by IANA without objection to the IESG Ratification assignment procedure. > Section 1 says: "[RFC8126] is incorporated herein except where there are > contrary provisions in this document. In this document, "IESG Ratification" is > used in some cases. "IESG Ratification" is specified in Section 5.1. It is > NOT the same as "IESG Approval" in [RFC8126].", and Section 5.1 has a long > section on "If the assignment is based on IESG Ratification:". > > I'm unclear why there are not just 2 assignment ranges / types -- 1: Expert > Review and 2: IESG Approval. The "based on IESG Ratification" section sounds > very similar to the regular "IESG Approval". There are several motivations. One is to provide the requester with a uniform interface so the requester does not need to worry about the assignment process. They always just fill out and submit a Template. Another is to provide a filter so that the Expert(s) can just turn down some request that would otherwise go to and use up time of the IESG. And a third is, when it does have to go to the IESG, to provide the IESG with the Expert's input to assist the IESG in making its decision. > [RFC5771 - "IANA Guidelines for > IPv4 Multicast Address Assignments"]( https://datatracker.ietf.org/doc/rfc5771/) > does something quite similar to this document, but uses the existing RFC8126 > process. It seems like asking the IANA to first pass requests through the > Experts, and, if the range is one of the "large" ones, it gets IESG approval > after that -- this is almost exactly the same thing as this document describes, > but without creating a new name/type of process. I disagree that it is the same thing. I haven't studied it in detail (I'm actually on vacation in Chengdu at the World Science Fiction Convention http://en.chengduworldcon.com) but it looks to me like RFC 5771 uses the old loosey, goosey redundant "Expert Review, or IESG Approval, or Standard Action" set of three parallel paths for most things. (As far as I know, Standards Action requires IESG Approval...) But it does not appear to satisfy the motivations I listed above. > I'm more than happy to be schooled as to why I'm wrong.... Well, I hope my response above clarifies the thinking in this draft for you. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you very much for writing this document; it seems useful and important, > and is well written to boot! > > Much thanks to Patrick Mevzek for the DNS-Dir review > ( https://datatracker.ietf.org/doc/review-ietf-intarea-rfc7042bis-10-dnsdir-lc-mevzek-2023-10-10/ ), > and for following up when the new version was posted.
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
