"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. Thanks, Phil _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
