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

[Robert Wilton]

Hi Tom,

Regarding the issue on the definition of inactive configuration, in the 
end we think that we don't need to define it for the following reasons:


1) Juergen's new objectives contains a brief description of inactive 
configuration (without defining it).
2) Inactive has been removed from the normative text, instead the 
normative text more generically refers to "configuration 
transformations" and just uses inactive as an example of such a 
transformation.

3) Configuration transformation is defined as:

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

OK?

Validating that this is sufficient to address your concern maybe easier 
when we post an updated revision with all WG LC markups applied.


Thanks,
Rob


On 17/09/2017 21:21, t.petch wrote:

- Original Message -
From: "Juergen Schoenwaelder" 
Sent: Friday, September 15, 2017 6:09 PM



Two comments:

- Obviously, inactive can be in  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.

Juergen

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

Tom Petch


/js

On Fri, Sep 15, 2017 at 05:20:15PM +0100, t.petch wrote:

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 

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

 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


- Original Message -
From: "Lou Berger" 
Sent: Friday, September 01, 2017 10:02 PM


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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Robert Wilton]

ave already included that material

Tom Petch


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.



ta

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.



Tom Petch

- Original Message -
From: "Lou Berger" <lber...@labn.net>
To: "t.petch" <ie...@btconnect.com>; "netmod WG" <netmod@ietf.org>
Cc: <netmod-cha...@ietf.org>;
<draft-ietf-netmod-revised-datasto...@ietf.org>
Sent: Wednesday, September 13, 2017 5:56 PM
Subject: Re: [netmod] WG Last Call:
draft-ietf-netmod-revised-datastores-04 duplicaiton



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,

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

Thanks,
Lou

On 9/13/2017 12:42 PM, t.petch wrote:

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" <lber...@labn.net>
To: "netmod WG" <netmod@ietf.org>
Cc: <netmod-cha...@ietf.org>;
<draft-ietf-netmod-revised-datasto...@ietf.org>
Sent: Friday, September 01, 2017 10:02 PM


All,

This starts a tw

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

[Robert Wilton]

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


On 15/09/2017 13:21, Martin Bjorklund wrote:

Ladislav Lhotka  wrote:

t.petch píše v Pá 15. 09. 2017 v 12:29 +0100:

Looking at a YANG module in future, how can I tell whether or not it is
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.

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



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

Lada


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


- Original Message -
From: "Lou Berger" 
Sent: Friday, September 01, 2017 10:02 PM



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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Lou Berger]

Sounds great. Thank you for the update.

Lou


On September 20, 2017 11:49:18 AM Robert Wilton  wrote:


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


On 18/09/2017 14:33, Lou Berger wrote:

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

On 9/1/2017 5:02 PM, Lou Berger wrote:

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


.







___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Robert Wilton]

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


On 18/09/2017 14:33, Lou Berger wrote:

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

On 9/1/2017 5:02 PM, Lou Berger wrote:

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


.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Robert Wilton]

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


On 11/09/2017 16:22, Robert Wilton 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:*

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 ()

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

   For simple implementations,  and  are identical.

    does not persist across reboots; its relationship with
    makes that unnecessary.

   ...

*NEW:*

4.4.  The Intended Configuration Datastore ()

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

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

   For simple implementations,  and  are identical.

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

    does not persist across reboots; its relationship with
    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 () . . . . .   9
 4.2.  The Candidate Configuration Datastore () . . .  10
 4.3.  The Running Configuration Datastore () . . . . .  10
 4.4.  The Intended Configuration Datastore () . . . .  10
 4.5.  Conventional Configuration Datastores . . . . . . . . . .  11
 4.6.  Dynamic Configuration Datastores  . . . . . . . . . . . .  11
 4.7.  The Operational State Datastore () . . . . .  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 () . . .  10
   4.1.2.  The Candidate Configuration Datastore () .  10
   4.1.3.  The Running Configuration Datastore () . . .  10
   4.1.4.  The Intended Configuration Datastore () . .  11
 4.2.  Dynamic Configuration Datastores  . . . . . . . . . . . .  12
 4.3.  The Operational State Datastore () . . . . .  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
---
>    

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

[t.petch]

