Re: "IETF consensus" in IANA considerations [was Re: Last Call: CR-LDP Extensions for ASON to Informational ]

[Thomas Narten <narten@us.ibm.com>]

> Absolutely.  Otherwise, this discussion wouldn't be worth the 
> trouble.  But, if you are going to define "IETF Consensus" as 
> "Publication as an RFC" then

Since I don't seem to be able to make this clear enough, once again, I
do not and have never intended "IETF Consensus", in the literal sense,
to be defined as "Publication as an RFC". We all know that the two are
not the same. That term was used as a shorthand way in RFC 2434 to
indicate RFC publication was required.

If I could go back in time, I would leave the defintion as it is, but
give it a different name. I probably wouldn't have tried to define
"IETF Consensus" at all, as I'm not sure how that would be done in a
way that encompasses both standards track and non-standards track
documents (or that such a definition would even be useful).

> 	- We don't need the added term to add confusion.
> 	
> 	- We open up a loophole case in which a document comes
> 	to the RFC Editor, then to the IESG.  The IESG decides
> 	it is a bad idea, and puts a disclaimer on it that says
> 	"this is a terrible idea".  The RFC Editor decides to
> 	publish it anyway.  We now have an RFC that, regardless
> 	of its other properties, clearly does not represent IESG
> 	consensus that it is a good idea.  But whatever it calls
> 	for is eligible for registration.

What this points out is that the relationship between IESG review,
IANA assignments and RFC editor independence is both complex and
subtle. Not suprisingly, it has evolved over time in a way that no
longer matches the exact words in (say) 2026. A literal intepretation
of some of these words could easily lead us into situations that we
probably don't want to be in.  I agree that it would be good to
clarify and update the written words.

Thomas