Thank you. That sounds like a useful path to go down.
Yours,
Joel
On 11/29/14, 10:54 PM, Andy Bierman wrote:
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
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
