Sam,
Some high-level responses, and I'm sure we'll hear other
input:
1/ I think you're overlooking something in "IETF pays for RFC
Editor"; RFC Editor has been paid by ISOC for years, and *that*
largely comes out of contributions from corporations. We actually
have no data beyond the fact that they support the RFC Editor
as currently constituted (i.e., including independent submissions).
We've already heard (in IETF discussion in March) input that
no in fact the IETF does not get to define the *in*dependent
submission process; one purpose of the planned discussion is
to ensure that the process is not at odds with the IETF's
standards needs, but that is very different than having the
IETF define it, as you describe.
2/ Termination of any contract is always going to be based on
terms in said contract. I assume ISOC BoT wouldn't approve
something that leaves them with dangerous exposure; that's
what they do.
This document is aiming to capture the principle of the
IAB's responsibility; the counter example is not
right, either (the IASA giving the IAB/IETF the news that
there is a new RFC Editor in town).
3/ Re. approval of ISOC BoT/IASA for creation of new streams: we
need to be careful with terminology. The IASA exists to implement
adminstrative support to meet the needs of the IETF & IAB & IRTFs
needs.
Leslie.
Sam Hartman 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.
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.
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.
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.
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.
--Sam
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf