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

[Andy Bierman]

On Mon, Oct 3, 2016 at 7:16 AM, Balazs Lengyel 
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  > wrote:
>
>> > Dale R. Worley  writes:
>> >> Ladislav Lhotka  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
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>
> ___
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
> --
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Balazs Lengyel]

  
  
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 
wrote:
>
  Dale R. Worley 
  writes:
  >> Ladislav Lhotka 
  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
  netmod@ietf.org
  https://www.ietf.org/mailman/listinfo/netmod

  
  

  
  
  
  
  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



-- 
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 

  


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Wed, Sep 28, 2016 at 7:52 AM, Dale R. Worley  wrote:

> Andy Bierman  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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Dale R. Worley]

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

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

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Tue, Sep 27, 2016 at 4:58 PM, Alex Campbell 
wrote:

> > Dale R. Worley  writes:
> >> Ladislav Lhotka  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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Alex Campbell]

> Dale R. Worley  writes:
>> Ladislav Lhotka  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.

> Dale

Alex


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Dale R. Worley]

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

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Ladislav Lhotka]

"Dale R. Worley"  writes:

> Balazs Lengyel  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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Sun, Sep 4, 2016 at 3:49 PM, Alex Campbell 
wrote:

> What prevents features from being units of conformance?
>


They are in a sense.

The "base module" is everything without any features.
Then each feature can be added somewhat independently to the base module.
So "base + feature-1" or "base + feature-2" or "base + feature-1 +
feature-2", etc.
can be implemented by a server.


Andy


> 
> From: netmod  on behalf of Juergen Schoenwaelder
> 
> Sent: Friday, 2 September 2016 5:06 a.m.
> To: Andy Bierman
> Cc: netmod@ietf.org
> Subject: Re: [netmod] How to constrain a leaf to a read-only list of
> supported values?
>
> On Thu, Sep 01, 2016 at 09:41:04AM -0700, Andy Bierman wrote:
> > Hi,
> >
> > We keep having discussions about YANG conformance related issues.
> > The only unit of conformance is the YANG module, so it is possible to
> > think the way to solve the conformance/discovery problem is to put every
> > definition
> > in its own module. This is operationally absurd of course, so someday
> YANG
> > is going to need a real conformance model.
> >
>
> Yes.
>
> /js
>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Alex Campbell]

What prevents features from being units of conformance?

From: netmod  on behalf of Juergen Schoenwaelder 

Sent: Friday, 2 September 2016 5:06 a.m.
To: Andy Bierman
Cc: netmod@ietf.org
Subject: Re: [netmod] How to constrain a leaf to a read-only list of supported 
values?

On Thu, Sep 01, 2016 at 09:41:04AM -0700, Andy Bierman wrote:
> Hi,
>
> We keep having discussions about YANG conformance related issues.
> The only unit of conformance is the YANG module, so it is possible to
> think the way to solve the conformance/discovery problem is to put every
> definition
> in its own module. This is operationally absurd of course, so someday YANG
> is going to need a real conformance model.
>

Yes.

/js

--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Thu, Sep 01, 2016 at 09:41:04AM -0700, Andy Bierman wrote:
> Hi,
> 
> We keep having discussions about YANG conformance related issues.
> The only unit of conformance is the YANG module, so it is possible to
> think the way to solve the conformance/discovery problem is to put every
> definition
> in its own module. This is operationally absurd of course, so someday YANG
> is going to need a real conformance model.
>

Yes.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

Hi,

We keep having discussions about YANG conformance related issues.
The only unit of conformance is the YANG module, so it is possible to
think the way to solve the conformance/discovery problem is to put every
definition
in its own module. This is operationally absurd of course, so someday YANG
is going to need a real conformance model.


Andy


On Thu, Sep 1, 2016 at 12:48 AM, Balazs Lengyel  wrote:

