JCK Lets ask Jorge if the Final RFP is different from interim RFP's then dont all parties have to be given proper review and response time to the final version? lest they recieve less access or are not favorites in the bidding-contract acquisition process? I recall this one from Basic Contracts, and yes I took the class. Todd -----Original Message----- >From: John C Klensin <john-ietf@xxxxxxx> >Sent: Jul 27, 2006 10:23 AM >To: Brian E Carpenter <brc@xxxxxxxxxxxxxx> >Cc: Leslie Daigle <leslie@xxxxxxxxxxxxxxx>, IETF Administrative Director <iad@xxxxxxxx>, ietf@xxxxxxxx, Allison Mankin <mankin@xxxxxxx>, iaoc@xxxxxxxx, Ted Hardie <hardie@xxxxxxxxxxxx> >Subject: Re: [IAOC] Re: RFC Editor RFP Review Request > >--On Thursday, 27 July, 2006 14:40 +0200 Brian E Carpenter ><brc@xxxxxxxxxxxxxx> wrote: > >> ... >>>> My main object is for the RFP to say to a prospective RFC >>>> Editor that the delineation of the independent submission >>>> series will be under the contract holder's management in >>>> some way, allowing input from the editor. I want to urge >>>> this just because the RFC series is shared by four streams. >>>> In justifying this before, I've talked mainly about the IETF >>>> stream because it is the one I know the best, but I could >>>> also detail taking this care for the others. Anyway, here's >>>> a revised proposal for the text: >>>> >>>> NEW 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 developed and authorized >>>> by an appropriate party to be determined, with input >>>> from the RFC Editor. >>> >>> >>> Since I have found myself in the uncomfortable position of >>> being temporary spokesperson for those whose views are >>> somewhat more conservative than mine, let me suggest, as a >>> clarification what this would look like if done from a more >>> traditional view (please see many earlier comments to clarify >>> the use of "conservative" and "traditional"): >>> >>> ... When documents are published at the request of the >>> IETF community, including for this purpose the IAB and >>> IRTF, include clear indications about the status and >>> origin of these documents. Develop appropriate >>> indications in conjunction with the requesting bodies... >> >> It's my opinion that we should stay silent on this matter in >> the >> RFP. It really won't be a crucial issue in analyzing the bids, >> and we have time to work out the words before negotiating the >> final >> SOW. >> >> I think I would argue for symmetry (i.e. John's words are fine >> for >> the I* streams but I'd like to see something equivalent for the >> Independent stream). >> >>> Explanation: >> >> I agree with all these points. I believe the RFP text is >> compatible >> with them. > >Brian, > >I hope you are right. However, I see one condition on which the >RFC must reflect the nature of decisions about these questions. >Suppose we had two groups of entities that might logically >respond to the RFP. > >One group, for whatever current or historical reasons, is >strongly committed to the independent submission model, perhaps >even with Joe's definition of "independent" (which I personally >sympathize with but consider a little extreme--see separate, >forthcoming, note). The role they are interested in involves an >RFC Editor-like function that is somewhat independent of the >IETF although willing to publish IETF-produced specifications >more or less as required by the IETF. If that is not the >definition of the role, they might lose interest in the >IASA-specified job, instead deciding to try to establish a >publication series that focused on documents and pieces that >serve the networking community, perhaps at the boundary between >research and ready-to-deploy specifications, but not moving into >standards. > >The second group might, hypothetically, care less about these >issues and be more interested in a "whatever the IETF wants" >editing/ publishing job, which might or might not include an >IESG-supervised "independent" thread. > >I don't need to take a position here on which of those >approaches would be better for the IETF or the broader >community. But, if groups aligned with the different approaches >exist, then it seems to me that we have two problems that the >RFP cannot plausibly avoid: > >(1) An RFP aligned with "the IETF leadership is in control of >everything" is not going to get a response (or at least should >not get a response) from members of the first group. They >can't very well respond within the terms of such an RFP and hope >to renegotiate the relationship later. That would also >constitute use of language in the RFP to determine who can >plausibly bid. That is something the IASA can clearly do, but >it probably isn't wise, especially if there really is support >for an independent process in the IETF community. > >(2) If the first group then goes off and identifies funding and >an institutional home for that non-standards-publication >mission, they might have a legitimate historical claim to >calling the documents they produce "RFCs" and even continuing >RFC numbering from whatever the last number was as of the end of >December (or whenever the current arrangements terminate). At >that point, if the IETF continues to use the "RFC" terminology >and its own, divergent, series numbering, we have, at best, >massive confusion which, whatever its other properties, does not >serve the Internet community well. Of course, there is also the >possibility of either that first group and institutional sponsor >or the IASA, deciding that the confusion level is high enough >that they needed to seek a legal determination about rights to >the "RFC" terminology. Whatever the outcome of that process, >the one thing that can be guaranteed is that the community loses. > >I believe we need to invest some serious effort in avoiding >those scenarios, not just hoping that the RFP can be issued >while ignoring them and the possibility of their arising. > > john > > > >_______________________________________________ >Ietf mailing list >Ietf@xxxxxxxx >https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf