----- Original Message ----- From: "Juergen Schoenwaelder" <j.schoenwael...@jacobs-university.de> 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" <lber...@labn.net> > > 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 > > > netmod@ietf.org > > > 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