- Original Message -
From: "Martin Bjorklund" 
Sent: Monday, September 18, 2017 8:58 AM


> "t.petch"  wrote:
> > - Original Message -
> > From: "Martin Bjorklund" 
> > Sent: Sunday, September 17, 2017 2:41 PM
> >
> > > Andy Bierman  wrote:
> > > > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
> > > > j.schoenwael...@jacobs-university.de> wrote:
> > > >
> > > > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> > > > > > 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.
> > > > > >
> > > > >
> > > > > 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.
> > > > >
> > > > >
> > > > So what?
> > > > Existing YANG specifications use RFC 2119 terms.
> > > > 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
> >
> > '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  (well, running configuration in RFC7950).  Is it a
> > 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
>  under the same path as before, and it is available.
>
> > 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.
>
> Are you saying that this is an argument for having "Updates: 7950"?

Yes

Tom Petch

>
> /martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Mon, Sep 18, 2017 at 11:14:55AM +0100, Robert Wilton wrote:
> > 
> > 
> > On 17/09/2017 21:21, t.petch wrote:
> > > - Original Message -
> > > From: "Juergen Schoenwaelder" 
> > > Sent: Friday, September 15, 2017 6:09 PM
> > > 
> > > 
> > > > Two comments:
> > > > 
> > > > - Obviously, inactive can be in  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.
> > > 
> > > Juergen
> > > 
> > > 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  could differ from , 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.

+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  from
.

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

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


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Lou Berger]

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

On 9/1/2017 5:02 PM, Lou Berger wrote:
> 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
>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Mon, Sep 18, 2017 at 11:14:55AM +0100, Robert Wilton wrote:
> 
> 
> On 17/09/2017 21:21, t.petch wrote:
> > - Original Message -
> > From: "Juergen Schoenwaelder" 
> > Sent: Friday, September 15, 2017 6:09 PM
> > 
> > 
> > > Two comments:
> > > 
> > > - Obviously, inactive can be in  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.
> > 
> > Juergen
> > 
> > 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  could differ from , 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.

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

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Robert Wilton]

On 17/09/2017 21:21, t.petch wrote:

- Original Message -
From: "Juergen Schoenwaelder" 
Sent: Friday, September 15, 2017 6:09 PM



Two comments:

- Obviously, inactive can be in  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.

Juergen

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  could differ from , 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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

"t.petch"  wrote:
> - Original Message -
> From: "Martin Bjorklund" 
> Sent: Sunday, September 17, 2017 2:41 PM
> 
> > Andy Bierman  wrote:
> > > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
> > > j.schoenwael...@jacobs-university.de> wrote:
> > >
> > > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> > > > > 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.
> > > > >
> > > >
> > > > 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.
> > > >
> > > >
> > > So what?
> > > Existing YANG specifications use RFC 2119 terms.
> > > 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
> 
> '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  (well, running configuration in RFC7950).  Is it a
> 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
 under the same path as before, and it is available.

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

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


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[t.petch]

- Original Message -
From: "Martin Bjorklund" 
Sent: Sunday, September 17, 2017 2:41 PM

> Andy Bierman  wrote:
> > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> > > > 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.
> > > >
> > >
> > > 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.
> > >
> > >
> > So what?
> > Existing YANG specifications use RFC 2119 terms.
> > 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

'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  (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


> /martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[t.petch]

- Original Message -
From: "Juergen Schoenwaelder" 
Sent: Friday, September 15, 2017 6:09 PM


> Two comments:
>
> - Obviously, inactive can be in  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.

Juergen

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

Tom Petch

> /js
>
> On Fri, Sep 15, 2017 at 05:20:15PM +0100, t.petch wrote:
> > 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 
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
> >  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
> >
> >
> > - Original Message -
> > From: "Lou Berger" 
> > Sent: Friday, September 01, 2017 10:02 PM
> >
> > > 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
> > >
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Sat, Sep 16, 2017 at 3:14 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Sat, Sep 16, 2017 at 02:56:45AM -0700, Andy Bierman wrote:
>
> > Either way, the new YANG rules seem half-baked and not ready
> > for standardization.
>
> OK. Then please tell us where you see problems. The usage of must vs
> MUST does not seem to be the issue.
>
>

