Sam,
Let's take another look at your example, from my point of view
(I can't speak for Mike).
--On Sunday, 23 January, 2005 22:39 -0500 Sam Hartman
<hartmans-ietf@xxxxxxx> wrote:
>
> I'd like to present one other example that motivates why I
> think having the review process is important. Say that the
> IASA has decided to pursue a meeting in Beijing. No contract
> has been signed yet, but that's getting close.
>
> Many contributors indicate they will be unable to attend.
> The IAOc has been focusing on the business aspects of the
> meeting: how affordable is it, are the necessary facilities
> available.
>
> The IESG and/or IAB formally asks for a review, arguing that
> whether the right set of people will attend a particular
> meeting is an important factor to consider in meeting site
> selection. Regardless of whether the IAOC ends up deciding to
> reverse its decision, having this review be available is
> important.
Ok. If we are doing meeting planning the way we have been doing
meeting planning, there is no announcement to the community
before a contract is signed. The IETF Chair knows, but the IAB
and IESG generally don't, and random IETF participants certainly
don't know. If we are going to change that, then changes need
to be made elsewhere than in this section. Under current
practice, the window you assume simply doesn't exist. If we
want it to exist, we need to make procedural changes elsewhere
-- probably not in the BCP, but in some way that makes
expectations extremely clear to the IAOC and IAD.
If, via those changes, the window is opened sufficiently that
the IESG and/or IAB can complain, then, under the scenario you
are describing, the IESG/IAB aren't involved with any of what I
(and I think Mike) are worried about. What you describe is
providing input to the IAD and IAOC _before_ a decision is made.
I think the IAOC should be open to pre-decision community input,
formal or otherwise. I think it would be seriously bad news if
the IAOC closed its collective ears to such input. I think
that, if the IAD stops listening to community input, and
especially IAB and IESG input, it would be a good sign that the
individual in that job should be re-educated or forced out of
the position.
But that isn't what I (and probably Mike, Spencer, and others)
are concerned about. We are concerned about the "decision gets
made and then someone tries to second-guess it" scenarios, on
which we want to place extreme limits.
So, from my perspective, if the case you describe is the one
that is of interest, you should be concentrating less on the
"review" (or appeal) procedures and other mechanisms for
questioning or correcting decisions already made and more on
being certain that, in areas where it is appropriate, the IAOC
is sufficiently open about what it is considering that
pre-decision/ pre-contract input is feasible.
Now, for some cases, that won't be practical for particular
situations or potential contracts. But there too, I think there
is a useful "make a window for comments" process.
Taking your meeting case as an example, I personally believe
that the IAOC should be setting criteria for meeting site
selection, that those criteria should be public, and they should
be set independent of particular sites and with full IETF
community involvement (a radical change from either "the IETF
Chair approves" or "the IETF Chair decides"). "The right set of
people needs to be able to go" is an important criterion which
has nothing specific to do with possible meetings in Beijing
(or, for that matter, in Fiji or Washington). If that is an
established criterion, than an IAD who doesn't do due diligence
on who could or could not attend prior to making a decision is
failing in the job. IAD job failure problems aren't managed by
reviews or appeals; that is what we have the IAOC for. And, if
they can't manage the job failures in an effective way... well,
that gets us back to discussions of group firing, but it isn't,
IMO, a post-decision review issue either.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf