--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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf