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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf