On 21/06/2017 18:20, Andy Bierman wrote:
On Wed, Jun 21, 2017 at 5:32 AM, Juergen Schoenwaelder
<[email protected]
<mailto:[email protected]>> 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 3103 <http://www.jacobs-university.de/
<http://www.jacobs-university.de/>>
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
