> 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?
Kent
> 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
