Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

From: Randy Presuhn <[email-masked]>
Date: Fri, 16 Oct 2015 20:29:11 -0700 (GMT-07:00)

Hi -

> From: Robert Wilton
> Sent: Oct 16, 2015 5:12 AM
> To: Kent Watsen , Nadeau Thomas
> Cc: "[email-masked]"
> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?
...
>    Here is my attempt at word smithing section 3:
...
>             A. A server may choose to support only synchronous configuration
>                operations, or only asynchronous configuration operations, or
>                both synchronous and asynchronous configuration operations in
>                a client specified per-operation basis.

Editorial comments:
  - is the "may" intended as a RFC 2119 MAY?  If so, this seems
    a semantically inappropriate use of the keyword.
  - please avoid unnecessary anthropomorphisms; the server doesn't
    "choose" anything here.
  - s/ in/ on/
  - s/client specified/client-specified/

...
>          failed.  A configuration protocol, or server, SHOULD provide
>          support for rollback-on-error behavior and MAY choose to
>          provide support for best effort semantics as well.

Editorial comments:

  - The implications of the RFC 2119 SHOULD and MAY are quite different
    depending on which of the two subjects ("protocol" or "server") one
    chooses to think about.  The server's observable behaviour is presumably
    circumscribed by the protocol, so I suggest removing ", or server,".

  - Please suppress anthropomorphisms.

  - s/best effort/best-effort/

Randy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 19 Oct 2015 13:14:15 +0000

Hi Rob,

I know there is an on-going discussion about the time-line of things, but
the draft needs to be posted today...  Can you help finalize the text?

Randy offers some good editorial suggestions below, and I believe you and
Gert had some ideas in wordsmithing 1.D. and bringing in error modes.

Thanks,
Kent

On 10/16/15, 11:29 PM, "Randy Presuhn" <[email-masked]>
wrote:

>> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for
>>asynchronous systems to provide a blocking config update?
>...
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Kent Watsen <[email-masked]>
Date: Mon, 19 Oct 2015 13:22:43 +0000

I meant 3.D, and so did you I think when you wrote on the 16th "E.g.
change the 1.D text to..."

Sorry for the confusion.

Kent

---

From: Gert Grammel <[email-masked]>
Date: Mon, 19 Oct 2015 13:37:45 +0000

Hi Kent,

Here my proposals

   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.

NEW   A. The way a server executes an operation (synchronous or asynchronous) is implementation specific and may change 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.

NEW (changed OR into AND)
       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 and errors from
          applying the configuration change.

OK
       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.
OK
       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.

From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Kent Watsen <[email-masked]<mailto:[email-masked]>>
Date: Monday 19 October 2015 15:22
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>, Robert Wilton <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

Sorry for the confusion.

Kent

On 10/19/15, 9:14 AM, "Kent Watsen" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Rob,

Thanks,
Kent

On 10/16/15, 11:29 PM, "Randy Presuhn" <[email-masked]<mailto:[email-masked]>>
wrote:

Hi -

From: Robert Wilton
Sent: Oct 16, 2015 5:12 AM
To: Kent Watsen , Nadeau Thomas
Cc: "[email-masked]<mailto:[email-masked]>"
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for
asynchronous systems to provide a blocking config update?
...
    Here is my attempt at word smithing section 3:
...
             A. A server may choose to support only synchronous
configuration
                operations, or only asynchronous configuration
operations, or
                both synchronous and asynchronous configuration
operations in
                a client specified per-operation basis.

Editorial comments:

...

Editorial comments:

  - The implications of the RFC 2119 SHOULD and MAY are quite different
    depending on which of the two subjects ("protocol" or "server") one
    chooses to think about.  The server's observable behaviour is
presumably
    circumscribed by the protocol, so I suggest removing ", or server,".

Randy

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Robert Wilton <[email-masked]>
Date: Mon, 19 Oct 2015 14:41:34 +0100

Hi Randy,

Thanks for the comments.

>      a semantically inappropriate use of the keyword.
No, I don't think that is intended as an RFC 2119 MAY.

>    - s/client specified/client-specified/
All three fixed.

Proposed updated text for 3.A:

        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.

>    - s/best effort/best-effort/
I had reworded 3.D based on Gert's comments.  Folding in your comments 
above to that text produces:

        D. The configuration protocol MUST specify how configuration
           errors are handled.  Errors could 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 term to add the definitions (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.

Thanks,
Rob

> .

---

From: Robert Wilton <[email-masked]>
Date: Mon, 19 Oct 2015 14:52:31 +0100

Hi Kent, Gert,

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

        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):

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

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Mon, 19 Oct 2015 15:01:32 +0100

Hi Gert,

On 19/10/2015 14:37, Gert Grammel wrote:
> NEW   A. The way a server executes an operation (synchronous or 
> asynchronous) is implementation specific and may change on a 
> per-operation basis.
I don't agree with this new text.  I think that the server (or protocol) 
should specify whether it supports sync and/or async operations.  But it 
is up to the client to choose which particular way (out of the supported 
options) that it wants the server to process a particular operation.  
Letting the server decide would seem to push additional complexity on 
the client.

Thanks,
Rob

> From: netmod <[email-masked] 
> <mailto:[email-masked]>> on behalf of Kent Watsen 
> <[email-masked] <mailto:[email-masked]>>
> To: Kent Watsen <[email-masked] <mailto:[email-masked]>>, 
> Robert Wilton <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
>     On 10/16/15, 11:29 PM, "Randy Presuhn"
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>         Hi -
>
>             From: Robert Wilton
>             Cc: "[email-masked] <mailto:[email-masked]>"
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Gert Grammel <[email-masked]>
Date: Mon, 19 Oct 2015 14:27:25 +0000

Rob,

The current text of 3a works for me although it looks a bit complex. So we converged.

Gert

Sent from my Apple ][

On 19 Oct 2015, at 16:01, Robert Wilton <[email-masked]<mailto:[email-masked]>> wrote:

Hi Gert,

Here my proposals

NEW   A. The way a server executes an operation (synchronous or asynchronous) is implementation specific and may change on a per-operation basis.
I don't agree with this new text.  I think that the server (or protocol) should specify whether it supports sync and/or async operations.  But it is up to the client to choose which particular way (out of the supported options) that it wants the server to process a particular operation.  Letting the server decide would seem to push additional complexity on the client.

Thanks,
Rob

OK

From: netmod <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> on behalf of Kent Watsen <[email-masked]<mailto:[email-masked]>>
Date: Monday 19 October 2015 15:22
To: Kent Watsen <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>, Robert Wilton <[email-masked]<mailto:[email-masked]>>
Cc: "<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

Sorry for the confusion.

Kent

On 10/19/15, 9:14 AM, "Kent Watsen" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

Hi Rob,

Thanks,
Kent

On 10/16/15, 11:29 PM, "Randy Presuhn" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
wrote:

Hi -

From: Robert Wilton

Editorial comments:

...

Editorial comments:

Randy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 19 Oct 2015 14:33:38 +0000

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

Kent   // with editor hat on  ;)