Hi Kent,
On 11/01/2016 20:59, Kent Watsen wrote:
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.)...
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”?
I think that the text for 2A would be more clear using MUST rather than
may (in the sense that a compliant server must choose one of the three
options listed).
Before:
A. A server may support only synchronous configuration
operations, or only asynchronous configuration operations, or
both synchronous and asynchronous configuration operations on
a client-specified per-operation basis.
After:
A. A server MUST support only synchronous configuration
operations, or only asynchronous configuration operations, or
both synchronous and asynchronous configuration operations on
a client-specified per-operation basis.
For 2B, I agree changing MAY to SHOULD but we should broaden this to
apply to synchronous servers as well. Even though a config edit
operation is synchronous it could still fail to be applied for some
leaves, and hence the intended and applied leaves could be out of step.
Hence I propose the following change:
Before:
B. Servers that support asynchronous configuration operations
MAY also provide a verify operation that a client can request
from the server to return information regarding the
difference between the intended and applied configurations.
After:
B. Servers SHOULD also provide a verify operation that a client
can request from the server to return information regarding the
difference between the intended and applied configurations.
For 2C, I think that the "may" should change to "SHOULD", otherwise the
requirement that "rollback on error" semantics SHOULD be provided
doesn't seem well grounded.
So, before:
C. The configuration protocol MUST specify how configuration
errors are handled. Errors MAY be handled by semantics
similar to NETCONF's error-options for the <edit-config>
operation (stop-on-error, continue-on-error, rollback-on-
error), as described in Section 7.2 in [RFC6241], but
extended to incorporate both the intended and applied
configurations. Support for "rollback on error" semantics
SHOULD be provided.
After:
C. The configuration protocol MUST specify how configuration
errors are handled. Errors SHOULD be handled by semantics
similar to NETCONF's error-options for the <edit-config>
operation (stop-on-error, continue-on-error, rollback-on-
error), as described in Section 7.2 in [RFC6241], but
extended to incorporate both the intended and applied
configurations. Support for "rollback on error" semantics
SHOULD be provided.
Thanks,
Rob
FWIW, the other requirements docs listed above also use "MAY" in some of their
“requirements"
Kent
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
