On one point (since it was mentioned in other thread as well):
(ii) For the reasons above and in my earlier note, I think the
IESG, and the IETF more broadly, must exert great caution in
rejecting a registration request and must exert that caution in
public. For example, the language of 2434, and the language of
2780 with regard to the registry in question, indicates that the
IESG may approve one of these requests. They do not appear to
me to indicate that the IESG may definitively reject it.
What 2434 says about "IESG approval" is:
IESG Approval - New assignments must be approved by the IESG, but
there is no requirement that the request be documented in an
RFC (though the IESG has discretion to request documents or
other supporting materials on a case-by-case basis).
(as an author) I agree that the "must" wording is poor and would be
better replaced by something like "may".
I would also add wording saying that "IESG Approval" is intended for
unusual circumstances, with the preferred approval through something
involving IETF review (e.g., "Standards Action").
In practice, what I have been telling folk over the years (when
advising about writing IANA considerations sections) is that including
"IESG Approval" is a useful thing to do to deal with unanticipated
circumstances -- it leaves the door open to convincing the IESG that
the documented approval paths are a problem in particular cases. I
suspect that a lot of existing RFCs use the above _in_ _addition_ _to_
specifying alternative approval methods.
Finally, in all the time I was on the IESG, I can't right now recall
the IESG ever getting an assignment request via the above mechanism,
much less approving one. So the above has not been used in practice
very often, if at all. Instead, folks generally know (or were
advised) to submit an ID instead and get it reviewed by an appropriate
WG rather than making a request directly to the IESG.
This all suggests that the case at hand is rather unusual and does not
reflect the common case. The more common case is to have requests
reviewed by the IETF community (or experts peforming reviews on behalf
of the community). But as has been noted, in this case the IETF does
not have open access to the proposal, so the community as a whole
cannot evaluate it. Thus, the IESG was forced into the role of having
to make a decision. Somewhat of a no-win situation, it seems to me.
Thomas
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf