Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

From: [email-masked]
Date: Sun, 18 Jun 2017 21:54:09 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

        Title           : Guidelines for Authors and Reviewers of YANG Data Model Documents
        Author          : Andy Bierman
	Filename        : draft-ietf-netmod-rfc6087bis-13.txt
	Pages           : 64
	Date            : 2017-06-18

Abstract:
   This memo provides guidelines for authors and reviewers of Standards
   Track specifications containing YANG data model modules.  Applicable
   portions may be used as a basis for reviews of other YANG data model
   documents.  Recommendations and procedures are defined, which are
   intended to increase interoperability and usability of Network
   Configuration Protocol (NETCONF) and RESTCONF protocol
   implementations that utilize YANG data model modules.  This document
   obsoletes RFC 6087.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-13
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-13

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Andy Bierman <[email-masked]>
Date: Mon, 19 Jun 2017 16:53:07 -0700

Hi,

This draft addresses all remaining open issues, include the rewrite of the
opstate section.
I think it is ready for another quick WGLC and then back to the IESG.

Andy

On Sun, Jun 18, 2017 at 9:54 PM, <[email-masked]> wrote:

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Phil Shafer <[email-masked]>
Date: Tue, 20 Jun 2017 02:05:42 -0400

>>In YANG, any data that has a "config" statement value of "false"    
>>could be considered operational data.  The relationship between    
>>configuration (i.e., "config" statement has a value of "true") and    
>>operational data can be complex.    

The NMDA draft includes the following in its terminology section:

  - configuration: Data that determines how a device behaves.  This
    data is modeled in YANG using "config true" nodes.  Configuration
    can originate from different sources.

  - operational state: The combination of applied configuration and
    system state.

It would be nice to use matching terms, either by importing the
NMDA terms directly, or by mimicing them in this draft.  If your
"operational data" means "config false" and NMDA's "operational state"
means both config true and config false, readers will be confused.

Also you say "operational state and other data such as statistics"
which inconsisent.  Under either set of terms, statistics are
part of operational state.

>>The original set of datastores defined in NETCONF (i.e., candidate,    
>>unning, and startup) are not sufficient to fully manage a device    
>>ith multiple sources of configuration data.  In additional, a    
>>separate datastore is needed to store operational state and other    
>>data such as statistics.  Refer to    
>>[I-D.ietf-netmod-revised-datastores] for details on this new "revised    
>>datastore" architecture.  Guidelines for usage of the new datastores    
>>(including the operational datastore) is defined in    
>>[I-D.dsdt-nmda-guidelines].

"not sufficient to fully manage" is too broad a claim.  Can I suggest
a more positive spin:

  The Network Management Datastore Architecture (NMDA) defines a
  new set of datastores that improve visibility into the device,
  both in terms of the "intended" configurations values and the
  true operationally "in use" values.  Refer to
  [I-D.ietf-netmod-revised-datastores] for details.  Guidelines for
  moving existing data modules to the NMDA are defined in
  [I-D.dsdt-nmda-guidelines].

Thanks,
 Phil

---

From: Kent Watsen <[email-masked]>
Date: Tue, 20 Jun 2017 11:32:32 +0000

Regarding the suggestion to add this text:

> Guidelines for

I'm hoping that we do not progress the guidelines doc.  Ideally 6087bis can just state what people should do, without providing a formula for transitioning. 

Kent (any hat)

---

From: "t.petch" <[email-masked]>
Date: Tue, 20 Jun 2017 12:39:55 +0100

--- Original Message -----
From: "Phil Shafer" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 20, 2017 7:05 AM

Phil

Well, it would if the definitions in NMDA brought clarity but I think
the opposite.

'Data that determines how a device behaves' seems clear until you read
on and find that this excludes data learnt from the system or data
learnt from routing protocols.

I find the idea that the behaviour of a device is not determined by
routing protocols or a hot-plugged card an odd one.

This definition is rather different to that in NETCONF and seems
unlikely to bring clarity so I think it would be a mistake to
incorporate it in rfc6087bis..

Tom Petch

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 20 Jun 2017 14:11:35 +0200

> incorporate it in rfc6087bis..

RFC 6087 (and RFC 6087bis) is about YANG models, not about NETCONF and
not about routing protocols or any other control plane mechanisms.

If the terms in the NMDA are not good, start a thread about it; try to
improve them if you can. I do not see that using different terms in
the YANG related specifications is less confusing.

/js

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

---

From: Robert Wilton <[email-masked]>
Date: Tue, 20 Jun 2017 13:35:04 +0100

Hi Tom,

> learnt from routing protocols.
Please can you clarify.  The text that you are quoting above is from the 
NMDA definition of "configuration".

Data learned from the system or routing protocols (for YANG config true 
nodes) would be classified as "system configuration" or "learned 
configuration", which are sub categories of "configuration", and hence 
are not excluded from the more general definition of "configuration".

Thanks,
Rob

> .

---

From: Andy Bierman <[email-masked]>
Date: Tue, 20 Jun 2017 07:27:25 -0700

On Tue, Jun 20, 2017 at 4:32 AM, Kent Watsen <[email-masked]> wrote:

> I'm hoping that we do not progress the guidelines doc.  Ideally 6087bis
> can just state what people should do, without providing a formula for
> transitioning.
>
>
I thought 6087bis is supposed to point people to the NMDA guidelines.
That is why 6087bis has been held back for so long, even though it was
supposed to be published with YANG 1.1.

We waste a lot of time refactoring drafts and re-reviewing them.
IMO the RD guidelines should be in the RD draft.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 20 Jun 2017 15:20:38 +0000

<KENT> I thought that this was settled before (maybe not): https://mailarchive.ietf.org/arch/msg/netmod/pDLDm8gdIBwwyGyfa_acVKHtu_Q

---

From: Andy Bierman <[email-masked]>
Date: Tue, 20 Jun 2017 08:27:28 -0700

Hi,

I rewrote 6.23 and it points at the NMDA guidelines.
The drafts will get published together so the references will
be to RFCs, not I-Ds.  That is usually what is meant by the comment below I
think

> I don't expect the guidelines doc is going to progress independently.
Agreed.

Andy

On Tue, Jun 20, 2017 at 8:20 AM, Kent Watsen <[email-masked]> wrote:

> <KENT> I thought that this was settled before (maybe not):
> https://mailarchive.ietf.org/arch/msg/netmod/pDLDm8gdIBwwyGyfa_acVKHtu_Q
>
>
>
>
>
>
>
>
>

---

From: "t.petch" <[email-masked]>
Date: Tue, 20 Jun 2017 17:36:12 +0100

----- Original Message -----
From: "Robert Wilton" <[email-masked]>
Sent: Tuesday, June 20, 2017 1:35 PM

> >>> This draft addresses all remaining open issues, include the
rewrite
> > of the

Robert

The definition of 'configuration' in netmod-revised-datastores-02 is
very different from what has gone before in NETCONF and NETMOD.

You start with
'Data that determines how a device behaves.  '
which is how I would have defined configuration before the days of
NETCONF and which I imagine is how many who have not been exposed to
NETCONF would still do.  NETCONF narrowed the definition a lot; 'Data
that determines how a device behaves' opens it up again.

You add the qualification 'using "config true" nodes' which doesn't
really mean anything in this context, unless you already know some YANG
models, and know what is modelled in this way and what is not and so can
work it out, reverse engineering.

Coming to netmod-revised-datastores-02  with an innocent eye, knowing
that the ground has moved, that some of my assumptions of the past 10
years are no longer valid, then these definitions convey to me that
configuration acquired from the system or from routing protocols, to
take two common examples, will now always be modelled 'config true',
that is the first sentence is the definition and the second - 'config
true' - is the consequence thereof.

Of course, if you come to the I-D knowing otherwise, then you may find a
different interpretation but I do not think that that is the obvious
interpretation.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 20 Jun 2017 19:51:13 +0200

> different interpretation but I do not think that that is the obvious

Is your proposal to take out "This data is modeled in YANG using
"config true" nodes."?

Note that the NMDA document further defines

   o  conventional configuration: Configuration that is stored in any of
      the conventional configuration datastores.

   o  dynamic configuration: Configuration obtained via a dynamic
      datastore.

   o  learned configuration: Configuration that has been learned via
      protocol interactions with other systems that is not conventional
      or dynamic configuration.

   o  system configuration: Configuration that is supplied by the device
      itself.

   o  default configuration: Configuration that is not explicitly
      provided but for which a value defined in the data model is used.

There are corresponding origin attribute definitions. (With the minore
caveat that the origin value for conventional configuration is
intended since this is the datastore conventional configuration
finally originates from.)

/js

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 20 Jun 2017 14:19:32 -0400

I was going to just watch this, but I can't.

To call protocol negotiated values "configuration" is to create a usage 
which will confuse MANY people.  Even worse, configuring protocol 
learned values is liable to break things.  To use one example, many 
protocols negotiate timers.  The value that a given systems starts with 
is the configured value.  The value that it learns from the protocol 
exchange is the operational value.  In fact, you better not try to 
configure that value or you are liable to break the protocol.

Yours,
Joel

On 6/20/17 1:51 PM, Juergen Schoenwaelder wrote:
>> 'Data that determines how a device behaves.'

---

From: Andy Bierman <[email-masked]>
Date: Tue, 20 Jun 2017 12:06:39 -0700

On Tue, Jun 20, 2017 at 11:19 AM, Joel M. Halpern <[email-masked]>
wrote:

> which will confuse MANY people.  Even worse, configuring protocol learned
> values is liable to break things.  To use one example, many protocols
> negotiate timers.  The value that a given systems starts with is the
> configured value.  The value that it learns from the protocol exchange is
> the operational value.  In fact, you better not try to configure that value
> or you are liable to break the protocol.
>
>

Maybe confusing, maybe clarifying, maybe some of both.

If you look at running-config and ephemeral datastores as sibling
configuration datastores,
and the operational datastore as the outcome of the system resolving all
possible configuration
sources, then the terms make more sense.

At the NYC NETMOD interim, we convinced ourselves of at least 2 things,
maybe neither is still true

   1) it could be an operator deployment decision to use any running-config
data model
        in the ephemeral datastore

   2) the values in the ephemeral datastore are always higher priority than
corresponding
       values from running (intended)

In this system, a configured value would just get ignored and the protocol
negotiated timer would get used instead.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 20 Jun 2017 21:40:19 +0200

On Tue, Jun 20, 2017 at 02:19:32PM -0400, Joel M. Halpern wrote:
> which will confuse MANY people.

There are people who have a broad concept of configuration and there
are people who have a narrow concept of configuration. There is not
way to resolve this. All we can do is come up with a terminology that
is consistent and can be used consistently.

> Even worse, configuring protocol learned

Nobody proposed this, please take a look at the figure in the document
to understand the information flow and where the distinction is made.

/js

---

From: Alex Campbell <[email-masked]>
Date: Wed, 21 Jun 2017 02:17:43 +0000

There are many different layers and all, or none of them could be called configuration depending on your perspective.
Consider the current set of routes on a router. I think we can all agree that from the point of view of the Linux kernel, or a hardware routing chip, this is configuration data.
But from the point of view of an OSPF process it is operational data. OSPF will reconfigure Linux every time the routes change.
Even *static* routes may be considered operational data at an even higher level (such as a network monitoring system).

________________________________________
From: netmod <[email-masked]> on behalf of Joel M. Halpern <[email-masked]>
Sent: Wednesday, 21 June 2017 6:19 a.m.
To: t.petch; Robert Wilton; [email-masked]
Subject: Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

Yours,
Joel

---

From: Robert Wilton <[email-masked]>
Date: Wed, 21 Jun 2017 10:03:21 +0100

Tom,

Thanks for the comments, please see inline ...

> true' - is the consequence thereof.
OK, I can see how one could take that interpretation, but I don't think 
that is the author's intention.

We found that trying to define what "configuration is, or isn't", is 
hard, but still regard having a definition is important.

In the end, I see that the real core of the definition is actually the 
config true sentence.  I.e. the intention of the draft is to define 
configuration as the nodes in the YANG schema that are labelled as 
config true, and hence it is the marking of the node as config true that 
actually makes it configuration (at least in the context of this draft 
and NETCONF/YANG).

So, do you think that it would help if the definition text was reordered 
to make the binding to YANG config true first and foremost?

E.g.

Old:
    o  configuration: Data that determines how a device behaves. This
       data is modeled in YANG using "config true" nodes. Configuration
       can originate from different sources.

New:
   configuration: All data that is modelled in YANG using "config
   true" nodes.  Configuration is used to instruct how a device behaves.
   Configuration can originate from different sources.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 21 Jun 2017 14:32:47 +0200

