Re: [yang-doctors] Identities vs enums

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Juergen,

Thanks.  Comments inline ...

> -----Original Message-----
> From: Juergen Schoenwaelder <[e-mail]>
> Sent: 29 August 2019 11:53
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: YANG Doctors <[e-mail]>
> Subject: Re: [yang-doctors] Identities vs enums
> 
> A few comments:
> 
> - Enums can be extended. RFC 7950 section 11:
> 
>    o  An "enumeration" type may have new enums added, provided the old
>       enums's values do not change.  Note that inserting a new enum
>       before an existing enum or reordering existing enums will result
>       in new values for the existing enums, unless they have explicit
>       values assigned to them.
 
But this only helps if you use the enum for a new leaf.  I.e. an implementation cannot add extra enum values into an existing leaf, without a "deviate replace" on the "type".

> 
>   It is important to not change the order and advisable to assign
>   explicit numeric values.
> 
> - Moving definitions into another module means that one has to use
>   module prefixes.
> 
> - All identities defined in a module share the same identifier
>   namespace. Using the same identifier in other namespaces should not
>   be a problem. See RFC 7950 section 6.2.1.
> 
>    o  All identity names defined in a module and its submodules share
>       the same identity identifier namespace.
> 
> - The decision whether an enum or an identity is appropriate should be
>   based on whether it is necessary to support future name allocations
>   that can made outside of the module, i.e., without updating the
>   module. This is where identities shine. But then they also have
>   issues since there is currently no standard way yet to define
>   subsets of identities, e.g., the subset of identities supported or
>   required by an implementation.

Yes.  I'm questioning (for a future version of YANG) whether enums should have somewhat similar flexibility as identities (yes, I appreciate that there are value/name collision concerns).

Thanks,
Rob


> 
> /js
> 
> On Thu, Aug 29, 2019 at 10:24:59AM +0000, Rob Wilton (rwilton) wrote:
> > I doubt that this is the first time that this has come up ...
> >
> > draft-ietf-netmod-intf-ext-yang-07, defines 3 identities (along with a
> base identity) for loopback configuration: "loopback-internal", "loopback-
> line" and "loopback-connector".
> >
> > One of the reviewers is complaining that the "loopback-" prefix in the
> identity is redundant and noisy.  I.e. he doesn't like having to write
> loopback='loopback-internal', and would like to be able to write
> loopback='internal' instead.
> >
> > His main suggestion is to move these loopback (or perhaps just the
> identities) to a separate YANG module so that they don't need to define a
> "loopback-" prefix.
> >
> > There seem to be some choices here:
> >
> > (1) Keep with identities with a "loopback-" prefix.  This causes
> loopback='loopback-internal'
> >
> > (2) Keep with identities, but loose the common prefix, i.e. the
> identities become "internal", "line", "connector".  Given the size of the
> module, the likelihood of an identity naming clash in future seems quite
> small, but they are somewhat generic terms.
> > (3) Use shorter identity names, but also put them in a separate types
> module (as requested by the reviewer).
> > (4) Use an enum rather than identities.  Although this has the potential
> issue that the enum cannot be extended (which I'm wondering if this is
> something that we should consider changing in the hypothetical YANG Next).
> >
> > Personally, I'm toying with changing to 4 or perhaps 2.  I'm not keen on
> 3.
> >
> > Any thoughts or opinions from the YANG doctors?
> >
> > Thanks,
> > Rob
> >
> 
> > _______________________________________________
> > yang-doctors mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/yang-doctors
> 
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>