On Mon, Oct 3, 2016 at 7:16 AM, Balazs Lengyel <[email protected]> wrote:
> Hello, > > Similarly to Andy's idea we are thinking about declaring data nodes > static-data. This means that > > - they can not be changed via the management interface e.g. > CLI/Netconf/Restconf > - that they are changed very infrequently ( at upgrade) > - that they are considered part of the systems design time definition, > meaning that the specific values must be subject to strict backwards > compatibility rules, just as the models themselves need to stay backwards > compatible > > This data can be config true or false, and the former allows > must/when/leafref restrictions on them. > config=true: This sounds like server-owned config. The frequency of changes is an implementation detail. config=false: This is just operational data. The client never had any control over changing these values. IMO this is an important missing piece that (hopefully) opstate work will address. It is too complex to expose in YANG all the logic that goes into a dynamic default. It is easier to just flag it as server-write-only. We have been using a YANG extension since 2012 to support this type of config. http://www.netconfcentral.org/modules/yuma-ncx/2013-09-23#user-write.678 It would be better to have standard YANG extensions for opstate. I am a little concerned that each point solution (like YANG Push) will create its own set of opstate extensions and they will overlap and leave gaps. regards Balazs > Andy > > On 2016-09-28 02:21, Andy Bierman wrote: > > > > 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 [email protected]https://www.ietf.org/mailman/listinfo/netmod > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: [email protected] > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
