Hi Tom,
Regarding the issue on the definition of inactive configuration, in the
end we think that we don't need to define it for the following reasons:
1) Juergen's new objectives contains a brief description of inactive
configuration (without defining it).
2) Inactive has been removed from the normative text, instead the
normative text more generically refers to "configuration
transformations" and just uses inactive as an example of such a
transformation.
3) Configuration transformation is defined as:
o configuration transformation: The addition, modification or
removal of configuration between the <running> and <intended>
datastores. Examples of configuration transformations include the
removal of inactive configuration and the configuration produced
through the expansion of templates.
OK?
Validating that this is sufficient to address your concern maybe easier
when we post an updated revision with all WG LC markups applied.
Thanks,
Rob
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.
Tom Petch
/js
On Fri, Sep 15, 2017 at 05:20:15PM +0100, t.petch wrote:
Inactive appears a dozen times but is not defined, except in the
course
of those appearances it effectively is, but is sometimes 'inactive',
sometimes 'inactive configuration', sometimes 'inactive data'.
I would find it clearer if the term was used consistently and if
there
was an explicit definition amongst the other definitions in section
2
such as
inactve configuration: Configuration that is present in <running>
which
is not in use by the device and which plays no part in validation.
It
cannot appear in any other datastore. The protocols that are
currently
standardised do not support inactive configuration but a number of
proprietary protocols do. Inactive configuration is only exposed to
clients that indicate support for inactive configuration; clients
not
indicating support for inactive configuration receive the contents
of
<running> with the inactive configuration removed.
This would put a stake in the ground for as and when the concept is
standardised and may reduce the proliferation of the term with
multiple
meanings.
Tom Petch
----- Original Message -----
From: "Lou Berger" <[email protected]>
Sent: Friday, September 01, 2017 10:02 PM
This starts a two week working group last call on
draft-ietf-netmod-revised-datastores-04.
The working group last call ends on September 17.
Please send your comments to the netmod mailing list.
Positive comments, e.g., "I've reviewed this document and
believe it is ready for publication", are welcome!
This is useful and important, even from authors.
Thank you,
Netmod Chairs
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
--
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/>
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
