On Wed, Jul 13, 2016 at 3:17 PM, Kent Watsen <kwat...@juniper.net> wrote:
> > > > > > RW: > > Are you thinking of a single global notification of convergence? > > > > > > > No > > > > > > I think the client would request a notification for its edit. > > > There would be a long-form and short-form notification. > > > > > > The interaction model is simple: > > > A) at the time of the request the client opt-in for being notified > > > > opstate-reqs refers to this as an asynchronous configuration operation. > Requirement 2-B says: > > > > Servers that support asynchronous configuration operations > > MUST provide a mechanism to notify the client when a request > > has completed processing. The notification MUST indicate > > whether the intended config is now fully applied or if there > > were any errors from applying the configuration change. > > > > I don’t see a need for long/short forms or timeouts here. Are you > suggesting a need to change how the requirements are worded? > > > I am just suggesting how I would design this feature. I certainly don't want to read any more requirements drafts, so implement whatever you want. The short-form is really just the long-form with an empty list of unapplied edits. > Kent > > > Andy > > > > B) the server will send the short form (all-ok) ASAP or even return > the short-form all-ok > > > in the response and skip the notifications if possible > > > C) if the timeout occurs, then the server sends the long-form > notification, which lists > > > all the intended config operations not yet applied. (This is > easier to do for YANG Patch > > > where the edits are identified, than with <edit-config> that has > an unordered blob of XML). > > > > > > > > > Parameters would be added to the edit request: > > > > > > - want-notif: (boolean: default false) > > > - notif-timeout: how long the server should wait before sending the > long-form notification > > > - trace-id: string provided by the client similar to persist-id that > will identify this edit > > > in the notifications > > > > > > > > > This approach does not deal with multi-client conflicts. > > > If client A does "create /foo" then the server ACKs that edit even if > client B > > > has started a subsequent "delete /foo" edit before the first edit was > ACKed. > > > > > > A separate RPC to retrieve the long-form notification for all pending > edits would > > > also be needed to allow for a notification to be lost or a client to > query the entire > > > list of unapplied edits. > > > > > > Andy > > > > > > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
