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. /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
