On Fri, Mar 6, 2015 at 10:04 AM, Jeffrey Haas <[email protected]> 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
