Subject: Re: RFC Editor RFP Review Request

From: John C Klensin <[email-masked]>
Date: Tue, 25 Jul 2006 16:24:01 -0400

--On Tuesday, 25 July, 2006 12:08 -0700 Allison Mankin
<[email-masked]> wrote:

> Hi, Ray, and all,
> 
> I read the SOW earlier to check that it matched with the
> draft-mankin-pub-req-10 (output of techspec), but I've now
> given a read to other matters in the RFP.  
> 
> If anyone wants to discuss points from this mail other than
> those specifics to the RFP, I suppose we should do so on
> [email-masked].
> 
> 1. Some wording under Independent Submissions is still a bit 
>    confusing.  2.a. states the optional presentation of the
> document    to the IESG for end-run evaluation while it is in
> the RFC Editor's    initial review.  2.e states the mandatory
> presentation which is    called for by RFC 2026.  2.a says see
> 2.e.  In a non-sequential    reading, which is possible, 2.e
> does not sound mandatory.  But it    is firmly required by RFC
> 2026.
> 
>    [And while I have this topic:  this is not because of power
>     projection for anyone, but because the WGs' labors are
> heavily     invested in RFCs as an end-product, and their
> charters and work     need to be consulted by their AD]
> 
>    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.

> 2.
>>    g. Final Editing and Publication 
>>       1) Edit and publish as for IETF community documents
> 
> This publication process is not identical to IETF community
> documents.  IETF has a BCP (3932) which currently specifies
> differences, but we're in some debate now (expressed during
> the Thursday plenary in Montreal) about its full applicability
> to the independent submissions.  There should be some
> statement in the SOW about how the differences, such as a
> boilerplate stating the nature of the independent submissions,
> or a specific type of identifier within the RFC series, will
> be further resolved.  How about wording like:
> 
> NEW:
>        1) Edit and publish with the same steps as IETF
> community           documents but with clear indications that
> these belong to           an independent series.  Specifics of
> these indications will           be authorized by the
> appropriate IETF community parties.

I agree there is a problem, but this appears to be the wrong
solution.  See below.

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

>  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.
 
The comments about focus in on an aspect of this situation that
has been extensively discussed in several forums recently and
that many of us had hoped to avoid confronting in the interest
of getting this RFP out.   The current text pushes very close
to, if not past, the line that would require confronting the
issue; the text about definitely does.

To try to briefly summarize that issue, there are two theories
about the existence and role of the RFC Editor.  One is that it
is a creature of the IETF (and/or IAB), to be redefined,
retasked, and reallocated at the whim of the IETF and its
management bodies.  Whatever the IESG says the RFC Editor should
do, the RFC Editor must do.   The other is that the RFC Editor
function existed long before there was an IETF and that, while
it is the traditional publisher of IETF-generated materials,
either party can change that relationship at any time (for
documents going forward -- the status of IETF-related documents
produced before a hypothetical changeover is ambiguous and the
IETF fairly clearly has no claim to Internet Standards produced
in the pre-IETF period).

While, again, I prefer that we not need to address the problem
now, I personally do not consider the first position sustainable
and believe it has implications that, if pressed to a
conclusion, will not make the IETF community happy.

As I have said many times before, it is my expectation that
whomever is acting as RFC Editor will try to do its work with
the best interests of the Internet Community as a major goal.
Doing so not only means agreeing to publish IETF documents as
long as the IETF wants that to happen, but working cooperatively
with the IETF and its leadership to avoid confusion among
documents produced in different ways but published under the
"RFC" label and, if necessary, to give IETF documents
appropriate priority.  I believe it is reasonable to build that
expectation into the RFP and make it explicit.

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.
In the most extreme version of that problem, the draft RFP is
complete nonsense:  were I ISI, I would argue that 30-odd years
of publication history has turned "RFC Editor" into an
unregistered, but still established, trademark of ISI or USC
which IASA and ISOC not in a position to rebid or reallocate.
Being less reasonable than our colleagues at ISI, I would
probably take up a small collection, find myself a judge, and
seek an injunction against ISOC's issuing this thing.

