Rob, The current text of 3a works for me although it looks a bit complex. So we converged.
Gert Sent from my Apple ][ On 19 Oct 2015, at 16:01, Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote: Hi Gert, On 19/10/2015 14:37, Gert Grammel wrote: Hi Kent, Here my proposals 3. Support for both synchronous and asynchronous configuration operations (see terms) A. A server may only support synchronous configuration operations, or may only support asynchronous configuration operations, or may support synchronicity to be client specified on a per-operation basis. NEW A. The way a server executes an operation (synchronous or asynchronous) is implementation specific and may change on a per-operation basis. I don't agree with this new text. I think that the server (or protocol) should specify whether it supports sync and/or async operations. But it is up to the client to choose which particular way (out of the supported options) that it wants the server to process a particular operation. Letting the server decide would seem to push additional complexity on the client. Thanks, Rob C. Support for synchronous configuration operations requires the server to block sending a response to the client until it is able to able to determine whether there are any errors in the request or errors from applying the configuration change. NEW (changed OR into AND) C. Support for synchronous configuration operations requires the server to block sending a response to the client until it is able to able to determine whether there are any errors in the request and errors from applying the configuration change. OK D. Support for asynchronous configuration operations requires the server to send a response to the client immediately indicated that the request was accepted and send a notification to the client when the intended config is fully effective or there are any errors from applying the configuration change. OK E. Support for asynchronous configuration operations MAY also provide a verify operation which a client can request from the server to obtain information regarding the difference between the intended and applied configurations. From: netmod <<mailto:netmod-boun...@ietf.org>netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> on behalf of Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>> Date: Monday 19 October 2015 15:22 To: Kent Watsen <<mailto:kwat...@juniper.net>kwat...@juniper.net<mailto:kwat...@juniper.net>>, Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>> Cc: "<mailto:netmod@ietf.org>netmod@ietf.org<mailto:netmod@ietf.org>" <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update? I meant 3.D, and so did you I think when you wrote on the 16th "E.g. change the 1.D text to..." Sorry for the confusion. Kent On 10/19/15, 9:14 AM, "Kent Watsen" <<mailto:kwat...@juniper.net>kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote: Hi Rob, I know there is an on-going discussion about the time-line of things, but the draft needs to be posted today... Can you help finalize the text? Randy offers some good editorial suggestions below, and I believe you and Gert had some ideas in wordsmithing 1.D. and bringing in error modes. Thanks, Kent On 10/16/15, 11:29 PM, "Randy Presuhn" <<mailto:randy_pres...@mindspring.com>randy_pres...@mindspring.com<mailto:randy_pres...@mindspring.com>> wrote: Hi - From: Robert Wilton Sent: Oct 16, 2015 5:12 AM To: Kent Watsen , Nadeau Thomas Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update? ... Here is my attempt at word smithing section 3: ... A. A server may choose to support only synchronous configuration operations, or only asynchronous configuration operations, or both synchronous and asynchronous configuration operations in a client specified per-operation basis. Editorial comments: - is the "may" intended as a RFC 2119 MAY? If so, this seems a semantically inappropriate use of the keyword. - please avoid unnecessary anthropomorphisms; the server doesn't "choose" anything here. - s/ in/ on/ - s/client specified/client-specified/ ... failed. A configuration protocol, or server, SHOULD provide support for rollback-on-error behavior and MAY choose to provide support for best effort semantics as well. Editorial comments: - The implications of the RFC 2119 SHOULD and MAY are quite different depending on which of the two subjects ("protocol" or "server") one chooses to think about. The server's observable behaviour is presumably circumscribed by the protocol, so I suggest removing ", or server,". - Please suppress anthropomorphisms. - s/best effort/best-effort/ Randy _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod