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

[Vladimir Vassilev <[e-mail]>]

On 08/31/2016 12:38 PM, Ladislav Lhotka wrote:
>> On 31 Aug 2016, at 11:10, Vladimir Vassilev <[e-mail]> 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