sec 4.4:

Validation is performed on the contents of .


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

What happens if a client does validation on ? 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 () 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
so that it would have different contents than ,
   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  and .  The client
can now
assume that  is always valid, but this draft breaks that.

IMO, only the  datastore work is standards-ready.


Andy



/js
>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Sat, Sep 16, 2017 at 02:56:45AM -0700, Andy Bierman wrote:

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

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

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> > 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.
> >
>
> 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.
>
>
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.



> /js
>
>
Andy


> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> 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.
>

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Fri, Sep 15, 2017 at 5:39 PM, Phil Shafer  wrote:

> Andy Bierman writes:
> >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) .
>
> The alternative would be removing inactive config from normal
>  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.
>
>
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.





> Thanks,
>  Phil
>


Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Phil Shafer]

Andy Bierman writes:
>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) .

The alternative would be removing inactive config from normal
 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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Fri, Sep 15, 2017 at 12:40 PM, Phil Shafer  wrote:

> "t.petch" writes:
> >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'.
>
> Agree.  Consistent terms are good things.
>
> >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  which
> >is not in use by the device and which plays no part in validation.  It
> >cannot appear in any other datastore.
>
> Inactive configuration should be allowed in  and ,
> 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
> >standardised do not support inactive configuration but a number of
> >proprietary protocols do.
>
> In JUNOS, we use the standard protocols but encoded these as
> non-standard attributes.
>
> >Inactive configuration is only exposed to
> >clients that indicate support for inactive configuration; clients not
> >indicating support for  inactive configuration receive the contents of
> > with the inactive configuration removed.
>
> This is also not true for our implementation.  If you 
> on any datastore that contains inactive data, you'll receive
> that data.
>
>

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,
>  Phil
>

Andy


>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

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


On Fri, Sep 15, 2017 at 5:34 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Fri, Sep 15, 2017 at 12:19:42PM +0100, t.petch wrote:
> > This I-D updates RFC7950, since it changes the XPath context that YANG
> > 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
>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Phil Shafer]

"t.petch" writes:
>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'.

Agree.  Consistent terms are good things.

>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  which
>is not in use by the device and which plays no part in validation.  It
>cannot appear in any other datastore.

Inactive configuration should be allowed in  and ,
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
>standardised do not support inactive configuration but a number of
>proprietary protocols do.

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

>Inactive configuration is only exposed to
>clients that indicate support for inactive configuration; clients not
>indicating support for  inactive configuration receive the contents of
> with the inactive configuration removed.

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

Thanks,
 Phil

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

Two comments:

- Obviously, inactive can be in  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

On Fri, Sep 15, 2017 at 05:20:15PM +0100, t.petch wrote:
> 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  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
>  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
> 
> 
> - Original Message -
> From: "Lou Berger" 
> Sent: Friday, September 01, 2017 10:02 PM
> 
> > 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
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[t.petch]

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


- Original Message -
From: "Lou Berger" 
Sent: Friday, September 01, 2017 10:02 PM

> 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
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Fri, Sep 15, 2017 at 12:19:42PM +0100, t.petch wrote:
> This I-D updates RFC7950, since it changes the XPath context that YANG
> 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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> t.petch píše v Pá 15. 09. 2017 v 12:29 +0100:
> > Looking at a YANG module in future, how can I tell whether or not it is
> > 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.

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


> 
> Coupling a data modelling language with rather specific aspects of an NM
> application is a bad design.
> 
> Lada 
> 
> > 
> > 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
> > 
> > 
> > - Original Message -
> > From: "Lou Berger" 
> > Sent: Friday, September 01, 2017 10:02 PM
> > 
> > 
> > > 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
> > > 
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Ladislav Lhotka]

t.petch píše v Pá 15. 09. 2017 v 12:29 +0100:
> Looking at a YANG module in future, how can I tell whether or not it is
> 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 

> 
> 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
> 
> 
> - Original Message -
> From: "Lou Berger" 
> Sent: Friday, September 01, 2017 10:02 PM
> 
> 
> > 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
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[t.petch]

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


- Original Message -
From: "Lou Berger" 
Sent: Friday, September 01, 2017 10:02 PM


