Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 inactive

[Martin Bjorklund <[e-mail]>]

Juergen Schoenwaelder <[e-mail]> 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" <[e-mail]>
> > > 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