Hi. I sent in some comments a while back and they sparked a lively
discussion. However I don't think I made the point I was trying to
make successfully and think because of lack of clarity on my part my
point came out much more controversial than I had hoped.
So, here's try #2.
First, I understand there is a consensus that some rfc-editor streams
are broader than the IETF and that we need to get community review
broader than the IETF when making decisions about those streams. That
seems fine to me; I personally think in practice it will be rare that
the IETF and this broader community will disagree, but I understand
the concern.
I'm not trying to object to that.
I caution the IAB to make sure that it does not get deadlocked trying
to find out how to approach this broader community. It would be
unfortunate if in an attempt to get broad review we got no review at
all or review by a very small community. I think that is a real
concern, but one the IAB is well equipped to handle.
I also understand there is a long recorded history of interactions
with the RFC editor. (There is an even longer oral tradition, but I
trust that we all see the undesirability of making governance
decisions about a million dollar/year organization based on oral
tradition.) We need to respect that history. We also need to realize
that one of the explicit goals of the adminrest process is to
formalize and clarify relationships and avoid the need for us to
consult this history to find out how things work. Quoting section
3.1.3 of RFC 3716:
However, the very clear requirement is for clarity in the
distribution of rights, responsibilities, and accountability
in those relationships. The usual mechanism for documenting
such clarity is in contract form. Thus, the IETF needs to
have clear contractual relationships with the organizations
supporting basic services, including meeting organization,
secretarial services, IT services, etc.
The current effort to clarify the relationship with the rfc-editor
fits well within that goal.
However there are two important ways in which we have already finished
the process of clarifying roles and responsibilities.
First, we need look only as far as RFC 2850 to find the IAB's role
in managing the RFC editor:
(d) RFC Series and IANA
The RFC Editor executes editorial management and publication
of the IETF "Request for Comment" (RFC) document series, which
is the permanent document repository of the IETF. The RFC
series constitutes the archival publication channel for
Internet Standards and for other contributions by the Internet
research and engineering community. RFCs are available free of
charge to anyone via the Internet. The IAB must approve the
appointment of an organization to act as RFC Editor and the
general policy followed by the RFC Editor.
Second, we need only look to RFC 4071 to find IASA's role in the
administrative and budget aspects of the RFC editor:
The IETF Administrative Support Activity (IASA) provides the
administrative structure required to support the IETF standards
process and to support the IETF's technical activities. As of
the time at which this document was written, this included the
work of IETF working groups, the IESG, the IAB, and the IRTF.
Should the IETF standards process at some future date come to
include other technical activities, the IAOC is responsible for
developing plans to provide administrative support for them.
Such support includes, as appropriate, undertaking or
contracting for the work described in [RFC3716], including IETF
document and data management, IETF meetings, and any operational
agreements or contracts with the RFC Editor and the Internet
Assigned Numbers Authority (IANA). The IASA is also ultimately
responsible for the financial activities
RFC 4071 makes it clear that the IAOC is charged with preparing a
budget that meets the IETF community's administrative needs; it is
clear that the IASA is responsible for evaluating each function and
making sure that it meets a legitimate IETF administrative need. It
would be inappropriate for the IASA to fund a function that did not
fill such a role.
Just as the ISOC board of directors has reviewed the rfc editor
function in detail to confirm that money was being spent in accordance
with ISOC's charitable mission, IAOC can and should review the
rfc-editor function to make sure that it is meeting the IETF's
administrative needs.
Why do I mention these two areas where we have already clarified roles
and responsibilities? Well, I think the document does not accurately
reflect these clarifications in the following ways.
First, there is a duality associated with formally granting the IAB
authority through a charter: that authority can be removed or changed
through revision to the charter. Perhaps long ago, the IAB had a
historical grant of authority because they had always worked with the
rfc editor. Today, though, the IAB has a very real de-jure grant of
authority through RFC 2850. This document should make it clear that
the IETF, by revising that charter through the BCP process used to
create the charter, may reassign the management of the rfc editor to
another organization, provide limits or processes on the IAB's
authority, or otherwise affect management of the rfc editor function
in ways that materially influence the processes outlined in this
document.
Secondly, this document needs to make it clear that IASA has an
obligation to review the rfc editor function to make sure that it is
meeting the IETF's administrative needs. The IAB must work within
this review as it has worked within the ISOC board's review in the
past. Similarly, the IAOC must work within the IAB's role setting
general policy for the rfc editor. The IAB's decisions to create new
streams or to change existing streams in a manner that increases
budget requirements are subject to the IAOC's prioritization of
funding.
--Sam
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf