Previously, someone wrote:
I finished reading the RFC editor document and have one major concern.
Ultimately, the rfc-editor function needs to be accountable to the
IETF community because we're the ones paying for it.
Incorrect. As I pointed out some weeks ago, and Leslie has
recently repeated, IETF has never paid for the RFC-Editor.
Historically, RFC-Editor was created by (D)ARPA and paid by
(D)ARPA. More recently, some large commercial firms have
donated substantial funds to ISOC -- with the understanding
that the RFC-Editor would be among the functions paid for
from those funds. 
In particular I believe that the IETF should be able to pass a BCP
placing requirements on an rfc-editor stream. We've done this with
RFC 3932 for example, and I think that was a good thing.
In effect, community consensus within the IETF should trump anything
It has NOT been the case in the past that IETF was the community
in control of RFC-Editor. In fact, that would represent a major,
and in many people's view highly undesirable, change.
Historically, RFC-Editor has served the broader Internet community,
including but not limited to the IETF. In fact, the RFC-Editor
has existed since the late 1960s, yet the IETF did not even exist
until the middle 1980s.
Now, we need to be careful about how to use that consensus. Several
RFC streams serve communities broader than the IETF. Unless we have
good reason to do so, we should not step on those communities by
overriding their requirements.
Indeed, it would be a gross assumption of non-existent authority
for the IETF to over-ride the broader Internet community. In
the narrow situation of preserving the integrity of the standards
process, existing procedures ensure that the standards process
is not bypassed by some 3rd party. There is not a problem here,
nor a reason for IETF to shut down the very important non-IETF
uses of the RFC publication process.
Despite the best efforts of new technologies (e.g. combining
Google Scholar and institutional technical reports), there are
still numerous RFCs each year that are not published by IETF
and yet are important for the broader Internet community
(which by definition includes, but is not limited to, the IETF).
There are roughly 3 categories of such documents:
- independent submissions to the RFC Editor relating
to technology, research, or other (non-standards) issues.
- IRTF submissions to the RFC Editor
(as a reminder to newcomers, the IRTF also reports
to the IAB, NOT to the IETF).
- publications by IAB or ISOC
All 3 of those categories are important. Generally speaking,
none of those categories are within the purview of the IESG
or the IETF -- and NEVER have been historically (with the
narrow and important exception, both historically and now,
that the IESG has a chance to object to publication of
something that is trying to make an "end run" around
the IETF standards process).
My long-standing personal hope is that the IRTF would have
its own document describing its own processes for submission,
review, and approval of IRTF documents -- rather than treating
IRTF documents as individual submissions as has been done
historically. In the extremely unlikely case that the IESG
would try to object to publication of some IRTF document,
I would think it VERY important that the IRTF document get
published -- in the interest of intellectual integrity and
I also have specific concerns about how this document interacts with
the IAOC and IASA.
1) The document gives the IAB the authority to terminate the
rfc-editor contract. Depending on when we do that, there may be
significant budget impacts and it may not be consistent with
ISOC's carrying out its financial responsibilities to terminate
the rfc-editor contract at an arbitrary point in time.
The RFC Editor has reported to the IAB since about 1992 -- this
was documented (if I recall correctly) in the revised process
RFCs after the Cambridge Tea Party. The RFC-Editor normally
has a liaison attending IAB meetings, for example. The choice of IAB
was very deliberate -- to ensure that the RFC-Editor did NOT
become limited in scope to just the IETF or to IETF-related
It is not an accident that the ISOC BoT are the ones who have
to approve or disapprove appointments to the IAB. The IAB and
ISOC are connected and have worked well together over the past
So a better way to think about this is that ISOC has been paying
for the RFC-Editor for years, with IAB as ISOC's manager for that
function. This is remaining the case. IAB is connected to ISOC,
so there is no real danger that IAB would get out of sync with ISOC.
The RFC Editor has *never* reported to the IESG or IETF,
though RFC-Editor has done a good job of coordinating with IESG
and ensuring that IETF's interests were properly looked
after. There is no real danger that this would change.
2) The document allows the IAB to create new streams of rfcs on its
own authority. It seems that we need ISOC and IAOC approval at
least on the budget question to do so.
The IAB has had this authority at least since circa 1992
(the reorganisation after the Cambridge Tea Party). This
is not a new situation. Further, IAB has shown that it is
responsible in this regard -- nothing silly has happened
in this area. So there is no change here -- and no real
cause for concern or anxiety.
The main conclusion that I draw from this thread so far is
that the we all need to do a better job of explaining how
things are currently organised to newcomers -- along with
enough of the history that people don't end up with
misunderstandings of how we got where we are organisationally.
(And I am a relative newcomer here myself, having only
participated since around 1990; a number of folks still in
IETF go back to the days of NCP, before IPv4 even :-)
Finally, I don't particularly care to get caught up in any
quagmire that might erupt, so I don't intend to post further
on this thread. Lack of response by me to other notes does
not imply that I agree with -- or disagree with -- whatever
those notes might claim.
(former IAB member)
 Several IAB members, including me, were told this directly
in plain language by representatives of at least 2 large firms
(during the time I was serving on IAB).
Disclaimer: I am not speaking for my employer in this note.
Ietf mailing list