--On Thursday, October 20, 2011 17:15 +0200 Henk Uijterwaal
<henk.uijterwaal@xxxxxxxxx> wrote:
>> 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.
>
> -1.
>
> Or I disagree completely here and I do not see the need for
> the RFP to be withdrawn.
>
> The task is clear, it is to write an ID with the requirements.
> The ID process offers sufficient opportunities for the
> community to provide input, it is a matter of finding somebody
> to hold the pen and write the document. I think we should
> move forward here and start doing the work, not endlessly
> discuss the fine details of a process.
Henk,
Actually, unless the IAOC has already selected either a vendor
or a short list of vendors, that isn't the task. The task is to
get proposals from a selection of vendors and then pick on. In
that regard, the list of issues the proposing contractor is
supposed to consider ("the Environment") is very important
because some potential proposers might, at least in principle,
submit a proposal for some list of environments to be supported
but not feel they were competent to evaluate others. If the
community introduces completely new issues or environments to be
considered once we go into the I-D process, a contractor might
be entirely justified to say either "not in the contract and I'm
not going to do it because I can't do it well" or "not in the
contract, it will cost you $XYZ extra for me to write
requirements for it, please send money". Neither is a desirable
situation, to put it mildly.
With regard to transparency and openness to community input, I
suggest that exposing a draft RFP to community review
--something the community has asked for several times and which
the IAOC has generally agreed is reasonable and appropriate--
serves two separate purposes. You can dismiss the second as
"fine details of a process", but it seems to me that the first
is quite substantive.
(1) The IETF Community often has perspectives on issues that are
broader from those represented on the IAOC. Consequently,
community input may actually provide ideas that should be
discussed and evaluated as to whether they should be in the RFP
(remembering that a different set of tasks may yield different
bidders). The few hours of discussion since I sent my note
illustrate the issues: whether you believe that consideration
for IPv6, poor-connectivity participant environments, more
specific consideration of input from those who have experienced
remote participation in various roles, or remote participation
in non-WG/non-BOF meetings is important, those issues should at
least be aired and discussed, openly, by the IAOC. Perhaps
they, and whatever else might be identified, already have been
discussed and the IAOC has made decisions about them that the
community will find acceptable. But, if they have, there is no
way to find out from any minutes that have been published, which
is why that isn't a "fine detail of process" either.
(2) The IAOC is required to be open and transparent with the
IETF community, including publishing timely minutes. Maybe no
one cares any more or maybe the IAOC has concluded that the
expectation/ requirements are impossible. But then another
provision of BCP 101 applies, which is that the IAOC, having
noticed that some procedures cannot be followed or requirements
met, is obligated to identify the problem to the community and
recommend changes to solve it. I don't consider simply
ignoring those rules to be an option or even a fine detail of
process, but YMMD.
best,
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf