On Tue, Sep 27, 2016 at 4:58 PM, Alex Campbell <[email protected]> wrote:
> > Dale R. Worley <[email protected]> writes: > >> Ladislav Lhotka <[email protected]> writes: > >>> typedef Compression-Method { > >>> ... > >>> } > >>> > >>> list node { > >>> config true; > >>> key name; > >>> > >>> string name; > >>> > >>> leaf-list supported-compression-methods { > >>> type Compression-Method; > >>> config false; > >>> } > >>> > >>> Compression-Method compression-method; > >>> must "compression-method ... supported-compression-methods"; > >>> } > > >> The only technical problem with your mock-up is that "must" expressions > >> on config nodes cannot refer to state data. > > > Ouch! That means that any technique like the one I proposed isn't going > > to work. Indeed, it may be that there is no way to constrain a config > > leaf based on value(s) provided by the implementation. > > It was my understanding was that this is a deliberate design decision, so > that a configuration tree can always be validated offline. > > Back before there was YANG 1.0 I proposed the concept of constants in YANG but this was seen as too complicated. This is the exact use-case I had in mind. The YANG module would #define the constants (maybe with a default or no value) and they could be used in statements. The vendors would set the constants at build or maybe the operators can set them at module load-time. I was thinking more about range/pattern statements at the time than bit-is-set() but I think the same concept could apply. #define SUPPORTED_COMPRESSION_METHODS must "compression-method ... SUPPORTED_COMPRESSION_METHODS"; This way config does not depend on operational state,which would be a really bad idea. > Dale > > Alex > > 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
