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? > 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
