Well, I've learned some things here, and shall attempt to summarize: 1) First. the "1" key is really close to the "2" key, and my spell-checker doesn't care. Apparently, I'm not alone in this problem. 2) We're all over the map in our use of 2119 language, and it is creating many headaches beyond my own. 3) The majority of respondents feel that 2119 language should be used as stated in 2119 -- sparingly, and free that MUST is not a substitute for "does". But some people feel we need a more formal specification language that goes beyond "key point compliance" or "requirements definition", and some are using 2119 words in that role and like it. I'm torn as to what to do with the draft in question. I picked up an editorial role after the authors fatigued in response to some 100+ AD comments (with several DISCUSSes) and a gen-art review that proposed adding several hundred 2119 invocations (and that was backed up with a DISCUSS demeaning that the gen-art comments be dealt with). My co-editor, who is doing most of the key-stroking, favors lots of 2119 language. And I think it turns the draft into unreadable felrgercarb. But there's nothing hard we can point to and say "This is the guideline", because usage has softened the guidelines in 2119 itself. It's rather like those rules in one's Home Owner's Association handbooks that can no longer be enforced because widespread violations have already been approved. There appears to be interest in clarification, but nobody really wants to revise the immortal words of RFC 2119, although there is a proposal to add a few more words, like IF and THEN to the vocabulary (I'm hoping for GOTO, myself; perhaps we can make 2119 a Turing-complete language.) -- Dean