On Fri, Oct 16, 2015 at 5:23 AM, Martin Bjorklund <m...@tail-f.com> 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. Is this mode no longer valid? > good question. I am curious how this synchronous return will be deployed. Is the intent to rewrite NETCONF and RESTCONF so they have some mechanism like "don't return until intended == applied". Andy > > > B. Support for synchronous operations as per the definition of > > "synchronous configuration operation". > > Doesn't this follow from A? > > > 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 >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
