On Tue, Jun 20, 2017 at 11:19 AM, Joel M. Halpern <[email protected]>
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
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
