See below ..
On 2016-15-01 18:24, "netmod on behalf of Robert Wilton"
<netmod-boun...@ietf.org on behalf of rwil...@cisco.com> wrote:
>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.
Gert> support
>
>
>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.
Gert> as per definition of synchronous, the confirmation has to indicate
that the intended config has been applied or has been failed. I therefore
like to keep the current text suggesting to change the existing text
slightly (SHOULD instead of MAY):
B. Servers that support asynchronous configuration operations
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.
>
>
>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.
Gert> support
>
>
>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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
