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(_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