Is there a requirement for asynchronous systems to provide a blocking config update?

[rgwilton]

It wasn't clear to me where the requirement 3 (A) came from. I'm not necessarily opposed to it, only that it doesn't appear to be obviously specified in the openconfig-netmod-opstate draft.

[kwatsen]

There seems to be on list agreement to remove sub-requirements A and B, but there remains an issue regarding if the top-level requirement (3) is still needed, or if it is just another way to describe the need for asynchronous/synchronous systems.

[kwatsen]

Closing: This issue no longer makes sense, given the new definitions for a/synchronous configuration operations. That is, the definition of a synchronous configuration operation is that the request blocks, whereas that's exactly not the case for an asynchronous configuration operation.

[kwatsen]

My bad, closed too early

[kwatsen]

Requirement #3 was discussed on today's call. We agreed to remove the
words "distributed" and "transactional" and to reword it in terms of
"configuration operations". The resulting text follows:

    3.  Support for both synchronous and asynchronous configuration operations (see terms)

       A. A server may only support synchronous configuration operations, or may only support
          asynchronous configuration operations, or may support synchronicity to be client
          specified on a per-operation basis.


       C. Support for synchronous configuration operations requires the server to block
          sending a response to the client until it is able to able to determine whether
          there are any errors in the request or errors from applying the configuration
          change.

       D. Support for asynchronous configuration operations requires the server to send
          a response to the client immediately indicated that the request was accepted
          and send a notification to the client when the intended config is fully 
          effective or there are any errors from applying the configuration change.

       E. Support for asynchronous configuration operations MAY also provide a verify
          operation which a client can request from the server to obtain information
          regarding the difference between the intended and applied configurations.

We have consensus on the above, but wanted to rewrite it relying more on
the terms from the Terminology section, and also potentially merge E into
D.

Anybody want to take a stab at it?

Thanks,
Kent

[kwatsen]

just sent email to Rob asking for final draft text

[kwatsen]

Moving issue to REVIEW. On list, Kent writes:

OK, it looks like we converged.  Thank you all.
I will use the text below for the draft.

Kent   // with editor hat on  ;)



On 10/19/15, 9:52 AM, "Robert Wilton" <rwilton@cisco.com> wrote:

Hi Kent, Gert,

For clarity, the text that I had reached for 3 (folding in the comments
so far) is this:

    3.  Support for both synchronous and asynchronous configuration
        operations (see terms)

        A. A server may support only synchronous configuration
           operations, or only asynchronous configuration operations, or
           both synchronous and asynchronous configuration operations on
           a client-specified per-operation basis.

        B. Servers that support asynchronous configuration operations MAY
           also provide a verify operation that a client can request from
           the server to return information regarding the difference
           between the intended and applied configurations.

        C. The configuration protocol MUST specify how configuration
           errors are handled.  Errors may be handled by "stop on error",
           "continue on error" or "rollback on error" semantics (see
           terms).  Support for "rollback on error" SHOULD be provided.


  Extra terms to add the definitions section (based on the definitions
for NETCONF RFC):

           stop-on-error:  The configuration operation is aborted on the
first
             error.

          continue-on-error:  Continue to process configuration data on
             error; error is recorded, and negative response is generated
             if any errors occur.

          rollback-on-error:  If an error condition occurs such that part
             of applying the configuration fails, the server will stop
             processing the configuration operation and restore the
             specified configuration to its complete state at the start
             of this configuration operation.


Gert has provided some definitions that are closer to Kent's original
text, how do we resolve?

Thanks,
Rob