On Friday, July 01, 2005 11:32:41 AM +0200 Harald Tveit Alvestrand
But this too is a change; if the people writing the IANA considerations
section had desired public review of requests, they would presumably have
used "IETF consensus" as the registration criteria; to me, the choice of
"IESG review" indicates that the writers of the IANA considerations
section thought that the IESG was able to come to a correct decision
*without* having to ask for an IETF consensus.
I don't entirely agree. The definition of "IETF Consensus" in RFC2434
requires an RFC developed through the IETF process _and approved by the
IESG_. There is no cookie-cutter policy defined in that document which
requires consensus of the IETF but _not_ approval of the IESG. If someone
wanted to set a policy like that for a registry, they'd have to state it
explicitly rather than incorporating one by reference.
On the other hand, my reading of the definition of "IESG Approval" is that
approval by the IESG is required, but not any particular means of getting
that approval. The simple path of "requestor asks IANA; IANA asks IESG;
IESG says yes or no" works fine, but so does following the procedure
Margaret just suggested to Larry, and so does going through the full
My suggestion for a change would be a bit shorter:
As an experiment, the IESG will send out Last Calls for all requests
requiring IESG approval that it wants to reject from <date> to <1 year
later>. At the end of that time, it will evaluate the result, and
either abandon the practice, modify the practice or make it a standard
I like this, except that I'm not sure 1 year is a long enough period to
gather useful data for this experiment. OTOH, I don't really know how
frequently the IESG sees requests like this, so I'll defer to those who do.
I think that a blanket retrofitting of a new meaning on the "IESG
approval" IANA considerations is a thoroughly bad idea.
Ietf mailing list