John C Klensin wrote: > 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. You could say roughly the same about the IETF not being as good as it should at producing valid ABNF, or giving correct examples in RFCs as soon as this involves to determine say an MD5. Sooner or later issues are reported, e.g., as errata, and fixed. For technical problems because it is the only way to get from PS to DS and beyond, for procedural problems because somebody cares to try it. It can be as simple as s/member/participant/g in a "procedural" draft I'm interested in. Correct terminology can be very important, no matter if it is about "members" or "bounce addresses". > this is a phenomenon often called "fighting the last war" Yes, and that is not necessarily futile if it boils down to fix known issues or to document lessons learned. > Cumulatively, that results in procedures that have so many > specific cases that no one really understands them. When that happens it is time to replace whatever it is by a KISS solution. This is not limited to "procedures", it also affects technical specifications like say Digest-MD5. > Any update to 2026 or other core documents should limit itself > to principles, not procedures. There are very precise procedures in 2026 like the STD 1 rules. IMHO it is no waste of time to fix rules that are "obviously" ignored. What might be a waste of time is to burden simple fixes with philosophical principles about DISCUSS or NOMCOM. Please do not reject simple fixes, please use the same overall design principles for IONs and "PUFI" as you would use for say IDNA and SMTP. > Getting down to the "what is a DISCUSS and how they are > administered" is much too far into the procedural area. Yes, that is in essence the idea of IONs. If IONs are judged to be too much work going back to shaky "procedural BCPs" is the only reliable solution for "O" participants. > 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. That is also a part of the ION concept: *Public*, *documented*, and *binding* rules without the need to track down obscure IAB pages, IESG minutes, or recent change patrol in a wgchairs wiki. > exceptional demonstrations of bad judgment are legitimate > subjects for discussion with Nomcoms and/or Recalls. NOMCOM and recalls are for "P" participants, and no way to clear a DISCUSS, or to decide wich parts of a NOMCOM questionnaire are confidential wrt the IAB. By design almost anything related to NOMCOM and recalls excludes "O" participants, "O" participants are not entitled to spend the money of paying "P" participants. > 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. In theory (until the I* find a trick to adjust their killfiles without saying so) anything can be appealed, silly examples, why do we still use binary bits when "ternary bits" are better, or why does IETF 71 use US "summer time" before spring in winter. But a real appeal based on "John posted on the general list that xyz is IETF consensus by bored silence" would be rather shaky. While the IAB might think that "precedence" is a legal concept in parts of the world, it is no legal concept in other parts of the world, back to the times of Napoloeon (maybe, IANAL). > 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. Some judgement calls are tricky. I could argue that the IAB has no business to overrule NOMCOM, and after I managed to convince enough folks that this is consensus I could "sell" the IETF to anybody wishing to spend about two years and 20,000,000 USD for the purpose of getting an RFC number for ECMA 376 or similar :-| > I think we have worse problems than an ION versus BCP debate. Likely, but finding enough folks to agree on the same definition of "worse" would be a challenge. > BCPs are probably the wrong mechanism for reaching consensus > on and publishing process documents, regardless of what we do > with IONs. s/probably/likely often/ and s/regardless of/also depending on/, in context very near to a NAK. After all a BCP is supposed to be a kind of consensus at the time it was approved. An example is RFC 2418 chapter 4 beating RFC 3710 chapter 4.3 from my POV. The latter or both could be IONs - I'd prefer it if RFC 2418 is not replaced by an ION. > 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. +1 for your conclusion: Frank _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf