Tom,
Thanks for the comments, please see inline ...
On 20/06/2017 17:36, t.petch wrote:
----- Original Message -----
From: "Robert Wilton" <[email protected]>
Sent: Tuesday, June 20, 2017 1:35 PM
Hi Tom,
On 20/06/2017 12:39, t.petch wrote:
--- Original Message -----
From: "Phil Shafer" <[email protected]>
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 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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
.
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
