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