> Hello,
>
> The proposed iana-entity.yang seems to take the same approach: one file
> defining 28 identities.
>
> And I share all your concerns about iana-if-type.
>
> Balazs
>
>
> On 2016-08-31 14:16, Vladimir Vassilev wrote:
>
>> On 08/31/2016 12:38 PM, Ladislav Lhotka wrote:
>>
>>> On 31 Aug 2016, at 11:10, Vladimir Vassilev 
 wrote:

 If you design your models using identityref and define the identities
 in separate modules e.g. compression-zip.yang, compression-gzip.yang, etc.
 you can just chose not to load the particular YANG models containing the
 identities not supported when your device starts.

>>> Right, and I have proposed this approach several times in the past.
>>> However, some people prefer that the modules defining identities mirror
>>> IANA and similar registries. In the case of iana-interface-types it also
>>> means that implementations have to deal with obsolete, obscure and
>>> experimental interface types that happen to be in the IANA registry but
>>> nobody will ever want to use.
>>>
>>> Lada
>>>
>> +1
>>
>> The 275 identities defined in iana-if-type.yang appearing as possible
>> /interfaces/interface/type tab completion options in a YANG aware cli or
>> drop-down menu in gui is annoying and stands out as an obvious problem.
>>
>> It is not late to split the file. No standard RFC YANG model includes
>> iana-if-type.yang yet. The actually referenced identities in current drafts
>> is less then 16 (grep-ing in my known YANG model archive) {ethernetCsmacd,
>> l2vlan, ieee8023adLag, ifPwType, pos, atm, atmSubInterface, sonet, otnOtu,
>> frameRelay, bridge, macSecControlledIF, fastdsl}
>>
>> If not single instance per file maybe dividing the file into categories
>> so if your device is atm aware you import iana-if-type-atm.yang and get
>> {atm, atmSubInterface}.
>>
>> However we can probably agree the iana-if-type.yang exception is not a
>> valid excuse for new models like the one in the example where there are 3
>> compression methods to not modularize the identity definitions into
>> separate files and not load identities the implementation does not support
>> but instead resolve to workaround solutions.
>>
>> Vladimir
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
> --
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Vladimir Vassilev]

One alternative for getting rid of unsupported "identity"-s is to use 
"if-feature" as sub-statement which is now supported in YANG 1.1. This 
would be an elegant solution for the example with the 3 compression 
methods. However for standard models one will either have to live with 
the many irrelevant options presented to the user or use some extension 
similar to 
https://tools.ietf.org/html/draft-vassilev-netmod-yang-direct-must-augment-ext-00 
but for identities instead of "must" statements. Then clients and 
servers supporting it will be able to take the light out of the 
"identity"-s the implementation does not support by augmenting those 
with relevant if-feature statements.


On 09/01/2016 09:48 AM, Balazs Lengyel wrote:

Hello,

The proposed iana-entity.yang seems to take the same approach: one 
file defining 28 identities.


And I share all your concerns about iana-if-type.

Balazs


On 2016-08-31 14:16, Vladimir Vassilev wrote:

On 08/31/2016 12:38 PM, Ladislav Lhotka wrote:
On 31 Aug 2016, at 11:10, Vladimir Vassilev 
 wrote:


If you design your models using identityref and define the 
identities in separate modules e.g. compression-zip.yang, 
compression-gzip.yang, etc. you can just chose not to load the 
particular YANG models containing the identities not supported when 
your device starts.
Right, and I have proposed this approach several times in the past. 
However, some people prefer that the modules defining identities 
mirror IANA and similar registries. In the case of 
iana-interface-types it also means that implementations have to deal 
with obsolete, obscure and experimental interface types that happen 
to be in the IANA registry but nobody will ever want to use.


Lada

+1

The 275 identities defined in iana-if-type.yang appearing as possible 
/interfaces/interface/type tab completion options in a YANG aware cli 
or drop-down menu in gui is annoying and stands out as an obvious 
problem.


It is not late to split the file. No standard RFC YANG model includes 
iana-if-type.yang yet. The actually referenced identities in current 
drafts is less then 16 (grep-ing in my known YANG model archive) 
{ethernetCsmacd, l2vlan, ieee8023adLag, ifPwType, pos, atm, 
atmSubInterface, sonet, otnOtu, frameRelay, bridge, 
macSecControlledIF, fastdsl}


If not single instance per file maybe dividing the file into 
categories so if your device is atm aware you import 
iana-if-type-atm.yang and get {atm, atmSubInterface}.


However we can probably agree the iana-if-type.yang exception is not 
a valid excuse for new models like the one in the example where there 
are 3 compression methods to not modularize the identity definitions 
into separate files and not load identities the implementation does 
not support but instead resolve to workaround solutions.


Vladimir

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Balazs Lengyel]

Hello,

The proposed iana-entity.yang seems to take the same approach: one file 
defining 28 identities.


And I share all your concerns about iana-if-type.

Balazs


On 2016-08-31 14:16, Vladimir Vassilev wrote:

On 08/31/2016 12:38 PM, Ladislav Lhotka wrote:
On 31 Aug 2016, at 11:10, Vladimir Vassilev 
 wrote:


If you design your models using identityref and define the 
identities in separate modules e.g. compression-zip.yang, 
compression-gzip.yang, etc. you can just chose not to load the 
particular YANG models containing the identities not supported when 
your device starts.
Right, and I have proposed this approach several times in the past. 
However, some people prefer that the modules defining identities 
mirror IANA and similar registries. In the case of 
iana-interface-types it also means that implementations have to deal 
with obsolete, obscure and experimental interface types that happen 
to be in the IANA registry but nobody will ever want to use.


Lada

+1

The 275 identities defined in iana-if-type.yang appearing as possible 
/interfaces/interface/type tab completion options in a YANG aware cli 
or drop-down menu in gui is annoying and stands out as an obvious 
problem.


It is not late to split the file. No standard RFC YANG model includes 
iana-if-type.yang yet. The actually referenced identities in current 
drafts is less then 16 (grep-ing in my known YANG model archive) 
{ethernetCsmacd, l2vlan, ieee8023adLag, ifPwType, pos, atm, 
atmSubInterface, sonet, otnOtu, frameRelay, bridge, 
macSecControlledIF, fastdsl}


If not single instance per file maybe dividing the file into 
categories so if your device is atm aware you import 
iana-if-type-atm.yang and get {atm, atmSubInterface}.


However we can probably agree the iana-if-type.yang exception is not a 
valid excuse for new models like the one in the example where there 
are 3 compression methods to not modularize the identity definitions 
into separate files and not load identities the implementation does 
not support but instead resolve to workaround solutions.


Vladimir

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Vladimir Vassilev]

On 08/31/2016 01:10 PM, Balazs Lengyel wrote:

Hello,

The problem is not just about identities. It can be a value range.
If your example was about value range then a deviation would be a 
solution. Then we have the same case for modularization. YANG files 
defining deviations loaded when the deviation is relevant and not loaded 
otherwise.
Sometimes we have a generic module like iana-interface type that list 
a lot of identities, and I don't want to have one YAM file per 
identity, to allow a fine control. Also sadly it is not possible to 
have a deviation removing identities. IMHO would be needed.
Well the biggest problem modularizing your identity definitions is you 
will have more YANG files proportional to the flexibility you want. I 
would have chosen that in the example you provide.


I would be more interested in having an extension saying static-data. 
This would state that that part of config is set by the system, and 
can not be modified by the user. So I could have conditions based on 
it, but the user might not modify it.
That is still not as good as modularization of your model and using 
optionally loadable YANG 'deviation's and 'identity' definitions. Even 
if you have "static-data tree" you will be able to use must statements 
to not allow certain range based on that "static data tree" it will 
still be the range defined in the type from the model that will be shown 
to the user editing the configuration in YANG aware CLI or GUI. It is 
still a workaround even if the must statement will fail upon commit.


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Vladimir Vassilev]

On 08/31/2016 12:38 PM, Ladislav Lhotka wrote:

On 31 Aug 2016, at 11:10, Vladimir Vassilev  wrote:

If you design your models using identityref and define the identities in 
separate modules e.g. compression-zip.yang, compression-gzip.yang, etc. you can 
just chose not to load the particular YANG models containing the identities not 
supported when your device starts.

Right, and I have proposed this approach several times in the past. However, 
some people prefer that the modules defining identities mirror IANA and similar 
registries. In the case of iana-interface-types it also means that 
implementations have to deal with obsolete, obscure and experimental interface 
types that happen to be in the IANA registry but nobody will ever want to use.

Lada

+1

The 275 identities defined in iana-if-type.yang appearing as possible 
/interfaces/interface/type tab completion options in a YANG aware cli or 
drop-down menu in gui is annoying and stands out as an obvious problem.


It is not late to split the file. No standard RFC YANG model includes 
iana-if-type.yang yet. The actually referenced identities in current 
drafts is less then 16 (grep-ing in my known YANG model archive) 
{ethernetCsmacd, l2vlan, ieee8023adLag, ifPwType, pos, atm, 
atmSubInterface, sonet, otnOtu, frameRelay, bridge, macSecControlledIF, 
fastdsl}


If not single instance per file maybe dividing the file into categories 
so if your device is atm aware you import iana-if-type-atm.yang and get 
{atm, atmSubInterface}.


However we can probably agree the iana-if-type.yang exception is not a 
valid excuse for new models like the one in the example where there are 
3 compression methods to not modularize the identity definitions into 
separate files and not load identities the implementation does not 
support but instead resolve to workaround solutions.


Vladimir

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Ladislav Lhotka]

> On 31 Aug 2016, at 13:10, Balazs Lengyel  wrote:
> 
> Hello,
> 
> The problem is not just about identities. It can be a value range. Sometimes 
> we have a generic module like iana-interface type that

A value range is IMO a good candidate for a deviation.

>  list a lot of identities, and I don't want to have one YAM file per 
> identity, to allow a fine control. Also sadly it is not possible to have a 
> deviation removing identities. IMHO would be needed.

What you can do is to bundle the identity in the same module with config and 
state data corresponding to that identity. This is what the routing model does 
with address families: "ipv4-unicast" identity is defined in 
"ietf-ipv4-unicast-routing", and "ipv6-unicast" identity is defined in 
"ietf-ipv6-unicast-routing". This is IMO far better than mirroring

http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml

in a module.

> 
> I would be more interested in having an extension saying static-data. This 
> would state that that part of config is set by the system, and can not be 
> modified by the user. So I could have conditions based on it, but the user 
> might not modify it.

This is something like system-controlled interfaces, no?

Lada

> 
> regards Balazs
> 
> 
> On 2016-08-31 12:38, Ladislav Lhotka wrote:
>>> On 31 Aug 2016, at 11:10, Vladimir Vassilev  
>>> wrote:
>>> 
>>> If you design your models using identityref and define the identities in 
>>> separate modules e.g. compression-zip.yang, compression-gzip.yang, etc. you 
>>> can just chose not to load the particular YANG models containing the 
>>> identities not supported when your device starts.
>> Right, and I have proposed this approach several times in the past. However, 
>> some people prefer that the modules defining identities mirror IANA and 
>> similar registries. In the case of iana-interface-types it also means that 
>> implementations have to deal with obsolete, obscure and experimental 
>> interface types that happen to be in the IANA registry but nobody will ever 
>> want to use.
>> 
>> Lada
>> 
>>> If you absolutely can not define your identities in separate YANG files 
>>> (better modularity is indeed the edge YANG has over other modeling 
>>> languages and it should be used) you can use feature with some limitations 
>>> e.g. instead of leaf of type enumeration you will have a choice with each 
>>> case containing if-feature and presence container for example.
>>> 
>>> If you can not change the model to be modular and your implementation does 
>>> not support it 100% then you are not supporting the model and you are free 
>>> to be creative with the workaround but then YANG is not the problem.
>>> 
>>> I also see alternative discussion value in the subject line. Lets say one 
>>> would like to specify in a standard way a list of values supported by a 
>>> device as valid /interface/interface/name values e.g. ("ge0", "ge1",  
>>> "xe0", "xe1", "me0"). This can be useful in many ways e.g. tab completion. 
>>> Also the supported types for each of the interface names and so on further 
>>> reducing the entropy. Does anyone else see value in that?
>>> 
>>> On 08/31/2016 09:35 AM, Balazs Lengyel wrote:
 Hello Jan,
 
 This may be the best solution we have, but nacm rules may be changed, and 
 then device limits might be edited by the operator, and then we have a 
 problem.
 
 The good solution would be to indicate that this is read-only static data, 
 and allow must, leafref towards it. However I don't see a way to do this 
 in YANG at the moment short of an ericsson-extension.
 
 regards Balazs
 
 
 On 2016-08-30 15:14, Jan Lindblad wrote:
> Balazs,
> 
>> We have the following design pattern.
>> 
>> 1) An enumeration or a set of identities are defined that define a set 
>> of options generally supported by Ericsson products.  (e.g. supported 
>> compression algorithms)
>> 2) The specific node sets in run-time a leaf-list indicating the set of 
>> values that this specific node supports (e.g. 
>> nodes-supported-compression-types: zip, gzip, bz)
>> 3) For some function the user has to select a specific option value 
>> (e.g. leaf file-compression for transferring backup files)
>> 
>> 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.
>> 
>> It would be perfectly reasonable because the 
>> nodes-supported-compression-types only change during upgrade, but YANG 
>> does not allow this.
>> 
>> I would still like to have some modeled solution, not just plain English 
>> stating the constraint. Any i

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

[Balazs Lengyel]

That would be a backward incompatible change, which is a general 
problem, not specific to this issue. (like changing a datatype from 
int16 to int8).


In this sense the data set by the system becomes part of the model and 
thus must be covered by backward compatibility rules.


Balazs


On 2016-08-31 10:54, Martin Bjorklund wrote:

But I assume that the list of supported-compression-algorithm can
change with a software upgrade, and if so, how do you handle the case
that the config contains a value that is removed in a software
upgrade?


--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Balazs Lengyel]

Hello,

The problem is not just about identities. It can be a value range. 
Sometimes we have a generic module like iana-interface type that list a 
lot of identities, and I don't want to have one YAM file per identity, 
to allow a fine control. Also sadly it is not possible to have a 
deviation removing identities. IMHO would be needed.


I would be more interested in having an extension saying static-data. 
This would state that that part of config is set by the system, and can 
not be modified by the user. So I could have conditions based on it, but 
the user might not modify it.


regards Balazs


On 2016-08-31 12:38, Ladislav Lhotka wrote:

On 31 Aug 2016, at 11:10, Vladimir Vassilev  wrote:

If you design your models using identityref and define the identities in 
separate modules e.g. compression-zip.yang, compression-gzip.yang, etc. you can 
just chose not to load the particular YANG models containing the identities not 
supported when your device starts.

Right, and I have proposed this approach several times in the past. However, 
some people prefer that the modules defining identities mirror IANA and similar 
registries. In the case of iana-interface-types it also means that 
implementations have to deal with obsolete, obscure and experimental interface 
types that happen to be in the IANA registry but nobody will ever want to use.

Lada


If you absolutely can not define your identities in separate YANG files (better 
modularity is indeed the edge YANG has over other modeling languages and it 
should be used) you can use feature with some limitations e.g. instead of leaf 
of type enumeration you will have a choice with each case containing if-feature 
and presence container for example.

If you can not change the model to be modular and your implementation does not 
support it 100% then you are not supporting the model and you are free to be 
creative with the workaround but then YANG is not the problem.

I also see alternative discussion value in the subject line. Lets say one would like to specify in a standard way a list of 
values supported by a device as valid /interface/interface/name values e.g. ("ge0", "ge1",  
"xe0", "xe1", "me0"). This can be useful in many ways e.g. tab completion. Also the supported types 
for each of the interface names and so on further reducing the entropy. Does anyone else see value in that?

