Ran,
RJ Atkinson wrote:
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. [1]
I would like to suggest a qualification to this. Things have changed
over time. When DARPA stopped funding ISI to perform the RFC Editor
function, ISOC stepped in to fill the gap. Subsequently, ISOC also
provided a discretionary fund for the IETF Chair, and extended its
liability insurance to cover the IETF leadership. (At some point,
the discretionary fund was split between the IETF Chair and the IAB
Chair.) In 2000/2001, ISOC consolidated these expenditures in its
"standards pillar" accounting. Subsequently, and most recently, ISOC
agreed to host IASA, which is now the funding agency for all of the
above plus meeting expenses and the Secretariat. So whatever the
historical situation, the *current* situation is that a single budget
is fed by ISOC member contributions, ISOC donations, and IETF attendance
fees, and the RFC Editor contract is just one item in that budget.
This doesn't contradict Ran's statement of the history in the least.
With reference to Ran's note [1], my recollection of numerous
meetings of the ISOC Advisory Council of organizational members
is that representatives there consistently stated support of the
"standards pillar" as their primary motivation for supporting
ISOC. Of course they knew that historically the bulk of the money
in that pillar was going to support the RFC publication process,
prior to the creation of IASA.
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
else.
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.
Historically, yes. But I think we're discussing the future.
Nevertheless, I personally support the existence of an independent
submission mechanism, as part of a general pattern of checks and balances.
(See below.)
However, I'd like to ask for a definition of "the broader Internet
community." Since about 1995, the Internet has been a public access
network, so I could interpret the phrase as referring to several hundred
million people at this point. Since the IETF is open to all, I'm
puzzled how to draw a line around "the broader Internet community" that
is meaningfully different from the IETF/IRTF/IAB community but
less than the entire on-line population.
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).
I fully support this view.
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
openness.
See draft-irtf-rfcs-00.txt for the proposal along these lines.
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
documents.
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
10+ years.
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.
As noted above, that isn't quite accurate since IASA was created.
...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.
Additionally, the IAB is subject to a recall procedure initiated
within the IETF. So there is a mechanism for dealing with
silliness.
Brian
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.
Yours,
Ran
rja(_at_)extremenetworks(_dot_)com
(former IAB member)
[1] 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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf