Sam,
Let me first take another stab at recap'ing the discussion that
lead to my proposal for 3.5 and 3.6, and clarifying what I
intend as a distinction between them.
As I understood them, John Klensin, Mike St.Johns, and others
were concerned about creating an IASA that could not or
operate without constant checking by the IETF community (having
their feet shot at, in the worst case). That makes sense
to me -- the IASA, as a separate activity, should have clear
boundaries of responsibility. The IETF community
as a whole should not become the invisible hands driving
the IASA actions. This is the intent of section 3.5.
At the same time, the IASA is meant to be responsive to the IETF,
and should not be able to lose track of that. We should have a
mechanism for expressing when we think the IASA is not behaving
according to its rules (the BCP, and operational guidelines it
develops to carry out those functions). This is the intent
of section 3.6
So, I don't (personally) expect a future where individual
IETF participants can derail a proposed meeting site because
they don't agree with it. However, individual IETF members
should be able to point out that a proposed meeting site
selection is not in line with state operational guidelines
for picking meeting sites (which might include proposing them
publicly for 2 weeks before finalizing, for eg).
To your specific question of how my proposed 3.5 and 3.6
(reproduced below for those who didn't memorize them) fit
with Margaret's notes:
[Margaret wrote:]
(1) I agree with you that we do not want a review process (whether
> invoked by an individual or by the IAB and IESG) that can overturn a
> contract award or hiring decision after that decision is made. The
> current proposed text (I think that the latest was from Leslie) makes
> the community impotent, without properly restricting the review requests
> from the IAB/IESG, IMO.
Well, I disagree that it makes the community impotent. See my
note to Avri today. My text does attempt to make clear what level
individual IETF members should get involved at.
So, the intent of my proposed text is to not only prevent
undoing of signed contracts, but also say that the IETF in
general should not be focused on every action that leads to
such contracts. I believe this is a point where Margaret and
I disagree.
(2) I think that the review process should be well-enough specified
> that a person who is not a (past or present) member of the I* could use
> it. This means that it needs to say where you send a review request, how
> you unambiguously identify a formal review request and what a review
> request should contain. This should be at least at the level of detail
> seem to find that process confusing enough that they don't often get it
> right).
Section 3.6 attempts to be clear about its review process. It
may not be sufficiently detailed. I think it is probably detailed
enough for the RFC. (Further detail could be... operational guidelines).
(3) I think that review requests should be limited to situations
where
> the IAOC violates written procedures (their own or the IASA BCP) and/or
> makes a decision that is against the best interests of the IETF. The
> request for review should be specific about what procedure was violated
> and/or how a specific decision runs against the IETF's interests.
I believe my text agrees with that. I'm positing that "best interests
of the ietf" are captured in the BCP and the operational guidelines;
to the extent that they do not, then it would be hard for the IASA
to know what it was supposed to have done. This may mean that
operational guidelines need to be created or updated for future
situations.
(4) Personally, I think that any member of the community (and yes, I
> understand that means the general public) should be able to make a
> formal review request and expect to get a response from the IAOC within
> a reasonable time period (~90 days). I do not think the response needs
> to be a lengthy hearing, or a complex legal document. But, I think that
> we should have a review process, open to everyone, where a response is
> mandated. The response could be: "We looked into this decision, and we
> didn't find anything irregular about the decision or about how it was
> reached".
I think the latter is achievable under 3.6, or a very slight
modification thereof. Earlier today I suggested that I thought
the last "Answered requests..." should be modified to "All requests...",
and it's not a big step from there to saying that all requests
are answered even with a short statement like hte last. I
don't have an issue with that. Others concerned about DoS
attacks might.
(5) I think that there should be at least one level of escalation
> possible if the person requesting a review does not receive a
> satisfactory response from the IAOC (I had suggested that this would go
> to the IESG). I don't think that the person should have to persuade the
> IAB or IESG to act on his/her behalf (which is another way in which the
> current process is really only open to political insiders), I think that
> the IESG (or whoever we use as the next level lf escalation) should be
> required to consider the IAOC's response and respond to the escalated
> review within a reasonable timeframe.
I don't have an opinion here. There have been cogent arguments against
making the IAB/IESG the next level of escalation, or the ISOC BoT.
Others who had stronger feelings should comment.
(6) I do not think that we want the IAB or IESG (or anyone else) to
be
> able to overturn a decision of the IAOC, only to advise the IAOC that
> they believe that an incorrect decision was made.
I don't have an issue wiht this, and I don't think the text
suggests any.
So -- what was the problem with the proposed text and these
principles (apart from the one noted disagreement, above)?
Leslie.
[I had proposed 3.5 and 3.6:]
3.5 Business Decisions
Decisions made by the IAD in the course of carrying out IASA business
activities are subject to review by the IAOC.
The decisions of the IAOC must be publicly documented for each formal
action.
3.6 Responsiveness of IASA to the IETF
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 operation 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 there are reported objective
performance metrics for all IETF process supporting activities.
In the case where someone questions that an action of the IAD or the
IAOC has been undertaken in accordance with this document
or those operational guidelines (including the creation of an
appropriate set of such guidelines), he or she may ask for a formal
review of the action.
The request for review is addressed to the person or body that took
the action. It is up to that body to decide to make a response,
and on the form of a response.
The IAD is required to respond to requests for a review from the
IAOC, and the IAOC is required to respond to requests for a review
of a decision from the IAB or from the IESG.
If members of the community feel that they are unjustly denied a
response to a request for review, they may ask the IAB or the IESG
to make the request on their behalf.
Answered requests for review and their responses are made public.
Reviews of the IAD's actions will be considered at his or her following
performance review. Reviews of the IAOC's actions may be considered
when IAOC members are subsequently being seated.
Sam Hartman wrote:
I don't think I can support your proposed text. I still don't
understand what your proposed section 3.5 does and don't think I could
go along with the plausable readings I'm coming up with for that text.
I don't think your text does a good job of meeting the principles
Margaret tried to outline; in particular it seems to fail to meet the
principle on escalation. I'd be very interested in an explanation of
how you think it compares to those principles.
--Sam
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf