Just out of curiosity - does anyone anticipate adding RSS feeds? T. ----- Original Message ----- From: "Ted Hardie" <[EMAIL PROTECTED]> To: "John C Klensin" <[EMAIL PROTECTED]>; "Jeffrey Hutzelman" <[EMAIL PROTECTED]>; "Allison Mankin" <[EMAIL PROTECTED]>; "IETF Administrative Director" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[email protected]> Sent: Wednesday, July 26, 2006 1:58 PM Subject: Re: RFC Editor RFP Review Request
> 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. > > regards, > Ted Hardie > > > > > _______________________________________________ > Ietf mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ietf
