--On Wednesday, 26 January, 2005 11:38 +0100 Brian E Carpenter
<brc(_at_)zurich(_dot_)ibm(_dot_)com> wrote:
John C Klensin wrote:
[many things, including]
(1) The note indicates that "the Transition Team is favorably
inclined to consider a proposal from NeuStar for continuing
Secretariat services...". Does that language imply that the
Transition Team believes that it has the authority to accept
such a proposal, without waiting for the IAD and IAOC to be in
place?
I simply observe that unless we stop word-smithing and get some
form of the BCP on the books really soon, this question will be
overtaken by events. If there is no IAOC in place, but a final
proposal with deadline arrives from NeuStar, somebody will have
to answer it - either the IETF Chair du jour, or the transition
team.
So despite the seriousness of the issues you raise and those
implied by Bob Kahn's message, I would very strongly favour
declaring the BCP "good enough for now" as soon as we see
the -05 version. Some of the issues cannot be resolved and
documented at this time, IMHO.
Brian,
Let me suggest a different (but admittedly paranoid) way of
looking at this. Suppose we forget about -05, declare -04 done
and all other issues queued for a hypothetical future revision,
and that the IETF signs off on -04 tomorrow and sends it off to
the RFC Editor with a request to expedite publication. (I'm
not suggesting that as a procedure, just as the fastest
theoretical way to get this finished). So we have a BCP
protocol action on Friday and, with a little effort and good
will, the ISOC Board approves an appropriate resolution next
week.
Now let's assume that, on the 6th of February, a proposal with
deadline arrives from Neustar and that it leaves all of the
issues that my questions suggest might be unresolved (and all of
the issues that Bob Kahn's note raises clearly unresolved).
The situation you fear doesn't change at all. The draft doesn't
give the IAOC any authority to accept an unsolicited proposal in
the absence of an IAD-created, IAOC-approved, RFP and at least
the potential for competitive proposals against that RFP. The
potential for CNRI to try to block an ISOC-based IAOC is
unchanged. The issues about review or appeals, who can initiate
them, and what they can change, that Sam, Avri, and others have
been discussing with Mike, myself, and others are likely to be
resolved by "no one at all in any meaningful way until the
initial term of the 'arrangement' expires", a situation that I'm
sure none of those who have been involved in that discussion
would find acceptable. (And the resemblance between that
situation and the one we now have with Foretec is very strong --
the only major difference that is apparent from Leslie's note is
that there will be an expiration/ review date.)
So, if such a proposal arrives and someone must respond to it,
whomever that is, either as an individual or as a body, are
going to need to go outside the bounds of the BCP and invent an
ad hoc procedure, whether the BCP has been approved or not...
unless, of course, the response is "no, we can't agree to this
because we have no authority". It may be just a matter of
aesthetics, but I don't want to see the BCP go into effect and
for the first action of the IAOC to be to violate its terms.
Unless I've misunderstood what is happening --and I may well
misunderstand, hence all the questions-- I'd rather either
* Fix the BCP to accommodate this case, i.e., to give
the IAOC the authority to accept unsolicited,
sole-source proposals for outsourced operations if that
seems appropriate to them, even if those proposals do
not fufill some of the principles of the BCP itself or
* Bury the BCP, at least in its present form, until we
are really ready to move forward with its provisions.
The first of those options would, of course, respond to my
question about how the community authorizes this type of deal:
we examine the principles and give the IAOC the authority to do
it.
regards,
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf