Re: IESG review of RFC Editor documents

> It seems to me that at least latent in your suggestions is the 
> assumption that the RFC Editor should publish only IETF consensus 
> documents or documents that are in general agreement with IETF 
> consensus.
Actually, my assumption is that only documents for which there is a 
significant supporting constituency should be considered for 
publication as RFCs.  So for instance, if a different well-recognized 
standards body wants to publish something as an RFC, I don't have a 
problem with that, as long as it's clearly labeled as being from that 
standards body.  Or if a WG specification doesn't manage to meet the 
requirements for standards track but the WG wants to publish that 
specification as an Informational RFC, as a record of the work that was 
done in case the problems can be solved in the future, I don't have a 
problem with that either, as long as it's clearly marked and the 
identified problems are also mentioned in the document.
What I have a problem with is individuals demanding the right to have 
their half-baked specifications published as RFCs, and for the RFC 
Editor to publish those documents as RFCs without public review, or (as 
has happened in the past) even when substantial oversights or design 
flaws in those specifications have been pointed out to the RFC Editor.
>   My sense is almost exactly the opposite. The IESG is not omniscient 
> and wouldn't be omniscient even if they had a lot more time.  The IETF 
> isn't omniscient either.
Nor, for that matter, is the RFC Editor.  But IESG is IMHO much more 
likely to catch problems in an individual submission than the RFC 
Editor.  And unlike RFC Editor decisions, IESG decisions can be 
appealed.
> IMO, one of the most valuable types of documents the RFC Editor could 
> publish would be an independent, in-depth analysis of why some 
> standards-track document was an operational hazard and generally a 
> complete crock of excrement.  Now I would expect that a very high 
> editorial and technical standard would be applied to the arguments of 
> such a document.  I would expect it to be excruciatingly clear that 
> the positions it was taking were in disagreement with an IETF 
> Standards-Track procedure.  But I would hope it would be publishable, 
> and, given those document quality standards, published, even if every 
> single member of the IESG disagreed with its stated position.
I don't have an inherent problem with that either.  However I haven't 
seen any defined "very high editorial and technical standard" for such 
documents, which makes me wonder if this amounts to the whim of the RFC 
Editor.  I think we're long past the day when any two or three people, 
no matter how intelligent or experienced, can profess to understand 
Internet protocols in enough breadth to be the sole judge of what 
should merit publication on behalf of IETF.  And like it or not, if 
there is no other well-identified supporting consistency for an RFC, 
it's assumed by the public to have IETF backing.
> Clearly-stated dissent is not "harmful".   Indeed, I suggest that it 
> is healthy.  And the procedure you propose would tend to suppress such 
> dissent, no matter how well reasoned that dissent was.
Clearly-stated dissent is not harmful.  But inflating it to appear to 
have equal or near-equal standing with community consensus can be 
misleading.
I can think of a number of topics for which I'd like to get on a soap 
box and have my "clearly-stated dissent" published as RFCs:  scoped 
addressing, encoding routing policy in address bits, and 
autoconfiguration systems being a few of the "interesting" and timely 
topics that come to mind.  However I don't think I have the right to 
demand that the RFC Editor provide, and ISOC fund, a soap box that 
appears to give my personal opinion near-equal weight to the consensus 
of IETF.  And I don't think it scales very well.
OTOH, I would certainly like to see a process that allowed 
"well-supported minority opinions" to get some recognition.
> Instead, we use the notion of "rough consensus" to essentially run 
> over dissent by small minorities, even small minority dissent that is 
> well-reasoned and has significant merit.  And our appeals is useless 
> in dealing with that issue because the "rough consensus" really does 
> exist.  And that makes the ability for the dissenters to write a 
> dissent, and have it published in near proximity to the 
> official/standard specification, really important to preserving the 
> openness and honesty of the system. Without it, all sorts of theories 
> about cabals become very plausible.
> Now we haven't used that mechanism very much.   In my personal 
> opinion, we haven't used it nearly often enough -- especially in the 
> last several years, the losing dissenters have tended to just go away 
> rather than documenting their positions --but that is another issue.  
> But taking it away, which I think your suggestion would ultimately do, 
> could ultimately be extremely harmful to our standardization model.
My opinion is that if we're going to pretend to have such a mechanism, 
we need to actually define it - establish publication criteria and the 
procedure for requesting publication and set up a vetting process that 
can hope to scale.  I don't think saying "whatever the RFC Editor 
wants" is a good way to do this.
Keith