My first reaction was that the entire topic is a bike shed. The goal is clear and understandable specifications and 2119 is just a tool we use to make the process of producing and reading specifications more efficient. What I'm getting from this is that there are a significant number of drafts being submitted to the IESG for publication that are not sufficiently precise in their use of language. Deciding to revise 2119 seems - at first blush - an interesting reaction to this problem. But it's become evident that we don't share a common understanding of the language, nor are we consistent in its application. Formalizing usage patterns (c.f. server MUST/client MAY, MUST...UNLESS...) does help, if only because you've made it easier to do the right thing in more cases. If the problem is that authors and editors don't have the tools they need, then maybe a revision is the right approach. However, I'd still like to see more RFCs that describe something without resorting to using these crude implements. On 2011-08-31 at 05:08:15, Adam Roach wrote: > There is no reason to tie authors' hands by restricting them from > using perfectly good English words just because they happen to be the > same symbols used by RFC 2119. If we're going down this path, let's > scrap using MUST/SHOULD/MAY/etc, and formalize our conformance terms > with symbols that aren't English words. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf