Because of the RFC-2188 experience and other interactions that I have had with the IESG and the RFC-Editor, I have some suggestions for improving the non IETF Informational RFC publication process and practice.
The IESG is a hand-full of volunteer engineers with a fancy group name. Based on my interactions with them, I have concluded that they hardly reach the "average" level of competence in my book - both in their technical and in their management abilities. The IESG often has little relevant experience and knowledge in the specialized subject matter of the RFCs that it needs to review.
Instead of functioning in its limited co-ordination and conflict detector role as defined in section 4.2.3, in practice the IESG has already expanded its own role and has assumed ultimate authority over publication/non-publication of non IETF originated Informational RFCs.
The IESG should not be permitted to engage in censorship or delay of publication of work coming from outside of IETF because they just don't like it, because they don't understand it, because they think that it may be competing with IETF/IESG work or because they think that it may be bad for the Internet.
Based on the case of RFC-2188, I have concluded that the IESG is out of control and irresponsible. It needs to be checked and managed.
In practice the role of the RFC Editor for documents coming from outside of the IETF/IESG/IAB has been reduced to that of a glorified clerk of the IESG.
If and when the IESG does not complete its review of the refered documents, it is the RESPONSIBILITY of the RFC Editor to go ahead and publish the document. The RFC Editor should not permit the IESG to introduce long delays in the publication of documents.
The RFC Editor should ensure that the IESG note going into an Informational RFC is in fact reasonable and correct and provide the author an opportunity to see the IESG note prior to publication.
The RFC Publication Service can benefit from additional resources. I am pretty sure that getting funding for such a critical service is not going to be difficult if we look at it the right way.
The spirit of sections 4.2.2 and 4.2.3 of BCP-9 is just right.
However, the case of RFC-2188 clearly shows that in practice the procedures of BCP-9 are not being followed.
We need to find a way to make sure that what BCP-9 says is in fact what happens.
Tighten BCP-9 to be more clear about minimum technical requirements for RFCs. Introduce an appeals process for when a document is rejected. More clearly define "timely"...
Provide mechanisms that safeguard against mistakes and negligence by the IESG or the RFC Editor.
Define specifically, what is supposed to happen when the IESG does not complete its limited review in a timely manner.
Re-orient everything towards responsibilities of the publication service providers instead of their authorities.
The RFC Editor task is primarily a Publication Service. The IETF/IESG/IAB is JUST one of the users/customers of the the RFC Publication Service.
There has been talk of putting the RFC Publication Service under management and funding of IETF/IESG/IAB/ISOC. That would be totally wrong.
There is an obvious inherent problem with allowing a common Publication Service to be managed and funded by one of its users. The problem is that IETF/IESG/IAB is likely to claim control over the entire RFC Publication Service and delay the publication or exclusion of protocols coming from outside of it and suppress standards competition even more.
Clear separation of powers is a good thing. It is a good way of introducing accountability and checks and balances.
A powerful and independent RFC Editor role which would oversee a fair and equitable RFC Publication service is ESSENTIAL for the Internet.
In practice, the RFC Editor role has been weakened over the years. We need to strengthen it.
Let's look at what needs to happen in the bigger picture. Standardization process iterates through 4 essentially distinct steps.
IETF/IESG are just one of the entities developing protocols. Many good protocols are developed by non-standards related entities.
A wide open, quick and fair publication service is needed to allow for anyone who wants to build or play with protocols to have access to its specification. The fundamental characteristics of the RFC Publication Service for the most part have been working real well. Any relevant protocol coming from essentially anywhere which meets a minimum technical and/or editorial standard should have speedy access to the RFC Publication Service.
If it is anything useful and is done right, it will be used. How it gets used is very important and unpredictable.
Some entity (e.g., IETF/IESG/IAB) blesses the protocol by putting some label on it. Although necessary, this function is mostly ceremonial. The real legitimacy comes from usage and the market place.
Without a question, IETF/IESG/IAB should play some role in step (1).
Without a question, IETF/IESG/IAB need to focus on step (4).
But, I am saying that putting step (2) under management and funding of IETF/IESG/IAB/ISOC is WRONG. Because it has the potential of further suppressing the results of step (1) coming from outside of IETF/IESG.
Note, that I don't have a problem with the spirit of the relationship between The RFC-Editor and IETF/IESG/IAB/ISOC as described in BCP-9. My point is that by making step (2) completely and truly independent of management and funding by IETF/IESG/IAB/ISOC, we will bring about the necessary checks and balances that are needed for a healthy overall process which needs to even encourage competition in step (1).