On 1/4/13 11:39 PM, Mikael Abrahamsson wrote: > As an operator, I purchase equipment and need to write RFQs. I would > like to able to ask more than "does the product implement RFC > <whatever>", I want to also ask "Please document all instances where you > did not follow all MUST and SHOULD, and why". > > Otherwise I think there needs to be better definition of what it means > to "implement" or "support" an RFC when it comes to completness and what > this means as per following SHOULD and MAY. I think being clear about who our constituencies are and what they need is probably key to coming to any sort of agreement on any of this. We've often complained about the lack of operator participation and Mikael's comments may be an example the consequences of that - that we don't fully understand how our documents are being used. That said, frankly I've tended to assume that language in standards documents is normative unless otherwise specified, and that highly legalistic language is difficult to read. On a third hand it wouldn't be a small thing if non-native English speakers had an easier time with our documents if every single normative thing in document is flagged through the use of 2119 language. So, basically where that leaves me is: 1) language in standards-track documents is already normative by default; 2) however, if inserting 2119 language in all standards-track documents will make documents more useful to people who actually run networks and/or clearer to people whose first language is not English, it's probably worth tightening up our language. Melinda