On Mon, Sep 18, 2017 at 11:14:55AM +0100, Robert Wilton wrote: > > > 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?
Yes, my preference would be to leave the definition of inactive configuration to a future draft. > 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. > Yes, this is better (if we have to define this). It all boils down: a) We publish an architecture which enables future standardization work on things we know exist in real implementations. b) We strictly limit us to what we define right now and this means that the architecture does not describe what some real implementations do and we have to revise the architecure should future work started to standardize such things. For simple inactive configuration, I do see an opportunity for a standard solution and hence I think what the revised datastores I-D proposes makes a lot of sense (but then I am of course biased here). It provides an architectural framework that enabled a further evolution without having to change the architectural framework again. /js -- 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
