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

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

[Andy Bierman]

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

>
>
>
>
> Regarding the suggestion to add this text:
>
> > Guidelines for
> >  moving existing data modules to the NMDA are defined in
> >  [I-D.dsdt-nmda-guidelines].
>
> 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.
>
>
>
>
>
>  I thought that this was settled before (maybe not):
> https://mailarchive.ietf.org/arch/msg/netmod/pDLDm8gdIBwwyGyfa_acVKHtu_Q
>
>
>
>
>
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

Regarding the suggestion to add this text:

> Guidelines for
>  moving existing data modules to the NMDA are defined in
>  [I-D.dsdt-nmda-guidelines].

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.


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




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

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

[Andy Bierman]

On Tue, Jun 20, 2017 at 4:32 AM, Kent Watsen  wrote:

>
> Regarding the suggestion to add this text:
>
> > Guidelines for
> >  moving existing data modules to the NMDA are defined in
> >  [I-D.dsdt-nmda-guidelines].
>
> 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.




> Kent (any hat)


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

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

[Robert Wilton]

Hi Tom,

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

--- Original Message -
From: "Phil Shafer" 
To: "Andy Bierman" 
Cc: 
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".


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

Thanks,
  Phil

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

[Juergen Schoenwaelder]

On Tue, Jun 20, 2017 at 12:39:55PM +0100, t.petch wrote:
> --- Original Message -
> From: "Phil Shafer" 
> To: "Andy Bierman" 
> Cc: 
> 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.
> 
> 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..
>

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 

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

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

[t.petch]

--- Original Message -
From: "Phil Shafer" 
To: "Andy Bierman" 
Cc: 
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.

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].
>
> Thanks,
>  Phil
>
> ___
> 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] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[Kent Watsen]

Regarding the suggestion to add this text:

> Guidelines for
>  moving existing data modules to the NMDA are defined in
>  [I-D.dsdt-nmda-guidelines].

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

Re: [netmod] Some comments on yang tree diagrams

[wangzitao]

Hi Acee,

-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2017年6月19日 23:17
收件人: wangzitao; Martin Bjorklund; Lou Berger
抄送: netmod@ietf.org
主题: Re: [netmod] Some comments on yang tree diagrams

Hi Michael, 

On 6/19/17, 3:20 AM, "netmod on behalf of wangzitao"
 wrote:

>Hi Authors,
>
>I have read this draft and think it is very useful. However, IMHO, 
>there are also something need to improved. For example:
># In section2 Tree Diagram Syntax, it describes " !  for a presence 
>container", but in some draft/ RFC the container not be marked by "!", 
>for example "ietf-interface" [RFC7223].
># And I suggest to highlight the symbol "-w",

How do you highlight a symbol in plain ASCII text?

[Michael]: I don't know, maybe just mark it as "-writable"...

Thanks,
Acee 

>it usually appears in "input" of RPC, for example "ietf-yang-push"
>[draft-ietf-netconf-yang-push]
>
>Please consider my suggestion.
>
>Best Regards!
>-Michael
>
>-邮件原件-
>发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 
>internet-dra...@ietf.org
>发送时间: 2017年6月13日 20:34
>收件人: i-d-annou...@ietf.org
>抄送: netmod@ietf.org
>主题: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-00.txt
>
>
>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   : YANG Tree Diagrams
>Authors : Martin Bjorklund
>  Lou Berger
>   Filename: draft-ietf-netmod-yang-tree-diagrams-00.txt
>   Pages   : 4
>   Date: 2017-06-13
>
>Abstract:
>   This document captures the current syntax used in YANG module Tree
>   Diagrams.  The purpose of the document is to provide a single
>   location for this definition.  This syntax may be updated from time
>   to time based on the evolution of the YANG language.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-00
>https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-tree-diagr
>ams
>-00
>
>
>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/
>
>___
>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