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 <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> on
behalf of Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>
Date: Monday 19 October 2015 15:22
To: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>, Robert
Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>>
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>"
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous
systems to provide a blocking config update?
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
On 10/19/15, 9:14 AM, "Kent Watsen"
<kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote:
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"
<randy_pres...@mindspring.com<mailto:randy_pres...@mindspring.com>>
wrote:
Hi -
From: Robert Wilton
Sent: Oct 16, 2015 5:12 AM
To: Kent Watsen , Nadeau Thomas
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>"
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
_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
