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.
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?
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?
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.
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><mailto: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><mailto:tnad...@lucidvision.com> wrote:
On Oct 14, 2015:7:51 PM, at 7:51 PM, Kent Watsen
<kwat...@juniper.net><mailto:kwat...@juniper.net>
wrote:
On 9/28/15, 1:40 AM, "Juergen Schoenwaelder"
<j.schoenwael...@jacobs-university.de><mailto: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<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<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
