Sam Hartman <hartmans-ietf@xxxxxxx> writes: > 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. I'm not sure I necessarily agree with Margaret's principles. Here's a cut at a set of my own: Any set of rules for how the IASA makes decisions and how the IETF can influence them needs to satisfy two somewhat conflicting constraints: 1. Preserve the openness of the process and allow the IETF to supervise IASA in order to ensure that it is serving the interests of the IETF. 2. Allow the IASA to make decisions without being second guessed at every turn by individual IETFers who happen not to like them. This is always a tricky problem, but we have a model to fall back on, which is RFC 2026 and 2727. We have three major mechanisms for the community to provide oversight for the IESG and IAB: 1. Appeals up the chain (S 6.5 of RFC 2026) for mistaken decisions by IESG. 2. The nomcom and recall process (RFC 2727) for misconduct by IESG/IAB members. 3. Creating new RFCs which constrain the behavior of IESG and IAB. It's important to note two things about these mechanism. First, each has its own role. Individual appeals, even if successful, do not really constrain the IESG's behavior in the future. Conversely, we generally don't attempt to write new RFCs to reverse specific IESG decisions, nor would we expect that they would succeed. Second, 2026 grants both the IESG and IAB a fair amount of latitude about how to structure their internal procedures. In particular, the IESG and IAB rules about how they reach decisions are largely self-made, with only very modest amounts of guidance from the RFCs. I think it's generally considered that that's a good thing. 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 recognize that point (3) above is somewhat controversial, so I'll attempt to justify it a bit. The simple fact is that the IASA (both IAD and IAOC) will be constantly making business decisions and if we are to keep the job manageable (and in the case of IAD keep the costs down) they have to know that they will not be constantly second-guessed by the community on what kind of cookies they purchased. If the community feels very strongly that the wrong kind of cookies were purchased then they can ask for a rule demanding chocolate chip, and in the worst case pass a chocolate chip cookie RFC. There's a parallel here in the RFC 2026 appeals process. While the IAB and IESG can review a decision both for process violations AND for technical merit, the ISOC BOT is extremely constrained in that it can only provide limited procedural review (S 6.5.3) Further recourse is available only in cases in which the procedures themselves (i.e., the procedures described in this document) are claimed to be inadequate or insufficient to the protection of the rights of all parties in a fair and open Internet Standards Process. Claims on this basis may be made to the Internet Society Board of Trustees. The President of the Internet Society shall acknowledge such an appeal within two weeks, and shall at the time of acknowledgment advise the petitioner of the expected duration of the Trustees' review of the appeal. The Trustees shall review the situation in a manner of its own choosing and report to the IETF on the outcome of its review. The Trustees' decision upon completion of their review shall be final with respect to all aspects of the dispute. It seems to me that this is a good model to follow for IASA. I've deliberately avoided trying to write text because I think it's important to agree on principles first. -Ekr _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf