The only way I can see to reduce the AD time requirement is to reduce the number of documents going through the IESG.
I made a proposal in RFC++ that would reduce the number of less important documents going through the IESG. While this is not guaranteed to reduce the number of documents going through the IESG, it should mean the IESG was working on things that are more important.
As the RFC series morphed into the IETF documents of record, Internet Drafts were introduced to fill the purpose originally conceived for RFCs, that is a series of documents soliciting comment from the community. Until relatively recently, Internet Drafts were deleted from the IETF servers after six months. Now they are available 'permanently'.
What I propose is to introduce a new status for Internet Drafts which I am calling Internet Documents (but I am not attached to that or any other name).
An Internet Document is an Internet Draft that the author has declared to be fixed and will not be revised further.
For example, having developed draft-hallambaker-jsonbcd-13 to its current state, I might decide it is ready to declare this a fixed document that others can reference. Once fixed it becomes document-hallambaker-jsonbcd
Once fixed, an Internet Document is immutable. Like an RFC, it can be superseded but cannot be changed. So if I think I am going to need some sort of versioning, I should call the draft
draft-hallambaker-jsonbcd-v1-13 so the document is document-hallambaker-jsonbcd-v1.
The applications I see for Internet Documents that are not currently addressed by drafts include:
* Specifying a protocol, document format, etc. for the purpose of assigning code points.
* Describing any form of cryptographic algorithm that is not the result of an exhaustive competitive review by the IRTF or other sanctioned body.
* Describing legacy protocols and formats that are not otherwise documented.
* Most non-IRTF protocols that are currently marked as 'experimental'.
* Application layer protocols being developed outside IETF by organizations ranging from ad-hoc collections of folk who bang out an application in a crazed whiteboard session to formal organizations that prefer not to publish their own document series.
The IETF is a finite organization that must by necessity focus its attention on the issues that are close to the 'narrow waist' of the Internet architecture. There is simply not enough bandwidth in the IETF to catalog all the application layer protocols that are in use today let alone lead their design. All that the IETF can hope to do is to present what it considers to be a sound engineering approach and hope that others will follow it. And even to succeed at that game it would be best to work by observing and codifying existing practice.
The Internet is now a large place with approaching five billion users. The first rule of the Internet is now that 'you are not in control' for all values of 'you'. Designing a computer network that governments cannot control necessarily means giving up control ourselves.
The proposal I am making requires the IESG to give up a certain degree of formal control over issues that do not matter in return for engaging a much wider group in some degree of IETF participation.
While there is a risk that some people may start referring to Internet Documents as standards and referring to them in purchasing requests and such, I do not see that as a problem. I see it as a sign of success.
PHB
