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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf