Juergen, Rob summarized the discussion well. Since I also have some strange feelings about transactions here, my proposal in the other thread was to define the state of the config at the time the client is notified.
Gert Sent from my Apple ][ > On 16 Oct 2015, at 14:19, Robert Wilton <rwil...@cisco.com> wrote: > > Hi Juergen, > >> On 15/10/2015 22:59, Juergen Schoenwaelder wrote: >>> On Thu, Oct 15, 2015 at 05:03:33PM +0000, Kent Watsen wrote: >>> These terms were edited on today's call, resulting in the following text: >>> >>> 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. This may be transactional or non- >>> transactional (need terms!). The transactionality of the operation >>> may be a server property or specified on as a property. >> I do not understand the transactionality blurb. What is it and why is >> it relevant? (The last sentence above also seems incomplete.) > > It was added in the meeting because some interpretations of the text assumed > that the text implied that the server would always rollback-on-error, so the > proposed text was intended to clarify that. > > However, I think that this clarification applies equally to both sync and > async operations and hence I have proposed (on a separate thread) that it be > documented as part of the requirement 3 "Support for both synchronous and > asynchronous configuration operations" instead. > > Thanks, > Rob > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
