Subject: Re: [yang-doctors] IANA full-registry definition

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 01 Apr 2019 10:07:37 +0200

Juergen Schoenwaelder <[email-masked]> writes:

> Benoit,
>
> I think Ruediger's problem is a BGP module where they modeled BGP
> capabilities as identities and they wanted to report the negotiated
> capabilities as config false data. This is problematic since not all
> capability numbers have an identity defined and the set of known
> identities may differ from implementation to implementation.  It would
> be much easier and more robust to simply report the capability
> numbers. Yes, this is less readable for a human, but much more robust
> for automation since clients know they always get a number.
>
> An alternative would be to create a union of an identity and a uint8
> but this does not address the problem that the set of identities known
> by different implementations can differ. One could fix this problem by
> moving from identities to enums since an enum fixes the set of known
> enums. Whether it is worth to have a union of enums and numbers needs

FWIW, in draft-lhotka-dnsop-iana-class-type-yang-01 we used a union of
enum and uint16 for IANA registries "DNS CLASSes" and "Resource Record
(RR) TYPEs".

I would say that this approach may be preferable for centrally
controlled resources such as IANA registries. Identities are better
suited for distributed extensibility where different parties add entries
on their own.

Lada

> to be decided by BGP people. I would suggest to simply define (in
> ietf-bgp-types) a
>
> typedef capability {
>   type uint8;
>   description
>     "BGP capability as maintained by IANA in the BGP capability
>      code registry";
>   reference
>     "RFC 5492: Capabilities Advertisement with BGP-4";
> }
>
> and then use bt:capability that instead of the much more complicated
> identityref { base bt:BGP_CAPABILITY; } to report the BGP capabilities.
>
> /js
>
> On Sat, Mar 30, 2019 at 02:44:06PM +0100, Benoit Claise wrote:
>> Hi Doctors,
>> 
>> I was approached by Ruediger with this problem statement. I'll let Ruediger
>> extend the problem description if necessary.
>> 
>> When we model an IANA registry with YANG, we model the entries one by one as
>> new values are assigned by IANA.
>> There are some IANA registries with clear ranges. For example, fields with a
>> couple of bits.
>> Would it be possible to have a generic way (YANG
>> typedef/identities:whatever) that would report all entries, even the ones
>> not yet assigned. The latter would report the observed values.
>> 
>> Regards, Benoit
>> 
>> 
>> 
>> _______________________________________________
>> 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/>
>
> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 1 Apr 2019 11:15:38 +0000

We want back and forth with identities vs enums for iana-routing-types. We ended up with enums. 

http://www.netconfcentral.org/modules/iana-routing-types 

Correct me if I'm wrong - an enum cannot be augmented but adding a new value in a subsequent version is backward compatible. If the latter is not true, we should relax this in YANG-NEXT. 

Thanks,
Acee

On 4/1/19, 4:08 AM, "yang-doctors on behalf of Ladislav Lhotka" <[email-masked] on behalf of [email-masked]> wrote:

    

    Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 01 Apr 2019 13:31:48 +0200

Hi Acee,

Acee Lindem (acee) píše v Po 01. 04. 2019 v 11:15 +0000:
> Correct me if I'm wrong - an enum cannot be augmented but adding a new value
> in a subsequent version is backward compatible. If the latter is not true, we
> should relax this in YANG-NEXT. 

The augment mechanism in YANG is designed to define new schema nodes under the
target schema nodes. Enums cannot be added this way.

I think the solution that we used for DNS classes and RRs would work just fine
in this case, i.e. a union of enumeration and uint16. Values that don't have a
corresponding enum can then be passed as integers, until the YANG module is
updated, or just as unregistered (experimental) values.

Lada  

> 
> Thanks,
> Acee
> 
> On 4/1/19, 4:08 AM, "yang-doctors on behalf of Ladislav Lhotka" <
> [email-masked] on behalf of [email-masked]> wrote:
>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 01 Apr 2019 13:36:17 +0200 (CEST)

"Acee Lindem (acee)" <[email-masked]> wrote:
> We want back and forth with identities vs enums for
> iana-routing-types. We ended up with enums.
> 
> Correct me if I'm wrong - an enum cannot be augmented but adding a new
> value in a subsequent version is backward compatible.

This is correct.

/martin

> If the latter is
> not true, we should relax this in YANG-NEXT.
> 
> Thanks,
> Acee
> 
> On 4/1/19, 4:08 AM, "yang-doctors on behalf of Ladislav Lhotka"
> <[email-masked] on behalf of [email-masked]> wrote:
>