On 17/09/2017 21:21, t.petch wrote:
----- Original Message -----
From: "Juergen Schoenwaelder" <[email protected]>
Sent: Friday, September 15, 2017 6:09 PM
Two comments:
- Obviously, inactive can be in <candidate> and I would not rule out
that inactive configuration can be in any other or future
configuration datastores.
- Whether protocols support inactive or not does not belong into a
definition of what inactive configuration is. The same for backwards
compatibility considerations etc.
So if we define inactive configuration, the definition should be
something like this:
* inactive configuration: Configuration held in a configuration
datastore that is marked to be inactive. Inactive configuration is
ignored during validation and never applied and actively used by
a device.
Yes, we should use 'inactive configuration' everywhere to be
consistent.
Juergen
Yes, your definition is better than mine; let's add it.
I'm not necessarily opposed to this, but I think that we want to be
careful here. Inactive configuration and templating are only meant to
be examples of how <running> could differ from <intended>, and we really
aren't trying to provide normative definitions of them. Is putting a
definition of 'inactive configuration' in this draft going to
potentially cause problems for a future 'inactive configuration'
extension that could possibly want to define the term differently?
If we do decide to incorporate a definition, I would suggest at least
tweaking it slightly to avoid the possible ambiguity of the last phrase:
* inactive configuration: Configuration held in a configuration
datastore that is marked to be inactive. Inactive configuration is
ignored during validation, never applied, and not actively used by
a device.
Thanks,
Rob
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
