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

[Martin Bjorklund <[e-mail]>]

"Acee Lindem (acee)" <[e-mail]> wrote:
> 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.

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"
> <[e-mail] on behalf of [e-mail]> wrote:
> 
>     Juergen Schoenwaelder <[e-mail]> 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
>     >> [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/>
>     >
>     > _______________________________________________
>     > yang-doctors mailing list
>     > [e-mail]
>     > https://www.ietf.org/mailman/listinfo/yang-doctors
>     
>     -- 
>     Ladislav Lhotka
>     Head, CZ.NIC Labs
>     PGP Key ID: 0xB8F92B08A9F76C67
>     
>     _______________________________________________
>     yang-doctors mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/yang-doctors
>     
> 
> _______________________________________________
> yang-doctors mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/yang-doctors