I note in this context that IESG (or even IAB or IASA)
assertions about what they are in control of don't count for
much unless the RFC Editor agrees: I can stand on any street
corner, proclaim myself king of all I survey and start giving
people orders but, unless I can back it up with either legal
authority or an army, I'm much more likely to end up in
psychiatric care than widely recognized as sovereign.  The fact
that, in the interest of the Internet community and perhaps of
continued funding from certain sources, the RFC Editor has, in
the past, decided to go along with such statements and posturing
does not imply blank-check agreement to do so in the future.

If we are to move forward without having to first resolve the
historical and control relationships, the RFP needs to be
respectful of the RFC Editor function and of the needs of the
Internet community outside the IETF.  It needs to promote a
cooperative and mutually respectful relationship between the
IETF (and its leadership) and the RFC Editor, especially with
regard to documents that originate outside the IETF and that are
not processed through the IETF (other than via a mutually-agreed
IESG courtesy check for confusion and efforts to prevent
confusion of all forms).   Or the RFP needs to go back for a
relatively comprehensive revision, starting with retitling it
to, perhaps, "IETF Publication Function Request for Proposal".
Perhaps the current RFC Editor organization would choose to
write a proposal to supply that function.  I would hope that, if
the IASA decided to overconstrain how they handled independent
submissions, they would not do so, just as I would expect that
they would not submit a proposal against an RFP that required
IESG review and approval of ISI's research agenda to assure
consistency with IETF standards.

As part of the cooperative spirit and best interests of the
Internet attitude that I'm encouraging, I would assume that, if
a better arrangement could be found to perform the RFC Editor
function with compatible tasks and rules, ISI would be willing
to sign over any rights they have to the name, service, and
publication series.  After all, the RFC Editor function didn't
originate there either.  But, to the degree that this RFP, or
any other mechanism, proposes to change the historical
relationships and turn the RFC Editor function into something
that operates only as an IETF/IASA subcontractor, subject
exclusively to IASA management, I would expect --and hope-- that
they would be quite resistant to the idea.

      john

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 25 Jul 2006 17:59:46 -0400

> Reinstating that criterion in this RFP seems completely

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

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

> 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) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: John C Klensin <[email-masked]>
Date: Tue, 25 Jul 2006 19:25:59 -0400

--On Tuesday, 25 July, 2006 17:59 -0400 Jeffrey Hutzelman
<[email-masked]> wrote:

>>>      conflicts or confusion with IETF process, end runs
>>>      around working      group activities, and obvious and
> 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
> 

I agree with all but the last.  See below.
 
> 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.

> 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

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

---

From: "todd glassey" <[email-masked]>
Date: Tue, 25 Jul 2006 16:42:54 -0700

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" <[email-masked]>
To: "Jeffrey Hutzelman" <[email-masked]>; "Allison Mankin" <[email-masked]>;
"IETF Administrative Director" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 25, 2006 4:25 PM
Subject: Re: RFC Editor RFP Review Request

---

From: Ted Hardie <[email-masked]>
Date: Tue, 25 Jul 2006 16:49:41 -0700

At 7:25 PM -0400 7/25/06, John C Klensin wrote:
> And the IETF/IASA can issue an RFP for IETF

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 awaFrom [email-masked] Tue Jul 25 19:52:37 2006
Date: Tue, 25 Jul 2006 16:49:41 -0700
To: John C Klensin <[email-masked]>, Jeffrey Hutzelman <[email-masked]>,
	Allison Mankin <[email-masked]>,
	IETF Administrative Director <[email-masked]>
From: Ted Hardie <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: RFC Editor RFP Review Request

At 7:25 PM -0400 7/25/06, John C Klensin wrote:
> And the IETF/IASA can issue an RFP for IETF

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 25 Jul 2006 20:09:24 -0400

> I agree with all but the last.  See below.

Sorry; I know that's a contentious issue, and I didn't mean to imply a 
position.  If the IESG is going to have such a right, it needs to be 
spelled out in the agreement with whoever becomes RFC-Editor.  If not, not.

> publication business elsewhere.

Whether it has this right...

> Absent figuring out who or what
> the term "RFC Editor" belongs to

Depends on the answer to this.

I agree that things would be simpler if we could come up with a way to do 
things that didn't require figuring out the answer.  Unfortunately, I'm not 
convinced we can.  Before I go any further, let me point out that I have no 
reason to believe that ISI will act other than in good faith and in 
accordance with the best interests of the Internet.  However, contracts are 
about what happens when someone you thought would act in good faith fails 
to do so.

