ietf
[Top] [All Lists]

Re: [IAOC] Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

2011-10-20 12:51:14
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.  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)"

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.  

Also, while the SOW does not indicate it, because it is not something the 
contractor will do, the Internet-Draft will be "last called" to confirm that it 
represents community consensus.  This will be done by the General AD as has 
been done earlier with other specification tasks.

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.

Regards,
Bob



On Oct 20, 2011, at 1:27 AM, John C Klensin wrote:

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 <iad(_at_)ietf(_dot_)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 rpelletier(_at_)isoc(_dot_)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




_______________________________________________
IAOC mailing list
IAOC(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/iaoc

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf