Hi Tom,
On 20/06/2017 12:39, t.petch wrote:
--- Original Message -----
From: "Phil Shafer" <p...@juniper.net>
To: "Andy Bierman" <a...@yumaworks.com>
Cc: <netmod@ietf.org>
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