The problem is that the point of this process seems to be to provide a 
certain amount of accountability.  I'm not talking about the independent 
submission stream, but about basic things like publishing documents in a 
timely manner, emitting documents that look like they were written by a 
competent writer instead of a six-year-old or an engineer, and being 
responsive to the needs of the community.  The way you provide 
accountabiltiy for things like that is by writing those requirements into 
the contract, and providing remedies if they are not met.  For an ongoing 
relationship like the one we're discussing, a key requirement is the 
ability to take your business elsewhere.

Unfortunately, the instant we try to take our business elsewhere, the 
question above surfaces.  If we don't know who owns the term "RFC Editor", 
and more importantly, the "RFC series", then there is a _huge_ burden 
associated with taking our business elsewhere.  We already have the problem 
that people think that anything that's an RFC is an Internet Standard.  Can 
you imagine trying to convince someone that something is an Internet 
Standard that's _not_ an RFC?

Because of that, I think we need to know the answer before the first time 
we might have to whether to find another supplier.  How can we possibly 
make such a decision if we don't know how much it will cost?

> whatever entity the IASA decides to designate.

So do I, to a point.  I would actually be happy to see those rights clearly 
in the hands of the Internet Society; in fact, I think such a thing would 
probably be in the best interest of the Internet.

> But at least
> community.

I'm not sure yet what my position is on that question; there are valid 
arguments on both sides.  However, I don't think this question needs to be 
resolved in order to put out an RFP, because I don't think the RFP should 
have that level of detail.  I believe that was one of Leslie's original 
points - there is no need to name a particular entity, especially when it 
might be changing.

-- Jeff

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Jul 2006 13:18:32 +0200

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:
> IAOC mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/iaoc
>

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 26 Jul 2006 08:56:49 -0400

Actually:

	. since the existence of the IASA (last year),
	  the ISOC BoT has been asked to support the RFC Editor
	  as part of what IASA supports -- IETF *and* IAB (and IRTF).

	. as part of the initial proposal of 2007 budget for IASA,
	  to the ISOC BoT, on July 1, 2006, it was proposed
	  this model continue.

I.e., ISOC is asked to support IASA.

IASA supports the IAB as well as the IETF.[*]

The IAB asks for support for the RFC Editor.

The IAB has been working through this year to formalize
a proposed framework for answering the questions of "who
controls what under which circumstances".  It started with
the proposed RFC Editor charter in March.  It is now a
14 page Internet-Draft (submitted to the repository yesterday;
should be out RSN:  draft-iab-rfc-editor-01 is the current
version).

[*] This is perhaps a reasonable time to reiterate that
the IAB is, in fact, a separate entity from the IETF organization.

Leslie.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 26 Jul 2006 09:30:53 -0700

>the IAB is, in fact, a separate entity from the IETF organization.

With respect, I believe that the formulation "separate entity"
is a bit too simple for the relationship of the IAB and the IETF.
The IAB is, to take a small example, composed of folks selected
by the NomCom, and NomCom eligibility is determined by participation
in the IETF.  The IETF and IAB also share confirmation duties for
a number of outside positions, where the IESG confirms choices
made by the IAB (and the IAB does the same for choices made by
the IESG).  More importantly for this question, the IAB  participates in the
IETF standards  process in the appeal chain, in discussions of new work, and
in managing the liaison relationships of the IETF.  Its roles and
relationships have changed over time, but 2850 says pretty clearly:

  "The IAB is chartered both as a committee of the IETF and as an
   advisory body of the Internet Society."

I think it would be clearer to say that the IAB has roles and responsibilities
beyond those which relate to the activities IETF.   Those activities
may be separate from the IETF (as the IRTF activities are), but that
does not mean it is separate from the IETF in all its roles.

			regards,
				Ted Hardie

---

From: John C Klensin <[email-masked]>
Date: Wed, 26 Jul 2006 12:49:27 -0400

--On Tuesday, 25 July, 2006 16:49 -0700 Ted Hardie
<[email-masked]> wrote:

>> 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,
> 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. 	

Ted,

Omitting the issues about IAB and IAOC relationships that have
been more than adequately covered by others...

I, too, would like to keep these worms independent.  However,
there is a point of interaction and it was an apparent step in
the direction of passing that point that caused me to write my
note. 

