Subject: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04

From: Lou Berger <[email-masked]>
Date: Fri, 1 Sep 2017 17:02:24 -0400

All,

This starts a two week working group last call on
draft-ietf-netmod-revised-datastores-04.

The working group last call ends on September 17.
Please send your comments to the netmod mailing list.

Positive comments, e.g., "I've reviewed this document and
believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thank you,
Netmod Chairs

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 Sep 2017 16:15:35 +0200 (CEST)

Hi,

As one of the authors of this document, I believe it is ready for
publication.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Sep 2017 16:40:53 +0200

I believe the document is ready for publication.

/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: Robert Wilton <[email-masked]>
Date: Mon, 11 Sep 2017 16:22:01 +0100

As one of the authors, I would like to see a few minor editorial 
updates, described below.  Otherwise I believe that the document is 
ready for publication.

Proposed changes:

1. I think that the document could further emphasis that the schema for 
all the conventional datastores must be the same.

*Old:*

4.5.  Conventional Configuration Datastores

    The conventional configuration datastores are a set of configuration
    datastores that share a common schema, allowing data to be copied
    between them.  The term is meant as a generic umbrella description of
    these datastores.  The set of datastores include:

*New:*

4.5.  Conventional Configuration Datastores

    The conventional configuration datastores are a set of configuration
    datastores that all share exactly the same schema, allowing data to 
be copied
    between them.  The term is meant as a generic umbrella description of
    these datastores.  The set of datastores include:

2. I think that the description of the intended datastore could be 
expanded to give a bit more clarity.

*OLD:*

4.4.  The Intended Configuration Datastore (<intended>)

    The intended configuration datastore (<intended>) is a read-only
    configuration datastore.  It is tightly coupled to <running>.  When
    data is written to <running>, the data that is to be validated is
    also conceptually written to <intended>. Validation is performed on
    the contents of <intended>.

    For simple implementations, <running> and <intended> are identical.

    <intended> does not persist across reboots; its relationship with
    <running> makes that unnecessary.

    ...

*NEW:*

4.4.  The Intended Configuration Datastore (<intended>)

    The intended configuration datastore (<intended>) is a read-only
    configuration datastore.  It represents the configuration after all
    configuration transformations to <running> are performed (e.g.
    template expansion, inactive configuration removal), and is the
    configuration that the system attempts to apply.

    It is tightly coupled to <running>.  When data is written to
    <running>, the data that is to be validated is also conceptually
    written to <intended>.  Validation is performed on the contents of
    <intended>.

    For simple implementations, <running> and <intended> are identical.

    The contents of <intended> is also related to the 'config true'
    subset of <operational>, and hence a client can determine to what
    extent the intended configuration is currently applied by checking
    whether the contents of <intended> also appears in <operational>.

    <intended> does not persist across reboots; its relationship with
    <running> makes that unnecessary.

    ...

3. I think that it may aid readability if the section on conventional 
configuration datastores was moved above the description of the 
individual conventional configuration datastores, which could then be 
intended one level.  Best illustrated via the change to the table of 
contents.

*E.g. current TOC: *

    4.  Architectural Model of Datastores . . . . . . . . . . . . . .   8
      4.1.  The Startup Configuration Datastore (<startup>) . . . . .   9
      4.2.  The Candidate Configuration Datastore (<candidate>) . . .  10
      4.3.  The Running Configuration Datastore (<running>) . . . . .  10
      4.4.  The Intended Configuration Datastore (<intended>) . . . .  10
      4.5.  Conventional Configuration Datastores . . . . . . . . . .  11
      4.6.  Dynamic Configuration Datastores  . . . . . . . . . . . .  11
      4.7.  The Operational State Datastore (<operational>) . . . . .  11
        4.7.1.  Remnant Configuration . . . . . . . . . . . . . . . .  12
        4.7.2.  Missing Resources . . . . . . . . . . . . . . . . . .  13
        4.7.3.  System-controlled Resources . . . . . . . . . . . . .  13
        4.7.4.  Origin Metadata Annotation  . . . . . . . . . . . . .  13

*Proposed TOC: *

    4.  Architectural Model of Datastores . . . . . . . . . . . . . .   8
      4.1.  Conventional Configuration Datastores . . . . . . . . . .   9
        4.1.1.  The Startup Configuration Datastore (<startup>) . . .  10
        4.1.2.  The Candidate Configuration Datastore (<candidate>) .  10
        4.1.3.  The Running Configuration Datastore (<running>) . . .  10
        4.1.4.  The Intended Configuration Datastore (<intended>) . .  11
      4.2.  Dynamic Configuration Datastores  . . . . . . . . . . . .  12
      4.3.  The Operational State Datastore (<operational>) . . . . .  12
        4.3.1.  Remnant Configuration . . . . . . . . . . . . . . . .  13
        4.3.2.  Missing Resources . . . . . . . . . . . . . . . . . .  13
        4.3.3.  System-controlled Resources . . . . . . . . . . . . .  14
        4.3.4.  Origin Metadata Annotation  . . . . . . . . . . . . .  14

4. Finally, I noticed one reference that could be improved, by changing 
it from "(described below)" to a proper section reference:

647,648c644,645
<    circumstances, e.g., an abnormal value is 'in use', or due to remnant
<    configuration (described below).  Note, that deviations are still
---
 >    circumstances, e.g., an abnormal value is "in use", or due to remnant
 >    configuration (see Section 4.7.1).  Note, that deviations are still

Thanks,
Rob

On 01/09/2017 22:02, Lou Berger wrote:
> .

---

From: Kent Watsen <[email-masked]>
Date: Mon, 11 Sep 2017 17:12:42 +0000

As an author, I believe the draft is ready for publication.

Regarding Robert's editorial suggestions:

1) how moving "all" like this?  (i.e., must have same modules, deviations, etc.)
-   datastores that all share exactly the same schema, allowing data to be copied
+  datastores that share exactly the same schema, allowing all data to be copied

2) better, but I think we should expand "It" in the beginning of the 2nd paragraph
to "The intended configuration datastore".  Also, how about this for the 3rd
paragraph instead?  (fixes a couple  plurality issues and one transition issue):

   The contents of <intended> are related to the 'config true'
   subset of <operational>, such that a client can determine to what
   extent the intended configuration is currently applied by checking
   whether the contents of <intended> also appear in <operational>.

3) I'm okay with this.

4) This is better.

Thanks,
Kent

On 9/11/17, 11:22 AM, "Robert Wilton" <[email-masked]<mailto:[email-masked]>> wrote:

As one of the authors, I would like to see a few minor editorial updates, described below.  Otherwise I believe that the document is ready for publication.

Proposed changes:

1. I think that the document could further emphasis that the schema for all the conventional datastores must be the same.

Old:

New:

   The conventional configuration datastores are a set of configuration
   datastores that all share exactly the same schema, allowing data to be copied
   between them.  The term is meant as a generic umbrella description of
   these datastores.  The set of datastores include:

2. I think that the description of the intended datastore could be expanded to give a bit more clarity.

OLD:

   ...

NEW:

   ...

3. I think that it may aid readability if the section on conventional configuration datastores was moved above the description of the individual conventional configuration datastores, which could then be intended one level.  Best illustrated via the change to the table of contents.

E.g. current TOC:

Proposed TOC:

4. Finally, I noticed one reference that could be improved, by changing it from "(described below)" to a proper section reference:

647,648c644,645

Thanks,
Rob

All,

Thank you,

Netmod Chairs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Sep 2017 19:27:45 +0200

>    whether the contents of <intended> also appear in <operational>.

Editorial: Should this not be "The content of <intended> is" and "the
content of <intended>"?

There are several possible pitfalls here since (i) <operational> can
change anytime, (ii) it might not be easy/possible to obtain a
consistent snapshot of <operational>, and (iii) dynamic datastores can
provide values that "overwrite" <intended> and hence comparing values
may not really be sufficient. As long as the text is understood as
additional explanation and not used to write naive code to determine
how much of <intended> has been applied, it is fine. Otherwise, it
may be a source of future problems.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 Sep 2017 19:31:24 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> -   datastores that all share exactly the same schema, allowing data to be
> -   copied

Or just remove "all".

>    whether the contents of <intended> also appear in <operational>.

Ok.

> 3) I'm okay with this.

I agree that the proposed TOC changes are better.

> 4) This is better.

Agreed.

/martin

> 
> 
> Thanks,
> Kent
> 
> 
> 
> On 9/11/17, 11:22 AM, "Robert Wilton"
> <[email-masked]<mailto:[email-masked]>> wrote:
> 
> 
> 1. I think that the document could further emphasis that the schema
> for all the conventional datastores must be the same.
> 
> Old:
> 
> 4. Finally, I noticed one reference that could be improved, by
> changing it from "(described below)" to a proper section reference:
> 
> 647,648c644,645

---

From: Robert Wilton <[email-masked]>
Date: Tue, 12 Sep 2017 11:48:58 +0100

>> + datastores that share exactly the same schema, allowing all data to
I also have a slight preference for just removing "all", but am also OK 
if it moves.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Tue, 12 Sep 2017 12:09:57 +0100

> Editorial: Should this not be "The content of <intended> is" and "the
I think "contents of <intended> are" is correct because the elements can 
be enumerated.  We also seem to use "contents" in other places in the draft.

> may be a source of future problems.
One tweak could be to change "applied" to "in use":

    The contents of <intended> are related to the 'config true'
    subset of <operational>, such that a client can determine to what
    extent the intended configuration is currently in use by checking
    whether the contents of <intended> also appear in <operational>.

Is this better?

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Sep 2017 13:18:07 +0200

>    whether the contents of <intended> also appear in <operational>.

I think this is better but the change does not address (i)-(iii) in
case someone uses this text to go and write naive code. But perhaps
nobody is ever going to do that. ;-)

/js

---

From: "t.petch" <[email-masked]>
Date: Wed, 13 Sep 2017 17:42:30 +0100

I think that in one respect, perhaps the key respect, this I-D fails to
state the obvious (or at least what is likely obvious to those who have
been at this for a while:-).

The problem that is hinted at but never explicitly stated is that data
objects can appear both as configuration and as state, e.g. when learned
by other means or at other times.  The original model of datastores
required these data objects to be modelled twice, as configuration false
and as configuration true, and since there could be many of them, and
the rules of YANG require them to be in separate trees, this led to a
twin-trees approach such as can be seen in RFC7277 or RFC7223.

Amongst other problems, this separation of operational state from
configuration in a
   separate branch in the data model has been found to be operationally
   complicated and impacts the readability of module
   definitions.  The relationship between
   the branches is not machine readable and filter expressions operating
   on configuration and on related operational state are different.

With revised datastores, there is a single data object to model both
values  but this now appears in two datastores, one for the
configuration value, one for the operational state value.

Instead of two YANG data nodes there is one data node in two datastores,
a more elegant and simpler solution to the problem.

I believe that text such as this would make the I-D much easier to
follow.  As it stands, you have to read between the lines and speculate.

Tom Petch

----- Original Message -----
From: "Lou Berger" <[email-masked]>
To: "netmod WG" <[email-masked]>
Cc: <[email-masked]>;
<[email-masked]>
Sent: Friday, September 01, 2017 10:02 PM

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

---

From: Lou Berger <[email-masked]>
Date: Wed, 13 Sep 2017 12:56:31 -0400

> follow.  As it stands, you have to read between the lines and speculate.
Tom,

    Thank you for the comments.  Do you have a specific change in mind,
or could your propose text, that would address this?

Thanks,
Lou

---

From: Phil Shafer <[email-masked]>
Date: Wed, 13 Sep 2017 18:58:32 -0400

>draft-ietf-netmod-revised-datastores-04.

I have reviewed this document and have several minor recommendations.
In addition, there were comments at the mic at the last IETF during
the NETCONF WG meeting regarding the draft-dsdt-nmda-netconf-00.txt
draft that refer to the architecture rather than the NETCONF mapping
of that architecture, specifically on validation, and restraints on
templating mechanisms.  The video is:

https://www.youtube.com/watch?v=wTlyEqTSuqo&feature=youtu.be&list=PLC86T-6ZTP5jdbiwi5ggLNnwLn1-r0M4h&t=4726

I'm submitting these comments as a "diff" against the text source
of the draft.   Hopefully this is clear and precise.

Thanks,
 Phil

diff --git a/draft-ietf-netmod-revised-datastores.org b/draft-ietf-netmod-revised-datastores.org
index b859760..be3b3b8 100644
--- a/draft-ietf-netmod-revised-datastores.org
+++ b/draft-ietf-netmod-revised-datastores.org
@@ -210,8 +210,8 @@ Some observations:
 - Operational state has not been defined as a datastore although there
   were proposals in the past to introduce an operational state
   datastore.
-- The NETCONF <get/> operation returns the content of the running
-  configuration datastore together with the operational state.  It is
+- The NETCONF <get> operation returns the content of <running>
+  together with the operational state.  It is
   therefore necessary that "config false" data is in a different branch
   than the "config true" data if the operational state can have a
   different lifetime compared to configuration or if
@@ -318,6 +318,26 @@ If a device does not have a distinct <startup> and non-volatile is
 available, the device will typically use that non-volatile storage to
 allow <running> to persist across reboots.

+*** Validation
+
+The process of "validation" examines a datastore to ensure the
+resulting configuration data will satisfy all data models constraints
+given in ^YANG^ section 8.1.   All constraints in all supported
+data models must be satisfied for the data to be considered "valid".
+
+Validation will examine the data after any locally-defined templating
+mechanism is performed and any inactive configuration is removed.
+
+While the operation of any specific templating mechanism is outside
+the scope of this document, such mechanisms are constrained by the
+rules of any data models, and cannot break the constraints given in
+^YANG^.
+
+The implication of the existence of templating mechanisms is that
+<running> is now explicitly allowed to be invalid, since the
+templating mechanism may be supplying additional data that satisfies
+constraints that may be satisfied by <running> itself.
+
 ** The Intended Configuration Datastore (<intended>)

 The intended configuration datastore (<intended>) is a read-only
@@ -422,6 +442,7 @@ error.
 <operational> does not persist across reboots.

 *** Remnant Configuration @remnant@
+
 Changes to configuration may take time to percolate through to
 <operational>.  During this period, <operational> may contain
 nodes for both the previous and current configuration, as closely as
@@ -709,12 +730,14 @@ This example defines a dynamic configuration datastore called
 "ephemeral", which is loosely modeled after the work done in the I2RS
 working group.

-  1. Name            : ephemeral
-  2. YANG modules    : all (default)
-  3. YANG data nodes : all "config true" data nodes
-  4. How applied     : automatic
-  5. Protocols       : NC/RC (default)
-  6. YANG Module     : (see below)
+| Name            | Value                        |
+|-----------------+------------------------------|
+| Name            | ephemeral                    |
+| YANG modules    | all (default)                |
+| YANG data nodes | all "config true" data nodes |
+| How applied     | automatic                    |
+| Protocols       | NC/RC (default)              |
+| YANG Module     | (see below)                  |

 !! include-figure example-ds-ephemeral.yang

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 14 Sep 2017 18:15:40 +0200

> +constraints that may be satisfied by <running> itself.

Section 8.1 in RFC 7950 identifies some constraints that "are true in
all data trees". If they are violated in <running>, it means that the
content is not a data tree as defined by YANG.

The same section also says that <running> MUST always be valid. This is
probably intended to be removed, but constraints that are supposed to
hold in all data trees should IMO stay no matter what.

Lada

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

---

From: "t.petch" <[email-masked]>
Date: Thu, 14 Sep 2017 17:37:21 +0100

Lou

I am proposing that the text I included would go more or less as is into
the beginning of section 3.  I think that it makes sense even before we
get into the historic definitions of configuration etc.  I want to spell
out the problem - two different values of the one conceptual object,
originally handled with two schema nodes in one store of data, now
handled with one schema node in two datastores.  Thus start section 3
with

NEW

Some data objects can take two different values, the one configured by
the user (configuration), the other the one that the device is using
(operational state),
perhaps as a result of interactions with hardware, with protocols, with
other devices and so on.

 The original model of datastores
required these data objects to be modelled twice, as configuration false
and as configuration true, and, since there could be many of them, and
the rules of YANG require them to be in separate trees, this led to a
twin-trees approach, such as can be seen in RFC7277 or RFC7223.

