Hi Randy,
Thanks for the comments.
On 17/10/2015 04:29, Randy Presuhn wrote:
Hi -
From: Robert Wilton
Sent: Oct 16, 2015 5:12 AM
To: Kent Watsen , Nadeau Thomas
Cc: "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.
No, I don't think that is intended as an RFC 2119 MAY.
- please avoid unnecessary anthropomorphisms; the server doesn't
"choose" anything here.
- s/ in/ on/
- 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.
...
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/
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
Randy
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
