Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Andy Bierman <[e-mail]>]

On Wed, Jul 13, 2016 at 3:17 PM, Kent Watsen <[e-mail]> 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
>
>
>
>
>
>
>