ietf
[Top] [All Lists]

Re: Proposed consensus text: #725 Appealing decisions

2005-01-28 11:33:18


--On Friday, 28 January, 2005 12:35 -0500 Leslie Daigle
<leslie(_at_)thinkingcat(_dot_)com> wrote:


Since I am responsible for some of this text, let me add
a couple of comments, in-line:

John C Klensin wrote:
3.5  Review and Appeal of IAD and IAOC Decision

   The IAOC is directly accountable to the IETF community for
the
   performance of the IASA.  In order to achieve this, the
IAOC and IAD
   will ensure that guidelines are developed for regular
operational
   decision making.  Where appropriate, these guidelines
should be
   developed with public input.  In all cases, they must be
made public.

   Additionally, the IASA should ensure that there are
reported objective
   performance metrics for all IETF administrative support
activities.


Back when I was actively doing political science, the belief
that everything could be reduced to objective and quantifiable
terms (the latter is what "metrics" means; if it isn't what
was intended, some other word should be chosen) statements
like this were described as "physics envy".    The statement
would be reasonable if "whenever feasible" or the equivalent
appeared there somewhere -- we _can_ evaluate the IAOC on its
interpretation of "feasible" and how far they are willing to
go to satisfy the needs or curiosity of the community.

The "Additionally..." sentence came in when I had a section
that
was about responsiveness to the IETF community.  The intent was
that there should be metrics (and I do mean metrics) maintained
with regard to various objective processes:  RFC Ed queue, IANA
queue, etc.  This allows the community as a whole to have some
insight into how the overall IETF machine is functioning.

I agree that is reasonable, appropriate, and desirable.

Now that the section is about appeal and decision review, the
text may be a little out of place.  Or not -- because one
should be able to flag when the whole system just doesn't seem
to be cutting it.  So perhaps it's a wording problem.  I'm
not inspired with alternatives.

While I don't consider any of these an inspiration, my objection
would disappear if you inserted the "whenever feasible" words
suggested above, or if you made that "...objective performance
metrics... for all IETF administrative support activities for
which such metrics are possible" or if you rewrote it to
something like "IASA should strive to organize all IETF
administrative support
activities in a way that makes objective measures of performance
feasible, and then to report those measures to the IETF".  I
think any of those are more or less consistent with the intent
as you expressed it above.

...
   on the nature of the review request.  Based on the results
of the review,
   the IAOC may choose to overturn their own decision and/or
to change their
   operational guidelines to prevent further
misunderstandings.


This doesn't give the IAOC the option of saying "no, you are
wrong [because...], and we aren't going to change anything".
Combined with other text above, that would imply that any
member of the community can force the IAOC into either
changing a decision or changing the operational guidelines.
The IAOC must be able to say "no you are wrong".  If must
even be able to say "you have raised fifteen objections in
the last 30 days, all of which have been turned down by us
and everyone in the appeals chain, please go improve you
sand-pounding skills".

Agreed -- and I think Scott Brim flagged a different aspect of
the same problem.  I don't think there is anything intentional
in not expanding this to include other options at the
discretion
of the IAOC.  Perhaps removing it (as Scott suggested) is best.
Personally, I'm as happy to leave those options in as explicit
(but not limiting) examples.

I can happily live with either Scott's fix or with making it
clear that these aren't limiting examples.  And I assumed that
the apparent limitation to just those options was unintentional.
But it is something that should be fixed, somehow, lest it get
us into lots of trouble down the road.

     john


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf