Ned wrote: > In particular, I see very little evidence that all these > rules are helping us get things "right" in the only sense > that matters: Producing clear technical specifications > for the protocols people need.
For some RFCs I care about a few written or unwritten rules helped to get it "right": It is just not allowed to ignore IPv6, I18N, security, or IANA. IMHO 2821bis is shorter and clearer since John replaced the verbatim copies of 2119 definitions by a simple reference, and his proposal to put that reference above the first use of these key words would again improve 2821bis. When somebody proposed to add new key words in a 2119bis to indicate a SHOULD expected to become a MUST later I thought "omigod, folks *just* agreed on using 2119, why can't they stick to it now ?" (For a value of *just* = 2821bis-07 in 2008) When 2821bis and 2822upd are STDs I hope that MIME can be also advanced mostly "as is", updating the syntax to ABNF, plus some on topic remarks in the security considerations. Using the same STD 68 ABNF everywhere, as far as RFCs use a form of syntax where that makes sense, is friendlier for readers, especially implementors and operators. It's not that the STD 68 style is especially nice, but it is good enough, and a consistent style in related RFCs is a good thing. E.g. the oddities of #-constructs almost guarantee interoperability issues, and STD 68 doesn't offer this #- "feature". In theory folks could reinvent it <shudder /> [about the "cut-off" ritual] > The painful reality is that another effect of all these > byzantine rules is that fewer and fewer people are > willing and able to navigate the treacherous waters we > have created. Getting an RFC number for an Internet Draft is extremely difficult for folks not familiar with those byzantine rules. Now if your proposal boils down to "undocument" some "de jure" rules while their "de facto" variants are still used it would be worse. My approach (after MARID) was "your only chance is to grok all their weird rules, and then beat them in their own game". Quite literally, IIRC I started to expriment with the "A. Mouse" xml2rfc example days after that WG was terminated. At that time Brian's marauder's map did not yet exist, unfortunately. And I was determined that RFC 4408 will follow any comma in any stylistic rules, I-D checklists, or BCPs, expired or otherwise, that somebody could dig up in a Last Call. [Various folks including me still missed the detail that IETF Last Calls are not required for "IETF experiments" in those byzantine rules. Today I'd know where to find "IESG review" at the end of chapter 4.2.3 in RFC 2026.] Unsurprisingly I'm now stunned when folks propose to use say an IPv6 address not covered by RFC 3849 in examples, or have syntax errors in their ABNF in an IETF Last Call. Those "byzantine rules" can also protect folks, and they might need protection from the PTB far more urgent than the elimination of some (documented) questionable rules. Frank
