Subject: Re: [netmod] How to constrain a leaf to a read-only list of supported values?

From: Balazs Lengyel <[email-masked]>
Date: Mon, 3 Oct 2016 16:16:41 +0200

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.

regards Balazs

On 2016-09-28 02:21, Andy Bierman
wrote:

On Tue, Sep 27, 2016 at 4:58 PM, Alex
Campbell <[email-masked]>
wrote:

Dale R. Worley <[email-masked]>
writes:

>> Ladislav Lhotka <[email-masked]>
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-masked]

https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Tue, 4 Oct 2016 09:44:52 -0700

On Mon, Oct 3, 2016 at 7:16 AM, Balazs Lengyel <[email-masked]>
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
>

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-masked]
> > wrote:
>
>> > Dale R. Worley <[email-masked]> writes:
>> >> Ladislav Lhotka <[email-masked]> writes:
>> >>>   must "compression-method ... supported-compression-methods";
>> >>> }
>>
>> >> The only technical problem with your mock-up is that "must" expressions
>> > 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.
>
>    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 [email-masked]://www.ietf.org/mailman/listinfo/netmod
>
>
> --