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

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 09 Sep 2016 15:33:58 +0200

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

> Balazs Lengyel <[email-masked]> writes:
>> Problem: how do you restrict values for (3) - file-compression so that 
>> it is one of the nodes-supported-compression-types. The natural solution 
>> would be to use a must expression or a leaf-ref, but as 
>> nodes-supported-compression-types is config-false data, it is not 
>> allowed to constrain the config=true leaf, file-compression, with it.
>
> I'm no expert at this, but it seems to me that the way to do it is to
> have the overall data structure be config-true but make the contained
> supported-compression-types be config-false.  You can nest config-false
> nodes in a config-true structure.  The Yang would be something like
> this:
>
> 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";
> }

I think this is a good idea. It would have to be done on ad hoc basis
but, on the other hand, not all enumerations permit implementations to
choose a subset of enums.

The only technical problem with your mock-up is that "must" expressions
on config nodes cannot refer to state data.

Lada

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

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 27 Sep 2016 13:46:45 -0400

> 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.

Dale

---

From: Alex Campbell <[email-masked]>
Date: Tue, 27 Sep 2016 23:58:13 +0000

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

> 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.

> Dale

Alex

---

From: Andy Bierman <[email-masked]>
Date: Tue, 27 Sep 2016 17:21:20 -0700

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

> 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.

> Alex

Andy

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 28 Sep 2016 10:52:45 -0400

> 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.

>   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.

Dale

---

From: Andy Bierman <[email-masked]>
Date: Wed, 28 Sep 2016 08:32:04 -0700

> 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.

> 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