Re: RFC Editor RFP Review Request

On Tuesday, July 25, 2006 04:24:01 PM -0400 John C Klensin 
<john-ietf(_at_)jck(_dot_)com> 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+(_at_)cmu(_dot_)edu>
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf