Kent, The new one looks much better. However the last sentence is confusing with respect to intended config. Why is there a need to update the intended config?
Proposal: The server MUST fully attempt to apply the configuration change to all impacted components in the server, updating the server's applied configuration (see terms), before replying to the client. Sent from my Apple ][ On 16 Oct 2015, at 15:45, Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote: Gert writes: > I don't see the need for defining synchronous/asynchronous config servers. Thank you (and Juergen) for the confirmation. Again, if no objections, these two terms will not be removed. > The new definitions look good. Later in the discussion there was a common > sentiment that the requirement for synchronous operations contained some > crisp wording we could use here too. I particularly liked the mentioning of > blocking requests for some time, [Note: the following removes the last two sentences on "transactions", as being discussed elsewhere on this thread] OLD: Synchronous configuration operation - A configuration request to update the running configuration of a server that is applied synchronously with respect to the client request. The server MUST fully attempt to apply the configuration change to all impacted components in the server, updating both the server's intended and applied configuration (see terms), before replying to the client. NEW Synchronous configuration operation - A configuration request to update the running configuration of a server that is applied synchronously with respect to the client request (i.e. a blocking call). The server MUST fully attempt to apply the configuration change to all impacted components in the server, updating both the server's intended and applied configuration (see terms), before replying to the client. What do you think? Kent
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod