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@xxxxxxx> To: "Jeffrey Hutzelman" <jhutz@xxxxxxx>; "Allison Mankin" <mankin@xxxxxxx>; "IETF Administrative Director" <iad@xxxxxxxx> Cc: <iaoc@xxxxxxxx>; <ietf@xxxxxxxx> 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@xxxxxxx> wrote: > > > On Tuesday, July 25, 2006 04:24:01 PM -0400 John C Klensin > > <john-ietf@xxxxxxx> 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@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf