Subject: [yang-doctors] Identities vs enums

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 19 Aug 2017 19:02:04 +0000

All,
In the context iana-routing-types.yang, we’ve been having a discussion of the merits of identities vs enums. We’ve followed the lead of RFC 7224 and used identities which allow augmentation. However, for IANA code points, there could be merit in having the type represent the actual numeric value. Any thoughts on this?

In the next version of YANG, it would be useful for a base identity to allow it to have a "base-type" (mutually exclusive of "identity-ref"). For all identities a "base-value" would be allowed as long as it conformed to the constraints of the actual or inherited (via “identity-ref”) “base-type”.

Thanks,
Acee

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 20 Aug 2017 10:03:01 +0200

> In the next version of YANG, it would be useful for a base identity to allow it to have a "base-type" (mutually exclusive of "identity-ref"). For all identities a "base-value" would be allowed as l…

The question here really is who is charge of controlling assignments
of a name space.

- If there is a single authority controlling the assignments, an enum
  works fine.

- If the assignments are not controlled by a single authority, an
  identity works fine.

We sometimes have situations that are somewhere in between, i.e., a
central authority controlling assignments but delegating parts of the
name space to other authoritities. I agree, we do not have good
support to model this explicitly in YANG today.

/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: Andy Bierman <[email-masked]>
Date: Wed, 23 Aug 2017 12:46:37 -0700

On Sun, Aug 20, 2017 at 1:03 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > In the context iana-routing-types.yang, we’ve been having a discussion
> of the merits of identities vs enums. We’ve followed the lead of RFC 7224
> and used identities which allow augmentation. However, for IANA code
> points, there could be merit in having the type represent the actual
> numeric value. Any thoughts on this?
> >
> > In the next version of YANG, it would be useful for a base identity to
> allow it to have a "base-type" (mutually exclusive of "identity-ref"). For
> all identities a "base-value" would be allowed as long as it conformed to
> the constraints of the actual or inherited (via “identity-ref”) “base-type”.
> >
>
I think Acee is asking about a new feature that does not exist in YANG,
which is to add
an enum value-stmt to an identity-stmt somehow.  Seems like a valid
use-case.

It is easy to be confused into thinking the "value" and "position"
assignments have any
relevance to the protocols, but unfortunately they do not (for NETCONF and
RESTCONF).
Think of them as "reference" statements, to identify conceptual codepoints
that are never
sent on the wire. Only the enum or bit names are sent on the wire in XML or
JSON.

Actually CORE WG is developing YANG-to-CBOR, which does use the value
and position fields for the binary encoding.

/js
Andy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Aug 2017 22:36:33 +0200

> an enum value-stmt to an identity-stmt somehow.  Seems like a valid

Identities can be without a central authority controlling assignments
- so there is little hope that values assigned to identities carry a
useful meaning unless there is a mechanism to partition and delegate
number spaces along the identity hierarchy.

/js