> 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
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[t.petch]

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" <lber...@labn.net>
To: "netmod WG" <netmod@ietf.org>
Cc: <netmod-cha...@ietf.org>;
<draft-ietf-netmod-revised-datasto...@ietf.org>
Sent: Friday, September 01, 2017 10:02 PM
Subject: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04


> 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
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[t.petch]

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

> >
> > 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.
> >
> >
ta
> > 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.
> >
> >

Tom Petch

----- Original Message -
From: "Lou Berger" <lber...@labn.net>
To: "t.petch" <ie...@btconnect.com>; "netmod WG" <netmod@ietf.org>
Cc: <netmod-cha...@ietf.org>;
<draft-ietf-netmod-revised-datasto...@ietf.org>
Sent: Wednesday, September 13, 2017 5:56

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

[Ladislav Lhotka]

Phil Shafer  writes:

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

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

The same section also says that  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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Lou Berger]

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

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

Thanks,
Lou

On 9/13/2017 12:42 PM, t.petch wrote:
> 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" 
> To: "netmod WG" 
> Cc: ;
> 
> Sent: Friday, September 01, 2017 10:02 PM
>
>> 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
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[t.petch]

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" 
To: "netmod WG" 
Cc: ;

Sent: Friday, September 01, 2017 10:02 PM

> 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
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Tue, Sep 12, 2017 at 12:09:57PM +0100, Robert Wilton wrote:
> > 
> > There are several possible pitfalls here since (i)  can
> > change anytime, (ii) it might not be easy/possible to obtain a
> > consistent snapshot of , and (iii) dynamic datastores can
> > provide values that "overwrite"  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  has been applied, it is fine. Otherwise, it
> > may be a source of future problems.
> One tweak could be to change "applied" to "in use":
> 
>The contents of  are related to the 'config true'
>subset of , such that a client can determine to what
>extent the intended configuration is currently in use by checking
>whether the contents of  also appear in .
> 
> Is this better?
>

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Robert Wilton]

On 11/09/2017 18:27, Juergen Schoenwaelder wrote:

On Mon, Sep 11, 2017 at 05:12:42PM +, Kent Watsen wrote:

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


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




There are several possible pitfalls here since (i)  can
change anytime, (ii) it might not be easy/possible to obtain a
consistent snapshot of , and (iii) dynamic datastores can
provide values that "overwrite"  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  has been applied, it is fine. Otherwise, it
may be a source of future problems.

One tweak could be to change "applied" to "in use":

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

Is this better?

Thanks,
Rob



/js



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Robert Wilton]

On 11/09/2017 18:31, Martin Bjorklund wrote:

Kent Watsen  wrote:

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


Or just remove "all".
I also have a slight preference for just removing "all", but am also OK 
if it moves.


Thanks,
Rob





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

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"
> 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:

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 ()

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

For simple implementations,  and  are identical.

 does not persist across reboots; its relationship with
 makes that unnecessary.

...

NEW:

4.4.  The Intended Configuration Datastore ()

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

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

For simple implementations,  and  are identical.

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

 does not persist across reboots; its relationship with
 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 () . . . . .   9
  4.2.  The Candidate Configuration Datastore () . . .  10
  4.3.  The Running Configuration Datastore () . . . . .  10
  4.4.  The Intended Configuration Datastore () . . . .  10
  4.5.  Conventional Configuration Datastores . . . . . . . . . .  11
  4.6.  Dynamic Configuration Datastores  . . . . . . . . . . . .  11
  4.7.  The Operational State Datastore () . . . . .  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.  

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

[Martin Bjorklund]

Kent Watsen  wrote:
> 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


Or just remove "all".

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

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"
> > 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:
> 
> 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 ()
> 
>The intended configuration datastore () is a read-only
>configuration datastore.  It is tightly coupled to .  When
>data is written to , the data that is to be validated is
>also conceptually written to .  Validation is performed on
>the contents of .
> 
>For simple implementations,  and  are identical.
> 
> does not persist across reboots; its relationship with
> makes that unnecessary.
> 
>...
> 
> NEW:
> 
> 4.4.  The Intended Configuration Datastore ()
> 
>The intended configuration datastore () is a read-only
>configuration datastore.  It represents the configuration after all
>configuration transformations to  are performed (e.g.
>template expansion, inactive configuration removal), and is the
>configuration that the system attempts to apply.
> 
>It is tightly coupled to .  When data is written to
>, the data that is to be validated is also conceptually
>written to .  Validation is performed on the contents of
>.
> 
>For simple implementations,  and  are identical.
> 
>The contents of  is also related to the 'config true'
>subset of , and hence a client can determine to what
>extent the intended configuration is currently applied by checking
>whether the contents of  also appears in .
> 
> does not persist across reboots; its relationship with
> 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 () . . . . .   9
>  4.2.  The Candidate Configuration Datastore () . . .  10
>  4.3.  The Running Configuration Datastore () . . . . .  10
>  4.4.  The Intended Configuration Datastore () . . . .  10
>  4.5.  Conventional Configuration Datastores . . . . . . . . . .  11
>  4.6.  Dynamic Configuration Datastores  . . . . . . . . . . . .  11
>  4.7.  The Operational State Datastore () . . . . .  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 

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

[Juergen Schoenwaelder]

On Mon, Sep 11, 2017 at 05:12:42PM +, Kent Watsen wrote:
> 
>The contents of  are related to the 'config true'
>subset of , such that a client can determine to what
>extent the intended configuration is currently applied by checking
>whether the contents of  also appear in .
>

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

There are several possible pitfalls here since (i)  can
change anytime, (ii) it might not be easy/possible to obtain a
consistent snapshot of , and (iii) dynamic datastores can
provide values that "overwrite"  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  has been applied, it is fine. Otherwise, it
may be a source of future problems.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

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

3) I'm okay with this.

4) This is better.


Thanks,
Kent



On 9/11/17, 11:22 AM, "Robert Wilton" 
> 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:

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 ()

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

   For simple implementations,  and  are identical.

does not persist across reboots; its relationship with
makes that unnecessary.

   ...

NEW:

4.4.  The Intended Configuration Datastore ()

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

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

   For simple implementations,  and  are identical.

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

does not persist across reboots; its relationship with
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 () . . . . .   9
 4.2.  The Candidate Configuration Datastore () . . .  10
 4.3.  The Running Configuration Datastore () . . . . .  10
 4.4.  The Intended Configuration Datastore () . . . .  10
 4.5.  Conventional Configuration Datastores . . . . . . . . . .  11
 4.6.  Dynamic Configuration Datastores  . . . . . . . . . . . .  11
 4.7.  The Operational State Datastore () . . . . .  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 () . . .  10
   4.1.2.  The Candidate Configuration Datastore () .  10
   4.1.3.  The Running Configuration Datastore () . . .  10
   4.1.4.  The Intended Configuration Datastore () . .  11
 4.2.  Dynamic Configuration 

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

[Robert Wilton]

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 ()

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

   For simple implementations,  and  are identical.

    does not persist across reboots; its relationship with
    makes that unnecessary.

   ...

*NEW:*

4.4.  The Intended Configuration Datastore ()

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

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

   For simple implementations,  and  are identical.

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

    does not persist across reboots; its relationship with
    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 () . . . . .   9
 4.2.  The Candidate Configuration Datastore () . . .  10
 4.3.  The Running Configuration Datastore () . . . . .  10
 4.4.  The Intended Configuration Datastore () . . . .  10
 4.5.  Conventional Configuration Datastores . . . . . . . . . .  11
 4.6.  Dynamic Configuration Datastores  . . . . . . . . . . . .  11
 4.7.  The Operational State Datastore () . . . . .  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 () . . .  10
   4.1.2.  The Candidate Configuration Datastore () .  10
   4.1.3.  The Running Configuration Datastore () . . .  10
   4.1.4.  The Intended Configuration Datastore () . .  11
 4.2.  Dynamic Configuration Datastores  . . . . . . . . . . . .  12
 4.3.  The Operational State Datastore () . . . . .  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:

All,

This starts a two week working group last call on

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

[Juergen Schoenwaelder]

I believe the document is ready for publication.

/js

On Fri, Sep 01, 2017 at 05:02:24PM -0400, Lou Berger wrote:
> 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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

Hi,

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


/martin

Lou Berger  wrote:
> 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
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Lou Berger]

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod