Hi Gert,
On 16/10/2015 13:58, Gert Grammel wrote:
Hi Rob,
The text looks good. With respect to D we probably need more wordsmithing:
D. Support for best effort and rollback-on-error error handling
semantics. The configuration protocol, or default server
behavior, MUST specify whether the configuration is applied
in a best effort fashion, or using "rollback on error"
semantics - where all configuration changes in the request are
undone if processing of any part of the configuration update
failed.
--> how would the client know that a certain operation is supported in
an atomic or non-atomic manner by the server. In my view the default
should be the client assumes best effort and the server is allowed to
do better.
Either the client would need to know what error semantics a particular
server will always use to apply configuration, or the operation needs to
indicate what semantics are in use (perhaps also being controllable by
the client request). But unless the client clearly knows what the error
semantics are when it applies the config it cannot know what the value
of the remaining leaves are if some configuration has failed.
The default error handling semantics for NC appear to be "stop on
error", with "continue on error" and "rollback on error" being the other
allowed options. I wasn't aware of the "stop of first error" being the
default option for netconf and hence hadn't considered it my text above.
So, perhaps we should lift the definitions of "stop on error", with
"continue on error" and "rollback on error" from section 7.2. of NETCONF
(rfc6241) into the requirements draft, and then rephrase the 1.D text in
the context of that.
E.g. change the 1.D text to:
D. The configuration protocol, or default server behavior, MUST
specify how configuration errors are handled. Errors can
be handled by "stop on error", "continue on error" or
"rollback on error" (see terms). Support for "rollback on
error" SHOULD be provided.
Lifted terms (from NETCONF):
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.
Enns, et al. Standards Track [Page 39]
------------------------------------------------------------------------
<https://tools.ietf.org/html/rfc6241#page-40>
RFC 6241 <https://tools.ietf.org/html/rfc6241> NETCONF Protocol June 2011
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.
Thoughts?
Hence no need for a MUST.
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.
Wondering how much we need here. Assuming the server supports
rollback, then do we need protocol extensions for that?
Yes, NC already has a rollback-on-error option.
Assuming the server doesn't support rollback. Then do we need anything
special in the protocol to re-configure the config to emulate
something like a rollback?
I would suggest no. Either the server supports this (which is the most
likely outcome), or the client can emulate it.
My point is: given that transaction is a requirement, would we need to
require here anything more that is not a consequence?
Perhaps it is better to limit or even avoid text about transactions
and just define the state of the applied config after error. I see 3
cases so far:
1) atomic: after error the applied config is identical to the config
before the error
2) sequence: if the config is applied in a sequence and a specific
leaf fails, the leafs that have been configured before will keep the
intended config, leafs not yet processed keep the applied config and
the failed leaf is undefined
3) all leafs in error are undefined, all error free leafs use the
(new) intended config as their applied config.
I agree with (1) and (2) but wasn't expecting (3). By best effort, I
was thinking of the equivalent of Netconf's "continue on error".
Thanks,
Rob
Thoughts?
Gert
Sent from my Apple ][
On 16 Oct 2015, at 14:13, Robert Wilton <rwil...@cisco.com
<mailto:rwil...@cisco.com>> wrote:
Hi Kent,
Here is my attempt at word smithing section 3:
The old D and E have been merged together (now labelled as C). A new
D has been added to try and define transactional error handling
semantics without introducing the term transactional.
3. Support for both synchronous and asynchronous configuration
operations
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.
B. Support for synchronous operations as per the definition of
"synchronous configuration operation".
C. Support for asynchronous operations as per the definition of
"asynchronous configuration operation". 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.
D. Support for best effort and rollback-on-error error handling
semantics. The configuration protocol, or default server
behavior, MUST specify whether the configuration is applied
in a best effort fashion, or using "rollback on error"
semantics - where all configuration changes in the request are
undone if processing of any part of the configuration update
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.
Any comments?
Thanks,
Rob
On 15/10/2015 18:32, Kent Watsen wrote:
Again, with better formatting for the list:
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.
Kent
On 10/15/15, 1:22 PM, "Kent Watsen"<kwat...@juniper.net> wrote:
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
On 10/14/15, 8:00 PM, "Nadeau Thomas"<tnad...@lucidvision.com> wrote:
On Oct 14, 2015:7:51 PM, at 7:51 PM, Kent Watsen<kwat...@juniper.net>
wrote:
On 9/28/15, 1:40 AM, "Juergen Schoenwaelder"
<j.schoenwael...@jacobs-university.de> wrote:
On Wed, Sep 23, 2015 at 03:03:57PM +0000, Kent Watsen wrote:
Popping the stack on this issue, the issue remains as to what to do
with requirement 3:
3. Support for both transactional, synchronous management systems
as well as distributed, asynchronous management systems
I fail to understand 'transactional' and 'distributed' here.
I hope that these terms will be clarified on tomorrow's call. There
is
also a chance that these terms will be removed from the text
altogether,
as they may be viewed as unnecessarily qualify the
synchronous/asynchronous terms.
And
frankly, I am not sure why the management _systems_ are classified to
be synchronous or asynchronous - I think we are talking about
protocols between a management system and a device.
Aye, I didn't see that before.
First off, elsewhere in the draft the term "system" is used 7 times to
refer to the device (e.g., NC/RC server). The term "system" is
otherwise
not defined.
But to your main point, we have been discussing the terms a/synchronous
to
have to do with internal server processing of an edit request, but in
'3'
the terms are being used to qualify a management system, which can't be
right. I think that '3' should be rewritten to be a statement about
devices, not a statement about management systems.
It might be better to frame this in terms of a client and a
server.
‹Tom
Anyway, I am not sure 3. is properly worded until someone defines
'transactional', 'distributed', 'synchronous management systems' and
'asynchronous management systems'.
The agenda for tomorrow's interim! :)
Kent
_______________________________________________
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
_______________________________________________
netmod mailing list
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
