Hi Warren and Ned on the same email response. >> "RFC8126 - IANA Considerations Section in RFCs" >> (https://tools.ietf.org/html/rfc8126) lists "IESG Approval" as one of >> the possibilities for a registry. >> Snippet: >> "New assignments may be approved by the IESG. Although there is no >> requirement that the request be documented in an RFC, the IESG has >> the discretion to request documents or other supporting materials on >> a case-by-case basis. >> IESG Approval is not intended to be used often or as a "common case"; >> indeed, it has seldom been used in practice." -- this then lists a >> few cases, including RFC6275 and RFC5771. >> RFC8126 goes on to say: "..., it is intended to be available in >> conjunction with other policies as a fall-back mechanism in the case >> where one of the other allowable approval mechanisms cannot be >> employed in a timely fashion or for some other compelling reason." > >> Your draft specifically says that "a registry whose policy is "IETF >> Review" or "Standards Action" [RFC8126] is not available to >> Independent Stream documents.", but doesn't mention what happens with >> "IESG Approval" registries. I would assume that these are also not >> available to IS documents, > > That's not the case currently. One counterexample is standards tree > media types in independent stream documents. RFC 6828 section 3.1 on > standards tree registrations states: > > Registrations published in non-IETF RFC streams are also allowed > and require IESG approval. A registration can be either in a > stand-alone "registration only" RFC or incorporated into a more > general specification of some sort. > > That said, I don't see anything in the document at hand that prevents > this. > >> but in my view it would be entirely >> appropriate for the ISE to be able to *request* that the IESG approve >> allocation. In my *personal* view, a request from the ISE for >> allocation under the IESG Approval procedure should be given extra >> weight. > >> Whatever the case, I think that the document should cover the other >> cases as well. I am particularly enthusiastic to avoid two things: 1. Precedent influencing my policy. Mistakes of the past shall not determine what we do tomorrow. 2. Imposing anything on IETF policies. I believe that the text that Warren quotes is clear about the cases under which "IESG Approval" may be used. Furthermore, I think that this document is clear that "Documents proceeding from the Independent Stream will always follow the assignment policies defined for the registries from which they request allocations." To me that says that IS documents *can* request code points from "IESG Approval" registries, but (of course) such requests would be subject to IESG review. You might like to think that IS documents would be given extra weight in such considerations, but I could not comment. It would certainly not be for me to write down how I think the IESG will behave! I think section 2 lists all registry types that are not available (so the others, including "IESG Approval," are, by default). I think section 3 lists the only allocation policies that could be used for new registries (in the rare case that they are created) and "IESG Approval" is not listed (because, of course, the ISE cannot tell the IESG what to do). So, I'm not convinced anything extra needs to be written. Cheers, Adrian -- Adrian Farrel (ISE), rfc-ise@xxxxxxxxxxxxxx