This duplication of definitions and separation of operationsl state from
configuration leads to a number of problems.  Having them in
 separate branches in the data model is operationally
complicated and impacts the readability of module
 definitions.  The relationship between
 the branches is not machine readable and filter expressions operating
on configuration and on related operational state are different.

With revised datastores,  the data object appears once in the model
but can appear in two datastores, one for the
configured value, one for the operational state value.

 Instead of two YANG data nodes there is one data node in two
datastores, a more elegant and simpler solution to the problem.

/NEW

I would make minor changes to the last three paragraphs of Section 3
mostly excising where I have already included that material

Tom Petch

> > a more elegant and simpler solution to the problem.
ta

Tom Petch

----- Original Message -----
From: "Lou Berger" <[email-masked]>
To: "t.petch" <[email-masked]>; "netmod WG" <[email-masked]>
Cc: <[email-masked]>;
<[email-masked]>
Sent: Wednesday, September 13, 2017 5:56 PM
Subject: Re: [netmod] WG Last Call:
draft-ietf-netmod-revised-datastores-04 duplicaiton

---

From: "t.petch" <[email-masked]>
Date: Fri, 15 Sep 2017 12:19:42 +0100

This I-D updates RFC7950, since it changes the XPath context that YANG
uses, yet there is no mention of 'Updates'

Well, a purist will say that people can create and use  models using
RFC7950 with no need to have any understanding of this I-D so
technically no 'Updates' is needed.

But a practical engineer will say that the expectation is that many, if
not most, future models will rely on this I-D and its updates to RFC7950
so to say that you do not need to know about it is just misleading.

I am in the latter camp.

I thought of alternatives.  It is true that new models will have a
Normative Reference to this I-D but I suspect that that will not be
enough to alert users.

RFC6087bis could mention it but that is aimed at producers rather than
consumers who are the ones affected.

So. pragmatically, I think that this I-D needs an 'Updates'.

Tom Petch

----- Original Message -----
From: "Lou Berger" <[email-masked]>
To: "netmod WG" <[email-masked]>
Cc: <[email-masked]>;
<[email-masked]>
Sent: Friday, September 01, 2017 10:02 PM
Subject: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04

---

From: "t.petch" <[email-masked]>
Date: Fri, 15 Sep 2017 12:29:01 +0100

Looking at a YANG module in future, how can I tell whether or not it is
written to work with revised datastores?

If the module is written assuming revised datastores and the environment
does not support this in some regard, then we have a management
malfunction, which could be disastrous.

I think that there should be some mechanistic way, something that can be
automated, for a system to check whether or not a module is assuming
revised datastores or not.  This is a bit like the change from YANG 1.0
to YANG 1.1; there needs to be a way of telling what environment the
module is written for, and so we have the

yang-version 1.1;

statement.

Revised datastores needs something similar in the module.

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 15 Sep 2017 13:57:34 +0200

> written to work with revised datastores?

Ideally, this ought to be a wrong question. A YANG module (or rather a YANG data
model) should specify constraints for a data tree, no matter where the tree
happens to reside.

Coupling a data modelling language with rather specific aspects of an NM
application is a bad design.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 15 Sep 2017 14:21:30 +0200 (CEST)

> model) should specify constraints for a data tree, no matter where the tree

I agree, and an old module can be implemented in an NMDA-compatible
server (with some redundant info), and a new modules can be implemented in a
non-NMDA-compatible server (with limited functionality).

But the truth is that modules are and will be designed to fit into
some environment (or "meta model").  For example, with NMDA, there
will be a single tree.  If we had an annotation for "comments" on
nodes, you wouldn't see any leafs called "description".  If we didn't
have the ability to create things in the protocol, our models would
have objects of type "RowStatus".  Etc.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Sep 2017 14:34:43 +0200

> uses, yet there is no mention of 'Updates'

I think the editors of the document reached the conclusion that the
xpath context rules stated in section 5.1. are the only meaningful
interpretation which is consistent with what RFC 7950 says.

The question is whether the text 'changes' the xpath context, or
'refines' the xpath context, or 'clarifies' the xpath context.  On a
synchronous system (where intended config and applied config never
differ), there is no change at all.

That said, I have no strong opinion about the question whether section
5.1 requires an 'Updates: RFC 7950' or not. I do not think section 5.1
is relevant for a system that uses RFC 7950 without implementing NMDA
and hence the value of having a forward pointer from RFC 7950 to NMDA
is likely not critical to have.

/js

---

From: "t.petch" <[email-masked]>
Date: Fri, 15 Sep 2017 17:20:15 +0100

Inactive appears a dozen times but is not defined, except in the course
of those appearances it effectively is, but is sometimes 'inactive',
sometimes 'inactive configuration', sometimes 'inactive data'.

I would find it clearer if the term was used consistently and if there
was an explicit definition amongst the other definitions in section 2
such as

inactve configuration: Configuration that is present in <running> which
is not in use by the device and which plays no part in validation.  It
cannot appear in any other datastore.  The protocols that are currently
standardised do not support inactive configuration but a number of
proprietary protocols do. Inactive configuration is only exposed to
clients that indicate support for inactive configuration; clients not
indicating support for  inactive configuration receive the contents of
<running> with the inactive configuration removed.

This would put a stake in the ground for as and when the concept is
standardised and may reduce the proliferation of the term with multiple
meanings.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Sep 2017 19:09:59 +0200

Two comments:

- Obviously, inactive can be in <candidate> and I would not rule out
  that inactive configuration can be in any other or future
  configuration datastores.

- Whether protocols support inactive or not does not belong into a
  definition of what inactive configuration is. The same for backwards
  compatibility considerations etc.

So if we define inactive configuration, the definition should be
something like this:

* inactive configuration: Configuration held in a configuration
  datastore that is marked to be inactive. Inactive configuration is
  ignored during validation and never applied and actively used by
  a device.

Yes, we should use 'inactive configuration' everywhere to be consistent.

/js

---

From: Phil Shafer <[email-masked]>
Date: Fri, 15 Sep 2017 15:40:49 -0400

>sometimes 'inactive configuration', sometimes 'inactive data'.

Agree.  Consistent terms are good things.

>cannot appear in any other datastore.

Inactive configuration should be allowed in <candidate> and <startup>,
as well as in dynamic datastores.  It's hard to put constraints on
a facility that we're really not defining.

>The protocols that are currently
>proprietary protocols do.

In JUNOS, we use the standard protocols but encoded these as
non-standard attributes.

>Inactive configuration is only exposed to

This is also not true for our implementation.  If you <get-config>
on any datastore that contains inactive data, you'll receive
that data.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Sep 2017 14:07:58 -0700

Hi,

I strongly agree with Tom that the current draft is an update to RFC 7950.
I also strongly disagree with the decision to omit RFC 2119 in a standards
track document. IMO RFC 2119 terms need to be used in normative text,
especially when dealing with XPath and YANG compiler behavior.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Sep 2017 14:41:37 -0700

> on any datastore that contains inactive data, you'll receive

But this means if any clients use the disable-node feature then all clients
need to know about the feature as well, or they will mistake these nodes
for enabled nodes (i.e., plain configuration according to the standard) .

I am in favor of waiting, and not defining new YANG rules that conflict
with real deployment. Better to wait until standard protocols need to
support
inactive vs. active configuration.

Thanks,

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 15 Sep 2017 20:39:57 -0400

>for enabled nodes (i.e., plain configuration according to the standard) .

The alternative would be removing inactive config from normal
<get-data> results, which means that a save/restore would be
discarding inactive config, which isn't acceptable.  Better to give
all data than to risk discarding anything.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Sep 2017 18:39:47 -0700

> all data than to risk discarding anything.
It might get set to "active" if the client preserves the
special attribute it doesn't know about.

This looks like 1 issue where each client cannot opt-in when ready.
Too bad it can't be standardized, even in a simplified form.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 16 Sep 2017 09:24:03 +0200

> especially when dealing with XPath and YANG compiler behavior.

RFC 8174:

   o  These words can be used as defined here, but using them is not
      required.  Specifically, normative text does not require the use
      of these key words.  They are used for clarity and consistency
      when that is what's wanted, but a lot of normative text does not
      use them and is still normative.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 16 Sep 2017 02:56:45 -0700

>       use them and is still normative.
So what?
Existing YANG specifications use RFC 2119 terms.
This draft uses those terms, just with lower-case.
Either way, the new YANG rules seem half-baked and not ready
for standardization.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 16 Sep 2017 12:14:08 +0200

> Either way, the new YANG rules seem half-baked and not ready

OK. Then please tell us where you see problems. The usage of must vs
MUST does not seem to be the issue.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 16 Sep 2017 09:59:30 -0700

> MUST does not seem to be the issue.

sec 4.4:

    Validation is performed on the contents of <intended>.

Does this mean validation is not done on <running>?
The draft does not say.  If so, then this seems to break all
existing clients that validate <running>. Standard operations
such as <commit> or <edit-config> with :writable-running capability work
this way.

What happens if a client does validation on <running>? It now can fail even
though RFC 7950, sec. 8.1 says:

   *The running configuration datastore MUST always be valid.*

The motivation is clear in the RD draft, sec 4.3:

   The running configuration datastore (<running>) holds the complete
   current configuration on the device.  It may include inactive
   configuration or template-mechanism-oriented configuration that
   require further expansion.

This forces a client to accept unspecified proprietary inactive
configuration and proprietary templates
that apparently are not subject to YANG validation.

   Currently there are no standard mechanisms defined that affect
   <intended> so that it would have different contents than <running>,
   but this architecture allows for such mechanisms to be defined.

This is a significant change in the NETCONF/RESTCONF standards which is
completely unrelated to operational state. The client MUST understand
unspecified
proprietary differences between <running> and <intentional>.  The client
can now
assume that <running> is always valid, but this draft breaks that.

IMO, only the <operational> datastore work is standards-ready.

Andy

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 17 Sep 2017 15:41:15 +0200 (CEST)

> This draft uses those terms, just with lower-case.

Actually, section 5.1 XPath Context in the revised datastore draft
uses the same language as section 6.4.1 XPath Context in RFC 7950.  In
fact, the text in the draft is copied (and adjusted) from RFC 7950.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 17 Sep 2017 08:31:46 -0700

Hi,

My concern is that the definition of <running> is being changed to
include undefined and undeclared proprietary extensions.
This is counter-productive to the IETF's stated goal of interoperability.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 17 Sep 2017 10:32:49 -0700

> This is counter-productive to the IETF's stated goal of interoperability.

I would prefer to solve this problem by making disabled nodes part of the
standard:
https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00
Bring back Kent's draft -- define a simple boolean for enabled/disabled.

I don't understand why templates are mentioned in the draft.
since they are not really defined.  Isn't it good enough to say that
the server can add configuration nodes to the <intended> datastore,
without getting specific about non-standard mechanisms?
There are many other ways the server can inject configuration that are not
mentioned.

Andy

---

From: "t.petch" <[email-masked]>
Date: Sun, 17 Sep 2017 21:21:07 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
Sent: Friday, September 15, 2017 6:09 PM

> Yes, we should use 'inactive configuration' everywhere to be
consistent.

Juergen

Yes, your definition is better than mine; let's add it.

Tom Petch

---

From: "t.petch" <[email-masked]>
Date: Sun, 17 Sep 2017 21:33:13 +0100

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
Sent: Sunday, September 17, 2017 2:41 PM

> > > > I strongly agree with Tom that the current draft is an update to
RFC
> > > 7950.

Martin

'Adjusted' might be seen as a weasel word:-)

   If the XPath expression is defined in a substatement to a
      "notification" statement, the accessible tree is the notification
      instance, all state data in the server, and the running
      configuration datastore.

becomes

If the XPath expression is defined in a substatement to a
      "notification" statement, the accessible tree is the notification
      instance and all operational state in the server.

Goodbye <running> (well, running configuration in RFC7950).  Is it a
material difference? - it will take me a while to work that one out.

I focussed on the XPath rules because they seemed the clearest case, but
updating the definitions, and saying this section will replace the
definitions in [RFC6241] and [RFC7950] when these documents are revised
seems .... well, like an Erratum held for Update i.e. another Updates.

Tom Petch

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 18 Sep 2017 09:58:35 +0200 (CEST)

> material difference? - it will take me a while to work that one out.

The difference is that the xpath expressions no longer sees unused
configuration in running.  But if the config is used, it exists in
<operational> under the same path as before, and it is available.

> seems .... well, like an Erratum held for Update i.e. another Updates.

Are you saying that this is an argument for having "Updates: 7950"?

/martin

---

From: Robert Wilton <[email-masked]>
Date: Mon, 18 Sep 2017 10:28:43 +0100

Hi Andy,

At the moment, NMDA does not change the definition of <running> for a 
standards compliant implementation of YANG/NETCONF/RESTCONF.  It is 
still the same as in 7950, and <running> must still be a "valid 
configuration data tree" for a standards complaint implementation.

However, the draft acknowledges that proprietary extensions exist that 
can modify the behaviour of <running> in ways that means that <running> 
is not always a valid configuration data tree.  The draft gives two 
examples of how <running> could be manipulated (inactive config, and 
templates).

If those extensions are standardized then I think it is likely that 
those RFCs would need to update 7950 to indicate that <running> isn't 
necessarily a "valid configuration data tree" when those extensions are 
used.  But I don't think that needs to be stated in the NMDA 
architecture at this time.

So, what is <intended>?
  - this is meant to represent the configuration that the system will 
actually attempt to apply after any and all manipulation (e.g. by 
templates, inactive removal, perhaps system scripts, etc) of the 
configuration has been performed.
  - it must always be a valid configuration data tree.
  - If <running> is updated then <intended> is always updated at the 
same time.  Hence, any successful change to <running> requires that 
<intended> has also been updated and validated.  E.g. in RESTCONF terms, 
I think that both <running> and  <intended> should get the same 
last-change timestamp whenever <running> is updated.
  - It provides a known fixed point so that any client can see the full 
validated config, i.e. even for devices that implement proprietary 
manipulations of the configuring in <running>.
  - If the device doesn't support any extra proprietary config 
manipulations, then <intended> is identical to <running>.

I think that we can possibly do a bit more to better define what 
<intended is>.  My previous suggestion as an improvement was below 
(perhaps you think it needs more clarification)?:

*OLD:*

    ...

*NEW:*

    ...

Thanks,
Rob

On 17/09/2017 16:31, Andy Bierman wrote:
> On Sun, Sep 17, 2017 at 6:41 AM, Martin Bjorklund <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
>     > [email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > > > I strongly agree with Tom that the current draft is an
>     update to RFC
>     > > 7950.

---

From: Robert Wilton <[email-masked]>
Date: Mon, 18 Sep 2017 11:14:55 +0100

> Yes, your definition is better than mine; let's add it.
I'm not necessarily opposed to this, but I think that we want to be 
careful here.  Inactive configuration and templating are only meant to 
be examples of how <running> could differ from <intended>, and we really 
aren't trying to provide normative definitions of them.  Is putting a 
definition of 'inactive configuration' in this draft going to 
potentially cause problems for a future 'inactive configuration' 
extension that could possibly want to define the term differently?

If we do decide to incorporate a definition, I would suggest at least 
tweaking it slightly to avoid the possible ambiguity of the last phrase:

* inactive configuration: Configuration held in a configuration
   datastore that is marked to be inactive. Inactive configuration is
   ignored during validation, never applied, and not actively used by
   a device.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Sep 2017 12:26:14 +0200

On Mon, Sep 18, 2017 at 11:14:55AM +0100, Robert Wilton wrote:
> I'm not necessarily opposed to this, but I think that we want to be careful
> here.  Inactive configuration and templating are only meant to be examples
> of how <running> could differ from <intended>, and we really aren't trying
> to provide normative definitions of them.  Is putting a definition of
> 'inactive configuration' in this draft going to potentially cause problems
> for a future 'inactive configuration' extension that could possibly want to
> define the term differently?

Yes, my preference would be to leave the definition of inactive
configuration to a future draft.

>   ignored during validation, never applied, and not actively used by

Yes, this is better (if we have to define this). It all boils down:

a) We publish an architecture which enables future standardization
   work on things we know exist in real implementations.

b) We strictly limit us to what we define right now and this means
   that the architecture does not describe what some real
   implementations do and we have to revise the architecure should
   future work started to standardize such things.

For simple inactive configuration, I do see an opportunity for a
standard solution and hence I think what the revised datastores I-D
proposes makes a lot of sense (but then I am of course biased here).
It provides an architectural framework that enabled a further
evolution without having to change the architectural framework again.

/js

---

From: Lou Berger <[email-masked]>
Date: Mon, 18 Sep 2017 09:33:58 -0400

All,

    The LC is closed.  There are clearly some issues to discuss and
resolve before this document can be submitted for publications.  Given
the issues raised, as well as the good on-list discussion, I'd like to
ask the authors to formally track all issues raised and their resolutions. 

We have two different issue tracking tools available at the moment: the
WG trac instance [1], or the github document repo [2]. The authors are
free to choose their preferred method, and should let the WG know once
the issues have been entered as well as once an issue is addressed with
through discussion and, as needed, draft text change.

Thank you,

Lou

(as Shepherd)

[1] https://trac.ietf.org/trac/netmod/
[2] https://github.com/netmod-wg/datastore-dt

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 18 Sep 2017 16:02:10 +0200 (CEST)

> configuration to a future draft.

+1

Since Andy raised a similar issue for templates, maybe we need to make
it more clear that both inactive and templates are really just
examples of things that can influence what goes into <intended> from
<running>.

> evolution without having to change the architectural framework again.

I also prefer (a).  If we did (b) without any additional explanation,
it would be quite unclear why we even bother to define <intended>.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Sep 2017 07:21:59 -0700

On Mon, Sep 18, 2017 at 2:28 AM, Robert Wilton <[email-masked]> wrote:

> standards compliant implementation of YANG/NETCONF/RESTCONF.  It is still
> the same as in 7950, and <running> must still be a "valid configuration
> data tree" for a standards complaint implementation.
>
> However, the draft acknowledges that proprietary extensions exist that can
> modify the behaviour of <running> in ways that means that <running> is not
> always a valid configuration data tree.  The draft gives two examples of
> how <running> could be manipulated (inactive config, and templates).
>

I don't see how NMDA can both acknowledge and violate the MUST be valid in
RFC 7950.
That statement is quite clear in RFC 7950.

> If those extensions are standardized then I think it is likely that those
> RFCs would need to update 7950 to indicate that <running> isn't necessarily
> a "valid configuration data tree" when those extensions are used.  But I
> don't think that needs to be stated in the NMDA architecture at this time.
>

 Right -- because 7950 still holds any any server that does not have a
valid <running>
is non-compliant to 7950.

Andy

So, what is <intended>?
>  - If <running> is updated then <intended> is always updated at the same
> time.  Hence, any successful change to <running> requires that <intended>
> has also been updated and validated.  E.g. in RESTCONF terms, I think that
> both <running> and  <intended> should get the same last-change timestamp
> whenever <running> is updated.
> I think that we can possibly do a bit more to better define what <intended
> is>.  My previous suggestion as an improvement was below (perhaps you think
> it needs more clarification)?:
>
> *OLD:*
>

---

From: Robert Wilton <[email-masked]>
Date: Mon, 18 Sep 2017 16:34:17 +0100

On 18/09/2017 15:21, Andy Bierman wrote:
>
>
> On Mon, Sep 18, 2017 at 2:28 AM, Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Andy,
>
>     At the moment, NMDA does not change the definition of <running>
>     for a standards compliant implementation of
>     YANG/NETCONF/RESTCONF.  It is still the same as in 7950, and
>     <running> must still be a "valid configuration data tree" for a
>     standards complaint implementation.
>
>     However, the draft acknowledges that proprietary extensions exist
>     that can modify the behaviour of <running> in ways that means that
>     <running> is not always a valid configuration data tree.  The
>     draft gives two examples of how <running> could be manipulated
>     (inactive config, and templates).
>
>
> I don't see how NMDA can both acknowledge and violate the MUST be 
> valid in RFC 7950.
I think that NMDA acknowledges non standard extensions could exist that 
would violate RFC 7950 if/when those features are used, and provides a 
standard architecture (i.e. the definition of <intended>) to allow 
devices to expose the effects of those bespoke features in a standard way.

Phil had proposed adding the following text on validation:

+The implication of the existence of templating mechanisms is that
+<running> is now explicitly allowed to be invalid, since the
+templating mechanism may be supplying additional data that satisfies
+constraints that may not be satisfied by <running> itself.

Do you think that text like this would help?  Or perhaps more 
generically, something like this:

The implication of the existence of mechanisms that can allow
<intended> to differ from <running> means that <running> is no
longer guaranteed to always be valid.  However, when any
change is made to <running>, <intended> must also be updated at
the same time and be successfully validated before the operation
on <running> can be completed.

Obviously this would then need to update 7950.

>
>     If those extensions are standardized then I think it is likely
>     that those RFCs would need to update 7950 to indicate that
>     <running> isn't necessarily a "valid configuration data tree" when
>     those extensions are used.  But I don't think that needs to be
>     stated in the NMDA architecture at this time.
>
>
I agree.

Thanks,
Rob

>
>
> Andy
>
>     So, what is <intended>?
>      - this is meant to represent the configuration that the system
>     will actually attempt to apply after any and all manipulation
>     (e.g. by templates, inactive removal, perhaps system scripts, etc)
>     of the configuration has been performed.
>      - If <running> is updated then <intended> is always updated at
>     the same time.  Hence, any successful change to <running> requires
>     that <intended> has also been updated and validated. E.g. in
>     RESTCONF terms, I think that both <running> and  <intended> should
>     get the same last-change timestamp whenever <running> is updated.
>      - It provides a known fixed point so that any client can see the
>     full validated config, i.e. even for devices that implement
>     proprietary manipulations of the configuring in <running>.
>>         > > > I also strongly disagree with the decision to omit RFC
>>         2119 in a
>>         > > standards

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Sep 2017 09:03:13 -0700

On Mon, Sep 18, 2017 at 8:34 AM, Robert Wilton <[email-masked]> wrote:

>> can modify the behaviour of <running> in ways that means that <running> is
>> not always a valid configuration data tree.  The draft gives two examples
>> of how <running> could be manipulated (inactive config, and templates).
>>
>
> standard architecture (i.e. the definition of <intended>) to allow devices
> to expose the effects of those bespoke features in a standard way.
>
> Do you think that text like this would help?  Or perhaps more generically,
> something like this:
>
>

No.  I do not agree that the MUST in RFC 7950 can be removed.
I do not agree the architecture should update YANG at all.

Andy

>> <intended is>.  My previous suggestion as an improvement was below (perhaps
>> you think it needs more clarification)?:
>>
>> *OLD:*
>>

---

From: Robert Wilton <[email-masked]>
Date: Mon, 18 Sep 2017 17:17:46 +0100

On 18/09/2017 17:03, Andy Bierman wrote:
>
>
> On Mon, Sep 18, 2017 at 8:34 AM, Robert Wilton <[email-masked] 
>>         At the moment, NMDA does not change the definition of
>>         <running> for a standards compliant implementation of
>>         <running> must still be a "valid configuration data tree" for
>>         a standards complaint implementation.
>>
>>         However, the draft acknowledges that proprietary extensions
>>         exist that can modify the behaviour of <running> in ways that
>>         means that <running> is not always a valid configuration data
>>         tree.  The draft gives two examples of how <running> could be
>>         manipulated (inactive config, and templates).
>>
>>
>     I think that NMDA acknowledges non standard extensions could exist
>     that would violate RFC 7950 if/when those features are used, and
>     provides a standard architecture (i.e. the definition of
>     <intended>) to allow devices to expose the effects of those
>     bespoke features in a standard way.
>
OK.

So, can the NMDA draft just be silent about whether <running> is valid 
or not?  I.e. allowing the current statement in 7950 to stand.  That way 
if inactive or templating are standardized, and if the standard solution 
means that running is no longer always valid, then those drafts can 
update 7950 as appropriate.

The NMDA architecture can still specify <intended> and also still 
specify that it is always valid, and explain its relationship to 
<running> and <operational>.

Thanks,
Rob

