On Tue, Oct 17, 2023 at 11:51 PM, Donald Eastlake <d3e...@gmail.com> wrote:
> Hi Warren, > > On Tue, Oct 17, 2023 at 1:48 PM Warren Kumari via Datatracker <noreply@ > 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. > Gadzooks, huge apologies. I *had* checked to see if 'IESG Ratification' had been used in the past, but came up empty. I just checked my shell history, and apparently I did: "grep -ri 'IESG Ratfication' * " (note the missing 'i' in Ratification) 'pologies again for stupid, DISCUSS cleared. W > > 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