On 08/31/2016 09:35 AM, Balazs Lengyel wrote:

Hello Jan,

This may be the best solution we have, but nacm rules may be changed, and then 
device limits might be edited by the operator, and then we have a problem.

The good solution would be to indicate that this is read-only static data, and 
allow must, leafref towards it. However I don't see a way to do this in YANG at 
the moment short of an ericsson-extension.

regards Balazs


On 2016-08-30 15:14, Jan Lindblad wrote:

Balazs,


We have the following design pattern.

1) An enumeration or a set of identities are defined that define a set of 
options generally supported by Ericsson products.  (e.g. supported compression 
algorithms)
2) The specific node sets in run-time a leaf-list indicating the set of values 
that this specific node supports (e.g. nodes-supported-compression-types: zip, 
gzip, bz)
3) For some function the user has to select a specific option value (e.g. leaf 
file-compression for transferring backup files)

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.

It would be perfectly reasonable because the nodes-supported-compression-types 
only change during upgrade, but YANG does not allow this.

I would still like to have some modeled solution, not just plain English 
stating the constraint. Any idea how to do it?

I have seen this use case many times. I usually solve this by making a 
container with device specific limits, lists of supported values, etc, which is 
config true but with nacm rules preventing everyone from making changes. Then I 
have a device specific database initialization file with the correct settings 
for this device, which is loaded into the database at first boot.

/jan


Vladimir

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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







--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Ladislav Lhotka]

> On 31 Aug 2016, at 11:10, Vladimir Vassilev  wrote:
> 
> If you design your models using identityref and define the identities in 
> separate modules e.g. compression-zip.yang, compression-gzip.yang, etc. you 
> can just chose not to load the particular YANG models containing the 
> identities not supported when your device starts.

Right, and I have proposed this approach several times in the past. However, 
some people prefer that the modules defining identities mirror IANA and similar 
registries. In the case of iana-interface-types it also means that 
implementations have to deal with obsolete, obscure and experimental interface 
types that happen to be in the IANA registry but nobody will ever want to use.

Lada

> 
> If you absolutely can not define your identities in separate YANG files 
> (better modularity is indeed the edge YANG has over other modeling languages 
> and it should be used) you can use feature with some limitations e.g. instead 
> of leaf of type enumeration you will have a choice with each case containing 
> if-feature and presence container for example.
> 
> If you can not change the model to be modular and your implementation does 
> not support it 100% then you are not supporting the model and you are free to 
> be creative with the workaround but then YANG is not the problem.
> 
> I also see alternative discussion value in the subject line. Lets say one 
> would like to specify in a standard way a list of values supported by a 
> device as valid /interface/interface/name values e.g. ("ge0", "ge1",  
> "xe0", "xe1", "me0"). This can be useful in many ways e.g. tab completion. 
> Also the supported types for each of the interface names and so on further 
> reducing the entropy. Does anyone else see value in that?
> 
> On 08/31/2016 09:35 AM, Balazs Lengyel wrote:
>> Hello Jan,
>> 
>> This may be the best solution we have, but nacm rules may be changed, and 
>> then device limits might be edited by the operator, and then we have a 
>> problem.
>> 
>> The good solution would be to indicate that this is read-only static data, 
>> and allow must, leafref towards it. However I don't see a way to do this in 
>> YANG at the moment short of an ericsson-extension.
>> 
>> regards Balazs
>> 
>> 
>> On 2016-08-30 15:14, Jan Lindblad wrote:
>>> Balazs,
>>> 
 We have the following design pattern.
 
 1) An enumeration or a set of identities are defined that define a set of 
 options generally supported by Ericsson products.  (e.g. supported 
 compression algorithms)
 2) The specific node sets in run-time a leaf-list indicating the set of 
 values that this specific node supports (e.g. 
 nodes-supported-compression-types: zip, gzip, bz)
 3) For some function the user has to select a specific option value (e.g. 
 leaf file-compression for transferring backup files)
 
 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.
 
 It would be perfectly reasonable because the 
 nodes-supported-compression-types only change during upgrade, but YANG 
 does not allow this.
 
 I would still like to have some modeled solution, not just plain English 
 stating the constraint. Any idea how to do it?
>>> I have seen this use case many times. I usually solve this by making a 
>>> container with device specific limits, lists of supported values, etc, 
>>> which is config true but with nacm rules preventing everyone from making 
>>> changes. Then I have a device specific database initialization file with 
>>> the correct settings for this device, which is loaded into the database at 
>>> first boot.
>>> 
>>> /jan
>>> 
>> 
> Vladimir
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Vladimir Vassilev]

If you design your models using identityref and define the identities in 
separate modules e.g. compression-zip.yang, compression-gzip.yang, etc. 
you can just chose not to load the particular YANG models containing the 
identities not supported when your device starts.


If you absolutely can not define your identities in separate YANG files 
(better modularity is indeed the edge YANG has over other modeling 
languages and it should be used) you can use feature with some 
limitations e.g. instead of leaf of type enumeration you will have a 
choice with each case containing if-feature and presence container for 
example.


If you can not change the model to be modular and your implementation 
does not support it 100% then you are not supporting the model and you 
are free to be creative with the workaround but then YANG is not the 
problem.


I also see alternative discussion value in the subject line. Lets say 
one would like to specify in a standard way a list of values supported 
by a device as valid /interface/interface/name values e.g. ("ge0", 
"ge1",  "xe0", "xe1", "me0"). This can be useful in many ways e.g. 
tab completion. Also the supported types for each of the interface names 
and so on further reducing the entropy. Does anyone else see value in that?


On 08/31/2016 09:35 AM, Balazs Lengyel wrote:

Hello Jan,

This may be the best solution we have, but nacm rules may be changed, 
and then device limits might be edited by the operator, and then we 
have a problem.


The good solution would be to indicate that this is read-only static 
data, and allow must, leafref towards it. However I don't see a way to 
do this in YANG at the moment short of an ericsson-extension.


regards Balazs


On 2016-08-30 15:14, Jan Lindblad wrote:

Balazs,


We have the following design pattern.

1) An enumeration or a set of identities are defined that define a 
set of options generally supported by Ericsson products.  (e.g. 
supported compression algorithms)
2) The specific node sets in run-time a leaf-list indicating the set 
of values that this specific node supports (e.g. 
nodes-supported-compression-types: zip, gzip, bz)
3) For some function the user has to select a specific option value 
(e.g. leaf file-compression for transferring backup files)


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.


It would be perfectly reasonable because the 
nodes-supported-compression-types only change during upgrade, but 
YANG does not allow this.


I would still like to have some modeled solution, not just plain 
English stating the constraint. Any idea how to do it?
I have seen this use case many times. I usually solve this by making 
a container with device specific limits, lists of supported values, 
etc, which is config true but with nacm rules preventing everyone 
from making changes. Then I have a device specific database 
initialization file with the correct settings for this device, which 
is loaded into the database at first boot.


/jan




Vladimir

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

Balazs Lengyel  wrote:
> Hello Jan,
> 
> This may be the best solution we have, but nacm rules may be changed,
> and then device limits might be edited by the operator, and then we
> have a problem.
> 
> The good solution would be to indicate that this is read-only static
> data, and allow must, leafref towards it. However I don't see a way to
> do this in YANG at the moment short of an ericsson-extension.

I think this is the only correct solution available today.  I.e.,
describe the behavior in description text, and/or add an extension
that makes this formal and machnie readable for your tools:

  leaf-list supported-compression-algorithm {
config false;
type eri:compression-algorithm;
description
  "Lists the compression algorithms supported by this device.";
  }

  leaf compression-algorithm {
config true;
type eri:compression-algorithm;
description
  "Must be one of the values listed in
   supported-compression-algorithm.";
eri:restrict-to "../supported-compression-algorithm";
  }

But I assume that the list of supported-compression-algorithm can
change with a software upgrade, and if so, how do you handle the case
that the config contains a value that is removed in a software
upgrade?


/martin


> 
> regards Balazs
> 
> 
> On 2016-08-30 15:14, Jan Lindblad wrote:
> > Balazs,
> >
> >> We have the following design pattern.
> >>
> >> 1) An enumeration or a set of identities are defined that define a set
> >> of options generally supported by Ericsson products.  (e.g. supported
> >> compression algorithms)
> >> 2) The specific node sets in run-time a leaf-list indicating the set
> >> of values that this specific node supports
> >> (e.g. nodes-supported-compression-types: zip, gzip, bz)
> >> 3) For some function the user has to select a specific option value
> >> (e.g. leaf file-compression for transferring backup files)
> >>
> >> 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.
> >>
> >> It would be perfectly reasonable because the
> >> nodes-supported-compression-types only change during upgrade, but YANG
> >> does not allow this.
> >>
> >> I would still like to have some modeled solution, not just plain
> >> English stating the constraint. Any idea how to do it?
> > I have seen this use case many times. I usually solve this by making a
> > container with device specific limits, lists of supported values, etc,
> > which is config true but with nacm rules preventing everyone from
> > making changes. Then I have a device specific database initialization
> > file with the correct settings for this device, which is loaded into
> > the database at first boot.
> >
> > /jan
> >
> 
> -- 
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Balazs Lengyel]

Hello Jan,

This may be the best solution we have, but nacm rules may be changed, 
and then device limits might be edited by the operator, and then we have 
a problem.


The good solution would be to indicate that this is read-only static 
data, and allow must, leafref towards it. However I don't see a way to 
do this in YANG at the moment short of an ericsson-extension.


regards Balazs


On 2016-08-30 15:14, Jan Lindblad wrote:

Balazs,


We have the following design pattern.

1) An enumeration or a set of identities are defined that define a set of 
options generally supported by Ericsson products.  (e.g. supported compression 
algorithms)
2) The specific node sets in run-time a leaf-list indicating the set of values 
that this specific node supports (e.g. nodes-supported-compression-types: zip, 
gzip, bz)
3) For some function the user has to select a specific option value (e.g. leaf 
file-compression for transferring backup files)

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.

It would be perfectly reasonable because the nodes-supported-compression-types 
only change during upgrade, but YANG does not allow this.

I would still like to have some modeled solution, not just plain English 
stating the constraint. Any idea how to do it?

I have seen this use case many times. I usually solve this by making a 
container with device specific limits, lists of supported values, etc, which is 
config true but with nacm rules preventing everyone from making changes. Then I 
have a device specific database initialization file with the correct settings 
for this device, which is loaded into the database at first boot.

/jan



--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Dale R. Worley]

Balazs Lengyel  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";
}

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Jan Lindblad]

Balazs,

> We have the following design pattern.
> 
> 1) An enumeration or a set of identities are defined that define a set of 
> options generally supported by Ericsson products.  (e.g. supported 
> compression algorithms)
> 2) The specific node sets in run-time a leaf-list indicating the set of 
> values that this specific node supports (e.g. 
> nodes-supported-compression-types: zip, gzip, bz)
> 3) For some function the user has to select a specific option value (e.g. 
> leaf file-compression for transferring backup files)
> 
> 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.
> 
> It would be perfectly reasonable because the 
> nodes-supported-compression-types only change during upgrade, but YANG does 
> not allow this.
> 
> I would still like to have some modeled solution, not just plain English 
> stating the constraint. Any idea how to do it?

I have seen this use case many times. I usually solve this by making a 
container with device specific limits, lists of supported values, etc, which is 
config true but with nacm rules preventing everyone from making changes. Then I 
have a device specific database initialization file with the correct settings 
for this device, which is loaded into the database at first boot.

/jan



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod