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