On 08/31/2016 12:38 PM, Ladislav Lhotka wrote:
On 31 Aug 2016, at 11:10, Vladimir Vassilev <vladi...@transpacket.com> 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
