Subject: Re: [Netconf] New Version Notification for draft-nmdsdt-netconf-rfc7895bis-00.txt

From: Andy Bierman <[email-masked]>
Date: Thu, 1 Jun 2017 02:20:10 -0700

On Wed, May 31, 2017 at 11:56 PM, Martin Bjorklund <[email-masked]> wrote:

> Hi,
>
> Andy Bierman <[email-masked]> wrote:
> > Hi,
> >
> > This appears to add 1 top-level container to the YANG Module Library
> > This new container can be in its own module, in another RFC.
>
> The main addition, which requires a new revision of YANG library, is
> the leaf-list datastore which is specified on a per-module basis.
> This allows the server to inform the client which modules are
> implemented in the different datastores.  This addition has been
> discussed in the previous versions of revised-datastores (most recent
> is section D.2 in draft-ietf-netmod-revised-datastores-01).
>
>
I get that.
This can easily be an augment.
IMO it is really poor cohesion to to throw RD into the YANG module library.
There is already a YANG module in the RD draft called ietf-datastores.
That is the natural place to find info about the new datastores.

> /martin

Andy

>
> >
> >     container datastores {
> >        config false;
> >        description
> >          "Identifies which datastores are supported by this server.";
> >        leaf-list datastore {
> >          type identityref {
> >            base ds:datastore;
> >          }
> >          description
> >            "A datastore supported by this server.";
> >        }
> >      }
> >
> >
> >
> > I do not see why this top-level YANG subtree is related to the YANG
> module
> > library.
> > It is not linked in any way to the /modules-state subtree.
> >
> > IMO this will confuse people since it is not obvious that something
> > called the YANG module library would contain a list of datastores.
> >
> > One might expect to find the datastore list in /netconf-state/datastores
> > since that's where its been for 7 years.
> >
> > Also the text says "supported by this server".  What protocol is "this
> > server"?
> > What if there are multiple protocols and not all datastores are
> accessible
> > in all protocols?
> >
> >
> > Andy
> >
> >
> >
> >
> > On Wed, May 31, 2017 at 11:39 AM, Kent Watsen <[email-masked]>
> wrote:
> >
> > >
> > > A proposed rfc7895bis has been posted, to update YANG Library to
> > > support the revised-datastores draft.
> > >
> > > Would the chairs kindly consider initiating a poll to adopt this
> > > draft as a WG item?
> > >
> > > Thanks,
> > > Kent
> > >
> > >
> > > -----ORIGINAL MESSAGE-----
> > >
> > > A new version of I-D, draft-nmdsdt-netconf-rfc7895bis-00.txt
> > > has been successfully submitted by Kent Watsen and posted to the
> > > IETF repository.
> > >
> > > Name:           draft-nmdsdt-netconf-rfc7895bis
> > > Revision:       00
> > > Title:          YANG Module Library
> > > Document date:  2017-05-30
> > > Group:          Individual Submission
> > > Pages:          15
> > > URL:            https://www.ietf.org/internet-
> drafts/draft-nmdsdt-netconf-
> > > rfc7895bis-00.txt
> > > Status:         https://datatracker.ietf.org/doc/draft-nmdsdt-netconf-
> > > rfc7895bis/
> > > Htmlized:       https://tools.ietf.org/html/draft-nmdsdt-netconf-
> > > rfc7895bis-00
> > > Htmlized:       https://datatracker.ietf.org/
> > > doc/html/draft-nmdsdt-netconf-rfc7895bis-00
> > >
> > >
> > > Abstract:
> > >    This document describes a YANG library that provides information
> > >    about all the YANG modules used by a network management server
> (e.g.,
> > >    a Network Configuration Protocol (NETCONF) server).  Simple caching
> > >    mechanisms are provided to allow clients to minimize retrieval of
> > >    this information.
> > >
> > >
> > >
> > >
> > > Please note that it may take a couple of minutes from the time of
> > > submission
> > > until the htmlized version and diff are available at tools.ietf.org.
> > >
> > > The IETF Secretariat
> > >
> > >
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/netconf
> > >
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 01 Jun 2017 12:04:40 +0200 (CEST)

> This can easily be an augment.

If it is just an augment it means that a client that doesn't
understand the augment is led to believe that all modules listed are
available in all datastores.

> IMO it is really poor cohesion to to throw RD into the YANG module library.

But YANG library lists the models a server implements.  It has
implicitly meant "implemented in all datastores supported by the
server".   With RD this is no longer true.  So adding this crucial
piece of information in YANG library makese sense imo.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 1 Jun 2017 08:01:15 -0700

> available in all datastores.

What does this even mean?
The server advertises both ietf-yang-library and ietf-datastores.
The client MUST understand both of them,

> piece of information in YANG library makese sense imo.
But RD is optional to implement. Adding the leaf-list by augment
does not change anything. This is not a mandatory node.
It is a leaf-list so it would have to be min-elements 1, but this node
will be empty for some modules (like ietf-yang-types) where datastores
are irrelevant.

The YANG module library contains YANG conformance info.
The datastore info is not conformance data.

Andy

> > That is the natural place to find info about the new datastores.

So why isn't ietf-datastores the correct module for datastore info?

---

From: Andy Bierman <[email-masked]>
Date: Thu, 1 Jun 2017 09:16:35 -0700

> piece of information in YANG library makese sense imo.
I see no reason why this data node cannot be an augment.
No reason why the RD draft cannot say "a server that implements
revised datastores MUST implement the ietf-datastores module".

         leaf-list datastore {
           type identityref {
             base ds:datastore;
           }
           description
             "The datastores in which this module is supported.";
         }

IMO this is a bad design because it lets the server change YANG conformance.
I get it that the intent is to list stuff like I2RS-only modules are for
I2RS-only datastores.
But this leaf-list goes way beyond the intended use-cases to support
anything the
server wants to implement.  e.g. modules A and C are candidate-only.
Modules B, D, E
are running only. Module F is candidate and startup only.  This will make
client implementations
much more complicated.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 02 Jun 2017 15:19:36 +0200

> piece of information in YANG library makese sense imo.

I agree but I have another comment: It seems that basically the same
info will be specified in two different ways for RD and for schema mount:

1. which modules are implemented in a datastore

2. which modules are implemented under a mount point

This is awkward and should IMO be unified. The schema mount approach,
if used for RD, would have the advantage that a named schema is defined as a
collection of modules and multiple datastores that use the same schema
can just reference it so that it is immediately clear what datastores
have identical schemas.

The other difference is that in schema mount we permit different
revisions of a module to be implemented under different mount points
and/or at the top level. I am not sure it is a good thing to do, and
actually I would be willing to change that - at least for the use-schema
case - so as to have only one revision of each module implemented.

Lada

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 02 Jun 2017 15:27:49 +0200

> The client MUST understand both of them,

What is then the benefit of combining the two modules via augment if
both are required? It would be much more comprehensible if everything is
defined in one module.

Either way, this means a new protocol because the clients that don't
understand RD won't be able to work will RD-enabled servers.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 2 Jun 2017 07:55:19 -0700

> both are required? It would be much more comprehensible if everything is

It is basic coupling and cohesion 101.
The RD module is only required for servers that implement RD.

The YANG module library contains the conformance data needed
to sync the schema trees between client and server.
Only data related to this purpose should be in this module.

As a developer, I prefer that the RFC defining the functionality
contain the YANG modules for that functionality.
The new YANG library (that I was obviously not consulted on as a co-author)
does not even explain how to use the new data additions at all.

> understand RD won't be able to work will RD-enabled servers.

No -- An RD-enabled server will implement the ietf-datastores module.
This is just another YANG module available via NETCONF and RESTCONF.
No need for new protocol.s.

An "old client" will still be able to use the "old datastores" just fine.

Andy

> >> > > > >    mechanisms are provided to allow clients to minimize
> retrieval
> >> of
> >> > > > >    this information.
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 2 Jun 2017 17:11:55 +0200

> On 2 Jun 2017, at 16:55, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

But clients that don't support RD cannot reliably work with such servers.

> Only data related to this purpose should be in this module.

But, as Martin wrote, we currently have only one schema tree. With RD, if I understand it correctly, YANG library is expected to contain modules that are not implemented in running but elsewhere.

> An "old client" will still be able to use the "old datastores" just fine.

It won't because YANG library may contain modules that aren't implemented in "old datastores". Adding the leaf-list via augment doesn't change this.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 2 Jun 2017 08:48:39 -0700

> But clients that don't support RD cannot reliably work with such servers.

yes they can -- if it is designed correctly

> But, as Martin wrote, we currently have only one schema tree. With RD, if
> I understand it correctly, YANG library is expected to contain modules that
> are not implemented in running but elsewhere.
>

lumping all info related to YANG modules in one module is poor cohesion.
Lumping all mandatory stuff together (ietf-mandatory.yang?)
is even worse cohesion.

> It won't because YANG library may contain modules that aren't implemented
> in "old datastores". Adding the leaf-list via augment doesn't change this.
>

There is never any expectation that functionality added to a server after
the client is coded
and deployed will be supported.   The only expectation is that the modules
used by
the client continue to work. There are exceptions (i.e., when the update
rules in RFC 7950 are broken)
but in general this works.

Andy

---

From: "t.petch" <[email-masked]>
Date: Fri, 2 Jun 2017 17:03:42 +0100

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>
Cc: "Netconf" <[email-masked]>
Sent: Thursday, June 01, 2017 5:16 PM

> > > On Wed, May 31, 2017 at 11:56 PM, Martin Bjorklund
<[email-masked]>

Andy

I think that the world is already complicated and that it will only get
more so:-(

Revised Datastores does not help because it largely ignores the
engineering
reality that YANG comes in YANG modules.  A box will have datastores, a
box will have modules, you need a list of pointers from datastores to
modules and a list of pointers from modules to datastores.  In
relational terms, all very simple.  Which RFC defines which is a
different question, of how the semantics may evolve over time.

I think that this should be in place even without Revised Datastores,
albeit in a rudimentary form, that it is inherent in YANG.

And I think that this is a general problem with YANG, with much of the
IETF work, that initially it is all very simple and things are bundled
together and over time it becomes apparent that different things have
been merged that should not have been and then it becomes necessary to
tease out the different concepts.

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Fri, 2 Jun 2017 10:02:03 -0700

> tease out the different concepts.

Whether RD will actually work or not is a separate topic.
I have doubts that the incremental architectural purity gained is
worth breaking many deployed modules.

Basic concepts like module cohesion can be subjective, so we can disagree
on whether augment /foo or republish /foo is the right choice.

The proposed leaf-list solution ignores the fact that datastores are not
independent of each other.  There are only 3 variants

  1) local configuration (config=true)
  2) operational state (config=false + value-in-use for config=true)
  3) other (special-case control-plane datastores)

Variant (1) ALWAYS includes the implemented subset of
candidate, running, startup, intended, and applied.
If not, the system is broken.

If the data model produces unintended garbage results, it might mean
its the wrong data model.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 5 Jun 2017 09:44:31 +0200

> On 2 Jun 2017, at 17:48, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> There is never any expectation that functionality added to a server after the client is coded

I guess you are talking about how your clients are coded. If it was so in general, what's then the point of providing YANG library as state data? 

> and deployed will be supported.   The only expectation is that the modules used by
> the client continue to work. There are exceptions (i.e., when the update rules in RFC 7950 are broken)

RFC 6244 describes the data model as "a contract between the clent and server", and further says: "A client knows how to create valid data for the server, and knows what data will be sent from the server."

But what is the value of such a contract if either party works with a different spec?

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 5 Jun 2017 06:52:10 -0700

On Mon, Jun 5, 2017 at 12:44 AM, Ladislav Lhotka <[email-masked]> wrote:

> > > >> > On Wed, May 31, 2017 at 11:56 PM, Martin Bjorklund <
> [email-masked]>
> > > >> wrote:
> > > >> >
> > > >> > > Hi,
> > > >> > >
> > But, as Martin wrote, we currently have only one schema tree. With RD,
> if I understand it correctly, YANG library is expected to contain modules
> that are not implemented in running but elsewhere.
> >
> >
> > It won't because YANG library may contain modules that aren't
> implemented in "old datastores". Adding the leaf-list via augment doesn't
> change this.
> >
> >
> I guess you are talking about how your clients are coded. If it was so in
> general, what's then the point of providing YANG library as state data?
>
> RFC 6244 describes the data model as "a contract between the clent and
> server", and further says: "A client knows how to create valid data for the
> server, and knows what data will be sent from the server."
>

Let's not re-open the long debate about whether YANG module update rules
should be ignored or not.  If the server implements a modules (e.g.
ietf-system)
then it better work the same after RD is added. If not, then the module
needs
to be republished with a new name.

Andy

> > > >> > > > Also the text says "supported by this server".  What protocol
> is
> > > >> "this
> > > >> > > > server"?
> > > >> > > > >    a Network Configuration Protocol (NETCONF) server).
> Simple
> > > >> caching

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 5 Jun 2017 15:56:23 +0200

> On 5 Jun 2017, at 15:52, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> should be ignored or not.  If the server implements a modules (e.g. ietf-system)
> then it better work the same after RD is added. If not, then the module needs

I think the problem at hand is exactly the opposite: A client may assume that the server implements all modules listed in YANG library but it won't be the case because some of them may not be implemented in running after RD is added.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 5 Jun 2017 08:08:31 -0700

> ....
> I think the problem at hand is exactly the opposite: A client may assume
> that the server implements all modules listed in YANG library but it won't
> be the case because some of them may not be implemented in running after RD
> is added.
>
>

I thought running stays the same and intended is extra.
You think people are going to deploy RD and break every single
existing client application they use?

Lada
Andy

> >
> >
> > Lada
> >
> > Andy
> >
> >
> > >
> > >
> > > Lada
> > >
> > >
> > >
> > > Andy
> > >
> > > >
> > > >
> > > > Lada
> > > >
> > > >
> > > > Andy
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > >> > IMO it is really poor cohesion to to throw RD into the YANG
> module
> > > > >> library.
> > > > >>
> > > > >> > > > Also the text says "supported by this server".  What
> protocol is
> > > > >> "this
> > > > >> > > > server"?

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 5 Jun 2017 18:01:21 +0200

> On 5 Jun 2017, at 17:08, Andy Bierman <[email-masked]> wrote:
> 
> 
> ....
> >

Running may stay the same but the "module" list in YANG library might contain entries that are not implemented in running but elsewhere. At least that's how I understand draft-nmdsdt-netconf-rfc7895bis-00.

> existing client application they use?

Honestly, I think that with the RD and schema-mount combo we are getting on a steep slippery slope, and I basically agree with what Tom Petch wrote earlier in this thread.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 5 Jun 2017 09:52:51 -0700

On Mon, Jun 5, 2017 at 9:01 AM, Ladislav Lhotka <[email-masked]> wrote:

> Running may stay the same but the "module" list in YANG library might
> contain entries that are not implemented in running but elsewhere. At least
> that's how I understand draft-nmdsdt-netconf-rfc7895bis-00.
>
> Honestly, I think that with the RD and schema-mount combo we are getting
> on a steep slippery slope, and I basically agree with what Tom Petch wrote
> earlier in this thread.
>
>
If done correctly, then existing clients will still be able to function with
their old view of the world.  Brand new protocols and datastores like I2RS
are not supported by old clients. An old client uses <get> for config=false
and does not know or care about intended vs. applied or operational values
of config=true nodes.

Lada

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 Jun 2017 19:31:09 +0200

> tease out the different concepts.

Tom, this is not an IETF problem nor is it a YANG problem. Pretty much
any computer technology I have seen requires careful maintenance when
the technology sees active use that goes beyond the narrow scope of
the initial design. Read the C language definition and compare it to
how it looked like 30-40 years ago. Take early versions of HTTP and
compare them to what we have today. I think the key challenge is to
sharpen architectural concepts during the evolution of the technology
in such a way that further evolution remains feasible or even becomes
simpler.

The networking world also has changed since the work on NETCONF (and a
bit later YANG) started. While perhaps some things were foreseeable,
others were likely not. We also punted a few issues during the design
process that we knew were not finally resolved. For example, some of
the debate how we deal with operational state was even documented in
RFC 6244 (published six years ago) and we had more discussions around
this issue when the interfaces model was written up.

Could we have designed a 'perfect' data modeling language and
supporting protocols before doing any implementations or deployments?
Perhaps - if we would have managed to ever complete. Would we have
been successful in terms of deployed running code? Most likely not. In
order to create and grow an ecosystem around a technology, you need to
start with something that offers value and is simple enough to get
implemented and deployed. And once you have the seeds out, you need to
carefully evolve the technology and grow the ecosystem around it. I do
not see this as a 'general problem' - I see this is a successful path
to introduce (and exploit) a new technology.

/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: Vladimir Vassilev <[email-masked]>
Date: Thu, 8 Jun 2017 13:45:06 +0200

Hello,

I was following this thread with interest. IMO allowing different 
datastores to have different schema trees is flexibility bringing a lot 
of standardization and implementation overhead and confusion with little 
practical value. The original draft-openconfig-netmod-opstate explicitly 
states the importance of keeping single schema "... single schema to 
avoid complex mapping between a particular intended configuration leaf 
and the corresponding applied configuration". Schizophrenic devices with 
datastores that have different schema have limited application usecases 
and numerous alternative solutions. Even if someone needs this  the 
solution should not put overhead and complexity on the mainstream 
devices that do not have use for such flexibility. The ietf-yang-library 
module is special and I would very much like to see a solution that does 
not import ietf-datastores from there.

My main question is:

What would be wrong with a solution leaving rfc7895 unchanged? 
ietf-datastores can have similar data - schema trees for the rest of the 
datastores that do not have matching schema tree while the data tree 
/modules-state defined in ietf-yang-library remains the model for the 
conventional running/intended ...  datastores. There are alternatives 
like reusing the ietf-yang-library groupings in a ietf-datastores 
defined /ietf-datastores:datastores/datastore[...]/modules-state 
container or schema mount /yanglib:modules-state container as 
/ietf-datastores:datastores/datastore[...]/modules-state and you can 
achieve the same without modifying rfc7895.

Obviously this alternative solution will comply with requirement 5 in 
draft-ietf-netmod-opstate-reqs-04 which the currently proposed 
modifications break:

5.  Backwards compatibility

A.  It MUST be possible to upgrade a server to one that supports
     the solution without breaking existing/legacy clients.

The conventional datastores -  running/intended, candidate ... - should 
keep their default semantics with a schema tree described in 
/yanglib:modules-state. IMO the requirement is similar to  keeping a 
printf C function (client) working despite that stdout is just another 
file descriptor and at some point fprintf is introduced (environments 
without file system still have printf and it works). Despite the changes 
of the C language definitions programs written 40 years ago still 
compile and work .. 
https://en.wikipedia.org/wiki/The_C_Programming_Language#/media/File:Hello_World_Brian_Kernighan_1978.jpg

Vladimir

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Jun 2017 09:16:31 -0700

On Thu, Jun 8, 2017 at 4:45 AM, Vladimir Vassilev <[email-masked]>
wrote:

> datastores to have different schema trees is flexibility bringing a lot of
> standardization and implementation overhead and confusion with little
> states the importance of keeping single schema "... single schema to avoid
> complex mapping between a particular intended configuration leaf and the
> corresponding applied configuration". Schizophrenic devices with datastores
> that have different schema have limited application usecases and numerous
> alternative solutions. Even if someone needs this  the solution should not
> put overhead and complexity on the mainstream devices that do not have use
> for such flexibility. The ietf-yang-library module is special and I would
> very much like to see a solution that does not import ietf-datastores from
> there.
>

I agree that there are no benefits whatsoever to adding datastore-related
objects to iewtf-yang-library.
I don't like the vendor-selected mapping to datastores for each module.
That is not how datastores
work.  It would violate the contract to advertise a capability like
:candidate and not allow certain
config=true nodes to be edited via the candidate datastore.  The mapping
from YANG object to
datastore should be algorithmic, not vendor-selected. It MUST be the same
mapping on every server.

> conventional running/intended ...  datastores. There are alternatives like
> reusing the ietf-yang-library groupings in a ietf-datastores defined
> /ietf-datastores:datastores/datastore[...]/modules-state container or
> schema mount /yanglib:modules-state container as

One can use a leafref to /modules-state/module/name instead of adding
datastore info the the 'module' list directly.

> draft-ietf-netmod-opstate-reqs-04 which the currently proposed
IMO the requirement to inspect individial transitions (from intended to
applied) for each
individual leaf is total overkill, and it doesn't even work if another
client changed
a leaf after me.

>     the solution without breaking existing/legacy clients.
This is critical -- especially considering that the RD design team wants to
replace many modules
with new incompatible versions.  There is no business-case to rewrite
client applications.
There is no  need to require a massive "flag day" upgrade for an entire
administrative domain.
That would be extremely disruptive and risky, without any cost
justification.

> /yanglib:modules-state. IMO the requirement is similar to  keeping a printf
> C function (client) working despite that stdout is just another file
> descriptor and at some point fprintf is introduced (environments without
> file system still have printf and it works). Despite the changes of the C
> language definitions programs written 40 years ago still compile and work
> .. https://en.wikipedia.org/wiki/The_C_Programming_Language#/me
> dia/File:Hello_World_Brian_Kernighan_1978.jpg