>>         If those extensions are standardized then I think it is
>>         likely that those RFCs would need to update 7950 to indicate
>>         that <running> isn't necessarily a "valid configuration data
>>         tree" when those extensions are used.  But I don't think that
>>         needs to be stated in the NMDA architecture at this time.
>>
>>
>>      Right -- because 7950 still holds any any server that does not
>>     have a valid <running>
>>          - this is meant to represent the configuration that the
>>         system will actually attempt to apply after any and all
>>         manipulation (e.g. by templates, inactive removal, perhaps
>>         system scripts, etc) of the configuration has been performed.
>>          - If <running> is updated then <intended> is always updated
>>         at the same time.  Hence, any successful change to <running>
>>         requires that <intended> has also been updated and
>>         validated.  E.g. in RESTCONF terms, I think that both
>>         <running> and <intended> should get the same last-change
>>         timestamp whenever <running> is updated.
>>          - It provides a known fixed point so that any client can see
>>         the full validated config, i.e. even for devices that
>>         implement proprietary manipulations of the configuring in
>>         <running>.
>>         I think that we can possibly do a bit more to better define
>>         what <intended is>.  My previous suggestion as an improvement
>>         was below (perhaps you think it needs more clarification)?:
>>
>>         *OLD:*
>>
>>>         On Sun, Sep 17, 2017 at 6:41 AM, Martin Bjorklund
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>             > > > I strongly agree with Tom that the current draft
>>>             is an update to RFC
>>>             > > 7950.
>>>             > > > I also strongly disagree with the decision to omit
>>>             RFC 2119 in a
>>>             > > standards

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Sep 2017 18:21:07 +0200

> > I do not agree the architecture should update YANG at all.

I am with Andy here. <running> has always had the requirement to be
valid and we are not supposed to change that. Mechanisms for inactive
configuration or templating must be designed to be backwards compatible
I think.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Sep 2017 09:44:45 -0700

> configuration or templating must be designed to be backwards compatible
I have been trying to think of a way that an enterprise-wide flag day
upgrade is not required,
but no luck so far. As Phil pointed out, if 1 client is using disabled
nodes,
unaware clients clients might end up deleting them if disabled nodes
are just omitted from <get-config> responses. (e.g., replace operation).

A client has no requirement to maintain attributes sent with server
responses
(unlike the server for <rpc> -> <rpc-reply>), so returning the disabled
nodes
to an unaware client is no solution either.

It looks to me that an operator has to make sure all apps that alter
configuration
are aware of the disabled nodes.

IMO a standard attribute should be defined using RFC 7952:

  md:annotation enabled {
    type boolean;
    description "...";
  }

Even if the server supports vendor-specific attributes, it has to report
this attribute as well.
The default is enabled, so only disabled nodes need this attribute.
Standard configuration can wait.  Standard reporting should not wait.

Since clients can ignore YANG extensions, a new version of YANG will be
needed eventually,
but at least this allows 3rd party clients to recognize disabled nodes from
any vendor.

/js

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 18 Sep 2017 20:07:34 +0200 (CEST)

> configuration or templating must be designed to be backwards compatible

Ok.  If we keep the requirement that <running> in itself must be
valid, it just restricts the usefulness/expressiveness of inactive and
template mechanisms, but it might be ok.

I think that even w/o this requirement, the observable behavior for a
client can be backwards compatible.  For example, suppose we have an
inactive access control rule that refers to a non-existing interface in
<running>.  If a client that doesn't know anything about inactive asks
for the contents of <running>, our implementation removes the inactive
nodes from the reply to the client.  Only a client that opts-in to
inactive will receive a reply with things that looks invalid if you
don't take the inactive annotation into account.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Sep 2017 11:25:26 -0700

> don't take the inactive annotation into account.
There are many ways that validation can fail because inactive nodes are
present,
and considered part of the validation.

e,g, min-elements, max-elements, mandatory, unique.

I think we all agree that validation on the enabled nodes is supposed to
continue to work.

Here is an attempt at a backwards-compatible solution:

1) current <get-config> and <get> responses only include enabled nodes.
2) old-style <edit-config> operations do not alter inactive nodes
3) NMDA clients use <get-data>, not <get-config> or <get>.  These responses
    include enabled and disabled nodes, so validation does not apply for
<running>
4) new style <edit-config> (i.e. <datastore> parameter used) can alter any
type of data node

Note that the YANG MUST rule still applies, because validation is only done
on enabled nodes.
It is only the response message representations that cannot be validated,
not the contents
of <running> on a server.

Andy

---

From: Robert Wilton <[email-masked]>
Date: Tue, 19 Sep 2017 10:39:52 +0100

On 18/09/2017 19:25, Andy Bierman wrote:
>
>
> On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund <[email-masked] 
>     Juergen Schoenwaelder <[email-masked]
> There are many ways that validation can fail because inactive nodes 
> are present,
> I think we all agree that validation on the enabled nodes is supposed 
> to continue to work.
>
>     include enabled and disabled nodes, so validation does not apply 
> for <running>
> 4) new style <edit-config> (i.e. <datastore> parameter used) can alter 
> any type of data node
//I think that inactive should always be an optional extension.  Not 
everything needs the additional complexity.

Hence rather than tying this function to specific NETCONF operations, I 
would suggest that there should be an extra parameter (like for 
with-defaults) to allow a client to indicate to the server that a get or 
edit request is using the "with-inactive" extension.
1) The server should also have a capability (or perhaps a leaf defined 
in YANG library) to indicate that it supports inactive configuration.
2) If a client doesn't use the extra "with-inactive" parameter during a 
get request then only active nodes are returned.
3) If a client doesn't use the extra "with-inactive" parameter during an 
edit-data request then the request cannot include an extra inactive 
meta-data.  The request is processed in a way that is equivalent to an 
existing NETCONF implementation, but it may unknowingly remove some 
inactive configuration (e.g. via a replace or remove operation on an 
inactive node).  Operations like create, delete, none, replace should 
all treat an inactive target node the same way as in the node doesn't 
exist (e.g. delete on an inactive node would return a "data-missing" 
error), this ensures that the behaviour that an unaware client observes 
is the same as the existing behaviour that it would expect from a 
regular 6241 compliant NETCONF implementation.
4) It a client makes a get request including the "with-inactive" 
parameter then they also get the inactive nodes as well, marked with a 
meta-data annotation.
5) If a client makes an edit request including the "with-inactive" 
parameter, then the inactive meta-data annotation can be used to label 
inactive nodes.  Inactive nodes are regarded as regular data nodes for 
create/delete/replace/none operation error checking.

I think that this approach is similar (perhaps even the same) as Martin 
described.

Thanks,
Rob

>
> Note that the YANG MUST rule still applies, because validation is only 
> done on enabled nodes.
> It is only the response message representations that cannot be 
> validated, not the contents

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 19 Sep 2017 11:55:59 +0200 (CEST)

> > I think we all agree that validation on the enabled nodes is supposed

Yes.

> Hence rather than tying this function to specific NETCONF operations,
> I would suggest that there should be an extra parameter (like for
> with-defaults) to allow a client to indicate to the server that a get
> or edit request is using the "with-inactive" extension.
> 2) If a client doesn't use the extra "with-inactive" parameter during
> a get request then only active nodes are returned.
> 3) If a client doesn't use the extra "with-inactive" parameter during
> an edit-data request then the request cannot include an extra inactive
> error), this ensures that the behaviour that an unaware client
> observes is the same as the existing behaviour that it would expect
> from a regular 6241 compliant NETCONF implementation.
> I think that this approach is similar (perhaps even the same) as
> Martin described.

This is indeed how our implementation works (except I think we don't
do 5; if the client sends an "inactive" attribute it doesn't have to
also send with-inactive).

> > of <running> on a server.

So the question is how we can make sure that the text in the NMDA
draft covers this yet-to-be-defined feature w/o having to define it
now?  We thought that the current text was sufficient, but do we have
to make any changes to it?

/martin

---

From: "t.petch" <[email-masked]>
Date: Tue, 19 Sep 2017 11:59:23 +0100

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
Sent: Monday, September 18, 2017 8:58 AM

> > > > > > I strongly agree with Tom that the current draft is an
update to
> > RFC
> > > > > 7950.
> > > > > > I also strongly disagree with the decision to omit RFC 2119
in a
> > > > > standards
> > > > > > track document. IMO RFC 2119 terms need to be used in
normative
> > text,
> > > > >    o  These words can be used as defined here, but using them
is
> > not
> > > > >       required.  Specifically, normative text does not require
the
> > use
> > > > >       when that is what's wanted, but a lot of normative text
does
> > not

Yes

Tom Petch

---

From: Robert Wilton <[email-masked]>
Date: Tue, 19 Sep 2017 16:22:24 +0100

> to make any changes to it?
1) Do we also need to illustrate a similar proof of concept templating 
implementation to show that templating could work whilst keeping running 
valid?  I would prefer that this is just deferred to whichever draft 
defines templating.

2) I think that we need to reach a decision as to whether the NMDA 
architecture needs to explicitly state that <running> is always valid, 
or if that can be left to the existing statement in 7950.  My thinking 
is that if the conclusion is that <running> must always be valid, then 
it would be helpful to explicitly state it the descriptions of both 
<running> and <startup> in the NMDA architecture.

3) I think that it would be useful to further refine my previous 
proposed text for intended, particularly rewriting the text on 
validation.  This should hopefully also address Balazs' concern about 
default values be included in validation.

<Old>

    One example of such a mechanism is support for marking nodes as
    inactive in <running>.  Inactive nodes are not copied to <intended>,
    and are thus not taken into account when validating the
    configuration.

    Another example is support for templates.  Templates are expanded
    when copied into <intended>, and the expanded result is validated.

</Old>
<Proposed>

4.1.4.  The Intended Configuration Datastore (<intended>)

    template expansion, removal of inactive configuration), and is the

    <intended> is tightly coupled to <running>. Whenever data is written
    to <running>, then <intended> is also immediately updated by
    performing all necessary transformations to the contents of <running>
    and then <intended> is validated.

    <intended> may also be updated independently of <running> (e.g., if
    one of the configuration transformations is changed), but <intended>
    must always be a 'valid configuration data tree' as defined in
    Section 8.1 of [RFC7950].

    One example of such a mechanism is support for marking nodes as
    inactive in <running>.  Inactive nodes are not copied to <intended>.
    A second example is support for templates, which can perform
    transformations on the configuration from <running> to the
    configuration written to <intended>.

</Proposed>

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Wed, 20 Sep 2017 10:52:37 +0100

There have been no objections to proposed changes (1), (3) and (4) so we 
will apply those to the draft.

(2) is still awaiting further comment from the latest updated text that 
I sent yesterday.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Wed, 20 Sep 2017 16:48:39 +0100

Hi Lou,

We are using github to track the issues: 
https://github.com/netmod-wg/datastore-dt/issues

We think that all issues have been entered.  The authors have discussed 
them today and will send proposed resolutions to the alias.

Thanks,
Rob

---

From: Lou Berger <[email-masked]>
Date: Wed, 20 Sep 2017 13:51:47 -0400

Sounds great. Thank you for the update.

Lou

---

From: Robert Wilton <[email-masked]>
Date: Fri, 22 Sep 2017 10:03:09 +0100

Hi,

Regarding whether <running> is always valid, the proposed modification 
to the draft is to add the following text to section 4.3 that describes 
<running>:

OLD:

4.3.  The Running Configuration Datastore (<running>)

    If a device does not have a distinct <startup> and non-volatile is
    available, the device will typically use that non-volatile storage to
    allow <running> to persist across reboots.

NEW:

4.3.  The Running Configuration Datastore (<running>)

    The running configuration datastore (<running>) holds the complete
    current configuration on the device.  This could, for example, include
    inactiveconfiguration or template-mechanism-oriented configuration
    thatrequires further expansion.However, <running> must always be a
    'valid configuration data tree' as defined in Section 8.1 of [RFC7950].

    If a device does not have a distinct <startup> and non-volatile is
    available, the device will typically use that non-volatile storage to
    allow <running> to persist across reboots.

END

Then the intention is that if inactive or a templating solution is 
standardized then those drafts would update the validation rules in RFC 
7950 such that <running> is still valid.  E.g. an inactive config draft 
would probably indicate that validation excludes all configuration nodes 
that are marked as inactive.

Does anyone have any comments?

Do we also need to state that <startup> must always be a 'valid 
configuration data tree'?

Thanks,
Rob

On 19/09/2017 16:22, Robert Wilton wrote:
>>>>      > On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
>>>>      > >
>>>>      > > > No.  I do not agree that the MUST in RFC 7950 can be 
>>>> removed.
>>>>      > > > I do not agree the architecture should update YANG at all.
>>>>      > > OK.
>>>>      >
>>>>      > I am with Andy here. <running> has always had the 
>>>> requirement to be
>>>>      > valid and we are not supposed to change that. Mechanisms for
>>>>      inactive
>>>>      > configuration or templating must be designed to be backwards
>>>>      compatible
>>>>      > I think.
>>>>
> implementation to show that templating could work whilst keeping 
> running valid?  I would prefer that this is just deferred to whichever 
> draft defines templating.
>

---

From: "t.petch" <[email-masked]>
Date: Fri, 22 Sep 2017 17:34:03 +0100

Robert

I wonder if this says the opposite of what is intended

- <running> holds the complete  current configuration on the device.

- This could include inactiveconfiguration

 - <running> must always be a  'valid configuration data tree' as
defined in Section 8.1 of [RFC7950].

Ergo, inactiveconfiguration must form part of a valid configuration
tree.

I thought the idea was that inactiveconfiguration was logically removed
before validation but this seems to state the opposite..

Tom Petch

---

From: Robert Wilton <[email-masked]>
Date: Fri, 22 Sep 2017 18:12:50 +0100

Hi Tom,

I agree.

I agree.

I agree.

> Ergo, inactiveconfiguration must form part of a valid configuration

Ergo, inactive configuration can form part of a valid configuration
tree.

> before validation but this seems to state the opposite..
I don't think that this is necessarily true.  One choice is inactive 
configuration is removed before validation, but this isn't quite what 
I'm proposing.  I'm proposing that the act of validation itself is 
refined (via an tbd inactive configuration draft) such that it ignores 
configuration nodes marked as inactive.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Wed, 27 Sep 2017 17:12:37 +0100

We want to close on some of the NMDA document comments.  I'll send a 
separate summary for all the issues later, possible tomorrow.

In the absence of seeing any comments to the contrary, and with the 
change supported by the other authors, I will apply the proposed update 
to the <intended> description below.

This should resolve two issues:
https://github.com/netmod-wg/datastore-dt/issues/9
  - Title: "Make it clear that validation of intended includes default 
values"

https://github.com/netmod-wg/datastore-dt/issues/3
- Title: "Enhance description of intended datastore"

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Wed, 27 Sep 2017 17:28:14 +0100

The authors discussed this, and we will close this issue 
(https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the 
NMDA architecture need to use RFC 2119 language?) by adding RFC 2119 
text to the document, which will probably be best illustrated with an 
updated draft revision.

For the record, the majority of the authors had the view that RFC 2119 
language does not particularly aid readability in this architecture 
document.

Thanks,
Rob

On 16/09/2017 10:56, Andy Bierman wrote:
>
>
> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder 
> <[email-masked] 
>     Fax:   +49 421 200 3103         <http://www.jacobs-university.de/
>     <http://www.jacobs-university.de/>>
>
>

---

From: Lou Berger <[email-masked]>
Date: Wed, 27 Sep 2017 13:20:13 -0400

I think this goes to if this, or any, draft is a proposed standard or
not. In other words, if it specifies any behavior that for which
interoperability between independent implementations is the objective. 
My general view is that in a Proposed Standard RFC, if it impacts
interoperability, the text should be normative and an RFC should use
2119 language to identify such normative text.  I accept that this is
not strictly required by IETF process, but it has become the norm for PS
track RFCs produced today  -- and I see no reason to not follow IETF norm.

In the context of this draft , as I read it, at least section 5.1 and
some portions of 4.

Lou

On 9/27/2017 12:28 PM, Robert Wilton wrote:
>>     the use
>>     does not

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 27 Sep 2017 19:41:39 +0200 (CEST)

> track RFCs produced today  -- and I see no reason to not follow IETF norm.

As Rob wrote, we will add 2119 language to the draft, since that's
seems to be WG consensus.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Sep 2017 22:41:56 +0200

Lou,

text is normative without RFC 2119 language. There clearly is no such
'norm' unless people try to make it a new norm and I am strictly
opposed to that. If the reason to add RFC 2119 language is to comply
to a new norm being created, I have to object. If you want such a norm
to be created, write an I-D and run it through the process.

/js

PS: Sorry co-authors I promised to be silent but somehow I can't let
    this reasoning go without seriously questioning it.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Sep 2017 13:56:10 -0700

Hi,

> to be created, write an I-D and run it through the process.

It is quite common for Standards Track documents to use RFC 2119 terms.
The only new norm being set here is that the RD draft mixes architecture and
normative YANG/protocol behavior together.

If this was an Informational RFC that just discussed architecture,
then I would agree the RFC 2119 terms are not needed.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Sep 2017 23:03:27 +0200

> normative YANG/protocol behavior together.

The idea that normative text requires RFC 2119 words is wrong.
 
> then I would agree the RFC 2119 terms are not needed.

If the only reason to add RFC 2119 language is to comply to an
unwritten norm, then I am questioning adding RFC 2119 language. There
needs to be a bit more logic and reasoning for each decision whether a
must or MUST or a should or a SHOULD is appropriate.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Sep 2017 14:04:57 -0700

Hi,

I do not want to generate more process so I will drop the issue,
but the fact that this draft updates RFC 7950 instead of RFC 6244
indicates the problems with it are way beyond using capital letters for a
few words.

Andy

---

From: Lou Berger <[email-masked]>
Date: Wed, 27 Sep 2017 17:50:30 -0400

Juergen,

I guess our experiences at the IETF differ.  Certainly RFCs I authored
prior to 2219 (being published) were loose in their use of
capitalization and, frankly, sometimes open to interpretation as to what
was normative and what was informative.  But soon very soon after, most
of us switched over to citing RFC2119 and using its language to
distinguish between the two -- and I think this truly helped readers and
implementers know what they had to do to conform with and what they
didn't to ensure interoperable implementations. I'm really not sure  how
20 years later, the use of RFC2119 to identify normative language can be
considered anything but the norm, let alone a proposed 'new norm'.

FWIW of the 3198 RFCs with a 'standards'  category published after
RFC2119, 1995 reference RFC2119.  In the last 5 years the numbers are
961 and 892 respectively.

Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Sep 2017 00:03:24 +0200

Lou,

I do not have statistics, just some RFC text:

- RFC 8174 section 2 first bullet in the === NEW === text says "These
  words can be used as defined here, but using them is not required.
  Specifically, normative text does not require the use of these key
  words.  They are used for clarity and consistency when that is
  what's wanted, but a lot of normative text does not use them and is
  still normative."

- I can also point to RFC 2119 section 6 which says "they MUST only be
  used where it is actually required for interoperation or to limit
  behavior which has potential for causing harm (e.g., limiting
  retransmisssions)".

/js

---

From: Lou Berger <[email-masked]>
Date: Wed, 27 Sep 2017 18:08:07 -0400

Juergen,

Thanks for the "interesting" discussion.  I really do appreciate the authors adding the 2119 language even though they are unconvinced of it's value.  

Lou

---

From: Robert Wilton <[email-masked]>
Date: Thu, 28 Sep 2017 10:37:19 +0100

Hi,

After comment from the other authors, an updated proposed description 
for <running> is as follows:

OLD:

NEW:

4.1.3.  The Running Configuration Datastore (<running>)

    The running configuration datastore (<running>) is aconfiguration
    datastore that holds the complete current configuration
    on the device.  It may include configuration that requires further
    transformation before it can be applied, e.g., inactive
    configuration, or template-mechanism-oriented configuration that
    needs further expansion.  However, <running> MUST always be a 'valid
    configuration data tree' as defined in Section 8.1 of [RFC7950].

    <running> MUST be supported if the device can be configured via
    conventional configuration datastores.

Given that the definition of <running> and <intended> are being updated, 
I think that the definitions should similarly be updated.  Hence I propose:

OLD:
    o  running configuration datastore: A configuration datastore holding
       the current configuration of the device.  It may include inactive
       configuration or template-mechanism-oriented configuration that
       require further expansion.  This datastore is commonly referred to
       as "<running>".

NEW (based on the new description of running above):
    o  running configuration datastore: A configuration datastore holding
       the current configuration of the device. It may include
       configuration that requires furthertransformations before it can
       be applied. This datastore is commonly referred to
       as "<running>".

OLD:

   o  intended configuration: Configuration that is intended to be used
       by the device.  For example, intended configuration excludes any
       inactive configuration and it would include configuration produced
       through the expansion of templates.

NEW (based on the proposed updated description of intended):

   o  intended configuration: Configuration that is intended to be used
      by the device. It represents the configuration after all
      configuration transformations to <running> have been performed and
      is the configuration that the system attempts to apply.

It may also be helpful if we define "configuration transformation", or 
would that be better captured in the introduction text?

A possible definition could be along the lines of:

  configuration transformation: The addition, modification or removal of
  configuration between the <running> and <intended> datastores.
  Examples of configuration transformations include the removal of
  inactive configuration and the configuration produced through the
  expansion of templates.

If I don't hear anything back, I'll take that as a tacit approval of 
these proposed changes.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Thu, 28 Sep 2017 12:05:06 +0100

The authors have discussed this issue 
(https://github.com/netmod-wg/datastore-dt/issues/15), and their 
proposal is to close this with no change to the NMDA draft with the 
following justifications:

1) This assumption is that longer term all models would become NMDA 
compliant and over time it would likely require that all modules would 
need to have this extension added, creating a CLR.

2) Defining the extension would take time, and further delay the IETF 
standardization of YANG models, but it is important that IETF actually 
gets standard YANG models published as quickly as possible so that they 
can be implemented by the industry.

3) NMDA devices can implement "non NMDA style" modules (but with 
duplication of state), and non NMDA devices can implement "NMDA style" 
modules (but with reduced functionality).

4) YANG Catalog can identify what type of style a particular module is, 
by using some heuristically analysis of the structure of the model.

Thanks,
Rob

---

From: "t.petch" <[email-masked]>
Date: Thu, 28 Sep 2017 16:39:13 +0100

Robert

I would like you to tweak the definition of running configuration
datastore slightly.

You say

" The running configuration datastore (<running>) is a configuration
  datastore that holds the complete current configuration
  on the device"

which I see as black and white, the terminology is <running>.

But then you say

"This datastore is commonly referred to
  as "<running>".

which I see as introducing wiggle room with the use of 'commonly' so I
would like you to excise 'commonly' leaving

NEW
This datastore is referred to as "<running>".

Black and white.

Tom Petch

----- Original Message -----
From: "Robert Wilton" <[email-masked]>
Sent: Thursday, September 28, 2017 10:37 AM
> >>> standardized then those drafts would update the validation rules
in
> >>>>>>> 1) current <get-config> and <get> responses only include
enabled
> >>>>>>> nodes.
> >>>>>>> 3) NMDA clients use <get-data>, not <get-config> or <get>.
These
> >>>>>>> 4) new style <edit-config> (i.e. <datastore> parameter used)
can
> >> alter
> >>>>>> with-defaults) to allow a client to indicate to the server that
a
> >> get
> >>>>>> meta-data. The request is processed in a way that is equivalent
to
> >> an
> >>>>>> inactive configuration (e.g. via a replace or remove operation
on
> >> an
> >>>>>> parameter, then the inactive meta-data annotation can be used
to
> >> label
> >>>>>> inactive nodes. Inactive nodes are regarded as regular data
nodes
> >> for
> >>>>> do 5; if the client sends an "inactive" attribute it doesn't
have
> >> to
> >>>>>>> Note that the YANG MUST rule still applies, because validation
is
> >> only

---

From: Robert Wilton <[email-masked]>
Date: Thu, 28 Sep 2017 17:11:59 +0100

> This datastore is referred to as "<running>".
Yes. fine with me.  We should also make the equivalent update for the 
other datastore definitions as well.

Thanks,
Rob