Things are getting a little too intertwined here, to the point
that I think we are having trouble keeping things separated that
ought to be separate.   During the IASA development process, it
was made very clear that, if ISOC did not follow IASA/IOAC
direction on IETF matters, we would "fire" ISOC.  We also
discussed all sorts of mechanisms to keep the IASA responsive to
the needs and desires of the IETF and picked a few of them.
Independently, we have many times observed situations in which
the IESG feels that it is justified making statements on behalf
of the IETF (for the record, I believe that for some, but not
all, of those situations the conclusion is reasonable).

Given those actual or imagined chains of authority, it doesn't
take very many steps to get to "the IESG can tell ISOC what to
write into and 'RFC Editor' RFP and can tell the IAOC how to
interpret that contract".  That is a problem because some of us
who believe in independent submissions believe that the first
and most important thing they should be independent of IESG
consensus.

If the IASA is going to issue an RFP that contains an
"independent submission" model that really is independent, i.e.,
along the lines outlined in draft-klensin-rfc-independent, then
I hope and trust that we will have no problem.  

At the other extreme, suppose that the IASA (or ISOC), at the
direction of :the IETF" (i.e., the IESG, with or without a
consensus call), issued an RFC that called for an "independent"
stream with conditions placed upon it that permitted the IESG,
without formally consulting the IETF community, to block or
indefinitely delay documents and mandate that any text it liked
was to be put in documents that were published.  There would
then be some question as to whether the entity for which the
ISOC was requesting bids could properly be known as "the RFC
Editor" and that might well raise the naming problem.   

Or there could be questions about whether ISOC was actually
acting in the best interests of the Internet Community -- their
BoT has responsibilities to communities other than IETF and
IASA.  Some of us might then feel that ISOC really should be
generating as issuing this RFP -- not on behalf of IASA, but on
behalf of the Internet Community, with the IASA requirements
governing the IETF (and, at the option of the IAB, the IAB and
IRTF) streams, but with the independent stream handled
separately and overseen by an ISOC-coordinated entity.

None of these are places I want to go.  They would be
inefficient and they would create additional distinctions that
would be hard to maintain without friction.  But the further the
folks who are convinced that "independent submission" really
means "as long as the IESG likes their content" or "second or
third-class citizens", the closer we get to the point at which
the naming issues and, more broadly, issues of authority to
issue the RFP at all, become relevant.

     john

---

From: John C Klensin <[email-masked]>
Date: Wed, 26 Jul 2006 14:23:11 -0400

--On Tuesday, 25 July, 2006 20:09 -0400 Jeffrey Hutzelman
<[email-masked]> wrote:

>...
>> of RFCs that do not arise from IETF processes subsidiary to
>> the IESG would not be in the best interests of the Internet
>> community.
> 
> I'm not sure yet what my position is on that question; there
> are valid arguments on both sides.  However, I don't think
> this question needs to be resolved in order to put out an RFP,
> because I don't think the RFP should have that level of
> detail.  I believe that was one of Leslie's original points -
> there is no need to name a particular entity, especially when
> it might be changing.

Then the RFP should be for "publications services for the IETF"
or "publications services for IASA" or "publications services
for ISOC". If the RFP is for "the RFC Editor" or "managing and
developing the RFC series", then either the document text has to
be much more neutral than it is now or we need to be reasonably
assured that the entity issuing the RFC has or can acquire the
standing to do so.

    john

---

From: Ted Hardie <[email-masked]>
Date: Wed, 26 Jul 2006 11:40:03 -0700

>and most important thing they should be independent of IESG

When RFC 3932 was written, I thought this sentence was
the "meat" of the issue:
  
    The new review model will have the IESG take responsibility
    ONLY for checking for conflicts between the work of the IETF and the
    documents submitted; soliciting technical review is deemed to be the
    responsibility of the RFC Editor.

For any independent review stream, I believe that the review by
the IESG is governed by this model.  If the IESG and a publisher of
an independent stream disagree about whether there is a conflict with
the work of the IETF, we could still have a problem, but I believe that
this division of responsibility is generally appropriate and has
community support.

>Editor" and that might well raise the naming problem.  

And here you've lost me.  Updating RFC 3932 would require
a new consensus call to the IETF, since it is a BCP.  I suppose
it could be argued that it applies only as long as the publisher
of the independent stream is called "the RFC Editor",
and an update to it if that name changes might be necessary.
But the IESG cannot change the rules by which it interacts
with the RFC Editor by RFP or SoW; it would have to get consensus
to do so from the IETF by publishing a new BCP.

