Requirements are one thing.
How about some discussion of "goals" to drive the requirements? For example,
is it a goal of the RFP to specify a tool set that would be so good that people
would pay to use it?
My reaction to the text in the announcement of the RFP is that the overall
objectives are ill-defined.
to enhance remote participation at IETF meetings,
interim and virtual working group meetings.
What does "to enhance" mean in this context?
If I was at all interested in bidding on this new piece of spec development
work, I would either ask for a lot more clarity on the desired goals of
"enhanced" remote participation, or I would propose that the first phase of the
project should be focused on developing some consensus on this.
+1 to John Klensin's view that if the RFP had been reviewed by the community
before publication, it would have been better.
From: John C Klensin <john-ietf(_at_)jck(_dot_)com>
Date: Thu, 20 Oct 2011 15:41:22
To: Phillip Hallam-Baker<hallam(_at_)gmail(_dot_)com>
Cc: <iaoc(_at_)ietf(_dot_)org>; <ietf(_at_)ietf(_dot_)org>;
Subject: Re: Anotherj RFP without IETF community input (was: Re:
RFP for Remote Participation Services Specifications Development)
--On Thursday, October 20, 2011 15:21 -0400 Phillip Hallam-Baker
One thing to consider is charging for this service
I have no problem paying some fee to the IETF in order to get
better remote participation capability when I am unable to
travel to the location chosen.
I would much rather pay $200-$300 to have good remote
attendance capability (video etc.) than get by on 'free'.
As others have pointed out, this is an RFP about writing a
requirements spec. Please examine the announcement and RFP (I
assume the latter is authoritative, but am not sure) to
determine whether you think the RFP should require that a
contractor include studying this issue as part of the task.
Perhaps it is. If so, you should be objecting to the RFP
itself. If not, this type of comment should probably be raised
when the first draft I-D shows up.
IMO, the question of "environments" to be examined is definitely
insufficient in the RFP, not because it prohibits a contractor
from doing or proposing anything else (as Bob points out, it
doesn't) but because I believe a draft requirements
specification would be completely inadequate unless some or all
of those issues -- especially issues with meetings that do not
conform to the paragraph starting "Each session..." in the
"Background" part of the SOW in the RFP -- were addressed.
Similarly, I don't think the RFP is adequate unless it insists
on proposals in which applicants provide details about their
plans for "conducting interviews" with the various listed
parties. Some of those groups, especially those who have
actually participated remotely in one or more meetings but
normally attend in person and those who almost always
participate remotely, are often underrepresented in IETF
considerations and easily blown off, especially if the
contractor expects all interviews to be completed in the IETF 82
timeframe. Without such a requirement, we could easily find
ourselves in a situation in which a contractor said "we bid on
the basis of resources to conduct interviews that week; if
additional interviews are needed, you will need to adjust the
I cite those as examples of comments on the RFP in the hope of
making the distinction between such comments and an attempt to
pre-discuss the I-D that will presumably come out of this
Ietf mailing list
Ietf mailing list