Whether we should require "IETF consensus"

[Harald Tveit Alvestrand <harald@alvestrand.no>]

Attempting to untangle some threads on this rather divergent debate....

We seem to have three different discussions going:

A - Is the IESG allowed to block publication of internet-drafts as RFCs if 
they make assignment in IANA registers where the rule for registration is 
"IETF Consensus", and the IESG determines that the IETF consensus is not 
satisfied?

B - What review process must the IESG take before taking the action to 
block or allow publication of such an internet-draft (ie "what does IETF 
Consensus mean")?

C - Given the debate about the specific documents, should the IESG have 
approved draft-aboulmagd-ccamp-crldp-ason-ext for publication?

To my mind, the answer to the first question is clearly YES.
When RFC 2434 was written, the "IETF Consensus" category was created 
because there were cases where any kind of "free-for-all" assignment was 
deemed harmful to the Internet - because of confusion, "name homesteading", 
resource depletion or too easy "labeled non-interoperability", or for other 
reasons - while each individual registration might be not important enough 
to warrant standards-track processing, be under the control of some other 
body, or be inappropriate for standards-track for other reasons.

There is clear, demonstrable harm to the Internet in these cases - in some 
cases, not in the individual request, but in the aggregate. The "IETF 
Consensus" mechanism is a tool that the community can use to give the IESG 
the power to defend the Internet against such harm. And the community has 
used it, as witnessed by the many documents using this mechanism.

The IANA follows the RFC-documented instructions on when to insert values 
into its registries, and IESG instructions on "IETF Consensus" registries.

Having a situation where an RFC documents something at variance with IANA 
registration seems absurd, so it seems unreasonable to me that the RFC 
Editor would publish an RFC documenting such an assignment, given that the 
IESG made the RFC Editor aware of the situation.
(Of course, that makes the position of RFC 2882, "extended RADIUS 
practices", which documents codes in use but not registered with the IANA, 
slightly absurd. We need to fix that, too....)

Rather than attacking the 2 other issues in the same mail, I'll follow up 
the second one in another message, and mainly leave the third one to 
subject matter experts - hopefully allowing us to untangle the abstract 
issues from the specific one....

                  Harald