Hi Eric,
At 5:40 PM -0800 1/26/05, Eric Rescorla wrote:
With that in mind, I would like to suggest the following principles:
1. The IETF community should have input on the internal rules
set by the IASA and the IASA should be required to respond
to comments by the community on said rules.
2. While the IASA's behavior should be constrained by BCPs (as it will
be constrained by the first one) we should in general refrain from
enacting specific internal IASA rules changes by BCP. If it is believed
that the IAOC is making bad decisions we have a mechanism for unseating
them.
3. Decisions of the IAOC should be appealable (following the
usual 2026 appeal chain) on the sole grounds that the IASA's
processes were not followed. Those decisions should NOT be
appealable on the grounds that the decisions were simply bad ones.
I think that something along these lines could meet all of my
"principles". BTW, I don't feel that I have any special right to set
the principles for this mechanism, so folks should feel free to add
new ones or argue with the ones I put forward...
Your proposal certainly meets the following ones:
(2) It is well-enough specified (here and in RFC 2026) that person
who is not a (past or present) member of the I* could use it.
(4) Any member of the community can make a review request (or appeal)
and get a response.
(5) There is at least one level of escalation possible. (In fact,
there are three.)
Your criteria are different than mine, and therefore there may be
some disagreement on:
(3) Review requests should be limited to situations where the IAOC
violates written procedures (their own or a BCP) and/or makes a
decisions that is against the best interests of the IETF.
You only want to allow appeals based on the fact that a published
rule was not followed, and I would like to allow appeals based on
both of the above criteria. I don't know how close or how far we are
on this... My idea is that the IAOC should not be able to make
decisions that are damaging to the IETF without any community
recourse, just because there is no written rule that prevents it.
If we are going to use the full appeals chain (which I totally
support), I would like to see appeals based on the best interests of
the IETF constrained to being escalated to the IESG and IAB (since
they are chosen by the IETF) and only allow process-based appeals to
be escalated to the ISOC BoT -- much as we do today for technical vs.
process appeals of WG decisions. I do not think that it is the ISOC
BoT's place to be the ultimate arbiter what is in the best interests
of the IETF.
We also seem to have some disagreement on:
(1) A review request cannot overturn a signed contract or hiring decision.
And
(6) The IAB, IESG and ISOC BoT (in hearing an appeal) cannot overturn
a decision of the IAOC, only advise the IAOC that they believe that
an incorrect decision was made.
I feel quite strongly about principle (1), as I don't know how the
IAOC could negotiate and administer contracts if they might, at any
time, be overturned by someone else. And, I don't even know what it
would mean to "overturn" a signed contract, since it would then be
outside the control of IASA to change it. I do think that the IAOC's
contract negotiation rules should include a period of public comment
on major decisions before they sign binding contracts or MOUs, but
that is a subject for future IAOC operating procedures, not for this
document, I guess.
I am actually not strongly in favor of principle (6) myself. I think
that the IAB, IESG and ISOC BoT could be trusted to decide whether
overturning a particular (non-binding) decision is appropriate in a
particular situation. But, others seemed to feel strongly that
allowing anyone else to overturn any decision of the IAOC would be
very bad. I can't say that I fully understand why.
Please note that principle (6) does allow the IAOC to overturn an IAD
or IAOC decision based on a review request/appeal. It also allows
the IAOC to overturn a decision based on advice from the IAB, IESG or
ISOC BoT that it would be best to do so. So, I am comfortable with
this one either way.
Do you have a strong opinion on this one way or the other?
Margaret
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf