--On Thursday, October 20, 2011 10:50 -0700 Bob Hinden
<bob(_dot_)hinden(_at_)gmail(_dot_)com> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf