Hi Martin,
On 16/10/2015 13:23, Martin Bjorklund wrote:
Robert Wilton <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.
I think the most common mode *today* is a mix of sync/async, on a
per-object basis.
Yes, I agree.
It might also be useful to have some text somewhere in the draft that
makes this point clear (i.e. that existing NC/RC implementations are
neither sync or async).
Is this mode no longer valid?
I don't think that we can or should invalidate existing netconf server
implementations.
However, to sensibly support the opstate requirements, I think that the
client has to know whether a particular request is, or all requests are,
being handled by the server in a sync or async fashion.
There has been a suggestion that existing NC implementations could be
regarded as being async, but that isn't going to work if there ends up
needing to be a separate "async config apply has completed" notification
since no existing NC/RC implementations are going to generate such a
notification.
So, I think that ultimately operations need to be regarded as one of:
(i) netconf current behavior
(ii) explicit sync
(iii) explicit async
It isn't clear to me whether only servers that support (ii) or (iii) can
meet the opstate requirements, or whether servers supporting (i) can
also be supported. What do you think?
B. Support for synchronous operations as per the definition of
"synchronous configuration operation".
Doesn't this follow from A?
Yes, possibly. I don't mind if B is deleted. If we do this then I
would suggest that we also delete the analogous first sentence of C, and
re-introduce the "(see terms)" text in the headline description.
Thanks,
Rob
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.
/martin
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
https://www.ietf.org/mailman/listinfo/netmod
