Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[Robert Wilton]

On 21/06/2017 18:20, Andy Bierman wrote:



On Wed, Jun 21, 2017 at 5:32 AM, Juergen Schoenwaelder 
> wrote:


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

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.



I agree with Joel that all protocol negotiated values should not be 
considered configuration.
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.




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

This should not be called configuration.
Agreed.  If these values are exposed they should be exposed as config 
false nodes in the operational datastore.


Thanks,
Rob




Andy

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

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

Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[Mehmet Ersue]

> 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

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.

> 
> '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
> 
> > > 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.
> >
> > 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
> >
> > --
> > 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] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[t.petch]

- Original Message -
From: "Juergen Schoenwaelder" 
Sent: Tuesday, June 20, 2017 8:40 PM

> On Tue, Jun 20, 2017 at 02:19:32PM -0400, Joel M. Halpern wrote:
> > 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.
>
> 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.

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

> > 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.
>
> 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
>
> --
> 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] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[Andy Bierman]

On Wed, Jun 21, 2017 at 5:32 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

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

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



> ---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
>
> --
> 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] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[Juergen Schoenwaelder]

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

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

-- 
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] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[Robert Wilton]

Tom,

Thanks for the comments, please see inline ...


On 20/06/2017 17:36, t.petch wrote:

- Original Message -
From: "Robert Wilton" 
Sent: Tuesday, June 20, 2017 1:35 PM



Hi Tom,

On 20/06/2017 12:39, t.petch wrote:

--- Original Message -
From: "Phil Shafer" 
Sent: Tuesday, June 20, 2017 7:05 AM


Andy Bierman writes:

This draft addresses all remaining open issues, include the

rewrite

of the

opstate section.

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.

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.

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

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



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


Thanks,
Rob



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



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 

Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[Alex Campbell]

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  on behalf of Joel M. Halpern 

Sent: Wednesday, 21 June 2017 6:19 a.m.
To: t.petch; Robert Wilton; netmod@ietf.org
Subject: Re: [netmod] Defining configuraiton: was I-D Action: 
draft-ietf-netmod-rfc6087bis-13.txt

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:
> On Tue, Jun 20, 2017 at 05:36:12PM +0100, t.petch wrote:
>>
>> 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.
>>
>
> 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
>

___
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] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[Juergen Schoenwaelder]

On Tue, Jun 20, 2017 at 02:19:32PM -0400, Joel M. Halpern wrote:
> 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.

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

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

-- 
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] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[Andy Bierman]

On Tue, Jun 20, 2017 at 11:19 AM, Joel M. Halpern 
wrote:

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

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.



> Yours,
> Joel
>
>

Andy



>
> On 6/20/17 1:51 PM, Juergen Schoenwaelder wrote:
>
>> On Tue, Jun 20, 2017 at 05:36:12PM +0100, t.petch wrote:
>>
>>>
>>> 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.
>>>
>>>
>> 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
>>
>>
> ___
> 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] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[Joel M. Halpern]

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:

On Tue, Jun 20, 2017 at 05:36:12PM +0100, t.petch wrote:


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.



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



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

Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[Juergen Schoenwaelder]

On Tue, Jun 20, 2017 at 05:36:12PM +0100, t.petch wrote:
> 
> 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.
>

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

-- 
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] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[t.petch]

- Original Message -
From: "Robert Wilton" 
Sent: Tuesday, June 20, 2017 1:35 PM


> Hi Tom,
>
> On 20/06/2017 12:39, t.petch wrote:
> > --- Original Message -
> > From: "Phil Shafer" 
> > Sent: Tuesday, June 20, 2017 7:05 AM
> >
> >> Andy Bierman writes:
> >>> This draft addresses all remaining open issues, include the
rewrite
> > of the
> >>> opstate section.
>  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.
> > 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.
> 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".

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

> Thanks,
> Rob
>
>
> >
> > 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
> >
> >
> >> 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].
> >>
> >>