Rob, Can you take all the comments from this thread to update the proposed definitions for "synchronous server" and "asynchronous server" terms?
Thanks, Kent From: Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>> Date: Thursday, October 1, 2015 at 5:50 AM To: Mahesh Jethanandani <mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>> Cc: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>, "netmod@ietf.org<mailto:netmod@ietf.org>" <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied) On 01/10/2015 00:55, Mahesh Jethanandani wrote: One comment. On Sep 30, 2015, at 8:02 AM, Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote: Hi Kent, Just some quick comments inline ... On 30/09/2015 15:31, Kent Watsen wrote: [As a contributor] I find that the term "system" is a bit ambiguous in this context. It is talking about the NMS, the server, or both together? [KENT] I believe that we're talking about the NETCONF/RESTCONF/<foo> server, specifically in how it processes update requests. Anyway, I've tried to define them relative to the configuration operations being performed. [KENT] Perhaps these could be collapsed if we use the terms "a/synchronous server" ? Personally, I think that defining the operations is arguably more useful because it is feasible that you could have a server that supports both sync and async operations and allows the client to choose which semantics should be used for a particular request. Synchronous configuration operation - A configuration request that the server applies synchronously with respect to the client request. Before the server replies back to the client indicating the success or failure of the operation it MUST semantically validate the contents of the request and update the intended configuration of the target datastore. If the request is to the running datastore then the configuration change MUST also be applied in the system before the server replies back to the client. The reply to the client indicates whether there are any semantic errors or system errors from applying the configuration change. [KENT] This generally matches my understanding, but here are some thoughts to improve it: 1. I think the language "semantically validate" would exclude an ephemeral datastore. We could put a qualifier on it, but I think it can be removed entirely as each datastore already has its own semantics around how it processes update requests. My aim here is potentially tied to the definition of intended config, were I am suggesting that the system has to at least have been checked that the request is well formed and any YANG constraints in the data model have been met, before it is accepted as intended config, otherwise it would be rejected. 2. I like how you call out the running datastore, but it is somewhat NETCONF-specific. How about something like "If the request impacts the intended configuration (see term), then..." Yes your text is better and I agree that we should avoid making the description NETCONF specific at all. 3. "applied in the system" seems too open ended, how about this: "...MUST also be propagated to and processed by the operational components of the server before..." ??? So my aim here was to tie it back to the definition of "applied configuration", but this could probably be expressed in a more direct way, e.g. perhaps ".... MUST update the applied configuration in the system before the server replies …" If I understand this correctly, we are still talking about “applied configuration” as configuration that has been written to datastore/hardware/line card etc. It does not imply that anything has come out of it, including whether the configuration is usable. That operating configuration (and I just introduced another term) will be reflected by derived state. Is that true? Yes. Rather than operating configuration I would perhaps say the "observable system behaviour is reflected by derived state". E.g. if you were to change the MTU of an interface to a different value (that was say incompatible with a peer device) then the "applied configuration" for the MTU leaf would only tell you whether or not that MTU was actively being used by the system. It wouldn't tell you that an ISIS session on that interface had gone down due to the MTU incompatibility. That could only be observed by the changing of the derived state representing the status of the ISIS session (or an alarm). Thanks, Rob
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
