--On Friday, 28 January, 2005 12:35 -0500 Leslie Daigle
<leslie@xxxxxxxxxxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf