Re: [Netconf] nmda-restconf operations (was: netconf-binary-encoding comments)

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Jul 10, 2018 at 11:43:08AM +0100, Robert Wilton wrote:
> 
> 
> On 09/07/2018 19:13, Juergen Schoenwaelder wrote:
> > On Mon, Jul 09, 2018 at 05:48:57PM +0000, Kent Watsen wrote:
> > > 
> > > > > This isn't what I meant.  To be more specific, I'm wondering if the nmda-restconf
> > > > > draft would benefit from having a sentence like:
> > > > > 
> > > > >     A RESTCONF server supporting NMDA datastores MAY implement the
> > > > >     "ietf-netconf" [RFC6241] and "ietf-netconf-nmda" [I-D. ietf-netconf-nmda-
> > > > >     netconf] modules to enable the NETCONF operations defined in those
> > > > >     drafts to appear {+restconf}/operations resource.
> > > > > 
> > > > > Note: I put "MAY" as RESTCONF may someday have a more native way to do this.
> > > > > 
> > > > Well, "ietf-netconf" does not really support NMDA well and this is why
> > > > we have "ietf-netconf-nmda". Does not make much sense to point to
> > > > "ietf-netconf" in an NMDA document.
> > > But we'd still need lock, unlock, commit, commit-confirmed, etc., right?
> > Yep.
> OK.  Just to check - the client can determine which of these operations are
> supported via the feature statements in ietf-netconf.yang and the
> corresponding module entry in YANG library bis?

The YANG module ietf-netconf is at the end nothing special. So clients
should treat it like any other module. If the yang-library says this
module is implemented, then it is implemented and features will work
exactly like they work for any other module.

> > > Maybe it's a moot point, since ietf-netconf-nmda requires that ietf-netconf
> > > is implemented too, but I thought being explicit would be helpful here.
> > As long as readers get the idea that implementing lets say edit-config
> > is perhaps not the best idea...
> It might be a good idea to explicitly list the NETCONF operations that are
> not well defined and hence SHOULD NOT be implemented.

It is risky to repeat what other documents already discuss since doing
so raises the risks of producing inconsistencies and it may create
additional headaches when document updates are made later on.

Note that draft-ietf-netconf-nmda-netconf-06 also extends <lock> and
<unlock> to handle NMDA datastores. I think a pointer to this I-D is
relevant, I am less sure about ietf-netconf. Someone implementing
<candidate> likely figures out that without implement <commit>, this
<candidate> datastore is not very usable.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>