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

Ladislav Lhotka <lhotka@nic.cz> Mon, 01 April 2019 11:31 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B991200F5 for <yang-doctors@ietfa.amsl.com>; Mon, 1 Apr 2019 04:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9VLJ8Akf6uX for <yang-doctors@ietfa.amsl.com>; Mon, 1 Apr 2019 04:31:52 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A051200E3 for <yang-doctors@ietf.org>; Mon, 1 Apr 2019 04:31:51 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id BA0C86333F; Mon, 1 Apr 2019 13:31:48 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1554118308; bh=pZ/B+WM3iBptM4IDezXq5P+o5a7GR90rFIHFzP87ptE=; h=From:To:Date; b=SucKDiZ/bDcxXLQIHOXVaRHf9V0lpSGlgWUNsEphGVR4baA7EuBgh1T3csqW8x/VM KMKZLeDn92sqm69DGI9+5pZoJ3Xy1vyz90Uv9IXuOx1uY7sbaY2tXjQXTQKD+213+o fuWnlQs85A1eHAPH4vCN0i/2FHh4ASpgAHigpKyc=
Message-ID: <156a07e7b8e3de12aac245944ae401d054687df9.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: "Acee Lindem (acee)" <acee@cisco.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Benoit Claise (bclaise)" <bclaise@cisco.com>
Cc: YANG Doctors <yang-doctors@ietf.org>, "Ruediger Volk, Deutsche Telekom Technik - FMED-41.." <rv@NIC.DTAG.DE>
Date: Mon, 01 Apr 2019 13:31:48 +0200
In-Reply-To: <5B876091-2B4A-45D9-91D9-D46716FECB87@cisco.com>
References: <b7a2f097-649b-ffca-6e80-921754fd85eb@cisco.com> <20190330142941.mx55xkis6g3do3cj@anna.jacobs.jacobs-university.de> <87lg0uywqe.fsf@nic.cz> <5B876091-2B4A-45D9-91D9-D46716FECB87@cisco.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/6EMhPQys-Kon6mtPfbNKZsLc_aE>
Subject: Re: [yang-doctors] IANA full-registry definition
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2019 11:31:55 -0000

Hi Acee,

Acee Lindem (acee) píše v Po 01. 04. 2019 v 11:15 +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. 

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" <
> yang-doctors-bounces@ietf.org on behalf of lhotka@nic.cz> wrote:
> 
>     Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> 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
>     >> yang-doctors@ietf.org
>     >> 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
>     > yang-doctors@ietf.org
>     > https://www.ietf.org/mailman/listinfo/yang-doctors
>     
>     -- 
>     Ladislav Lhotka
>     Head, CZ.NIC Labs
>     PGP Key ID: 0xB8F92B08A9F76C67
>     
>     _______________________________________________
>     yang-doctors mailing list
>     yang-doctors@ietf.org
>     https://www.ietf.org/mailman/listinfo/yang-doctors
>     
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67