[As a contributor]
And just when I thought we were done with this draft ;) >>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 This does seem better, thanks for the suggestion. I view this as an editorial fix. >>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. I agree with Gert on this one - and it is what I told Benoit I would do... My observation that the “difference” could be as simple as a flag or as complex as an actual diff. When considering the former, there is no need for an addition verify option when a synchronous call is made, whereas a verify option *would* be useful when an asynchronous call is made. That said, when considering the latter, it seems that a verify option would always be useful. Being conservative, I choose to believe that “difference" has the simplest meaning and hence conclude that the SHOULD only applies to servers that support asynchronous configuration operations. This doesn’t mean that a solution can always provide a verify operation, of course, and if the result includes an actual diff, it’s value will be understood as being generally useful. Makes sense? >>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 This does seem better than the s/MAY/may/ I proposed to Benoit. The important thing to me is that there is still a lot of leeway in the "handled by semantics similar to” clause. It’s just saying that the client SHOULD have some control over error handling, which I think is still in keeping with the original phrasing of the requirement. So I view this as another editorial fix. Thanks, Kent _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
