Subject: [netmod] LC of NDMA NETCONF/RESTCONF drafts

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 17 Jan 2018 10:39:44 -0800

The authors of draft-ietf-netconf-nmda-netconf and draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and believe that the documents are ready for LC.

This starts a 2 week LC on the two drafts that will end on January 31. Please send your comments on this thread. Comments like “I have reviewed the documents and believe they are ready for publication”, or “I have concerns about the document because …” are welcome and useful for the authors.

Authors please indicate whether you are aware of any IPR for either of the drafts.

Thanks.

Mahesh & Kent

---

From: Kent Watsen <[email-masked]>
Date: Wed, 17 Jan 2018 19:02:00 +0000

I'm not aware of any IPR impacting either of these two drafts.

Kent // as co-author

===== original message =====

Thanks.

Mahesh & Kent

_______________________________________________
Netconf mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=YD0IXtUkMMI3qIK63vNpsDmumHSc_7n1T6esiz6Nzhc&s=5dIbx4-7CM-5NmbIyhGS16He41fyV_CoCuTLBV0mDLw&e=

---

From: Robert Wilton <[email-masked]>
Date: Wed, 17 Jan 2018 22:38:05 +0000

Rob

On 17/01/2018 19:02, Kent Watsen wrote:
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Vladimir Vassilev <[email-masked]>
Date: Thu, 18 Jan 2018 08:57:55 +0100

Hello,

There is a YANG error in [email-masked]:

Error: XPath expression 'derived-from-or-self(../datastore, 
"or:operational")' with invalid identity param 'or:operational'
ietf-netconf-nmda.yang:148.63: error(348): invalid XPath expression syntax

Error: XPath expression 'derived-from-or-self(../datastore, 
"or:operational")' with invalid identity param 'or:operational'
ietf-netconf-nmda.yang:178.63: error(348): invalid XPath expression syntax

The correct datastore identity is ds:operational. The same error was 
reported for the previous version of the draft.

> -------- Forwarded Message --------
> Subject:     [netmod] validation of draft-ietf-netconf-nmda-netconf-01
> Date:     Mon, 13 Nov 2017 19:48:49 +0100
> From:     Vladimir Vassilev <[email-masked]>
> To: [email-masked] <[email-masked]>
>
> Hello,
>
> There is a validation error reported for
> [email-masked]:
>
> Error: XPath expression 'derived-from-or-self(../datastore,
> "or:operational")' with invalid identity param 'or:operational'
> [email-masked]:140.63: error(348): invalid
> XPath expression syntax

Vladimir

On 01/17/2018 07:39 PM, Mahesh Jethanandani wrote:
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Robert Wilton <[email-masked]>
Date: Fri, 26 Jan 2018 12:01:03 +0000

Hi,

One minor point that came up after the WG LC drafts had been posted is 
that draft-ietf-netconf-nmda-netconf-02 explicitly references the path 
"/yang-library/checksum", which means that the draft has a hard 
dependency on this leaf always existing at this path in YANG library.

e.g. section 2 of draft-ietf-netconf-nmda-netconf-02 contains:

    The parameter "checksum" has the same value as the leaf
    "/yang-library/checksum" from "ietf-yang-library".  This parameter
    MUST be present.

I think that it would be more flexible if the draft only referred to a 
"YANG library checksum", and then have Yang Library bis formally define 
the "YANG library checksum" term.  This is to avoid the need to formally 
update NMDA NETCONF draft, if the checksum path ever needs to be updated 
in a future revision of YANG library.

To give an example of where we hit a similar issue, was in RFC 7950, 
section 5.6.4, that has to be updated by 
draft-ietf-netconf-nmda-netconf-02 because it explicitly references the 
"/modules-state/module" list.   Generally, I think that it would be good 
to try and avoid these tight dependencies where possible, and try to 
have them more loosely coupled.

E.g., text from 7950:

        5.6.4 <https://tools.ietf.org/html/rfc7950#section-5.6.4>.
        Announcing Conformance Information in NETCONF

    This document defines the following mechanism for announcing
    conformance information.  Other mechanisms may be defined by future
    specifications.

    A NETCONF server MUST announce the modules it implements (see
    Section 5.6.5 <https://tools.ietf.org/html/rfc7950#section-5.6.5>) by implementing the YANG module "ietf-yang-library"
    defined in [RFC7895 <https://tools.ietf.org/html/rfc7895>] and listing all implemented modules in the
    "/modules-state/module" list.

Requiring this text in draft-ietf-netconf-nmda-netconf-02:

    This document updates [RFC7950], Section 5.6.4, to allow servers to
    advertise the capability :yang-library:1.1 instead of :yang-
    library:1.0, and to implement the subtree "/yang-library"
    [I-D.ietf-netconf-rfc7895bis] instead of "/modules-state".

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 26 Jan 2018 13:19:28 +0100

I support this proposal.

/js

On Fri, Jan 26, 2018 at 12:01:03PM +0000, Robert Wilton wrote:
> Hi,
> 
> One minor point that came up after the WG LC drafts had been posted is that
> draft-ietf-netconf-nmda-netconf-02 explicitly references the path
> "/yang-library/checksum", which means that the draft has a hard dependency
> on this leaf always existing at this path in YANG library.
> 
> I think that it would be more flexible if the draft only referred to a "YANG
> library checksum", and then have Yang Library bis formally define the "YANG
> library checksum" term.  This is to avoid the need to formally update NMDA
> NETCONF draft, if the checksum path ever needs to be updated in a future
> revision of YANG library.
> 
> 
> To give an example of where we hit a similar issue, was in RFC 7950, section
> 5.6.4, that has to be updated by draft-ietf-netconf-nmda-netconf-02 because
> it explicitly references the "/modules-state/module" list.   Generally, I
> think that it would be good to try and avoid these tight dependencies where
> possible, and try to have them more loosely coupled.
> 
> E.g., text from 7950:
> 
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 30 Jan 2018 10:27:39 -0800

Authors and WG,

We have not received any explicit support for this LC on this email thread. If you believe these drafts are important and should proceed, please state your support by responding to this email thread.

Thanks.

> On Jan 17, 2018, at 10:39 AM, Mahesh Jethanandani <[email-masked]> wrote:
> 

Mahesh & Kent

---

From: Kent Watsen <[email-masked]>
Date: Tue, 30 Jan 2018 18:55:32 +0000

I have read and support both drafts for advancement.

Kent // co-author

Authors and WG,

Thanks.

Mahesh & Kent

_______________________________________________
Netconf mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=chxZG5ZrBnHC_vO0f9kYhGnMwAUeF2ALqnpqjt2FOwI&s=cLxPvaw3wBK8KfUx0ZKNPyqPPhC17Yx-o9SJQ_q4AWE&e=

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Jan 2018 20:33:01 +0100

Same here.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 30 Jan 2018 12:35:33 -0800

Hi,

I have some questions about these drafts.

1) what if datastore set to "conventional"?
    There are many places where a datastore-ref type is used.
    However, "conventional" is valid for base "datastore", even though
    it is ambiguous as a datastore selector.

2) origin filter is limited to 1 source
   This filtering seems rather limited.  A client must retrieve
<with-origin> and check
    all the values in use, then make repeated requests for each source as a
different
    <origin-filter> leaf

3) with-defaults broken
    The operational datastore does not support with-defaults.
     Instead, the client must use origin-filter=or:default or with-origin
     and check all the origin attributes.  Since a client needs to use
     with-defaults for other datastores, this special handling of
<operational>
     seems unhelpful.

Andy

On Tue, Jan 30, 2018 at 10:27 AM, Mahesh Jethanandani <
[email-masked]> wrote:

> Authors and WG,
>
> We have not received any explicit support for this LC on this email
> thread. If you believe these drafts are important and should proceed,
> please state your support by responding to this email thread.
>
> Thanks.
>
> > The authors of draft-ietf-netconf-nmda-netconf and
> draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and
> believe that the documents are ready for LC.
> >
> > This starts a 2 week LC on the two drafts that will end on January 31.
> Please send your comments on this thread. Comments like “I have reviewed
> the documents and believe they are ready for publication”, or “I have
> concerns about the document because …” are welcome and useful for the
> authors.
> >

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 31 Jan 2018 08:57:10 +0100 (CET)

> Same here.

And same here.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 31 Jan 2018 09:11:18 +0100

>     it is ambiguous as a datastore selector.

We can add explicit text that an identity that does not resolve to a
datastore implemented by the server results in an invalid value error.
 
>     all the values in use, then make repeated requests for each source as a

If the client does <with-origin>, then it has all origin information
and it can filter locally. That said, we could make origin-filter a
leaf-list which is logically ORed so that one can retrieve
origin-filter=or:system or origin-filter=or:learned in one request.

>      with-defaults for other datastores, this special handling of

I think the with-defaults semantics for conventional configuration
datastores are much more complicated than necessary for the
operational state datastore. Note that that the operational state
datastore reports in-use values not really defaults:

  <leaf or:origin='default'>foo</leaf>

This reports that the value 'foo' is in use and that it originates
from a default value. Note that this could also be

  <leaf or:origin='intended'>foo</leaf>

in case the intended configuration datastore configured the value
'foo' (despite this value matching the default). The with-defaults
solution is pretty complex because it tries to handle how different
systems deal with configuration defaults. The idea is to not carry
this complexity over to in-use values in the operational state
datastore.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 31 Jan 2018 09:22:04 +0100 (CET)

Hi,

>     it is ambiguous as a datastore selector.

For edit-data, the text says:

        leaf datastore {
          type ds:datastore-ref;
          description
            "Datastore which is the target of the edit-data operation.

             If the target datastore is not writable, then the server
             MUST return an <rpc-error> element with an <error-tag>
             value of 'invalid-value'";

So from this it follows that if the client sends "conventional", the
server will reply with an 'invalid-value' error.

Maybe we can even clarify:

             If the target datastore is not writable, or is not
             supported on the server, then the server
             MUST return an <rpc-error> element with an <error-tag>

There is similar text for lock/unlock/validate.

But for get-data, the text just says:

        leaf datastore {
          type ds:datastore-ref;
          ...
          description
            "Datastore from which to retrieve data.";

I think we should add text:

  If the datastore is not supported on the server, , then the server
  MUST return an <rpc-error> element with an <error-tag> value of
  'invalid-value'.

>     all the values in use, then make repeated requests for each source as a

Since "AND" of origins doesn't really make any sense, I think we can
make this a leaf-list and explain that these values are OR:ed.  Do you
think this would be a good idea?

>      with-defaults for other datastores, this special handling of

The "with-defaults" feature is mostly useful in configuration
datastores, where the client needs to understand how the server treats
defaults.  When the server starts to operationally use config data, it
will also take default values into account and use these values, just
as if they had been explicitly configured.  default values are "in
use" and thus present in the operational state datastore (which by
definition contains all values that are in use).  Since these values
are present in the datastore, they are always returned.  If for some
reason a default value is NOT used, the leaf will not be present in
<operational>, and it will not be reported.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 31 Jan 2018 01:22:30 -0800

> datastore implemented by the server results in an invalid value error.

OK

> origin-filter=or:system or origin-filter=or:learned in one request.

OK

> this complexity over to in-use values in the operational state

Before NMDA, the client could decide if it wanted to retrieve default nodes
or not.
This client-choice has been removed from NMDA, which is a problem.

Andy

---

From: Robert Wilton <[email-masked]>
Date: Wed, 31 Jan 2018 09:28:39 +0000

As co-author, I have read and support both drafts for advancement.

In fact, I think that it is important that we get these drafts (and 
YL-bis) completed and standardized quickly, since the YANG models that 
IETF is standardizing rely on the NMDA.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Wed, 31 Jan 2018 11:31:20 +0000

Hi Andy,

On 31/01/2018 09:22, Andy Bierman wrote:
>
>
> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Before NMDA, the client could decide if it wanted to retrieve default 
> nodes or not.
We tried to reach a sensible compromise on the data returned from 
operational (defined in section 5.3 of the NMDA architecture):
  - it should return explicit values for everything that is affecting 
the actual running state of the device (regardless of whether the 
operational value matches a schema default value).
  - it does not need to, and should not, return operational values for 
stuff that isn't actually in use, i.e. don't return needless and 
unwanted data.

In particular, if no value is returned from a particular data node in 
<operational> then, barring mgmt protocol errors, a client can assume 
that any functionality associated with that data node is off (i.e. not 
in use).

Some examples to illustrate the behavior:

(i) If a protocol, e.g. OSPF,  is not enabled/running then <operational> 
does not need to return any data for it.  It would be reasonable to 
return a flag to indicate that OSPF is not enabled/running.

(ii) If you have some funky widget on an interface that defaults to 
being off and isn't being used then <operational> don't need to return 
any data for it.

(iii) But, if you have some funky widget on an interface that defaults 
to being on, then the server should return data for it.  If it is 
actually enabled, then it would indicate that it is on and return any 
associated values with its operational state, or if it is disabled then 
it should explicitly report that it is off.

(iv) I would regard that all applied configuration is "in use" by the 
system, even if it matches the default value, and hence it should be 
reported.

This behavior for <operational> is obviously slightly different from the 
existing with-default handling that is supported for configuration 
datastores.  As I recall, there were a couple of reasons that we decided 
to have a different behavior for <operational>:
(a) to have consistent semantics for all servers, rather than different 
servers supporting different with-defaults behaviors (which makes life 
harder for clients because they must cope with all variants).
(b) to remove any potential ambiguity if data isn't returned.  I.e. with 
the existing with-defaults semantics it is not clear to me that servers 
will always return an explicit value to indicate that a particular 
widget is off if the schema defines that the default it that is 
enabled.  If the server doesn't support a given widget at all, it is 
quite plausible that it will just return no data for it. In theory 
features/deviations should handle this, but those don't work so well if 
different linecards have different capabilities. Hence being explicit 
about stuff that is in use seems more robust.

Thanks,
Rob

>     Fax:   +49 421 200 3103         <https://www.jacobs-university.de/
>     <https://www.jacobs-university.de/>>
>
>
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 31 Jan 2018 13:32:59 +0100

Hi,

I read the draft draft-ietf-netconf-nmda-restconf-02, I believe it is
important and ready to be published. We plan an implementation.

Thanks for this work,

Lada

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 31 Jan 2018 16:53:48 +0000

I have read and support these two drafts going forward.

I do have one additional thought below on draft-ietf-netmod-revised-datastores section 5.3 default handling process.  See in-line...

From: Robert Wilton -X, January 31, 2018 6:31 AM

Hi Andy,

On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

OK

OK

Before NMDA, the client could decide if it wanted to retrieve default nodes or not.
This client-choice has been removed from NMDA, which is a problem.
We tried to reach a sensible compromise on the data returned from operational (defined in section 5.3 of the NMDA architecture):
 - it should return explicit values for everything that is affecting the actual running state of the device (regardless of whether the operational value matches a schema default value).
 - it does not need to, and should not, return operational values for stuff that isn't actually in use, i.e. don't return needless and unwanted data.

In particular, if no value is returned from a particular data node in <operational> then, barring mgmt protocol errors, a client can assume that any functionality associated with that data node is off (i.e. not in use).

(i) If a protocol, e.g. OSPF,  is not enabled/running then <operational> does not need to return any data for it.  It would be reasonable to return a flag to indicate that OSPF is not enabled/running.

(ii) If you have some funky widget on an interface that defaults to being off and isn't being used then <operational> don't need to return any data for it.

(iii) But, if you have some funky widget on an interface that defaults to being on, then the server should return data for it.  If it is actually enabled, then it would indicate that it is on and return any associated values with its operational state, or if it is disabled then it should explicitly report that it is off.

(iv) I would regard that all applied configuration is "in use" by the system, even if it matches the default value, and hence it should be reported.

This behavior for <operational> is obviously slightly different from the existing with-default handling that is supported for configuration datastores.  As I recall, there were a couple of reasons that we decided to have a different behavior for <operational>:
(a) to have consistent semantics for all servers, rather than different servers supporting different with-defaults behaviors (which makes life harder for clients because they must cope with all variants).
(b) to remove any potential ambiguity if data isn't returned.  I.e. with the existing with-defaults semantics it is not clear to me that servers will always return an explicit value to indicate that a particular widget is off if the schema defines that the default it that is enabled.  If the server doesn't support a given widget at all, it is quite plausible that it will just return no data for it.  In theory features/deviations should handle this, but those don't work so well if different linecards have different capabilities.  Hence being explicit about stuff that is in use seems more robust.

<eric> These are good examples.  It would be great if section 5.3 could be tweaked to make clearer the relationship between running datastore defaults and other operational datastore defaults for the same tree.

For example, let’s say I create a configured subscription, and the default transport protocol is NETCONF.  NETCONF will be used for that subscription even though the node might not be populated.  In this case, the object would not appear in the running datastore, but MUST* appear in the operational datastore with the default origin (as it is in-use).

This to me is the desired behavior as it doesn’t incorrectly add information to the running datastore, but shows what is in-use within operational.   I suspect other such relationships for other operational tree defaults could be asserted, perhaps based on the origin.

(* Maybe ‘MUST eventually’, as obviously there is a temporal relationship between the two datastores.)

Eric

Thanks,
Rob

/js

Andy

netmod mailing list

[email-masked]<mailto:[email-masked]>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 31 Jan 2018 17:24:11 +0000

Hi Eric,

On 31/01/2018 16:53, Eric Voit (evoit) wrote:
> I do have one additional thought below on 
> draft-ietf-netmod-revised-datastores section 5.3 default handling 
> process.  See in-line...
>
> *From:*Robert Wilton -X, January 31, 2018 6:31 AM
>
> Hi Andy,
>
> (i) If a protocol, e.g. OSPF,  is not enabled/running then 
> <operational> does not need to return any data for it.  It would be 
> reasonable to return a flag to indicate that OSPF is not enabled/running.
>
> associated values with its operational state, or if it is disabled 
> then it should explicitly report that it is off.
>
> This behavior for <operational> is obviously slightly different from 
> the existing with-default handling that is supported for configuration 
> datastores.  As I recall, there were a couple of reasons that we 
> decided to have a different behavior for <operational>:
> (a) to have consistent semantics for all servers, rather than 
> different servers supporting different with-defaults behaviors (which 
> makes life harder for clients because they must cope with all variants).
> (b) to remove any potential ambiguity if data isn't returned.  I.e. 
> with the existing with-defaults semantics it is not clear to me that 
> servers will always return an explicit value to indicate that a 
> particular widget is off if the schema defines that the default it 
> that is enabled. If the server doesn't support a given widget at all, 
> it is quite plausible that it will just return no data for it.  In 
> theory features/deviations should handle this, but those don't work so 
> well if different linecards have different capabilities.  Hence being 
> explicit about stuff that is in use seems more robust.
>
> <eric> These are good examples.  It would be great if section 5.3 
> could be tweaked to make clearer the relationship between running 
> datastore defaults and other operational datastore defaults for the 
> same tree.
>
I think that the boat has probably sailed on changing 5.3 in the NMDA 
architecture, unless it is done as an erratum.  I'm not sure that this 
is required.  I actually think that FAQs are a good place for these 
sorts of examples, and extra explanatory text.

> For example, let’s say I create a configured subscription, and the 
> default transport protocol is NETCONF.  NETCONF will be used for that 
> subscription even though the node might not be populated.  In this 
> case, the object would not appear in the running datastore, but MUST* 
> appear in the operational datastore with the default origin (as it is 
> in-use).
>
Yes, that is the intended interpretation, although I think that we say 
SHOULD rather than MUST, and give the implementation a bit of leeway in 
choosing what is "in use".

Also, the NMDA definition of the "default" origin is wider than the YANG 
default statement, or "with-defaults" definition.  The NMDA definition 
of the "default" origin is:

          "Denotes configuration that does not have an configured or
           learned value, but has a default value in use.  Covers both
           values defined in a 'default' statement, and values defined
           via an explanation in a 'description' statement.";

The aim of this text is to allow more complex defaults, such as a 
hierarchical default behavior that cannot be expressed using a simple 
"default" statement.

Thanks,
Rob

> This to me is the desired behavior as it doesn’t incorrectly add 
> information to the running datastore, but shows what is in-use within 
> operational.   I suspect other such relationships for other 
> operational tree defaults could be asserted, perhaps based on the origin.
>
> (* Maybe ‘MUST eventually’, as obviously there is a temporal 
> relationship between the two datastores.)
>
> Eric
>
> Thanks,
> Rob
>
>
>
>         /js
>
>     Andy
>
>         --
>     [email-masked] <mailto:[email-masked]>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 31 Jan 2018 19:16:19 +0100

> I do have one additional thought below on draft-ietf-netmod-revised-datastores section 5.3 default handling process.  See in-line...

Well, this document is with the RFC editor now. I do not think it needs
clarification. It already has text in 5.3 such as:

   Requests to retrieve nodes from <operational> always return the value
   in use if the node exists, regardless of any default value specified
   in the YANG module.  If no value is returned for a given node, then
   this implies that the node is not used by the device.

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 31 Jan 2018 20:55:40 +0000

From: Robert Wilton, January 31, 2018 12:24 PM

Hi Eric,

Hi Andy,

OK

OK

<eric> These are good examples.  It would be great if section 5.3 could be tweaked to make clearer the relationship between running datastore defaults and other operational datastore defaults for the same tree.
I think that the boat has probably sailed on changing 5.3 in the NMDA architecture, unless it is done as an erratum.  I'm not sure that this is required.  I actually think that FAQs are a good place for these sorts of examples, and extra explanatory text.

<eric> FAQs are fine considering that NMDA Arch has gone through WGLC.

For example, let’s say I create a configured subscription, and the default transport protocol is NETCONF.  NETCONF will be used for that subscription even though the node might not be populated.  In this case, the object would not appear in the running datastore, but MUST* appear in the operational datastore with the default origin (as it is in-use).
Yes, that is the intended interpretation, although I think that we say SHOULD rather than MUST, and give the implementation a bit of leeway in choosing what is "in use".

<eric>  The point I was trying to highlight is that there are definable categories of defaults and their instantiation across the NMDA datastores. For example, the case listed above has a ‘config true’ tree with a default value which is not populated in ‘running’, but SHOULD be populated in ‘operational’.   Because of the SHOULD, it will be hard to build portable cross-vendor applications.  But that is where we are at this time.

At some future time, implementers followed by YANG users, will want guidance (and consistency) across this universe of cross-datastore object population possibilities. And BTW this guidance will need to consider the complexities of the time dimension too.

Eric

Also, the NMDA definition of the "default" origin is wider than the YANG default statement, or "with-defaults" definition.  The NMDA definition of the "default" origin is:

The aim of this text is to allow more complex defaults, such as a hierarchical default behavior that cannot be expressed using a simple "default" statement.

Thanks,
Rob

Eric

Thanks,
Rob

/js

Andy

netmod mailing list