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

From: Kent Watsen <[email-masked]>
Date: Wed, 21 Jun 2017 14:40:17 +0000

This thread has caused the NMDA-authors to search for a solution
that does not entail modifying RFC 7895 (e.g., by using another
module).  

But alas, it seems that we're limited by rfc7950#section-5.6.4,
where it states that NETCONF servers MUST advertise:

     urn:ietf:params:netconf:capability:yang-library:1.0?
       revision=<date>&module-set-id=<id>

and we very much want NC clients to be able to determine that
the server supports NMDA via a capability, and yet they would
not (could not) support yang-library in its current form.

Thus, the current plan it to put forward yet another variation
of 7895bis (i.e., a new 'revision' of yang-library:1.0) that
does NOT alter the existing "modules-state" tree in any way
(so as to not break legacy clients) by introducing a new 
top-level container called "yang library", which would contain
an organization that incorporates modules, module-sets, and
datastores (and, perhaps, schema-mounts too).

Thoughts?

Kent

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

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: Andy Bierman <[email-masked]>
Date: Wed, 21 Jun 2017 07:57:32 -0700

Hi,

I am confused.
Why can't a server advertise yang-library:1.0 and also advertise
ietf-datastores:1.0?

IMO the RD architecture is totally broken is each vendor can choose the
datastores
that support a YANG module.  This metadata MUST come from the YANG module
itself.  This is not a vendor implementation decision.

Andy

On Wed, Jun 21, 2017 at 7:40 AM, Kent Watsen <[email-masked]> wrote:

> Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-nmdsdt-netconf-rfc7895bis-00
>
>
> Abstract:

---

From: Phil Shafer <[email-masked]>
Date: Wed, 21 Jun 2017 11:24:14 -0400

Can we use an ERRATA to completely remove 5.6.4?  It was
a mistake to intertwine these standards, since it prohibits
any evolution away from "yang-library:1.0".

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 21 Jun 2017 08:37:59 -0700

Hi,

IMO -- no. You do not understand this capability URI.
The purpose of this capability is to advertise the revision-date used
so there is no chicken-and-egg problem wrt/ to the ietf-yang-library module
itself.

The text does not say a specific revision date MUST be sent.
A client MUST read the revision-date and find the proper module version.