I know of no interest in changing the current consensus and no
desire to publish a new BCP; I also don't think such a BCP would
get consensus.
			regards,
				Ted Hardie

---

From: John C Klensin <[email-masked]>
Date: Wed, 26 Jul 2006 15:28:24 -0400

--On Wednesday, 26 July, 2006 11:40 -0700 Ted Hardie
<[email-masked]> wrote:

>> interpret that contract".  That is a problem because some of
>> us who believe in independent submissions believe that the
>> first and most important thing they should be independent of
>> IESG consensus.
> 
>     ONLY for checking for conflicts between the work of the
> IETF and the     documents submitted; soliciting technical
> review is deemed to be the     responsibility of the RFC
> Editor.
> 
> the IESG is governed by this model.  If the IESG and a
> publisher of an independent stream disagree about whether
> there is a conflict with the work of the IETF, we could still
> have a problem, but I believe that this division of
> responsibility is generally appropriate and has community
> support.

I actually agree... and have never had any problem with that
statement in 3932.  But there are two issues here and this is
only one of them.

>> consensus call), issued an RFC that called for an
>> "independent" stream with conditions placed upon it that
>> permitted the IESG, without formally consulting the IETF
>> community, to block or indefinitely delay documents and
>> mandate that any text it liked was to be put in documents
>> that were published.  There would then be some question as to
>> whether the entity for which the ISOC was requesting bids
>> could properly be known as "the RFC Editor" and that might
>> well raise the naming problem.  
> 
> it could be argued that it applies only as long as the
> publisher of the independent stream is called "the RFC Editor",
> with the RFC Editor by RFP or SoW; it would have to get
> consensus to do so from the IETF by publishing a new BCP.

And this is at the heart of the other issue.  3932 appears to do
two things.  One is to define the role of the IESG in this
process and how that role is managed.  Clearly, it is within the
authority of the IETF, and the IESG as interpreter of IETF
consensus, to do that.  I don't think anyone has questioned
that.  

The other is that, to some readers, it appears to impose binding
requirements on how the RFC Editor deals with input from the
IESG, either directly (as in "if we recommend that this text be
inserted, you must insert it or not publish") or indirectly (as
in "if you don't follow our recommendations, we will see to it
that your funding is cut off").  For those of us who believe
that it is important to the Internet that the RFC Editor
function as an independent, cooperating, entity rather than as a
subsidiary of the IETF, that level of requirement is not
acceptable (that consideration is the source of this discussion
about aspects of the RFP and what should, or should not, be in
it).  While the IETF can attempt to establish links to
particular funding sources and apply leverage that way (which
some of us are trying to discourage), it is also beyond the
ability of the IETF to give itself the authority to impose such
requirements directly, any more than approval of a document as
an IETF Standard can force someone to conform to it.

There is a critical balance in this that has worked reasonably
well since before the IETF came into being.  One of its elements
has historically been ongoing discussions between the RFC Editor
and the IAB in which agreements were reached about how to
proceed on things (rather than one party assuming that it has
the right or authority to dictate to the other).  As I have said
before, I think that model, based on mutual respect and
cooperation, is a good one and that it has served the Internet
well.  But there have periodically been efforts to change that
balance into one in which the RFC Editor is merely an IETF
contractor subject to the IETF's (potentially changing) will as
specified by the IESG.    I believe that would be a very bad
change indeed and hence am pushing back on what I see as efforts
to push the RFP in that direction.
 
> desire to publish a new BCP; I also don't think such a BCP
> would get consensus.

We may disagree about that, but I don't see resolving it as
necessary to moving forward with the task at hand.

regards,
   john

---

From: "todd glassey" <[email-masked]>
Date: Wed, 26 Jul 2006 12:36:27 -0700

In making it easier to follow this obtuse and convoluted solicitation
document, the other thing is that the HISTORY section needs to go - go
elsewhere - and I personally don't ever need to see it again in the RFP
itself.

The RFP is a formal solicitation for participation or services - it is step
one of a contract and needs to be clean, terse, and to the point -
concise... which means that this group is probably lost this one already...
but hey - bad attitude on my part eh?

So the Solicitation Document should have the specific requirements of the
Solicitation and nothing more. It is not a literary work or a work-of-art
much to many of your chagrin I bet. This is not about publishing for fame
and fortune - its a solicitation for a specific contract and those that are
not aware of the nightmare they are bidding into are never going to survive
the vetting process so ... I suggest a quick edit and we can the History and
the graphs.

Also the terms that are show-stoppers must be enumerated as such and there
are a couple that are unclear.

Todd

----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: "Jeffrey Hutzelman" <[email-masked]>; "Allison Mankin" <[email-masked]>;
"IETF Administrative Director" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 26, 2006 11:23 AM
Subject: Re: RFC Editor RFP Review Request

---

From: Ted Hardie <[email-masked]>
Date: Wed, 26 Jul 2006 13:58:02 -0700

>an IETF Standard can force someone to conform to it.

I don't agree with this understanding, but I appreciate your
taking the time to clarify it.  The "imposition of binding requirements"
you cite above is, from my way of looking at it, instead a description of
how the two cooperating entities cooperate.  Putting descriptions of
that kind into the RFP (or, rather, references to them) is useful for a
potential respondent so that know what timelines and level of external,
unpaid effort to expect from the IETF.  Other ways around this seem to have
their own headaches. For example, requiring  the publisher of the independent
stream to establish that a document  does not inappropriately usurp an
unregistered standards-dependent  IANA  namespace or  reserved protocol
bits would otherwise take the time and talents of the publisher's review teams. 
That slows the stream or increases costs in a different way. 

				regards,
					Ted Hardie

---

From: "todd glassey" <[email-masked]>
Date: Wed, 26 Jul 2006 14:07:57 -0700

Just out of curiosity - does anyone anticipate adding RSS feeds?

T.
----- Original Message ----- 
From: "Ted Hardie" <[email-masked]>
To: "John C Klensin" <[email-masked]>; "Jeffrey Hutzelman"
<[email-masked]>; "Allison Mankin" <[email-masked]>; "IETF Administrative
Director" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 26, 2006 1:58 PM
Subject: Re: RFC Editor RFP Review Request

---

From: John C Klensin <[email-masked]>
Date: Wed, 26 Jul 2006 17:56:05 -0400

--On Wednesday, 26 July, 2006 13:58 -0700 Ted Hardie
<[email-masked]> wrote:

>> The other is that, to some readers, it appears to impose
>> binding requirements on how the RFC Editor deals with input
>> from the IESG, either directly (as in "if we recommend that
>> this text be inserted, you must insert it or not publish") or
>> indirectly (as in "if you don't follow our recommendations,
>> we will see to it that your funding is cut off").  For those
>> of us who believe that it is important to the Internet that
>> the RFC Editor function as an independent, cooperating,
>> entity rather than as a subsidiary of the IETF, that level of
>> requirement is not acceptable (that consideration is the
>> source of this discussion about aspects of the RFP and what
>> should, or should not, be in it).  While the IETF can attempt
>> to establish links to particular funding sources and apply
>> leverage that way (which some of us are trying to
>> discourage), it is also beyond the ability of the IETF to
>> give itself the authority to impose such requirements
>> directly, any more than approval of a document as an IETF
>> Standard can force someone to conform to it.
> 
> taking the time to clarify it.  The "imposition of binding
> requirements" you cite above is, from my way of looking at it,
> instead a description of how the two cooperating entities
> cooperate.  Putting descriptions of that kind into the RFP
> (or, rather, references to them) is useful for a potential
> respondent so that know what timelines and level of external,
> unpaid effort to expect from the IETF.  Other ways around this
> seem to have their own headaches. For example, requiring  the
> publisher of the independent stream to establish that a
> document  does not inappropriately usurp an unregistered
> standards-dependent  IANA  namespace or  reserved protocol
> bits would otherwise take the time and talents of the
> publisher's review teams.  That slows the stream or increases
> costs in a different way. 

Then I think we are more or less on the same page.  The
challenge now is to get the RFP to appropriately reflect that
shared understanding.

    john

---

From: "todd glassey" <[email-masked]>
Date: Wed, 26 Jul 2006 15:47:46 -0700

So let me ask the obvious thing... why is the RFP content being voted on?
This is a business decision in regard to services and process. Why is any of
it open to review inside the IETF?

Todd
----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: "Ted Hardie" <[email-masked]>; "Jeffrey Hutzelman" <[email-masked]>;
"Allison Mankin" <[email-masked]>; "IETF Administrative Director"
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 26, 2006 2:56 PM
Subject: Re: RFC Editor RFP Review Request

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Jul 2006 20:23:38 -0700

> it open to review inside the IETF?

Because the lunatics want to run the asylum?  ;-)

Seriously though, it seems to me that most people agree
with us, and want to let the IAD and IESG do their jobs,
and stop all this obsessing over every detail of our "Process".

How about if we get that "quality" and "timeliness" thing
under control before spending a lot of time agreeing on
the 427 most important factors in selecting IETF meeting locations?

(Just my $0.02.  OK, maybe it's the whole dollar :-)

> Todd

Andy

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Jul 2006 07:16:47 -0700

Leslie Daigle wrote:
...
> the IAB is, in fact, a separate entity from the IETF organization.

There are many who believe that all RFCs are Internet standards
documents, thus the current concern with adding IESG non-review
statements to independent submission (which I reiterate - I do not
recognize their right to do so).

There are many who also believe that the IAB, by virtue of being
appointed by exactly the same body as the IESG, is part of the "IETF".

You can point to your org chart all you want; sauce for the goose is
sauce for the gander. Either the actual differences matter, or we're
working off of public perception.

Perhaps it's time that the IETF demand that all IAB statements and
documents begin with an IETF "separate entity" disclaimer as well?

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Jul 2006 07:23:59 -0700

Jeffrey Hutzelman wrote:
...
> I agree that things would be simpler if we could come up with a way to
> do things that didn't require figuring out the answer.  Unfortunately,
> I'm not convinced we can.  Before I go any further, let me point out
> that I have no reason to believe that ISI will act other than in good
> faith and in accordance with the best interests of the Internet. 

s/ISI/IESG/, and for that matter, IETF.

I don't see how adding disclaimers of documents that are not generated
in nor declared as related to the IETF requires a disclaimer. I don't
think adding that statement - which *will* have a chilling effect on
independent submissions - is in the best interest of the Internet.

Joe

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 27 Jul 2006 11:01:50 -0400

Note that I never said that the IAB was not part of the
IETF family/universe/collection.

The important thing is that the IAB is independent in
its decision making, and not subject to the IESG's
whims or strictly bound by the IETF's input, which appeared to
be the key elements in your concerns of IETF "ownership".

draft-iab-rfc-editor-01 (now in the repository) lays out a
framework for the IAB to ensure there is a (broader-than-IETF)
community-defined RFC series, with community input and
feedback.

So -- it's a proposal for community-driven RFC Series
not under IETF (IESG) control.

Leslie.

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Jul 2006 08:13:24 -0700

> not under IETF (IESG) control.

So:
	- the IAB is part of the IETF family

	- draft-iab-rfc-editor-01 (surprise)
	lays out a framework where the IAB
	(i.e., IETF family) declares itself
	responsible for ensuring broader-than-IETF
	input/feedback to the RFC series

My position is that:

	- the RFC series includes independent
	submissions (at least at this point
	let's assume that, but we - the non-IETF
	community - may need to revisit if the rest
	is not possible - which is why I'm including
	[email-masked] in this discussion.

		note: it's unfortunate that this discussion
		is continuing here, rather than there.

	- independent submissions MUST NOT assume or
	require IETF family control - either direct
	or indirect

		A board of directors/advisors is fine,
		but NOT the IAB, IETF, or IETF family,
		and NOT appointed by the IAB, IETF, or IETF family.

	- independent documents MUST NOT be required to
	include IETF-family disownership assertions

*independent* means that. It does NOT mean IETF-family controlled.

Joe

---

From: Eliot Lear <[email-masked]>
Date: Thu, 27 Jul 2006 17:43:05 +0200

Joe,
> [...]

I would first see independent submissions abolished altogether.  There
are many publishing outlets.  This is not the 1970s.  The term RFC has
been appropriated by the IETF community.

Eliot

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Jul 2006 08:47:54 -0700

> been appropriated by the IETF community.

The term RFC is one the IETF is getting a free ride on.

RFCs core to the Internet itself were independent, pre-IETF submissions.
It is THEY that establish the utility of the series, not the IETF.

Joe