Ray and IAOC, I hate to keep bringing this up, but the discussions leading up to BCP 101 and the oft-replated principle of "maximum amount of transparency to the IETF community that can be reasonably obtained" strongly suggest that documents that are intended to evolve into RFPs be circulated in draft to the IETF community for comment. If there is some reason why that it not possible, reasonable transparency suggests that the IAD or IAOC proactively provide an explanation to the community, rather than waiting to be asked.
Community review of draft RFPs is particularly important because, for reasons outlined in BCP 101, there is little opportunity for effective community input once proposals are received and contract negotiations start. Each time this issue has been raised in the past, the IAOC has agreed that exposing RFP drafts is The Right Thing to do, yet RFPs keep appearing without opportunity for community review. Two omissions from this document illustrates why community input is important: (1) I don't know how much experience IAOC members have with trying to participate remotely, but, having done so, there are insights into what is needed that one just cannot obtain by physically attending a meeting and observing how things work. If any RFP or subsequent contract does not provide for input from, and probably interviews of, selected people who have tried to participate remotely while carrying out various roles, then the odds are high that the resulting work will not be adequate in practice. Instead, this RFP appears to provide only for "observ[ing] group and plenary sessions" and then review of the initial specifications by groups that are unlikely to include the full range of remote participants. It seems to me that a call for comments from those with actual remote participation experience and for contractor interviews with a selection of those people. There is a long history of asking developers and tool-builders what users need. The perceived success level in having a process that is limited to asking developers and tool-builders produce results that actually match user needs has been abysmal. (2) The list of "Environments" is also interesting. Whether caused by health issues, travel limitations, or other considerations beyond the control of the individuals, we've had experience that has required remote participation of IAB and IESG members, members of key committees (the RSOC and RFC Editorial Board are on my mind at the moment, but, if the IAOC itself has not been affected yet, I believe that is only a matter of time). At least parts of the meetings of those groups are, properly, not open. While most of those meetings are scheduled far in advance, ad hoc sessions for which participation by members who happen to be remote do occur. Those bodies and meetings create remote participation requirements that are quite different from the environments listed -- small meeting support that goes well beyond "8 being simultaneous at any one time", a need for session privacy, and a need to accommodate meetings that are scheduled on relatively short notice. I don't fault the IAD or IAOC for failure to identify those types of issues internally. I do believe it reinforces the importance of getting community review of RFP drafts so that there is maximum opportunity for others to spot issues that the IAD and IAOC have overlooked. In addition, while I don't believe members of the community should be required to read and study IAOC minutes to find out that particular RFPs are under development so that they can comment, I note that no IAOC minutes have been posted since those for an IAOC meeting held on 27 July during IETF 81. I recommend that the RFP be withdrawn until modifications such as those suggested above can be discussed by the IAOC and further input on draft RFP provisions sought from the community. I also recommend that no further RFPs be issued until the relevant IAOC discussions and decisions be properly recorded in IAOC minutes and those minutes posted. regards, john --On Wednesday, October 19, 2011 09:25 -0700 IETF Administrative Director <i...@ietf.org> wrote: > The IETF Administrative Oversight Committee (IAOC), on behalf > of the IETF, announces this Request for Proposal to develop > the specifications for Remote Participation Services. The > successful bidder will enter into a contract with the Internet > Society. > > The primary goal of this project is to develop consensus on a > set of requirements for IETF Remote Participation Services > (RPS) to enhance remote participation at IETF meetings, > interim and virtual working group meetings. > > Background > The IETF has supported remote meeting participation over the > Internet for many years. For example, the audio of each > session is made available in real time so that remote > participants can listen to the proceedings. Instant messaging > is supported by having a jabber room 'conference' for each > session, so that comments from remote participants can be > relayed to people in the face-to-face meeting and to permit > side exchanges that comment on material being presented. In > addition, we have experimented with bi-directional audio > support for remote presenters, as well as video broadcasting > of the face-to-face meeting, but these more advanced features > have, to date, have proved difficult to scale. > > Environments > 1. IETF Meeting Group Sessions > There are about 150 sessions, with up to 8 being simultaneous > at any one time. A session varies in size from twenty to two > hundred on-site participants. > > 2. IETF Meeting Plenary Sessions > There are two plenaries. On-site attendance at plenary > sessions averages 700. The number of speakers at the front of > the room ranges up to twenty. > > 3. Interim Group Meetings > In addition to sessions during one of the three regular > meetings, there can be as many as thirty Interim Working > Group Meetings held throughout the world annually, serving a > range of on-site participants from 15 to 50 and an unknown > number of remote participants. > > 4. Virtual Group Meetings > There are currently 30-50 Virtual Group Meetings held > throughout the year annually, serving 15-75 online > participants from all parts of the globe. These have no > physical, on-site instantiation and are conducted entirely > through teleconferencing tools. > > The contractor is expected to highlight development and > operational challenges to the functions that are defined. > > Deliverables > > 1. The IETF is seeking development of functional > specifications for a suite of tools that enable Remote > Participation Services, meeting the needs described above, > ideally enabling an experience for remote attendees that > rivals that of on-site attendees. > 2. The specifications shall rely solely upon IETF and other > open standards for all communications and interactions. 3. At > a minimum it is expected that the RPS will support the > following real time functionality: a. audio, bi-directional > b. video, bi-directional > c. instant messaging > d. slide presentations, including by remote attendees > e. whiteboard, for collaborative document development > f. conference control and moderation > g. transcription and broadcast of audio to text in real-time > h. ability to conduct and participate in straw polls. > > In addition to real-time participation support, the service > must support recording of an entire session, using > standards-based encoding, to permit integration into the IETF > meeting proceedings system. > > Timeline > > The contractor will observe group and plenary sessions at IETF > 82 (Fall 2011 in Taipei) and conduct interviews with vendor > teams (at a minimum, Meetecho, Adobe, Citrix and Webex when > possible), the Network Operations Center (NOC) volunteers, > remote participants, and those individuals who run the working > group and plenary sessions. 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. Following these discussions, the contractor will > update the specification as required. > > Specifications will be circulated as IETF Internet-Drafts > (I-D). It is expected that an initial I-D containing the > specifications will be developed prior to IETF 83 (Spring > 2012) and a completed I-D will be delivered prior to IETF 84 > ( 2012). > > The RFP can be found at: <http://iaoc.ietf.org/rfpsrfis.html>. > > Proposals must be received via email at rpellet...@isoc.org no > later than November 1, 2011, 5:00 P.M. EDT. All > questions/inquiries must be submitted in writing and must be > received no later than midnight, EDT, October 24, 2011. > Responses to questions and inquiries shall be posted on the > IAOC website, <http://iaoc.ietf.org/rfpsrfis.html> by > midnight, EDT, October 27, 2011. > > The point of contact regarding this RFP is the IETF > Administrative Director, Ray Pelletier. > > Ray Pelletier > IETF Administrative Director _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf