Subject: [netmod] some comments on revised-datastores-01

From: Andy Bierman <[email-masked]>
Date: Sat, 18 Mar 2017 12:23:36 -0700

Hi,

I like this draft -- even more than I like datastores.
Looks like some thought went into the terminology section.

One minor concern:

sec. 4.1:

   On a traditional NETCONF implementation, <running> and <intended> are
   always the same.

The intended datastore is completely proprietary.
Is that part of the architecture or are there any plans for the standards
to have some purpose for the intended datastore?

I want to support 2 datastores that don't fit your descriptions very well:

factory:  read-only config representing the values that a factory reset
would use.  Allows copy-config to support a factory config reload.

library-config: needed as a bootstrap datastore with the module/bundle
configuration. Like the ietf-yang-library, but the config does not exactly
match
the structure of the YANG library.

Can vendors add datastores to a server?
Or is this IANA-registered?  And/or hard-wired in RFCs?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 19 Mar 2017 09:47:33 +0100 (CET)

> to have some purpose for the intended datastore?

The idea was to have a defined place for the "intended configuration"
in the common architecture, even if there are no current standard
mechanism that affects it.  If such mechanisms are added, they can be
defined in terms of the datastores in this architecture.

> Or is this IANA-registered?  And/or hard-wired in RFCs?

The draft has a section about what is needed to define dynamic
datastores.  IMO this should be generalized to any datastore.  The
datastore names are identities, so vendors can define their own
datastores.  Currently there is no explicit mechanism for a server to
advertise which datastores is supports, other that the advertisment of
features in "ietf-datastore".  Maybe we should add an explicit list of
supported datastores (but this will be protocol-dependent, since some
protocols might not expose all datastores).

/martin

---

From: Kent Watsen <[email-masked]>
Date: Sun, 19 Mar 2017 12:09:29 +0000

> Currently there is no explicit mechanism for a server to

The new dynamic datastores are (per this draft) advertised by being listed in YANG Library.   Only the "built in" datastores wouldn't have a module-backing.  

This is okay for the most part today as NETCONF has its capabilities and RESTCONF has its unified datastore, but it does leave <intended> hanging in the wind.  

Formally defining the built-in datastores as you suggest, using a module to define their presence, would be nice from a consistency perspective. 

K.

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 19 Mar 2017 17:37:02 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
> The new dynamic datastores are (per this draft) advertised by being
> listed in YANG Library.  Only the "built in" datastores wouldn't have
> a module-backing.

Actually, in the current draft, each module has a leaf-list of all
datastores (not only dynamic) where the module is implemented.

We have discussed various variations on this theme, but the current
leaf-list is probably the simplest.

> This is okay for the most part today as NETCONF has its capabilities
> and RESTCONF has its unified datastore, but it does leave <intended>
> hanging in the wind.
> 
> Formally defining the built-in datastores as you suggest, using a
> module to define their presence, would be nice from a consistency
> perspective.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Sun, 19 Mar 2017 18:11:35 +0000

> leaf-list is probably the simplest.

Wait, I think you're mixing things up.  I'm not talking about using YANG Library to identify which datastores a module can be accessed in, so much as knowing which datastores are implemented in the first place.  

For instance, assuming the "ephemeral" datastore example example in the draft, a client knows a server implements it because ietf-ds-ephemeral is listed in YANG Library.   And so it is with all dynamic datastores, but not so for built-in (non-dynamic) datastores (e.g. intended) because there isn't a module to advertise for them (yet).

K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 19 Mar 2017 19:16:30 +0100

> For instance, assuming the "ephemeral" datastore example example in the draft, a client knows a server implements it because ietf-ds-ephemeral is listed in YANG Library.   And so it is with all dyn…

Obviously, relying on module names does not work if a module defines
multiple datastores. So either the set of datastores is identified
from reading the whole yang-library list or we provide a separate list
(and I think we should provide a separate list).

/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: Kent Watsen <[email-masked]>
Date: Sun, 19 Mar 2017 19:49:05 +0000

> (and I think we should provide a separate list).

It seems okay for more than one datastore to be represented by a single module.  Presumably the set of them come together as a package (all or none), right?  This could be a datastore-designer decision to make.   

For instance, I2RS talks about priority-ordered planes of glass, so maybe they have a single "ietf-ds-ephemeral" module defining a package of datastores like: plane-1, plane-2, ... plane-8.

Yes, we could have a separate explicit list, but it'd be nice if we could reuse what we have...

K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Mar 2017 07:27:23 +0100

> Yes, we could have a separate explicit list, but it'd be nice if we could reuse what we have...

Sorry, overloading is bad. The definition of an identity does in
general not mean an implementation of an identity.

/js

---

From: Kent Watsen <[email-masked]>
Date: Mon, 20 Mar 2017 14:05:09 +0000

>> It seems okay for more than one datastore to be represented by a single
>> module.  Presumably the set of them come together as a package (all or
>> none), right?  This could be a datastore-designer decision to make.
>>
>> For instance, I2RS talks about priority-ordered planes of glass, so maybe
>> they have a single "ietf-ds-ephemeral" module defining a package of 
>> datastores like: plane-1, plane-2, ... plane-8.
>> 

Why are you mentioning identities here?  Yes, the module defines 
identities, but that is beside the point to what I'm saying.  I'm
only discussing the module (e.g. ietf-i2rs-solution) showing up
in YANG Library and using the age-old logic of, if the server
advertises it, then it means that it supports it, which in this
case means that it supports all the datastores defined by the
module.

K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Mar 2017 15:17:29 +0100

> case means that it supports all the datastores defined by the

But this logic is already broken for the datastores defined in the
revised datastores document. It defines an identity for startup but
not all systems implement startup. End of proof.

/js

---

From: Kent Watsen <[email-masked]>
Date: Mon, 20 Mar 2017 14:28:53 +0000

> not all systems implement startup. End of proof.

Ha ha, yes professor.  But recall this started as a discussion regarding
what to do for the new dynamic datastores (not built-in datastores) and
then someone said maybe we should support other datastores too.  I'm not
sure we need to do this but, if we did, then we could create modules for
them (i.e., ietf-startup).

K.

---

From: Robert Wilton <[email-masked]>
Date: Mon, 20 Mar 2017 14:37:56 +0000

> them (i.e., ietf-startup).
I also think that having the device advertise a single list of supported 
datatstores as part of YANG library might be a good idea. It seems like 
it is a straight forward way to make the information available in a way 
that is easy for clients to consume.

Thanks,
Rob

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Mar 2017 15:43:38 +0100

> them (i.e., ietf-startup).

I believe this is the wrong direction, even if we rewrite the module
in the revised datastores document and split it into multiple modules.
A simple list of implemented datastores is cheap. It is flexible. It
does not require explanations and rules how definitions must be split
into modules that finally must be remembered and checked still in 5-10
years from now. I firmly believe that these types of 'optimizations'
lead to creeping complexity down the road. Lets not create CLRs how
modules must be structued, named, etc.

/js

---

From: Kent Watsen <[email-masked]>
Date: Mon, 20 Mar 2017 17:09:16 +0000

> modules must be structued, named, etc.

That's a better answer.  At least now I get the sense that you actually
understood what I was saying.

As for your proposal, I agree with you that it would be best to have an
explicit list.  I assume that this would be another proposed change to
YANG Library (i.e., Section D.2 in the revised-datastores draft).  It
will be tricky to enforce the use of this version of YANG Library in 
RESTCONF without a -bis document...

K.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Mar 2017 16:21:44 -0700

Hi,

Not sure I like the YANG module with all the datastore identities
because it makes datastore discovery more complicated.
I prefer the server advertise capabilities in the <hello> message.

More importantly, all the existing NETCONF operations use
a container with a choice in it to select the source and target for various
operations.
It is trivial for a YANG module to simply augment these choices with new
leafs,
rather than forcing all client and server implementations to duplicate
these operations
with identifyref leafs for these parameters.

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 21 Mar 2017 09:11:14 -0400

+1 to Juergen's point on a separate module list. 

Sue 

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Juergen
Schoenwaelder
Sent: Sunday, March 19, 2017 2:17 PM
To: Kent Watsen
Cc: [email-masked]
Subject: Re: [netmod] some comments on revised-datastores-01

On Sun, Mar 19, 2017 at 06:11:35PM +0000, Kent Watsen wrote:
> 
> Wait, I think you're mixing things up.  I'm not talking about using YANG
Library to identify which datastores a module can be accessed in, so much as
knowing which datastores are implemented in the first place.  
> 
> For instance, assuming the "ephemeral" datastore example example in the
draft, a client knows a server implements it because ietf-ds-ephemeral is
listed in YANG Library.   And so it is with all dynamic datastores, but not
so for built-in (non-dynamic) datastores (e.g. intended) because there isn't
a module to advertise for them (yet).

Obviously, relying on module names does not work if a module defines
multiple datastores. So either the set of datastores is identified from
reading the whole yang-library list or we provide a separate list (and I
think we should provide a separate list).

/js

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 21 Mar 2017 09:19:29 -0400

Kent and Juergen: 

To summarize your messages: 

a) a global datastore list 
b) Each datastore contains a list of modules it contains (currently done) 
c) Each module contains a list of datastores it supports. 

Is this correct?  Or did I misunderstand. 

Sue 

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Monday, March 20, 2017 1:09 PM
To: Juergen Schoenwaelder
Cc: [email-masked]
Subject: Re: [netmod] some comments on revised-datastores-01

As for your proposal, I agree with you that it would be best to have an
explicit list.  I assume that this would be another proposed change to YANG
Library (i.e., Section D.2 in the revised-datastores draft).  It will be
tricky to enforce the use of this version of YANG Library in RESTCONF
without a -bis document...

K.

---

From: Kent Watsen <[email-masked]>
Date: Tue, 21 Mar 2017 16:17:46 +0000

Sue,

I think that only (c) is "done", and even then only to the point that a proposal is offered in the appendix D.2 in the revised-datastores draft.

(b) has never been discussed.

(a) is what this recent flap has been about.  We'll see if it's a list of datastores or capabilities or something else...

Kent

-----ORIGINAL MESSAGE-----

Kent and Juergen: 

Sue 

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Monday, March 20, 2017 1:09 PM
To: Juergen Schoenwaelder
Cc: [email-masked]
Subject: Re: [netmod] some comments on revised-datastores-01

K.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 21 Mar 2017 13:48:48 -0400

Thank you for letting me know.  

Sue 

-----Original Message-----
From: Kent Watsen [mailto:[email-masked]] 
Sent: Tuesday, March 21, 2017 12:18 PM
To: Susan Hares; 'Juergen Schoenwaelder'
Cc: [email-masked]
Subject: Re: [netmod] some comments on revised-datastores-01

Sue,

Kent

-----ORIGINAL MESSAGE-----

Kent and Juergen: 

Sue 

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Monday, March 20, 2017 1:09 PM
To: Juergen Schoenwaelder
Cc: [email-masked]
Subject: Re: [netmod] some comments on revised-datastores-01

> modules must be structued, named, etc.

That's a better answer.  At least now I get the sense that you actually understood what I was saying.

As for your proposal, I agree with you that it would be best to have an explicit list.  I assume that this would be another proposed change to YANG Library (i.e., Section D.2 in the revised-datastores draft).  It will be tricky to enforce the use of this version of YANG Library in RESTCONF without a -bis document...

K.