Re: [IAOC] Re: RFC Editor RFP Review Request

Ted is correct. The "harm to the Internet" text is wrong -
it isn't mentioned on 2026 and it is excluded from consideration
by 3932 - but we shouldn't mix fixing that bug in the RFP
with fixing the procedural issues.

    Brian

Ted Hardie wrote:
> At 7:25 PM -0400 7/25/06, John C Klensin wrote:
>
> > And the IETF/IASA can issue an RFP for IETF
> > publications and publishing any time it likes, specifying
> > whatever conditions it likes.  _That_ is perfectly normal.  It
> > can even try to specify what other activities an entity that
> > responds to the RFP may or may not engage in.  That would likely
> > be stupid, since it would probably reduce the number of bidders
> > and increase costs, but nothing prevents "the IETF" from doing
> > so.
> >
> > What it cannot do is to assume it has the right to impose those
> > requirements on the RFC Editor and that, if the RFC Editor
> > doesn't agree, the IETF's remedies extend beyond taking its
> > publication business elsewhere.  Absent figuring out who or what
> > the term "RFC Editor" belongs to (I don't know whether it is
> > ISI, but is certainly is not the IETF unless I get to transfer
> > your name after buying you lunch), the RFP should be titled
> > something more like "... for services currently performed by the
> > RFC Editor...".
>
> John,
>         Leaving aside all of the naming issues, I believe the point
> that is being missed is that ISOC, through this IASA process, intends
> to fund two things:  an "IETF" stream of documents and an "independent"
> stream.  It can put conditions on the "independent" stream solely because it
> will pay  for the publication of that stream.  As you point out, that has
> nothing to do with any publication work done for anyone else by the respondents;
> it simply means that for the "independent" stream paid for
> by ISOC, a particular set of processes are being put forward to ensure
> that they relate to the "IETF" stream (or don't relate to it) in particular 
> ways.
>         I would appreciate it if we kept that point, and what the "particular
> set of processes" should be, separate from the naming issue.  The worms
> in one can need not interbreed with the worms in the other.
>                         thanks,
>                                 Ted Hardie
>                 
>
>
>
>
>
>
>
>
>
>
>
>
> > I continue to hope and believe that, if the RFP and award
> > process is obviously fair, in the best interests of the Internet
> > community ISI will consent to the release of any rights they
> > might have to the "RFC Editor" terminology and materials to
> > whatever entity the IASA decides to designate.   But at least
> > some of us believe that making the approval process or content
> > of RFCs that do not arise from IETF processes subsidiary to the
> > IESG would not be in the best interests of the Internet
> > community.  Were the RFP to go out with such a requirement, and
> > were USC to agree with that conclusion about the best interests
> > of the community, things could get rather strange.
> >
> >
> > > 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". 
> > That is correct.
> >
> >
> > > 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.
> > So would I.  For just this reason, I have repeatedly tried to
> > suggest that the RFP should specify a series of functions to be
> > performed, rather than the name to be given to the entity that
> > performs it, but those suggestions haven't gone anywhere and the
> > process has probably already gone too far.
> >
> > Were that change made, I would still argue that there should be
> > an independent submission model and that ISOC (IASA, IETF) still
> > should not assert IESG control over it and should not permit
> > IESG to insert required text into independent submissions that
> > was not true and/or exceeded the IESG's knowledge and quality of
> > review.  But that discussion at least would not get tied up with
> > the concept of the RFC Editor and its role.
> >
> >  john
> >
> >
> >
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf(_at_)ietf(_dot_)org
> > https://www1.ietf.org/mailman/listinfo/ietf
>
>
> _______________________________________________
> IAOC mailing list
> IAOC(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/iaoc
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf