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

From: Balazs Lengyel <[email-masked]>
Date: Thu, 1 Sep 2016 09:48:50 +0200

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 
>>> <[email-masked]> 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
> [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: Vladimir Vassilev <[email-masked]>
Date: Thu, 01 Sep 2016 13:47:38 +0200

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 1 Sep 2016 09:41:04 -0700

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 <[email-masked]
> wrote:

>>> On 31 Aug 2016, at 11:10, Vladimir Vassilev <[email-masked]>
>>>> 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.
>>>>
>>> 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
>>
>> /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.
>>
>> 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}.
>>
>> 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
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Sep 2016 19:06:06 +0200

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

---

From: Alex Campbell <[email-masked]>
Date: Sun, 4 Sep 2016 22:49:59 +0000

What prevents features from being units of conformance?
________________________________________
From: netmod <[email-masked]> on behalf of Juergen Schoenwaelder <[email-masked]>
Sent: Friday, 2 September 2016 5:06 a.m.
To: Andy Bierman
Cc: [email-masked]
Subject: Re: [netmod] How to constrain a leaf to a read-only list of supported values?

Yes.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sun, 4 Sep 2016 16:20:16 -0700

> 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