totally agree.
For example, if /interfaces-state is collapsed into /interfaces (not even
sure what problem
this fixes), then the interfaces-state subtree should be deprecated, and
still supported by
servers for 2 - 3 years.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Jun 2017 19:55:45 +0200

On Thu, Jun 08, 2017 at 09:16:31AM -0700, Andy Bierman wrote:
> I agree that there are no benefits whatsoever to adding
> datastore-related objects to iewtf-yang-library.  I don't like the
> vendor-selected mapping to datastores for each module.  That is not
> how datastores work.  It would violate the contract to advertise a
> capability like :candidate and not allow certain config=true nodes
> to be edited via the candidate datastore.  The mapping from YANG
> object to datastore should be algorithmic, not vendor-selected. It
> MUST be the same mapping on every server.

Please note that this was not the intented usage; in fact we defined
the 'conventional' identity on purpose in ietf-datastores in order to
make it possible to announce in a concise way that a module is
implemented in all 'conventional' datastores.
 
> datastore info the the 'module' list directly.

Yes, something like that addresses the backwards compatibility concern.

> This is critical -- especially considering that the RD design team
> wants to replace many modules with new incompatible versions.

Trust me, it is not our goal to break backwards compatibility. If we
did so, we will fix this. Claiming that the design team 'wants to
replace many modules with new incompatible versions' is not really
helpful.

> For example, if /interfaces-state is collapsed into /interfaces (not
> even sure what problem this fixes), then the interfaces-state
> subtree should be deprecated, and still supported by servers for 2 -
> 3 years.

Yes. Nobody proposed something different.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Jun 2017 12:32:42 -0700

On Thu, Jun 8, 2017 at 10:55 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> avoid

I don't think the mapping is needed at all for any of the traditional
datastores.
The RD draft already says how to handle [candidate .. operational].
The only modules that need a mapping are special datastores like ephemeral.
IMO the datastore identity in ietf-datastores needs to be used in
a YANG extension in each YANG module.
Susan already proposed this YANG extension I think.

> like

> replace many modules with new incompatible versions' is not really

I have heard they will be incompatible.
If /foo and /foo-state are both defined for a few years then things should
work OK.
If /foo-state is taken away (even in new modules) then old clients will
break.

> Yes. Nobody proposed something different.
good

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Jun 2017 15:52:44 -0700

> replace many modules with new incompatible versions' is not really

I have not seen a detailed proposal for "RD transition strategy" and I am
supposed to write something for 6087bis.

Here is my first draft of a solution:

  extension datastore-relocate {
     argument path;
     description
        "If present in a config=false data node, indicates where the data
is re-mapped
         for revised datastore usage.";
  }

  container foo { ... }

   container foo-state {
      status deprecated.
      config false;
      rd:datastore-relocate "/ex:foo";
      // config=false leafs follow
  }

The /foo-state subtree only exists if <get> is used.
If the the new <get-data> is used to retrieve the operational datastore,
the server will relocate the /foo-state contents as child nodes of /foo.
The actual YANG objects in /foo-state are not cut-and-pasted or
shared via groupings.

RD-aware clients and servers MUST support the rd:datastore-relocate
extension.
Other YANG extensions to support datastore mappings are probably needed as
well.

After the transition period (3 years?) the /foo-state objects will no longer
be defined and the datastore-relocate extension can be phased out.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 9 Jun 2017 01:49:20 +0000

Hi Andy,

> supposed to write something for 6087bis.

The RD transition strategy, at least from a model-designer's perspective, is
mostly captured in draft-dsdt-nmda-guidelines, but read on...

> <snip/>

I agree that it would be good if there were a flag in the deprecated -state trees to
signal to a nmda-compatible server to NOT present an effectively-redundant -state
tree, but I don't view it as a relocation instruction to a client.

> RD-aware clients and servers MUST support the rd:datastore-relocate extension.
> Other YANG extensions to support datastore mappings are probably needed as well.

The way I've been thinking about this, the worst-case scenario (no special annotation
on deprecated trees), the nmda-compatible server would just show redundant data.  In
this sense, I view the need for RD-clients to grok it more as a SHOULD than a MUST.

> be defined and the datastore-relocate extension can be phased out.

Agreed, but this would be normal deprecation process, not specific to nmda, right?

Kent