Subject: [netmod] datastore conformance

From: Andy Bierman <[email-masked]>
Date: Mon, 24 Jul 2017 11:17:02 -0700

Hi,

I am still concerned that the datastore conformance requirements are
under-specified and too server-centric.

The YANG definitions defined for NETCONF and RESTCONF operations do not ac
tually
require the "real" datastore identities to be used by a server. The server
implementor
has the freedom to replace all of the standard datastores with proprietary
definitions.
While this provides unlimited flexibility for the server, it also provides
unlimited
complexity for the client.

I think the existing :candidate, :writable-running, and :startup
capabilities cover
the standard conventional datastores.

IMO the MUST be a new capability for the :operational datastore and the
exact identityref and semantics for this datastore MUST be supported
if the :operational:1.0 capability is advertised.

Both NETCONF and RESTCONF can list capabilities so both protocols can
advertise
this capability URI.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 25 Jul 2017 19:47:51 +0000

> under-specified and too server-centric.

Okay.

> The YANG definitions defined for NETCONF and RESTCONF operations
> do not actually require the "real" datastore identities to be used by a server.
> The server implementer has the freedom to replace all of the standard datastores
> with proprietary definitions.  While this provides unlimited flexibility for the
> server, it also provides unlimited complexity for the client.

I don't understand this.

> I think the existing :candidate, :writable-running, and :startup capabilities
> cover the standard conventional datastores.

What about <intended>?   - and let's not forget the dynamic datastores...

> Both NETCONF and RESTCONF can list capabilities so both protocols
> can advertise this capability URI.

We agree that the client needs to be able to discover which datastores are
available.  Already there is a proposal to update YANG Library to provide
this data.   It seems redundant to also have capabilities, but I can see the
argument that it has to be done for completeness too.

So is the proposal for 1) the netconf-nmda draft to define NETCONF
capabilities for :intended and :operational, 2) the restconf-nmda draft to
define RESTCONF capabilities for :running, :startup, :intended, and
:operational, and 3) future dynamic datastore drafts to define a capability
URI that can be used by both NETCONF and RESTCONF?

> Andy

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Jul 2017 13:01:29 -0700

> > server, it also provides unlimited complexity for the client.

The YANG identityref allows any identity that is derived from the same base.
You keep talking about "the" operational datastore when in fact your YANG
definitions
require no such thing.  They merely require any identify with the proper
base
(i.e, edit-config, get-data operations)

> capabilities

You are right that interoperability is the same either way (very weak IMO).
The client can read the list of datastores.
If 3rd-party clients are viable (not likely) then they will be able to print
an error message "Operational datastore not supported" either way..

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 Jul 2017 22:07:03 +0200

On Tue, Jul 25, 2017 at 01:01:29PM -0700, Andy Bierman wrote:
> 
> The YANG identityref allows any identity that is derived from the
> same base.  You keep talking about "the" operational datastore when
> in fact your YANG definitions require no such thing.  They merely
> require any identify with the proper base (i.e, edit-config,
> get-data operations)

There are standard identities. You implement the standard if you
implement the standard identities. There is a standard identity for
"the" operational datastore. Yes, you can implement non-standard
datastores. This was also true before.

Perhaps we need to say more explicitly somewhere implementing NMDA
requires to implement at least the <running> and <operational>
datastore (the ones with the standard identity). Is that what you
are looking for?

/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: Andy Bierman <[email-masked]>
Date: Tue, 25 Jul 2017 13:16:25 -0700

> datastore (the ones with the standard identity). Is that what you

Yes --  what does conformance to NMDA mean (if anything)?
How does a client know the server claims NMDA conformance?

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 25 Jul 2017 17:44:59 -0400

Andy Bierman writes:
>The YANG definitions defined for NETCONF and RESTCONF operations do not actually
>require the "real" datastore identities to be used by a server.

The identities are defined in the YANG modules contained in the
NMDA draft (draft-ietf-netmod-revised-datastores).  The protocol-specific
drafts (draft-dsdt-nmda-netconf and draft-dsdt-nmda-restconf)
describe protocols operations that use these identities, such as
the <source> parameter to <get-data>.  The YANG library draft
(draft-ietf-netconf-yang-library) allows the server to indicate
which datastores are supported.

>The server implementor
>has the freedom to replace all of the standard datastores with proprietary definitions.

Yes.  The implementation can also choose not to support any
conventional datastores, allowing only, say, some new dynamic
datastore.  Clients can learn this via YANG Library.

In the end, I've confidence that the market place will give limited
success to servers that make funky and weird choices.  We all
understand that most-common behaviors are most desirable, but forcing
a limit on such things is imho counter productive.

>While this provides unlimited flexibility for the server, it also provides unlimited

"unlimited"?

>I think the existing :candidate, :writable-running, and :startup capabilities cover

Yes, these capabilities allow a client to know that a server supports
a datastore, but not what it can contain.  It's not sufficient
information.  The client needs the YANG library information to
have meaningful interaction with a server.

>if the :operational:1.0 capability is advertised.

What does a new capability give that YANG library does not?

I don't follow the bit about "the exact identityref and semantics
for this datastore".  Is your concern that I could make a follow-on
to <operational> that derives from the operational identity?

>Both NETCONF and RESTCONF can list capabilities so both protocols can advertise
>this capability URI.

Same for YANG Library, right?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Jul 2017 15:43:27 -0700

Hi,

I am aware how YANG identities work.
Let the market decide.  Good enough.

Andy