ietf
[Top] [All Lists]

Re: RFC Editor RFP Review Request

2006-07-25 16:43:14
John it may be that RFC Editor is a role description rather than a Term or
Art or controlled function or service mark. If this is true, then they the
IETF could easily seek a new candidate to serve as the Editor of RFC's.

Todd
----- Original Message ----- 
From: "John C Klensin" <john-ietf(_at_)jck(_dot_)com>
To: "Jeffrey Hutzelman" <jhutz(_at_)cmu(_dot_)edu>; "Allison Mankin" 
<mankin(_at_)psg(_dot_)com>;
"IETF Administrative Director" <iad(_at_)ietf(_dot_)org>
Cc: <iaoc(_at_)ietf(_dot_)org>; <ietf(_at_)ietf(_dot_)org>
Sent: Tuesday, July 25, 2006 4:25 PM
Subject: Re: RFC Editor RFP Review Request


--On Tuesday, 25 July, 2006 17:59 -0400 Jeffrey Hutzelman
<jhutz(_at_)cmu(_dot_)edu> wrote:

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.

And wrong in both cases; I just hadn't gotten that far in my
reading.

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

I agree with all but the last.  See below.

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.

See below.

 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.

I suppose this means we need to take a serious peek into the can
of worms Leslie has suggested (I believe correctly) that we not
open.

Before going further, let me try to repeat and clarify something
that several others have said in different contexts.

Let's assume I invite you out to lunch.   By virtue of doing so,
I have the "right" to pick the place and even the menu, although
you certainly can decline the invitation or even offer to pay
for your own lunch if you don't like my conditions.  Assuming
you eat the meal, I do not thereby acquire either the right to
establish restrictions on your diet for the rest of your life,
nor do I acquire the right to transfer the name "Jeffrey
Hulzelman" to someone else whom I might want to buy lunch for
next week, instead of you.  In particular, if I make a statement
that I am going to take Jeffrey Hulzelman to lunch every week,
and you decide you don't want to come any more (or I decide you
aren't a good lunch companion) either I need to find someone
else of the same name or I need to adjust my statement: the
option of finding an interesting person and assigning your name
to him is not something I can plausibly do.

Now the RFC Editor is an established, historical, function and
entity.  The existence of that function predates the membership
of the current team at ISI.  It also predates ISI and arguably
predates Jon Postel's involvement.   The IAB and then the IETF
concluded that it should publish its standards and related
documents as part of the RFC series.  The RFC Editor agreed to
that presumably because doing so seemed to be in the best
interest of the Internet.  After Govt funding for the RFC Editor
function ended, ISOC picked up responsibility for supporting the
_entire_ RFC Editor function, including, but not limited to, the
IETF-related document stream.

ISOC didn't need to do that.  Either the IETF or the RFC Editor
could, at any point, have discontinued use of the RFC series for
future IETF documents.   The IETF could, at any point, have
imposed conditions on the publication of its documents with the
understanding that the RFC Editor could either accept those
conditions or not publish IETF documents any more.   And, if the
RFC Editor decided to stop publishing IETF documents, the IETF
powers that be could have tried to persuade the ISOC powers that
be to withdraw the funding, which would leave the RFC Editor in
search of funds to publish _non-IETF_ documents.  We haven't
tried to pay that scenario out and, more important to the
current thread, the RFC Editor never sold its name or identity
to ISOC (or the IETF) in return for the ISOC support.

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.

Absolutely.  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...".

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


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