Also, there is nothing in YANG preventing you from writing a new module
that augments
the YANG library, if that is required (which it isn't in this case).

The RD work provides no advantages whatsoever for many devices that
will not have I2RS or slow config convergence. The traditional datastores
have their own capability URIs with no need to change them.  We should not
disrupt these implementations because new non-applicable functionality is
being added
to the standards.

Andy

On Wed, Jun 21, 2017 at 8:24 AM, Phil Shafer <[email-masked]> wrote:

> >URL:            https://www.ietf.org/internet-
> drafts/draft-nmdsdt-netconf-rfc7895bis-00.
> >txt

---

From: Kent Watsen <[email-masked]>
Date: Wed, 21 Jun 2017 20:37:58 +0000

> I am confused.
> Why can't a server advertise yang-library:1.0 and also advertise ietf-datastores:1.0?

We want a module that can provide *all* the metadata a server can provide
in one response.  We originally thought about "ietf-datastores", but that didn't
fit the bill, so then we considered "server-metainfo" and then "yang-library2".
However, since yang-library as it stands is not suitable for NMDA servers,
and there is that nasty requirement in rfc7950#section-5.6.4, it seems that
embrace-and-extend yang-library:1.0 might be the best option.

> IMO the RD architecture is totally broken is each vendor can choose the datastores

Assuming 's/is each/if each/', that's not what we're saying.  Of course, modules
are primarily deployed to datastores as they have always been.  The only real
new thing here is that some modules may be datastore-specific, especially with
regards to dynamic datastores.  But the expectation is that any such module-
deployment limitations would be called out in the associated RFC, perhaps in
the form of a new YANG extension statement.

Kent

On Wed, Jun 21, 2017 at 7:40 AM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

Thoughts?

Kent

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

Thanks,
Kent

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

Abstract:

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<http://tools.ietf.org>.

The IETF Secretariat

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

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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 21 Jun 2017 20:46:37 +0000

> so there is no chicken-and-egg problem wrt/ to the ietf-yang-library module itself.
>

Yes, this is why the proposal is the update yang-library:1.0 with a new revision date.

> that augments the YANG library, if that is required (which it isn't in this case).

Perhaps, but that doesn't appear to be the best approach, since yang-library
as it stands appears to not be suitable for NMDA servers.

> have their own capability URIs with no need to change them.  We should
> not disrupt these implementations because new non-applicable functionality
> is being added to the standards.

I2RS and slow convergence withstanding, given that future YANG modules
will reflect the NMDA "guidelines", it means that the operational state of their
config true nodes would only be available via the new <operational> datastore.
Hence, even these devices will need to be NMDA-compatible in order to report
all their data.

Kent

On Wed, Jun 21, 2017 at 8:24 AM, Phil Shafer <[email-masked]<mailto:[email-masked]>> wrote:
Can we use an ERRATA to completely remove 5.6.4?  It was
a mistake to intertwine these standards, since it prohibits
any evolution away from "yang-library:1.0".

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 21 Jun 2017 13:50:33 -0700

> embrace-and-extend yang-library:1.0 might be the best option.
Why are you assuming a protocol is incapable of retrieving data in 1
response?
This is not the case at all if you augment /modules-state from another
module.
The augmented data is in the same tree.

The "1.0" in the capability refers to the capability definition itself.
It in no way means RFC 7895 has to be used as the YANG library.

> the form of a new YANG extension statement.

Seems to me there is a simple static mapping from YANG to datastore for
everything except I2RS.  The solution should add localized-cost only to
systems using I2RS.

The I2RS solution proposals seem better because they tag the YANG module
not the server implementation.  A mapping that is read at runtime and can
possibly change and can be different on every server is very high
maintenance.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 21 Jun 2017 14:19:01 -0700

> as it stands appears to not be suitable for NMDA servers.

The module represents YANG module conformance information for the server.
You are saying YANG conformance mechanisms as defined in RFC 7950
need to be rewritten?

> Hence, even these devices will need to be NMDA-compatible in order to

Many people are OK with the limitations of traditional datastores and do
not want to
read the operational values of config=true nodes.  Vendors can deploy the
fake foo-state.yang
modules as needed for new style modules.

There is no business case for rewriting clients to use get-data(/foo,
operational) instead of get(/foo-state).

It's starting to look like all the big-router-specific stuff like RD and
schema-mount will
cause YANG deployment to fork. That may be better than a 1-size-fits-all
that
nobody is happy with.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 21 Jun 2017 17:19:52 -0400

>This is not the case at all if you augment /modules-state from another

The current setup is unsuitable for augmentation.  IIRC it was
you that pointed out that augmenting the module list with a
list of supported datastores will break backwards compatibility
with clients that assume that any listed module will be supported
in <running>.

>It in no way means RFC 7895 has to be used as the YANG library.

The root cause is that we've put comformance with "yang-library:1.0"
into the spec for YANG (1.1 at least) and this prevents us from
replacing it with something else.

My proposal is that we make a new container that holds a list of
supported modules, and under each module is a container called
"conditional".  If this container is present, the client should
ensure that it understands all the data under that container before
accessing that module.

An NMDA module would then augment that container with a list of
supported datastores.  Further modules could similarly augment their
data, knowing that they will not be replicating our current situation
(where clients don't know and don't know that they don't know).

This frees us from having to respin yang-library when the next new
idea requires it.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 21 Jun 2017 14:26:10 -0700

> with clients that assume that any listed module will be supported
Then you want a completely different module.
Any solution that maps server implementations to datastores instead
of schema definitions to datastores is really broken.
What you are really doing is introducing a whole new type of
module deviations, ala SNMP MIN-ACCESS. Not a step forward for standards.

A traditional client does not care about I2RS so there are no compatibility
issues.

> This frees us from having to respin yang-library when the next new

I don't see how this relates to the YANG library at all.
You are creating something new that is not applicable to every YANG
implementation.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 21 Jun 2017 19:03:32 -0700

Hi,

Here is my YANG extension based proposal for RD, instead of a server
implementation specific
mapping from module to datastore

1) make a guideline/rule that YANG modules do not mix datastore models
    so there is 1 datastore model for the whole module

 2) add some definitions to ietf-datastore.yang

 extension datastore-model {
    argument type;
    description
        "Identifies the datastore model type that is used in this module.
          This statement must be contained within the module-stmt and
          should be near the top of the module.

           The parameter 'type' specifies the datastore type, which is
represented
           as a YANG leaf of type identityref, base datastore-type.

            Example:
                rd:datastore-model rd:revised-datastore;
         ";
  }

  identity datastore-model {
       description
        "Abstract base identity for datastore model identities.";
  }

  identity netconf-datastore {
       base datastore-model;
       description
        "Identifies the NETCONF datastore model, as defined in RFC 6241.";
   }

   identity revised-datastore {
       base datastore-model;
       description
        "Identifies the Revised datastore model, as defined in RD-draft.";
   }

   identity i2rs-datastore {
       base datastore-model;
       description
        "Identifies the I2RS datastore model, as defined in I2RS-draft.";
   }

The default is "netconf-datastore" so that all existing traditional YANG
modules
already comply with this mechanism.

Andy

---

From: Robert Wilton <[email-masked]>
Date: Thu, 22 Jun 2017 16:07:42 +0100

Hi Andy,

On 21/06/2017 21:50, Andy Bierman wrote:
>
>
> On Wed, Jun 21, 2017 at 1:37 PM, Kent Watsen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > I am confused.
>
I think that there may need to be some sort of combination.

I'm not sure that you want to tag every node that is writable via I2RS, 
since this might require all existing modules to be updated to reflect 
this, although it could potentially be achieved via something like a 
deviation statement.

Personally, I think that "config true" should at least mean that the 
node is configurable via regular NETCONF/RESTCONF.

I also think that it is reasonable for an I2RS specific module to label 
the module, or nodes, as "config false, ephemeral true" to indicate that 
they are only writable via I2RS.

But it isn't clear to me that all "config true" nodes/modules will 
necessarily be configurable via I2RS.  I could imagine that it may be a 
much narrower subset of modules/nodes, which is why the suggestion was 
that the server should advertise which modules (and possibly even which 
features) are supported for an I2RS datastore.

Another case where a per datastore list of supported modules could be 
the useful, is the example that you have previously given of just 
wanting to support only operational state without configuration.  In 
this case the device could report that it doesn't support the 
configuration datastores, or perhaps that it doesn't support any modules 
in those datastores.

Thanks,
Rob

>         URL:
>         https://www.ietf.org/internet-drafts/draft-nmdsdt-netconf-rfc7895bis-00.txt
>         <https://www.ietf.org/internet-drafts/draft-nmdsdt-netconf-rfc7895bis-00.txt>
>         Status:
>         https://datatracker.ietf.org/doc/draft-nmdsdt-netconf-rfc7895bis/
>         <https://datatracker.ietf.org/doc/draft-nmdsdt-netconf-rfc7895bis/>
>         Htmlized:
>         https://tools.ietf.org/html/draft-nmdsdt-netconf-rfc7895bis-00
>         <https://tools.ietf.org/html/draft-nmdsdt-netconf-rfc7895bis-00>
>         Htmlized:
>         https://datatracker.ietf.org/doc/html/draft-nmdsdt-netconf-rfc7895bis-00
>         <https://datatracker.ietf.org/doc/html/draft-nmdsdt-netconf-rfc7895bis-00>
>
>
>         Abstract:
>         until the htmlized version and diff are available at
>         tools.ietf.org <http://tools.ietf.org>.
>
>         The IETF Secretariat
>
>
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/netconf>
>
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/netconf>
>
>
>
>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 22 Jun 2017 17:15:34 +0100

On 21/06/2017 22:19, Andy Bierman wrote:
>
>
> On Wed, Jun 21, 2017 at 1:46 PM, Kent Watsen <[email-masked] 
> Many people are OK with the limitations of traditional datastores and 
> do not want to
> read the operational values of config=true nodes.
But that may due to confusion about the precise meaning of the data that 
is being returned by the NETCONF RPCs today.

E.g. when the device returns that foo is enabled in the GET request, 
they think that foo is enabled ... when it doesn't actually mean that at 
all, it only means that the client has asked for foo to be enabled.

The argument has been that for all intents and purposes the intended and 
applied value is the same, so it doesn't matter.  But I think that the 
interesting question concerns when the intended and applied values 
diverge: if only a single value can be given back to the client then 
which value should it be?  I think that the "what is it doing" is more 
important than "what did I asked it to do".

So, if you want to keep clients simple (e.g. by only having a single 
datastore view rather than two), then having writes going to running and 
reads coming from operational may be a better compromise rather than 
returning running + config false.

So, in a long winded way, I am saying that I think that the NMDA 
architecture applies to all distributed configuration management, even 
if the devices choose not to expose all of the data in order to present 
a simplified view to clients.

Rob

>   Vendors can deploy the fake foo-state.yang
> It's starting to look like all the big-router-specific stuff like RD 
> and schema-mount will
> cause YANG deployment to fork. That may be better than a 
> 1-size-fits-all that
> nobody is happy with.
>
>
>     > Andy
>
>     Kent
>
>
>
> Andy
>
>         https://www.ietf.org/internet-drafts/draft-nmdsdt-netconf-rfc7895bis-00
>         <https://www.ietf.org/internet-drafts/draft-nmdsdt-netconf-rfc7895bis-00>.
>         >txt
>         >Status:

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Jun 2017 09:21:25 -0700

> this, although it could potentially be achieved via something like a

My solution proposal is 1 extension-stmt per module, one datastore model
per module.
I did not mean to suggest individual object tagging. If you want a solution
that client developers
will hate, then let every server implementation make up their own datastore
model
like they were making a salad from the salad bar.

>
> Personally, I think that "config true" should at least mean that the node
> is configurable via regular NETCONF/RESTCONF.
>
>
agreed

> they are only writable via I2RS.
that has been one proposal going back to the NYC interim.

> much narrower subset of modules/nodes, which is why the suggestion was that
> the server should advertise which modules (and possibly even which

there are 2 issues:
  1) conformance: what is a compliant I2RS agent required to support
   2) deviations: what does this non-compliant I2RS agent actually support

>
> Another case where a per datastore list of supported modules could be the
> useful, is the example that you have previously given of just wanting to
> support only operational state without configuration.  In this case the
> device could report that it doesn't support the configuration datastores,
> or perhaps that it doesn't support any modules in those datastores.
>

This MIN-ACCESS approach has been rejected in the past because the focus
of NETCONF is configuration management, so allowing a vendor to implement
NETCONF
but not support configuration did not seem appropriate. But YANG
conformance has
no way of expressing MIN-ACCESS.

Andy

>> drafts/draft-nmdsdt-netconf-rfc7895bis-00.txt
> Netconf mailing [email-masked]://www.ietf.org/mailman/listinfo/netconf
>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Jun 2017 09:32:15 -0700

On Thu, Jun 22, 2017 at 9:15 AM, Robert Wilton <[email-masked]> wrote:

> E.g. when the device returns that foo is enabled in the GET request, they
> think that foo is enabled ... when it doesn't actually mean that at all, it
> only means that the client has asked for foo to be enabled.
>
> interesting question concerns when the intended and applied values diverge:
> if only a single value can be given back to the client then which value
> should it be?  I think that the "what is it doing" is more important than
> "what did I asked it to do".
>
> architecture applies to all distributed configuration management, even if
> the devices choose not to expose all of the data in order to present a
> simplified view to clients.
>
>
You seem to be making an assumption that the lack of precision wrt/ when
some data
has changed value is required for these "simple" devices. It is not. If the
data modeler
expects there is state data that needs to be exposed, then 1 oper-state
leaf is added
for the whole data structure.  There are so many details a client developer
needs to code from
the model, that this oper-state leaf is a tiny increment in the entire
project.

There are many systems that are distributed, and yet can still converge in
less than a second.
NETCONF already requires servers to report their datastores in
/netconf-state/datastores
and also advertise the proper capabilities like candidate, etc. The NETCONF
datastore model defined
in RFC 6241 works fine for these systems.  Forcing them to upgrade just to
report these same
datastores twice is not a good idea.  Forcing RD into the
mandatory-to-implement YANG library
(the only reason YANG library was picked apparently) will not help force
this extra work to get done.

Rob
Andy

---

From: Robert Wilton <[email-masked]>
Date: Thu, 22 Jun 2017 18:01:30 +0100

On 22/06/2017 17:32, Andy Bierman wrote:
>
>
> On Thu, Jun 22, 2017 at 9:15 AM, Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>>     Many people are OK with the limitations of traditional datastores
>>     and do not want to
>     But that may due to confusion about the precise meaning of the
>     data that is being returned by the NETCONF RPCs today.
>
>     E.g. when the device returns that foo is enabled in the GET
>     request, they think that foo is enabled ... when it doesn't
>     actually mean that at all, it only means that the client has asked
>     for foo to be enabled.
>
>     The argument has been that for all intents and purposes the
>     intended and applied value is the same, so it doesn't matter.  But
>     I think that the interesting question concerns when the intended
>     and applied values diverge: if only a single value can be given
>     back to the client then which value should it be?  I think that
>     the "what is it doing" is more important than "what did I asked it
>     to do".
>
>     So, if you want to keep clients simple (e.g. by only having a
>     single datastore view rather than two), then having writes going
>     to running and reads coming from operational may be a better
>     compromise rather than returning running + config false.
>
>     architecture applies to all distributed configuration management,
>     even if the devices choose not to expose all of the data in order
>     to present a simplified view to clients.
>
>
> You seem to be making an assumption that the lack of precision wrt/ 
> when some data
> has changed value is required for these "simple" devices. It is not.

No, this is not the reason why I think that NMDA applies to these 
"simple" devices at all.  I completely appreciate that many of these 
devices normally apply their configuration very quickly.

My argument for the applicability of NMDA is just about the devices 
returning the actual true values, because I believe that returning the 
true values is what is required to build robust distributed systems.

In 99% of cases, you can infer what the true value is likely to be from 
the intended value, but in the other 1% of cases you can't and in these 
scenarios the system likely fails, and the client probably has no way of 
knowing exactly what has actually failed, because the client does not 
know what configuration the device has actually applied.

> If the data modeler
> expects there is state data that needs to be exposed, then 1 
> oper-state leaf is added
> for the whole data structure.  There are so many details a client 
> developer needs to code from
The data modeller cannot know for a given config true node whether all 
devices that implement that model will always be able to implement that 
config node in a way that can never fail.  You either need a duplication 
of all the config nodes, or an operational state datastore.

>
> There are many systems that are distributed, and yet can still 
> converge in less than a second.
> and also advertise the proper capabilities like candidate, etc. The 
> NETCONF datastore model defined
> in RFC 6241 works fine for these systems.  Forcing them to upgrade 
> just to report these same
> (the only reason YANG library was picked apparently) will not help 
> force this extra work to get done.
I'm not trying to force them to report the same data twice.  I'm trying 
to encourage them to report the actual true values that are being used, 
e.g. because there are hardware issues, or out of resource issues, or 
bugs in the system that will sometimes cause the system to fail to apply 
the configuration.

Rob

>>     There is no business case for rewriting clients to use
>>     get-data(/foo, operational) instead of get(/foo-state).
>>
>>     It's starting to look like all the big-router-specific stuff like
>>     RD and schema-mount will
>>         On Wed, Jun 21, 2017 at 8:24 AM, Phil Shafer
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Jun 2017 10:31:26 -0700

On Thu, Jun 22, 2017 at 10:01 AM, Robert Wilton <[email-masked]> wrote:

> No, this is not the reason why I think that NMDA applies to these "simple"
> devices at all.  I completely appreciate that many of these devices
> normally apply their configuration very quickly.
>
> returning the actual true values, because I believe that returning the true
> values is what is required to build robust distributed systems.
>
> knowing exactly what has actually failed, because the client does not know
> what configuration the device has actually applied.
>
>
Thanks for making my point for me.
For many deployments there is no business case to update a lot of code to
go from 99% to 100%.
This is not a new problem, and if it turns out that a config=false
oper-status leaf is needed
to supply the actual value, then the developer justs adds that.

There is no real need to have the actual values at a 1:1 granularity with
the config nodes.
It is not really a burden to know about /foo-state/oper-status as a
special-case.
IMO it is more of a burden to compre entire data structures between
intended and operational
just to find out the oper-status.

Systems that need NMDA should migrate to it.
Other systems can use the transition strategy and update as needed over
time.

Andy

If the data modeler
> config node in a way that can never fail.  You either need a duplication of
> all the config nodes, or an operational state datastore.
>
>
>
> I'm not trying to force them to report the same data twice.  I'm trying to
> encourage them to report the actual true values that are being used, e.g.
> because there are hardware issues, or out of resource issues, or bugs in
> the system that will sometimes cause the system to fail to apply the
> configuration.
>
> Rob
>
>
>
> Rob
>>
>>
> Andy
>
>

---

From: Robert Wilton <[email-masked]>
Date: Fri, 23 Jun 2017 10:41:52 +0100

On 22/06/2017 18:31, Andy Bierman wrote:
>
>
> On Thu, Jun 22, 2017 at 10:01 AM, Robert Wilton <[email-masked] 
>>>         On Wed, Jun 21, 2017 at 1:46 PM, Kent Watsen
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>             Yes, this is why the proposal is the update
>>>             yang-library:1.0 with a new revision date.
>>>
>>>         Many people are OK with the limitations of traditional
>>>         datastores and do not want to
>>         But that may due to confusion about the precise meaning of
>>         the data that is being returned by the NETCONF RPCs today.
>>
>>         actually mean that at all, it only means that the client has
>>         asked for foo to be enabled.
>>
>>         intended and applied value is the same, so it doesn't
>>         matter.  But I think that the interesting question concerns
>>         when the intended and applied values diverge: if only a
>>         single value can be given back to the client then which value
>>         should it be?  I think that the "what is it doing" is more
>>         single datastore view rather than two), then having writes
>>         going to running and reads coming from operational may be a
>>         better compromise rather than returning running + config false.
>>
>>         So, in a long winded way, I am saying that I think that the
>>         NMDA architecture applies to all distributed configuration
>>         management, even if the devices choose not to expose all of
>>         the data in order to present a simplified view to clients.
>>
>>
>>     You seem to be making an assumption that the lack of precision
>>     wrt/ when some data
>     "simple" devices at all.  I completely appreciate that many of
>     these devices normally apply their configuration very quickly.
>
>     My argument for the applicability of NMDA is just about the
>     devices returning the actual true values, because I believe that
>     returning the true values is what is required to build robust
>     distributed systems.
>
>     In 99% of cases, you can infer what the true value is likely to be
>     from the intended value, but in the other 1% of cases you can't
>     and in these scenarios the system likely fails, and the client
>     probably has no way of knowing exactly what has actually failed,
>     because the client does not know what configuration the device has
>     actually applied.
>
>
My pleasure ;-)

> For many deployments there is no business case to update a lot of code 
> to go from 99% to 100%.
I agree, but the converse is also true.

> to supply the actual value, then the developer justs adds that.

Perhaps this works in bespoke scenarios, but I can't see how this 
approach works in a generalized way: Specifically, who is adding the 
extra oper leaf to the model?

If this is the developer of the standard model then they cannot know 
which devices may fail which bits of configuration.

But, If it is the device vendors adding the extra config=false 
oper-status leaves then the models end up fragmenting, clients are 
forced to handle each device in a bespoke way.

NMDA gives an architecture to do this in a generic way that can be 
applied in the same way to all devices and all models that are 
structured in a suitable way.

>
> There is no real need to have the actual values at a 1:1 granularity 
> with the config nodes.
I disagree.  Many clients probably think that they are getting actual 
values when they are not, particularly given that the datastore is given 
the somewhat misleading name called "running"!  I think that in the 
general case the client has more need for the actual value than the 
configured value.

> just to find out the oper-status.
The overhead seems the same to me if they compare against operational 
rather than running.

Current model:
Clients compare their desired state against the devices intended config 
(running datastore).  The client can determine whether the device has 
been given the configuration, but not whether the device is using it.

NMDA model:
(1) Client compares their desired state against the devices intended 
config (running datastore) and operational.  The client can determine 
both whether the device has been given the config and also whether the 
config has been applied.

(2) Or, client only compares their desired state against operational.  
The client cannot know whether the device has got their intended 
configuration, but they can determine that the operational behaviour 
matches their intent.

> Other systems can use the transition strategy and update as needed 
> over time.
This point at least we agree on ;-)

Thanks,
Rob

>>     the model, that this oper-state leaf is a tiny increment in the
>>     entire project.
>     The data modeller cannot know for a given config true node whether
>     all devices that implement that model will always be able to
>     implement that config node in a way that can never fail.  You
>     either need a duplication of all the config nodes, or an
>     operational state datastore.
>
>
>>
>>     and also advertise the proper capabilities like candidate, etc.
>>     The NETCONF datastore model defined
>>     (the only reason YANG library was picked apparently) will not
>>     help force this extra work to get done.
>     I'm not trying to force them to report the same data twice.  I'm
>     trying to encourage them to report the actual true values that are
>     being used, e.g. because there are hardware issues, or out of
>     resource issues, or bugs in the system that will sometimes cause
>     the system to fail to apply the configuration.
>
>     Rob
>
>>
>>
>>         Rob
>>
>>
>>     Andy
>>
>>>         It's starting to look like all the big-router-specific stuff
>>>         like RD and schema-mount will
>>>                 >until the htmlized version and diff are available
>>>                 at tools.ietf.org <http://tools.ietf.org>.
>>>                 >
>>>                 >The IETF Secretariat
>>>                 >
>>>                 >
>>>                 >

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Jun 2017 09:37:09 -0700

On Fri, Jun 23, 2017 at 2:41 AM, Robert Wilton <[email-masked]> wrote:

> Perhaps this works in bespoke scenarios, but I can't see how this approach
> works in a generalized way: Specifically, who is adding the extra oper leaf
> to the model?
>
> If this is the developer of the standard model then they cannot know which
> devices may fail which bits of configuration.
>
> But, If it is the device vendors adding the extra config=false oper-status
> leaves then the models end up fragmenting, clients are forced to handle
> each device in a bespoke way.
>
> NMDA gives an architecture to do this in a generic way that can be applied
> in the same way to all devices and all models that are structured in a
> suitable way.
>
>
>
> the somewhat misleading name called "running"!  I think that in the general
> case the client has more need for the actual value than the configured
> value.
>
> (running datastore).  The client can determine whether the device has been
> given the configuration, but not whether the device is using it.
>
> NMDA model:
> config (running datastore) and operational.  The client can determine both
> whether the device has been given the config and also whether the config
> has been applied.
>
> (2) Or, client only compares their desired state against operational.  The
> client cannot know whether the device has got their intended configuration,
> but they can determine that the operational behaviour matches their intent.
>
>
I have favored an RPC-based approach from the start.
e.g.

For writable-running:

   <rpc>
      <edit-config>
            ...  // regular params
           <wait-for-apply />
           <wait-timeout>60</wait-timeout>
           <timeout-action>send-diff</timeout-action>
      </edit-config>
    </rpc>

For candidate:

   <rpc>
      <commit>
            ...  // regular params
           <wait-for-apply />
           <wait-timeout>60</wait-timeout>
           <timeout-action>send-diff</timeout-action>
      </commit>
    </rpc>

Client sends an edit or commit with options to wait until the edit is
applied before
sending a response. Wait 60 seconds to timeout and then send back
a diff highlighting the values that are not applied yet (may be entire edit)

Other timeout actions could be ignore, rollback.

IMO this is much easier for the client to use than a 1:1 mapping between
config and state.  There are so many exceptions where the state data model
is not exactly the same as the config data model.

Andy

>> There are many systems that are distributed, and yet can still converge
>> in less than a second.
>> in RFC 6241 works fine for these systems.  Forcing them to upgrade just
>> to report these same
>> e.g. because there are hardware issues, or out of resource issues, or bugs
>> in the system that will sometimes cause the system to fail to apply the
>> configuration.
>>
>> Rob
>>
>>
>>
>> Rob
>>>
>>>
>> Andy
>>
>>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 26 Jun 2017 16:35:08 +0000

> You are saying YANG conformance mechanisms as defined in RFC 7950

To some extent, yes.  The main thing it that currently features and deviations
are expressed at a global-level, whereas we believe that servers may need to
be able to express these on a per-datastore basis.  For instance, a feature is
supported in <running>, but not in a dynamic datastore, or a module is
supported in <running>, but a deviation is needed in <operational>.

>Many people are OK with the limitations of traditional datastores and do not want
> to read the operational values of config=true nodes.  Vendors can deploy the fake
> foo-state.yang modules as needed for new style modules.

The -state trees are recommended to support a transition period.  Currently there is
no statement for how now the transition period may last.   Let the market decide,
right?  At some point a decision will need to be made to either stop publishing
-state modules, or something else.  Of course, moving a server from supporting
-state modules (the hard part) to the <operational> datastore should be easy.  So,
we're really only talking about servers that never want to support <operational>,
non NMDA-capable servers.  Do you think there is going to be a market for such
things?  - would these be ity-bitty IoT things?

> There is no business case for rewriting clients to use get-data(/foo, operational)
> instead of get(/foo-state).

See how easy a change it is?    And there's the benefit not having to advertise
a separate and potentially out-of-sync -state module, not to mention the reduction
of burden on module-designers to not maintain distinct -state modules in their
Appendix sections.

> It's starting to look like all the big-router-specific stuff like RD and schema-mount will
> cause YANG deployment to fork. That may be better than a 1-size-fits-all that
> nobody is happy with.

I don't think we're anywhere close to that yet.

Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 26 Jun 2017 10:23:39 -0700

> supported in <running>, but a deviation is needed in <operational>.

Datastore specific YANG sounds like a bad idea.
Can you elaborate on real use-cases?
I can see how YANG extensions might be added for controlling
behavior on new datastores, but not something like if-feature
that only applies to a subset of datastores.

> not want

IMO YANG modules are not rare or hard to create and the market will decide
which YANG modules are needed and which are not.

> operational)

But it is a sideways change -- no loss or gain of any functionality.
We needed to create proprietary <get-bulk> anyways, so it doesn't
really matter. The standard filtering in <get> is not sufficient.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Jun 2017 16:43:38 +0200

> any evolution away from "yang-library:1.0".

I think procedurally this requires a new RFC that updates the sections
5.6.4 and 5.6.5 of RFC 7950 with new text.

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