Hi. After reading both the "IONs and discuss..." thread and last month's discussion about the ION Experiment and RFC 4693, I want to repeat something that at least some of us discussed extensively during the NEWTRK period (and maybe the POISSON period before that). Part of this has been said in the last few days, but bears repeating in the current context. Several of us have observed that the IETF is not very good at writing precise procedural rules. Some of us would even claim that history shows that we are fairly poor. Part of this is a phenomenon often called "fighting the last war" -- we tend to see a particular problem occur and then change the rules to deal with that problem, even if the odds of its recurring are low. Cumulatively, that results in procedures that have so many specific cases that no one really understands them. Worse, we can never anticipate all future cases that might need special handling, so we either need to be continually revising any precise rules or we need to tolerate simply ignoring them when they seem inappropriate. None of those situations is good, especially since cycles spent dealing with procedural issues are generally cycles that are wasted (and not recoverable) as far as the real work of the IETF is concerned. Our best way out of the trap posed by our difficulties with writing exact procedural documents and our inability to foresee the future is to give the IESG a lot of discretion but, to use Ted's language, hold them accountable. What I think I learned during the NEWTRK work is that this means, in practice, that... * Any update to 2026 or other core documents should limit itself to principles, not procedures. We could probably use a better statement of principles about the general conditions under which the IESG is expected, or permitted, to hold up a document. Getting down to the "what is a DISCUSS and how they are administered" is much too far into the procedural area. * The community should expect that the IESG will figure out procedural rules that work for it, that they will announce those rules to the community, and that they will be receptive to input about them. * Whatever those rules are, the IESG may change them at its discretion, but should be prepared for input to the effect that the ADs must have better things to do with their time. The things the IESG is not permitted to do are to change the rules without telling the community or to ignore the rules it has set. To borrow from specific POISSON and NEWTRK discussions, games of "Gotcha" based on "we know the rules and aren't going to tell you enough that you can make predictions" are not a legitimate activity. * While one would hope that the IESG would be receptive to informal community input and calibration, choices of procedures can be appealed if necessary and exceptional demonstrations of bad judgment are legitimate subjects for discussion with Nomcoms and/or Recalls. Similarly, once the IESG says "we do things this way" and gets community consensus that the procedure is reasonable (even if that consensus is interpreted from bored silence), doing things in a different way is subject to appeal. * The community should never tolerate repeated demonstrations of bad judgment. While such things have been rare in the history of the IESG, community tolerance for it tends to be interpreted as approval and often causes things to get worse. If we can't trust the IESG that much, or can't get people onto the IESG who are of sufficient caliber that we _can_ trust them that much. What is interesting about all of this in the context of recent discussions is that it makes little difference how the procedural rules are stated or the medium in which they are published. I would expect the IESG and appeals bodies to take a statement about how the IESG intends to work seriously whether it is shouted from the rooftops, embedded in an ION, turned into a BCP, or chiseled in large letters on stone tablets. If that is not the case, I think we have worse problems than an ION versus BCP debate. Moreover, if the IESG were to go back to whispering about policy changes, or even shouting them from rooftops, rather than publishing things in some place accessible, I would hope that the community would take serious exception to that approach. Some of this points out, once again, that BCPs are probably the wrong mechanism for reaching consensus on and publishing process documents, regardless of what we do with IONs. Should we keep IONs and, if so, should we keep them in their present form or so some tuning? Frankly, I don't care about the specifics. But, if we get rid of them and the price is either (i) to try to give BCP status to relatively informal statements about interpretation of principles or (ii) to encourage the IESG to keep its real procedures secret because there is no place to put them, I think those would be significant steps in the wrong direction. best, john _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf