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

["Acee Lindem (acee)" <[e-mail]>]

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" <[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