Andy Bierman <[email protected]> writes: > On Sat, Nov 29, 2014 at 6:42 PM, Joel M. Halpern <[email protected]> wrote: >> I can not tell from your description Andy who has control and who has >> predictability. If the device folds the I2RS changes into the permanent >> state, and saves them, it will make a mess with the way the WG has assumed >> things to work. >> > > > I am not suggesting the I2RS edits ever change the running or persistent > configuration. The TBD extensions include some mechanism to > tell RESTCONF to edit the ephemeral config instead of any other datastore. > > ephemeral for I2RS: > > PATCH /restconf/edata > > running for RESTCONF: > > PATCH /restconf/data >
But what if the same parameter appears both in edata and data? Let's say it is "hostname". What happens if it is edited in edata? If the same change is not applied in /restconf/data, then a RESTCONF client that doesn't know about edata has no way to discover the actual hostname the system is using. Lada > > >> Yours, >> Joel > > Andy > > >> >> On 11/29/14, 9:38 PM, Andy Bierman wrote: >>> >>> On Sat, Nov 29, 2014 at 3:41 AM, Juergen Schoenwaelder >>> <[email protected]> wrote: >>>> >>>> On Fri, Nov 28, 2014 at 02:39:21PM -0500, Jeffrey Haas wrote: >>>>> >>>>> Joel, >>>>> >>>>> On Thu, Nov 13, 2014 at 11:28:04PM -0500, Joel M. Halpern wrote: >>>>>> >>>>>> I don't recall seeing that form of commit in any protocol that has >>>>>> been proposed. I think it would be rather hard to do. >>>>> >>>>> >>>>> One of the prior complicating details had been I2RS saying we'd use >>>>> "netconf >>>>> and restconf" when we selected our protocol earlier this year. >>>>> >>>>> As we've since seen, netconf commit and datastore semantics (protocol >>>>> components) significantly complicate our needs. This has been a detail >>>>> that >>>>> I believe is pushing netconf off the table and moving us more firmly >>>>> into >>>>> restconf. >>>> >>>> >>>> I like to understand this better. My understanding is that there are >>>> several implementations underway that use the same backend >>>> infrastructure for both NETCONF and RESTCONF. So I wonder how RESTCONF >>>> exposes datastore semantics that are simpler to deal with than NETCONF >>>> datastore semantics. I personally find the 'unified' datastore defined >>>> in RESTCONF somewhat handwaving. >>>> >>>> Each RESTCONF edit of a datastore resource is saved to non-volatile >>>> storage in an implementation-specific matter by the server. There is >>>> no guarantee that configuration changes are saved immediately, or >>>> that the saved configuration is always a mirror of the running >>>> configuration. >>>> >>>> This leaves it completely up to the implementation what is made >>>> persistent and when. While this may be great for implementors, I am >>>> not sure how this gives you predictable semantics needed to build >>>> implementations that work with different protocol implementations. >>>> >>> >>> Not what, just when. The text is intended to allow for implementations >>> that may NV-save in the background, so a reboot just after an >>> edit may or may not come back. I will try to clarify this text in the >>> -04 version. >>> >>> >>> >>>> Yes, I this is an issue I should raise on the NETCONF list. But for >>>> me, a protocol with unclear semantics is even harder to deal with than >>>> a protocol where it is actually clear in which situations which >>>> content is made persistent. >>> >>> >>> >>> IMO the combination of RESTCONF (+ TBD extensions) >>> and YANG Patch allows the client to clearly specify the intended results, >>> and the unified datastore lets the server integrate the ephemeral >>> datastore >>> with the running config and the operational state however it wants. >>> >>> >>>> >>>> /js >>>> >>> >>> Andy >>> >>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >>>> >>>> _______________________________________________ >>>> i2rs mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/i2rs >>> >>> >> > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
