John, You seem to be making a lot of assumptions about the RFP that aren't part of the RFP. Or perhaps you are reading between the lines. For example that the RFP will only be sent to the IETF list, that we won't allow non-IETFers to bid, that no discussion will occur between who ever does this work and the community, that the requirements are fixed, that the conclusions are pre-determined, etc., etc. The goal of the RFP is to hire someone who will investigate the problem, talk to many people, analyze the data, and make a proposal for what is doable. The RFP is not a specification of the outcome. We want to hire someone who will think about the problem space and make a proposal for the functions that should be present in a remote access system that the IETF will use. Any contract awarded based on this RFP will require the contractor to interact with the community. BCP101 requires the IAOC to operate in a transparent manner. I don't see how publishing an RFP to hire someone to write a specification that includes public review of the work and an IETF wide last call isn't transparent. It would have been non-transparent if the IAOC had hired someone with out first doing a public RFP. BCP101 doesn't require that everything the IAOC thinks about must be first sent to the community for review. Bob On Oct 20, 2011, at 12:23 PM, John C Klensin wrote: > --On Thursday, October 20, 2011 10:50 -0700 Bob Hinden > <bob.hinden@xxxxxxxxx> wrote: > >> John, >> >> The RFP is not a solicitation to vendors of remote >> participation services. It is to hire someone to write a >> requirements document for remote participation services. It >> is not to develop any code nor are the items listed in the RFP >> the only things that should be included. > > Bob, > > I was somewhat confused by differences between the description > of the RFP in the announcement that was sent out and the RFP > itself (aggravated very slightly by the link in the announcement > not being correct). I apologize for that confusion at the same > time I suggest that propriety suggests that they should be > consistent. > > That said, I understood that this was to hire someone to write a > requirements document. I suggest that, if you want a fair and > open process, it would be good to follow the rules closely > enough to make it possible for non-insiders to bid (or to make > it explicit that only insiders and regular attendees are > eligible). > > As I mentioned in my response to Henk, what you ask for in an > RFP not only affects what you get (even if all you are looking > for is a requirements spec) and who is likely to consider it > plausible to bid. More important, I see nothing in BCP 101 that > says that the IAOC does not need to expose draft RFPs to > community review just because they do not, e.g., require code to > be written. If the IAOC believes that such an exception is > needed because things don't work without it, then BCP 101 very > explicitly requires that the IAOC submit a change proposal to > the community. That hasn't been done, so there is no exception. > >> Note that it >> explicitly calls for having community input into the >> requirements. The RFP includes: >> >> "After gathering all of this input, the contractor will >> prepare an initial specification for review by the IETF >> Tools Team and the vmeet mail list participants." >> >> and >> >> "Specifications will be circulated as IETF Internet-Drafts >> (I-D)" > > Right. But those are provisions for community review of a > requirements spec, expressed as an I-D. We know how to handle > those, especially if you already have General AD and IESG > agreement for a Last Call. What I'm concerned about is > community review of the RFP to be sure that any proposals > address the right set of issues and use adequate mechanisms to > be sure a good spec is developed (see my note to Henk). > >> The intent of this work is to develop a set of requirements >> for community review. I don't see any significant value in >> asking the community for input on an RFP that is for hiring >> someone to write a specification to generate community input. > > Again, I don't believe that BCP 101 or the associated > discussions and precedents give you (or the IAOC) the authority > to eliminate community review on the grounds that you don't see > it as having significant value. Consider what would happen if > the IESG decided to waive IETF Last Call on a Standards-Track > document on the grounds that they understood the community well > enough to know that such a Last Call would be unlikely to yield > any significant comments. I have no doubt that they could make > those judgments and make them accurately, but that is not the > point. Nor is the IAOC authorized to translate its obligations > about transparency and openness to community comment so that it > applies only in cases where you believe there is significant > value in asking. > >> ... >> Regarding the IAOC minutes, the IAOC is aware that there is a >> problem. I am sorry to report that the current volunteer >> approach to taking and producing IAOC minutes is not working. >> I had hoped we could make the volunteer approach work. The >> IAOC concluded on today's IAOC call that we should approach >> ISOC to get additional administrative support to improve this >> function. I will report on the outcome of that in Taipei. > > I look forward to your report, but have a sense of deja vu about > prior discussions of this problem and similar commitments. > Perhaps I was just dreaming on the prior occasions. > > best, > john > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf