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