Re: [secdir] [i2rs] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF

[Andy Bierman <[e-mail]>]

On Fri, Mar 6, 2015 at 10:04 AM, Jeffrey Haas <[e-mail]> wrote:
> On Thu, Mar 05, 2015 at 09:18:02AM +0100, Juergen Schoenwaelder wrote:
>> On Wed, Mar 04, 2015 at 03:57:50PM -0800, Andy Bierman wrote:
>> > > The simple solution is to make "A B C" one atomic edit.
>> > >
>> >
>> >
>> > We use entity tags and If-Match in RESTCONF so the client can
>> > be sure it is editing the correct version of the resource instance.
>> > This works nicely for persistent configuration, especially if
>> > the server can reboot with the same config ETags.
>> >
>> > If-Match will cause the edit to fail if the server reboots and the
>> > I2RS state is gone.
>> > The client will get a 412 Precondition Failed response and know it might have to
>> > start over.
>> >
>> > RESTCONF only requires the server to maintain an ETag for the config root.
>> > Finer granularity (e.g., the parent resource has an ETag) is probably needed
>> > to support multiple concurrent edits.
>> >
>>
>> Thanks, this all makes sense. So there is a viable mechanism to create
>> a sequence of linked edits. The main trade-off, however, between a
>> single atomic edit and a sequence of linked edits is who is taking the
>> pain to cleanup the mess if things fail in the middle. If you write a
>> client, you love the server to do it. If you write a server, you love
>> the client to do it. ;-)
>
> It's all pain, but some component has to deal with it.
>
> I'm glad that restconf seems to have this situation covered, Andy.  Is there
> a similar mechanism in netconf that I've missed?  If so, this completely
> deals with the need for i2rs to have to ask for anything new. :-)
>

NETCONF has no support at all for this sort of thing.

> -- Jeff

Andy