Juergen Schoenwaelder <[email protected]> wrote: > 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.
+1 Since Andy raised a similar issue for templates, maybe we need to make it more clear that both inactive and templates are really just examples of things that can influence what goes into <intended> from <running>. > > 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. I also prefer (a). If we did (b) without any additional explanation, it would be quite unclear why we even bother to define <intended>. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
