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" <john-ietf@xxxxxxx> To: "Ted Hardie" <hardie@xxxxxxxxxxxx>; "Jeffrey Hutzelman" <jhutz@xxxxxxx>; "Allison Mankin" <mankin@xxxxxxx>; "IETF Administrative Director" <iad@xxxxxxxx> Cc: <iaoc@xxxxxxxx>; <ietf@xxxxxxxx> Sent: Wednesday, July 26, 2006 2:56 PM Subject: Re: RFC Editor RFP Review Request > > > --On Wednesday, 26 July, 2006 13:58 -0700 Ted Hardie > <hardie@xxxxxxxxxxxx> wrote: > > > At 3:28 PM -0400 7/26/06, John C Klensin 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. > > > > 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. > > 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 > > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf