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
- [yang-doctors] IANA full-registry definition Benoit Claise
- Re: [yang-doctors] IANA full-registry definition Juergen Schoenwaelder
- Re: [yang-doctors] IANA full-registry definition Benoit Claise
- Re: [yang-doctors] IANA full-registry definition Ladislav Lhotka
- Re: [yang-doctors] IANA full-registry definition Acee Lindem (acee)
- Re: [yang-doctors] IANA full-registry definition Ladislav Lhotka
- Re: [yang-doctors] IANA full-registry definition Martin Bjorklund