On Wed, Jun 21, 2017 at 10:03:21AM +0100, Robert Wilton wrote:
> 
> We found that trying to define what "configuration is, or isn't", is hard,
> but still regard having a definition is important.
> 
> configuration as the nodes in the YANG schema that are labelled as config
> true, and hence it is the marking of the node as config true that actually
> makes it configuration (at least in the context of this draft and
> NETCONF/YANG).
> 
> So, do you think that it would help if the definition text was reordered to
> make the binding to YANG config true first and foremost?
> 
> E.g.
> 
> Old:

I think this was true at some point of the internal discussions but I
think it is not true any longer. I believe the fix is this (moving the
config true statement to the definition of conventional
configuration):

NEW:

   o  configuration: Data that determines how a device behaves.
      Configuration can originate from different sources.

   o  conventional configuration: Configuration that is stored in any of
      the conventional configuration datastores. This data is modeled in
      YANG using "config true" nodes.

---8<--- snip ---8<---

In the current NMDA draft, configuration is a combination of
conventional configuration, dynamic configuration, learned
configuration, system configuration, and default configuration.
Perhaps we need to create more figures:

   configuration
        |
        + conventional configuration (origin intended)
        + dynamic configuration      (origin dynamic)
        + learned configuration      (origin learned)
        + system configuration       (origin system)
        + default configuration      (origin default)

I am not sure whether dynamic configuration (e.g., coming from an I2RS
subsystem) or system configuration is necessarily restricted to config
true nodes. By moving the config true statement to the definition of
the term conventional configuration, we state something where we are
sure the statement is correct.

/js

---

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

On Wed, Jun 21, 2017 at 5:32 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> hard,
> to

I agree with Joel that all protocol negotiated values should not be
considered configuration.

I2RS is somewhere in between configuration and protocol-negotiated values.
We don't have a good term for it yet.

There will be some protocol negotiation that is modeled in YANG and
represented in
a configuration datastore (e.g. ephemeral datastore). This data can be
modified with configured values.
The operational datastore reflects the actual values used. Maybe this is
called
ephemeral configuration?

There will be some protocol negotiation that is not modeled in YANG and not
represented in
a configuration datastore, but the operational datastore can still contain
these values.
This should not be called configuration.

Andy

---

From: "t.petch" <[email-masked]>
Date: Thu, 22 Jun 2017 11:21:14 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
Sent: Tuesday, June 20, 2017 8:40 PM

> is consistent and can be used consistently.

Juergen, Robert,

This is what triggered my post (which I have been mulling ever since
ietf-netmod-revised-datastores appeared).

There has been a narrow (IMHO) definition in use for over a decade to
whit

'Configuration data is the set of writable data that is required to
   transform a system from its initial default state into its current
   state.  '

which I have accepted as the basis of this work (having previously used
a much wider definition) .

'Data that determines how a device behaves' seems to me a much wider
definition encompassing much of 'state' as has been defined for the past
decade.

I don't expect to have to read the rest of the I-D (about the kinds of
configuration) to find out that the definition does not mean what it
appears to say; I may have to read on to fully understand it but the
words as written seem to brook no misunderstanding!

Having ' This data is modeled in YANG using "config true" nodes ' sort
of suggests that the original definition holds sway and so contradicts
the previous sentence.  And for this sentence to make sense, a reader
would really have to understand the debates over configuration, state
and how to model them that have been going on for so long which means
that regardless of how true it is, it does not really belong in a
definition.

There is no reference back to the previous definition, as to whether or
not the latest definition is meant to be the same or not.  I find this
confusing.

I think that the previous definition has to appear in this I-D, since it
has influenced so much work, and this I-D then needs to go on to say

'We are revising it ..
or
'We are not revising it ...

I have read the later posts but this one seemed to catch the crux of my
discontent.

Tom Petch

---

From: "Mehmet Ersue" <[email-masked]>
Date: Thu, 22 Jun 2017 13:01:19 +0200

> Having ' This data is modeled in YANG using "config true" nodes ' sort of
> suggests that the original definition holds sway and so contradicts the
> previous sentence.  And for this sentence to make sense, a reader would
> really have to understand the debates over configuration, state and how to
> model them that have been going on for so long which means that regardless
> of how true it is, it does not really belong in a definition.
> 
not
> the latest definition is meant to be the same or not.  I find this
confusing.
> I think that the previous definition has to appear in this I-D, since it
has
> influenced so much work, and this I-D then needs to go on to say

It is indeed confusing to the reader if a document referring to a standard
track RFC defines and uses a term differently.
I agree that revising a term might become necessary though the revision
should be introduced properly.

> > > Even worse, configuring protocol learned values is liable to break
> > > things.  To use one example, many
> protocols

---

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

On 21/06/2017 18:20, Andy Bierman wrote:
>
>
> On Wed, Jun 21, 2017 at 5:32 AM, Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
There are values e.g. protocol timers that may be set either manually 
through configuration, or through a value negotiated by a peer.  In some 
protocols, it may be defined that a manually configured value would 
override a negotiated value.  In other cases, a negotiated value wins.

However, in both cases, there is only ever one actual operational value 
being used.  The idea of the classification of different types of 
configuration, and associated origin values, is so that a client can 
determine whether the actual operational value in use was taken from the 
configuration, or through protocol negotiation, or somewhere else.

Other examples are like IP addresses that may be set through 
configuration, or learned from DHCP, or other sources.

> The operational datastore reflects the actual values used. Maybe this 
> is called
> ephemeral configuration?
I think that draft refers to this as dynamic configuration, but the 
expectation is that this would only apply to config true nodes.  I don't 
think that we have a name if I2RS writes to config false nodes (which is 
in the I2RS requirements draft).

>
> There will be some protocol negotiation that is not modeled in YANG 
> and not represented in
> a configuration datastore, but the operational datastore can still 
> contain these values.
Agreed.  If these values are exposed they should be exposed as config 
false nodes in the operational datastore.

Thanks,
Rob

>     Fax:   +49 421 200 3103         <http://www.jacobs-university.de/
>     <http://www.jacobs-university.de/>>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 23 Jun 2017 16:28:20 -0400

I happened to be looking at Appendix C.  YANG Module Template (because a
YANG Dr pointed out that I wasn't following it in one of my drafts) and
noticed an inconsistency.  The template says:
   Copyright (c) <insert year> IETF Trust and the persons
   identified as authors of the code.  All rights reserved.

Which matches current trust language, so this is all good.

But: the template then has
   Editor:   your-name
             <mailto:[email-masked]>";

*and* no place to list all who authored the "code", i.e., the module. 
Given the copyright, I think the template should be revised to:

OLD
   Editor:   your-name
             <mailto:[email-masked]>";
NEW
   Authors:  //List all who contributed text to the module
             your-name
             <mailto:[email-masked]>";

Lou

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Jun 2017 13:34:19 -0700

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

How about just "Authors".
It is an administrative nightmare to keep track of everyone who
contributed the tiniest edit to a module.  The module header would be 10
pages long
listing the name and email of anyone who contributed any text.
The draft itself has a contributors section.
The template has always been to list the document authors here.

Andy

---

From: Lou Berger <[email-masked]>
Date: Fri, 23 Jun 2017 16:53:12 -0400

On 6/23/2017 4:34 PM, Andy Bierman wrote:
>
>
> On Fri, Jun 23, 2017 at 1:28 PM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>                  <mailto:[email-masked]
>     <mailto:[email-masked]>>";
>
>                  <mailto:[email-masked]
>     <mailto:[email-masked]>>";
>     NEW
>                  <mailto:[email-masked]
>     <mailto:[email-masked]>>";
>
>
>

you mean: //List all who authored the module
That works for me.

> contributed the tiniest edit to a module.  The module header would be
> 10 pages long
The copyright says " identified as authors of the code. " so it seems to
me that all copyright holders need to be identified in the module.  I
have no idea that the test/bar is to become a copyright holder, but can
ask for an official trust position if needed.

Lou

>  
>
>     Lou
>
>
> Andy
>  
>
>
>     On 6/19/2017 12:54 AM, [email-masked]
>     <mailto:[email-masked]> wrote:
>     <https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/>
>     >
>     <https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-13>
>     >
>     <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-13>
>     >
>     <https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-13>
>     >
>     >
>     > until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>     >
>     <ftp://ftp.ietf.org/internet-drafts/>
>     >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Jun 2017 18:44:46 +0200

> ask for an official trust position if needed.

I suggest to not open pandora's box. Using the names of the authors /
editors of the RFC has practically worked for a few decades with
hundreds of MIB modules.

/js