Hi, I find this exercise to classify servers as synchronous or asynchronous mostly useless. We have both types of instrumentation in our server. They can be different on a per-node basis. They can both take a long time or both be instant, depending on the instrumentation code the vendor writes.
In any case, the server does not know if the instrumentation has finished making the network behave according to the new edit. That would be new functionality that no vendor supports at this time. Currently servers return "ok" if the edit is accepted into the running datastore. There are no other semantics wrt/ returning "ok". Even something as simple as "set the log-level" could be centralized or distributed. So every single leaf is a separate case and every single implementation of every leaf is a separate case. It is completely implementation-dependent. One platform may take a long time and another from the same vendor may not, for the exact same leaf. So instead of talking about the entire server being sync or async, we need to talk about a specific implementation of a specific leaf, and not try to generalize and simplify the problem. Andy On Thu, Sep 24, 2015 at 6:25 AM, Robert Wilton <rwil...@cisco.com> wrote: > Hi Kent, > > On 23/09/2015 17:15, Kent Watsen wrote: > > > Jonathan Hansford writes: The requirements talk about both synchronous and > asynchronous systems (1(D), 3, 3(A)) but really only address the behaviour > for asynchronous systems. Would it not be worth clarifying the relationship > between the intended and applied configurations for synchronous systems > (i.e. they are the same), hence there is no need for synchronous > requirements equivalent to 1(D) and 3(A)? > > Ultimately, I think we need normative text in the "Terminology Section" > for a "synchronous system" and "asynchronous system". Would someone care > to take a stab providing these two definitions? > > > First stab only, probably needs some tweaking ... > > I find that the term "system" is a bit ambiguous in this context. It is > talking about the NMS, the server, or both together? > > Anyway, I've tried to define them relative to the configuration operations > being performed. > > 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. > > Asynchronous configuration operation - A configuration request that the > server applies asynchronously 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 is applied to the > system after the server has replied back to the client. The reply to the > client only indicates whether there are any semantic errors in the > configuration change. > > Synchronous system - NETCONF/RESTCONF client/server interactions that > processes all configuration operations as synchronous configuration > operations. > > Asynchronous system - NETCONF/RESTCONF client/server interactions that > processes all configuration operations as asynchronous configuration > operations. > > Thanks, > Rob > > > > > PS: please Reply-All to this thread, rather than post comments on the GitHub > issue tracker. > > Thanks, > Kent > > > > _______________________________________________ > netmod mailing listnetmod@ietf.orghttps://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
