John C Klensin wrote: > If the IESG wants to see 2119 invoked via some specific sentence > if it is invoked at all, what difference does that make that is > worth a fight, especially given the tendency to turn IDNits > suggestions or warnings into firm rules (that tendency may be > worth fighting, but the text, IMO, is not). > If you, or anyone else, believe that the IESG has gone too far > over toward rules and assertions of their own authority > vis-a-vis the community, tell it to the Nomcom
Hi John, I'm not very interested in fights about trivial IDnits. AFAIK the IESG has no problem with using a full 2119 boilerlate, or a boilerplate truncated to the actually used 2199 terminology, i.e. what I called "Bruce's style" (with a reason, see below). Truncation requires more attention by authors, it would be wrong to define only SHOULD, but actually use MUST. The "IDnits tool" is a stupid script, it can check that you use 2119 terms without boilerplate. It can identify the full boilerplate. It emits a warning for a truncated boilerplate, because it does not check if you use MUST without definition. That's all, quite harmless, no fight and no issue an IESG review. Last year you feared that you "MUST" have "I18N considerations" in a memo that's about I18N starting with the abstract and ending with the Acknowledgements. The author of this rule in RFC 2277 and others talked you out of this, it is *NOT* required when it makes no sense (as in a document about EAI, pure I18N). Rules must make sense. Not talking about I18N without obvious reason would be wrong. As expected your memo without "I18N considerations" was approved without any problems. Just for fun also the opposite case, Bruce didn't believe that his style is nicer and better readable, as I did. He believed that his style is REQUIRED, and submitted errata when documents used the full 2119-boilerplate without using all key words. IMO that was nonsense, and his editorial errata should be summarily rejected (for this issue, not everything he reported). So if there was a fight, it was his fight, and I think Bruce lost it. A different issue are "IANA considerations", they are used as a flag for IANA to signal "nothing to do", after that they can be removed in AUTH48. That makes sense, of course it might be odd for folks who authored RFCs before that convention was invented. But it's nothing to fight about, "security considerations" are also required, even if they end up to repeat what is already said elsewhere in a memo. Actually the presence indicates that the authors tried their best to find potential security issues. In practice that might not work as expected, but just removing this requirement because authors could cheat is no good idea. And for me the 2606 recommendation also makes sense. Not for a fight, I wouldn't appeal the publication of 2821bis for the high crime of using foo.bar in 19 examples or similar nits. For a fight I'd want big and evil enemies, as in the various MARID fights. Or the ooXML fights elsewhere, affecting the IETF only remotely with the broken wannabe-pack: URI scheme. > I believe that the IESG must have broad discretion in order > to do its job and to keep the rest of us from getting bogged > down in even more mechanistic rules that we have to follow > even if it violates good technical judgment. ACK. I'm far from sure that "we" (as the IPR WG) managed that with the new IPR rules, but I still hope "we" at least managed to make this not worse than it is (with the current rules). >> Address the real problem: >> | Readers are cautioned to use examples as described in >> | RFC 2606 in their texts to avoid the various problems >> | with real or potential domains in examples as explained >> | in the security considerations of this BCP. > I don't believe that there is sufficient consensus in this > group that there are actually problems the use of bogus > domains in actual examples or few-time tests. That's why we don't agree about this. I think this *is* the problem with using made-up "real" addresses and domains in examples (without consent of their owners or future owners). You can certainly tune this in various directions, as long as readers understand that they are not supposed to make up similar examples only because 2821bis did it for historical reasons. The old examples in 2821 are anyway "burnt", they are no part of the problem. Taking FOO + BAR as funny, and based on that trying something else, say SUN + JCK, could be a problem. In odd senses, "why is there an ad for SUN, but not for IBM", or straight forward, address harvester adds JCK to its list. > Appeals by relatively sensible people protesting apparently > poor and badly-documented decisions and asking that the IESG > go back, review them again, and either change their minds or > at least document their reasoning are an important check on > the process. Your gateway appeal back in 2005 certainly influenced one to three later technical appeals, as you might have guessed. :-) > I suggest that the process is working. If they improve the I-D Checklist and maybe tune the tracker. They could also forget this if more pressing actual events (IPv6 issues, DNS issues, IDN "fights", ...) distract them. Frank
