imo this update is much needed - there has been considerable confusion about some of the processes in RFC 2434 and it would be good to clear up the confusion one specific area of confusion was what used to be called "IETF Consensus" - renaming it to "IETF Review" may help but I'm not sure I think there should be a IANA evaluation process that includes a required IETF-wide Last-Call and evaluatiopn of the results of that Last-Call by the IESG - the current text for "IETF Review" does not make a Last-Call manditory (this is seperate from IETF Standards action because it should not require a standards-track RFC - an info or exp RFC should be fine) it would be my suggestion to use a very specific term such as "IETF Last-Call & Consensus" for a process that includes the following requires a public document (not limited to IDs & RFCs) requires an IETF-wide Last-Call includes IESG evaluation of results of Last-Call IESG permitted to do own evaluation but if results differ from results of Last-Call then IESG has to specifically justify difference in public message to IETF list also concerning the "IESG Approval" process I'm fine with having such a process but considering the mess we have been going through I would like to add a step to the "IESG Approval" process if the IESG decides to turn down a request it must document the reason(s) for the reject in a message to the IETF list and run a Last-Call like request for opinions on the proposed IESG rejection - if the responses to the comment requested process clearly do not support the proposed IESG rejection the IESG must withdraw its proposed rejection. The IESG can publish a RFC listing its issues with the proposed use but can not block the assignment if the responses to the comment requested process do not clearly object to the proposed IESG rejection then the IESG recommendation for rejection can be forwarded to the IANA Scott _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf