On Wed, Sep 28, 2016 at 7:52 AM, Dale R. Worley <[email protected]> wrote:
> Andy Bierman <[email protected]> writes: > > 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. > > The difficulty in the scenario we are discussing (I think) is that the > list of valid values can be updated by the device, though presumably > infrequently (e.g., when the software is updated). So the valid values > aren't determined by the module itself. > Right. I did not make it clear that the #define is incomplete. It is a place-holder. The implementation magically fills it in. > > > #define SUPPORTED_COMPRESSION_METHODS > > > > must "compression-method ... SUPPORTED_COMPRESSION_METHODS"; > > I assume you can do this by writing the list of values directly in the > Xpath expression. Not at all as nice, but at least it would work. > It would be difficult to support configuration validation that relied on operational state 1) could be high frequency of changes 2) trigger to initiate validation not defined, not part of the protocol 3) chicken and egg: what if the config change would cause the operational state that is part of the validation to change? Dale > Andy
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
