Hi Kent,

[btw, speaking as a contributor]
Hi Benoit,


You use MUST, SHOULD, MAY, and you refer to RFC 2119. Fine.
However, it might be beneficial to say something such as in RFC 7698

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in [RFC2119].

    While [RFC2119] describes interpretations of these key words in terms
    of protocol specifications and implementations, they are used in this
    document to describe design requirements for protocol extensions.
Is this needed?  Looking at RFC2119, I don’t read it as being very particular 
about the context it’s terms are used in.

Additionally, other requirements docs use RFC2119 without any such a paragraph 
(e.g., RFC7698, RFC7497, RFC7449, etc.)...
Yes, I've seen those RFCs. The IETF is not really consistent regarding RFC 2119 and requirement documents. So I wanted to put the issue on the table. No strong view on way or the other.


Btw, I never quite understood what a MAY means for a requirement.
See requirement 2B and 2C
For 2B, would you rather is be a SHOULD?
For 2C, would you rather this be a “may”?

FWIW, the other requirements docs listed above also use "MAY" in some of their 
“requirements"
I saw that.
Changing the MAY keywords the way you proposed is one solution, but more importantly, you should tell us what is intent behind a MAY sentence is.
From 2119:

   5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
       truly optional.  One vendor may choose to include the item because a
       particular marketplace requires it or because the vendor feels that
       it enhances the product while another vendor may omit the same item.
       An implementation which does not include a particular option MUST be
       prepared to interoperate with another implementation which does
       include the option, though perhaps with reduced functionality.
   In the
       same vein an implementation which does include a particular option
       MUST be prepared to interoperate with another implementation which
       does not include the option (except, of course, for the feature the
       option provides.)

So it means that the specified solution MAY or MAY not have this functionality, right? So what is the requirement? Maybe it's not a requirement, but just something to think about.

Regards, Benoit



Kent



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to