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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
IAOC mailing list
IAOC@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/iaoc
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf