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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
