On Fri, Sep 15, 2017 at 12:40 PM, Phil Shafer <[email protected]> wrote:
> "t.petch" writes: > >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'. > > Agree. Consistent terms are good things. > > >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. > > Inactive configuration should be allowed in <candidate> and <startup>, > as well as in dynamic datastores. It's hard to put constraints on > a facility that we're really not defining. > > >The protocols that are currently > >standardised do not support inactive configuration but a number of > >proprietary protocols do. > > In JUNOS, we use the standard protocols but encoded these as > non-standard attributes. > > >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 is also not true for our implementation. If you <get-config> > on any datastore that contains inactive data, you'll receive > that data. > > But this means if any clients use the disable-node feature then all clients need to know about the feature as well, or they will mistake these nodes for enabled nodes (i.e., plain configuration according to the standard) . I am in favor of waiting, and not defining new YANG rules that conflict with real deployment. Better to wait until standard protocols need to support inactive vs. active configuration. Thanks, > Phil > Andy > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
