John's concern and suggested improvements work for me.
FWIW, I am more comfortable with 2026-style appeals when we're talking about publishing a protocol specification than I am when we're talking about (for example) contracting for an IETF meeting location. The short-term downside of not making a decision is a lot higher in the second case - and John's suggested text seems to limit the DoS characteristics, which I like.
Spencer
From: "John C Klensin" <john-ietf@xxxxxxx>
Harald,
Another dissenting view...
Unless we modify the suggested text to deal with all sorts of cases that we probably can't predict and that would make things quite complicated, I don't see this working as intended. The sorts of cases I'm concerned about include not only information given the IAOC under non-disclosure provisions but also personnel matters, matters that could become the subject of litigation or that were already being litigated, and so on, for probably a longer list than I can imagine.
It probably will come as no surprise that I'm uncomfortable with the potential intersection of "whipped-up mob" with "administrative entity and processes".
So let me suggest an entirely different model for your consideration:
(1) The IAB and/or IESG can formally ask (I don't care about the details) the IAOC, or the IAD, to reconsider its decision on any matter. If such a request is made, the relevant body or individual is obligated to review the decision, seek more voters or a larger consensus if possible, and then either reaffirm the decision or make another one.
(2) Any member of the community (or, preferably, any handful of members of the community) can ask the IAB and/or IESG to initiate such a reconsideration request. The decision on that request t initiate reconsideration can be appealed using normal mechanisms.
(3) If the IAOC regularly misbehaves, the correct remedy is to fire them, just like any other body acting as a board of directors. So we need to look carefully at recall and related procedures and make sure that they can be used... easily enough, but no more easily than that.
Following the model of the current text leads to opportunities for micromanagement by appeal, and, if the IAOC and IAD are to be effective, we just don't want to go there. Put differently, if people don't believe that The Right Thing is being done, they shouldn't be looking in detail at particular decisions. They should, instead, be suggesting that the IAOC review its own decisions contributing whatever additional information is available to that review. And, if the IAOC adopts a pattern of doing Wrong Things, it should be time to replace them (starting with a request for resignations), not to try to retune or override individual decisions.
Get the right people into these positions, and then let them do the job.
If we can't find the right people and put them there, then none of these procedures --other than firing the duds and trying again-- are good enough to protect the IETF. Perhaps worse, we then run the risk of getting us seriously bogged down while we try to use those incremental correction procedures.
john
--On Wednesday, 22 December, 2004 16:21 +0100 Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx> wrote:
These two tickets are linked, as both contain discussions on how the IAD and the IAOC behave where people believe that they have not done the Right Thing (for whatever meaning of "right").
The text from the head of the #720 thread:
While there is a method to appeal procedural lapses by the IAOC, and I am fine with that, there does not seem to be a way for a member of the community to question, i.e. appeal, the actions of the IAD. I.e. 3.4 does not contain method to appeal the actions of the IAD for procedural issues or suspected malfeasance.
The thread in #725 is rather convoluted, and touches upon a number of issues - DoS attacks, ability to appeal decisions rather than procedure violations, recourse to recall and whether that is appropriate.... go read the thread for details.
The current relevant text from 3.4 is:
If someone believes that the IAOC has violated the IAOC rules and procedures, he or she can ask the IETF leadership to investigate the matter, using the same procedure as is used for appeals of procedural issues in the IETF, starting with the IESG.
If the IESG, IAB or the ISOC Board of Trustees find that procedures have been violated, they may advise the IAOC, but do not have authority to overturn or change a decision of the IAOC.
and from 3.2:
The IAOC's role is to provide appropriate direction to the IAD, to review the IAD's regular reports, and to oversee the IASA functions to ensure that the administrative needs of the IETF community are being properly met.
Suggested resolution:
1) Make a separate section for the appeals stuff in 3.4 (for clarity), so that this becomes section 3.5
2) Change the section to read:
If someone believes that the IAOC has made a decision that is clearly not in the IETF's best interest, he or she can ask the IETF leadership to investigate the matter, using the same procedure as is used for appeals of procedural issues in the IETF, starting with the IESG.
In cases where appeals concern legally-binding actions of the IAOC (hiring, signed contracts, etc.), the bodies handling the appeal may advise the IAOC, but are not authorized to make or unmake any legally binding agreements on the part of IASA.
In cases where no legally-binding actions are at stake, the bodies handling the appeal may nullify the IAOC decision and ask IAOC to restart its decision process.
(mostly suggestion from Margaret)
3) Add the following to the IAOC's role in 3.2:
The IAOC will hear and respond to concerns from the community about the activities of the IASA.
Does this make sense, or are we leaning too far in the "too many appeals" direction?
Harald
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf