Subject: [Netconf] input to the RESTCONF scope discussion

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Mar 2015 23:57:49 +0100

Hi,

during our discussions after today's NETCONF meeting, it became clear
to me that I might not have been clear enough in my comments that
touch on the scope of RESTCONF. So for the benefit of all, I try to
clarify some things:

- I am fine with the concept of a unified datastore. However, I like
  to have it clearly defined and in particular I like to have it
  defined how the unified datastore interacts with traditional NETCONF
  datastores (in particular when it comes to persistence properties).
  I also like to see explicit text how the unified datastore interacts
  with NETCONF locks etc. (e.g., is the RESTCONF implementation
  acquiring locks behind the scenes, which errors do I get in case
  NETCONF has something conflicting locked). I am _not_ requesting
  that all NETCONF datastores are exposed via RESTCONF.

- I suggest that RESTCONF is _prepared_ to support future extensions
  such as ephemeral datastores.

- I generally like the YANG patch approach for editing but I like to
  see it defined such that it _can_ work with both RESTCONF and
  NETCONF.  I do _not_ request that RESTCONF supports edits by
  exposing the NETCONF edit-config approach to RESTCONF clients.

- I believe we should take advantage of things like anydata or boolean
  if-feature expressions etc. that we have worked on during the last
  year in the context of YANG 1.1. Since the same set of people are
  involved in the various documents, we should be able to make sure
  nothing gets stuck because of dependencies.

- I am somewhat concerned about data models that are NETCONF or
  RESTCONF specific. While there will be such data models, these
  should be rare corner cases. The majority of data models should work
  regardless of the protocol choice. In particular, references in data
  models SHOULD use YANG naming schemes and data types (e.g.,
  instance-identifier) and avoid using protocol specific naming
  schemes.

Perhaps this helps to better understand my other comments.

/js

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 25 Mar 2015 09:42:03 -0500

> On 24 Mar 2015, at 17:57, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Hi,
> 

The RESTCONF spec should indeed define the precise semantics of the unified datastore but the interaction with NETCONF is IMO secondary because there is no requirement that NETCONF be present as a “backend” to RESTCONF.

Lada

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Mar 2015 18:12:28 +0100

> The RESTCONF spec should indeed define the precise semantics of the unified datastore but the interaction with NETCONF is IMO secondary because there is no requirement that NETCONF be present as a…

There are implementations that do both so it better be defined what
happens if things interact so behaviour is predictably. This has
nothing to do with any requirements logic.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 25 Mar 2015 14:38:57 -0500

> On 25 Mar 2015, at 12:12, Juergen Schoenwaelder <[email-masked]> wrote:
> 

My point is that this part needn’t necessarily be in the base RESTCONF spec which is already quite long.

Lada