On Tuesday, July 25, 2006 04:24:01 PM -0400 John C Klensin
<john-ietf@xxxxxxx> wrote:
So I'd like to suggest that 2.e be changed a little bit:
OLD:
Submit document to IESG for review of
conflicts or confusion with IETF process, end runs around
working group activities, and obvious and significant
harm to the Internet
NEW:
As required by RFC 2026, submit document to IESG for
review of conflicts or confusion with IETF process, end
runs around working group activities, and obvious and
significant harm to the Internet
This change is counter to RFC 3932, which is claimed to have
removed "harm" from the things that the IESG will consider.
Reinstating that criterion in this RFP seems completely
inappropriate.
While I'm not sure I entirely agree with the complete removal of "harm to
the Internet" as something the IESG will consider, RFC3932 does in fact do
that, and I agree it would be inappropriate to reintroduce it here.
However, I should point out that that's not the effect of the proposed
change - the language about "harm" was already in there.
I would suggest that neither this RFP nor any eventual contract for the
RFC-Editor function should specify exactly what the IESG will or will not
review for. Instead, it should spell out what rights and responsibilities
the various entities have; specifically
- the responsibility to send the document to the IESG for review
- the responsibility of the IESG to respond within a particular time
- the right of the RFC-Editor to publish
- the right of the IESG to require inclusion of an IESG note
h. Coordination with Other Document Streams
1) Coordination with and prioritization of other document
streams is the prerogative of the IAB
I'm assuming that h.1 is not intended to cover the document
differentiation issue, but in any event, it would not do it
well. The IESG and the BCP-approving community hasn't
finished discussing (by approving a changed BCP) a view that
the IAB is now arbiter of the IETF's public messaging on
independent RFCs.
Nor has the broader community agreed that the IESG (which is
more or less the same entity as the "BCP-approving community)
has the authority to do this.
I think "BCP-approving community" was intended to include the IETF as a
whole. Without making any comment on who has the power to do what, it
seems prudent for the RFP to avoid painting itself into a corner.
Due to independent RFC's potential close
involvement with working group RFCs, there are reasons for WG
folks to really think about this. I don't think there's any
intention to affect a standards-related issue by placing
language in the RFP/contract, but we should really watch that
we do not.
But, if parts of this RFP evolve to assert that the RFC Editor
function is under IESG control for non-IETF documents, or that
the IESG can set rules for how non-IETF documents are handled
without the consent of the RFC Editor, then we have a problem.
Why? If ISOC is funding this thing, then it gets to have some say in its
operation. Exactly how much autonomy the RFC-Editor has and in what areas
is ultimately a matter for mutual agreement between ISOC and whoever ends
up providing that function. The vehicle for expression of that agreement
is a contract, and the RFP is nothing more than a means for finding people
who might be interested in such a contract. The question of whether it's
the IESG or the IAB or some other group that gets to set the rules for
publication is effectively just determining who will drive ISOC's decisions
regarding the functioning of the RFC-Editor, once an agreement is in place.
Now, you might argue that the RFC-Editor should have some level of
authority to publish documents on its own, or to make rules about how
document publication should work, or to be consulted in the making of those
rules, and I might even agree with you. But if the IETF decides it doesn't
want that, I don't see how that is a problem -- a relationship in which I
pay you to perform some service in the way I specify, and not in some other
way, is perfectly normal.
You might also argue that even if ISOC gets some say in how the RFC-Editor
function is performed as long as it is funding it, and has the right to
stop funding it, ISOC (and by extension, the IETF) doesn't have the right
to hire someone else to be "RFC-Editor". If I understand correctly, this
is the question you don't want to put in the critical path of this RFP.
Unfortunately, I think this is something that must be resolved before the
process goes too far. I'd hate to see people's decisions affected by
concerns over what might happen if ISI doesn't get the contract.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@xxxxxxx>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf