--On Saturday, 22 January, 2005 23:52 -0500 Michael StJohns
<mstjohns(_at_)mindspring(_dot_)com> wrote:
John/Leslie et al - this is a good improvement, and Leslie's
3.5 now reads in a way I can support. 3.6 still has some
sticking points.
After the last round of comments I went away and thought and
came up with the following:
There are three separate things that I think were meant by the
original 3.5 phrase "review". They were IAOC review of IAD
decisions, IAOC reconsideration of its own actions and public
review of the IAOC and IAD actions.
....
Mike,
I've read, and reread, your note several times and want to
comment on it from a slightly higher level. First, and most
important, I think we all need to understand and accept that
there is real disagreement in the community on this subject.
If I have correctly understood, you are at, or close to, one
extreme. Your view, as I understand it, is that the IASA should
be treated as a semi-independent body with periodic "reviews" of
its performance and little or no ability of the IETF community
(including the IAB and IESG) to interfere in any individual
decisions either before or after the fact. "Interfere" might
include micromanagement, specific direction about decisions, and
the ability to overturn decisions or even to force the IAOC to
reconsider decisions. And you believe that, without that much
autonomy, the IASA will simply be unable to function, or at
least function efficiently.
My personal, historical, position is close to that. I believe
that the IASA needs considerable autonomy and to be treated by
the IETF largely as an entity. While I have modified my
positions in the hope of reaching some sort of consensus (see
below), I have argued from time to time that the majority of the
IAOC membership should come from outside the IETF process, for
the presence of the IETF and IAB Chairs on the IAOC only as
observers or liaisons, for "reviews" of performance only and no
reviews of individual decisions, and for the ability of the IETF
community to "fire the IAOC" --remove them as a group-- rather
than relying on recall of individuals or incremental
nomcom-based phaseout. I've stated each of those positions
separately, usually in terms of either preventing interference
or abuse by those who are not chosen for their skills in the
types of management that IASA will require or preventing the
appearance of conflicts of interest between the administrative
entity and the standards process. I have now realized, after
reading your notes, that they are really all part of the same
underlying theme, which is that the IAOC and IAD must be able to
function without concern about having individual decisions
--contractual or not-- regularly second-guessed.
At the other extreme are those who believe that the IASA is
really a functional subsidiary of the IETF, that all (or as many
as possible) of its decisions should be able to be overturned by
the IESG (or IAB, or both), that the community should be able to
appeal individual IAD decisions, with the potential of having
those decisions reversed and with the appeal chain running
though the IESG and IAB to, potentially, the ISOC Board as is
the case with standards-related decisions. Many of the
advocates of those positions see them as democratic, with the
IETF membership being in ultimate and immediate control.
And there are various people and positions "in the middle".
While I think the "democratic" position is logically consistent,
however impractical, I can't see logical or operational sense in
some of the "middle" positions. But maybe I just lack
sufficient imagination.
Until we can somehow resolve these rather different models of
how to proceed, I don't think new and more specific text helps
except insofar as it clarifies the differences in positions.
Where I, and some others, have tried to go in the interest of
finding a position that everyone can live with is well short of
what I (and I think you) would like. I suspect we may still end
up pretty close to your position or mine in practice, but that
the community will need to learn, experimentally, that frequent
and detailed interactions with the IAOC does not serve either
the IASA or the IETF well. The base of that idea is that the
text in the BCP needs to reflect the following model, more or
less (the current draft text is close to this, but may need
additional editorial or even substantive tuning):
* The IAOC may establish the conditions, restrictions,
and permissions under which the IAD may make decisions
that commit the IASA without prior IAOC approval.
Subject to commercial and contractual constraints, the
IAOC may also establish the rules by which they can
reverse IAD decisions or actions after they are made.
* While lots of things may happen informally, only the
IAOC can demand that the IAD reconsider a decision or
hold the IAD directly accountable for such decisions.
Anything else creates a management-chain mess. However,
this statement is at variance with the way I read the
current text in the draft BCP.
* Any member of the community may provide free advice to
the IAOC (or IAD) by sending them notes. And any member
of the community can question a decision with a note,
preferably one that has some content along the lines of
"I think you should reconsider because you may not have
had the following information". The IAOC may respond to
such input with a changed decision, a decision to do
things differently in the future, an explanation as to
why the decision or direction are appropriate, or some
combination of them. But they are under no obligation to
do so because needing to respond to every input, no
matter how well intentioned, can easily prevent anything
else from getting done. While that concern has been
coded as "DoS attack", such attacks are really not the
problem I've been concerned about. Instead, I've been
concerned about an excess of free advice, at a micro
level, from perfectly well-intentioned members of the
community. I've also assumed that an IAOC which
decided to ignore all such input (and review/
reconsideration requests), regardless of content, would
find itself retired in due course.
* The IAB and/or IESG can ask the IAOC to "review" a
decision and can insist on a response. I/we used the
term "review", rather than "reconsider" deliberately,
although putting them together with an "or" is probably
desirable. The outcome of a review could be a
decision to reconsider (when contractually feasible,
etc.). It could be a decision that the decision was
correct, even after new information was considered. It
could be a decision to go ahead with the original
decision, but to adjust procedures to permit timely
consideration or weighting of different types of
information in the future. Or it could be something
else. The IAB and IESG get to do this, not because they
are important, or even because they are going to be the
members of the community most familiar with the impact
of IASA operations and decisions (although that will
almost certainly be the case), but because they can be
held accountable if they overload the IAOC with "review"
requests to the point that it interferes with IASA
functioning. Random members of the community, or even
collections of such members, cannot be held accountable
in the same way.
Looking at your specific questions in this context:
What's the goal of the reconsideration or review? E.g. can
this action result in the IAOC or IAD reversing or revising a
decision? If not, why do it?
It can result in a reversal or revision of a decision. Whether
it does, even if the IAOC agrees with the complaint, is up to
the IAOC. And, even if that "even if we agree, we aren't going
to change the decision" result can be anticipated, we should do
it because it is almost inevitable that we are going to learn
about what should be done here as we go along. That makes "hmm.
good point, we will do it differently next time" a valuable
result -- perhaps the most valuable result.
What's the statute of limitations for a demand for
reconsideration or review? Is an action or decision subject to
reexamination 6 months after the decision? Does the IAD or
IAOC need to announce such decisions with enough of a waiting
period that the reexamination process can take place before
the decision becomes final?
I hope we can avoid the waiting period, precisely because I
don't ever want to see the potential of that much
micromanagement from outside the IAOC (as should be obvious from
the more general comments above). But there is no statute of
limitations. The only real limitation is that, the longer one
waits, the higher the odds that the IAOC will respond "will
consider this the next time an issue like this arises" rather
than "we will change the decision". And, if the times start to
get really long the odds rise that the IAOC will respond with
"waste of time to consider this" (or not respond at all.
What is the exact set of decisions subject to this process?
Everything? Meeting sites? Meeting fees? A delay in
publication of an RFC? Cost of paper needed to support an
IETF meeting? The date of the public meeting? Etc. If we
can't come up with a description of this that isn't
"everything" I'm very concerned, but I'm having problems
figuring out what smaller set is appropriate.
Everything, although I'd expect some of the things you list to
get very brief consideration. And, to give an example I'm sure
won't arise in practice, if the IAB or IESG were to demand that
the IAOC review explain the cost of paper at frequent intervals,
I'd expect the IAOC members to make that, and its impact on
getting work done, known to the community, the nomcom, etc.
Who gets to kick this process into starting (e.g. who gets to
file a complaint)?
Anyone, but only the IAB or IESG can demand a response.
Is that what I'd like in a perfect world? Nope. Do I think it
will need tuning over time, probably in the direction of more
IASA autonomy? Yes, but maybe not in ways that change the BCP.
But I think that, given the divisions in the community over this
issue, it is probably about the best that any of us will be
able to get.
regards,
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf