Subject: [yang-doctors] Identities vs enums

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 29 Aug 2019 10:24:59 +0000

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Aug 2019 12:53:12 +0200

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.

  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.

/js

> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 29 Aug 2019 13:11:13 +0200

On Thu, 2019-08-29 at 10:24 +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.
>  
> (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.
> (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).

I would go for (2).

In fact, the namespace for identity names probably needn't be module-wide, I
think it would be perfectly fine to require unique names only for identities
derived from the same base.

Lada

>  
> Personally, I’m toying with changing to 4 or perhaps 2.  I’m not keen on 3.
>  
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 29 Aug 2019 12:00:38 +0000

Hi Juergen,

Thanks.  Comments inline ...

> -----Original Message-----
> From: Juergen Schoenwaelder <[email-masked]>
> Sent: 29 August 2019 11:53
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: YANG Doctors <[email-masked]>
> Subject: Re: [yang-doctors] Identities vs enums
> 
> A few comments:
> 
 
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".

>   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

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 29 Aug 2019 14:12:06 +0200 (CEST)

"Rob Wilton (rwilton)" <[email-masked]> wrote:

[...]

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

You can also use a union of an enumeration and an identity.

/martin

> > > Personally, I'm toying with changing to 4 or perhaps 2.  I'm not keen
> > > on
> > 3.
> > >

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 29 Aug 2019 14:13:33 +0200 (CEST)

> > that we should consider changing in the hypothetical YANG Next).

+1  (provided you really need the flexibility!)

> derived from the same base.

Yes that would have worked as well.  But it would have a big impact on
implementations that use the fact that they are unique...

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 29 Aug 2019 14:33:31 +0200

On Thu, 2019-08-29 at 14:13 +0200, Martin Bjorklund wrote:
> base
> identities)
> > > (1) Keep with identities with a "loopback-" prefix.  This causes
> 
> > > loopback='loopback-internal'
> 
> > > (3) Use shorter identity names, but also put them in a separate types
> module
> 
> > > (as requested by the reviewer).
> 
> issue

Yes, although I think the required changes shouldn't be too big. On the other
hand, it would be backward compatible in terms of existing modules.   

Lada

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 29 Aug 2019 16:14:43 +0000

+1 for option 2.

On 2019-08-29, 7:11 AM, "yang-doctors on behalf of Ladislav Lhotka" <[email-masked] on behalf of [email-masked]> wrote:

    I would go for (2).

    Lada

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 30 Aug 2019 09:21:57 +0000

> From: yang-doctors <[email-masked]> On Behalf Of Ladislav
> Lhotka
> Sent: 29 August 2019 13:34
> To: Martin Bjorklund <[email-masked]>
> Cc: [email-masked]
[RW] 
FWIW, I raised:

https://github.com/netmod-wg/yang-next/issues/91

Even if we decide to just close it, I thought that it might be worth a discussion.

Thanks,
Rob

> 
> Lada
> 
> >
> >
> > /martin
> >
> >
> >
> > >
> >
> > > Lada
> >
> > >
> >
> > > >
> >
> > > > Personally, I’m toying with changing to 4 or perhaps 2.  I’m not
> > > > keen on
> > 3.
> >
> > > >
> >