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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Sat, 30 March 2019 14:29 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 63E961201B3 for <yang-doctors@ietfa.amsl.com>; Sat, 30 Mar 2019 07:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 kEu6s-t6Ec9Q for <yang-doctors@ietfa.amsl.com>; Sat, 30 Mar 2019 07:29:47 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261E2120187 for <yang-doctors@ietf.org>; Sat, 30 Mar 2019 07:29:46 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E345937; Sat, 30 Mar 2019 15:29:43 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id LVzqiebBQT2j; Sat, 30 Mar 2019 15:29:43 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sat, 30 Mar 2019 15:29:43 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id A3F04200A8; Sat, 30 Mar 2019 15:29:43 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id zLqApfi0ApWr; Sat, 30 Mar 2019 15:29:43 +0100 (CET)
Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 34485200A7; Sat, 30 Mar 2019 15:29:43 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Sat, 30 Mar 2019 15:29:42 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 4913F3007A4C6D; Sat, 30 Mar 2019 15:29:42 +0100 (CET)
Date: Sat, 30 Mar 2019 15:29:41 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Benoit Claise <bclaise@cisco.com>
CC: YANG Doctors <yang-doctors@ietf.org>, "Ruediger Volk, Deutsche Telekom Technik - FMED-41.." <rv@NIC.DTAG.DE>
Message-ID: <20190330142941.mx55xkis6g3do3cj@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Benoit Claise <bclaise@cisco.com>, YANG Doctors <yang-doctors@ietf.org>, "Ruediger Volk, Deutsche Telekom Technik - FMED-41.." <rv@NIC.DTAG.DE>
References: <b7a2f097-649b-ffca-6e80-921754fd85eb@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <b7a2f097-649b-ffca-6e80-921754fd85eb@cisco.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/YPmMnLyKCvPtyeWMrNUt9rkGKBI>
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: Sat, 30 Mar 2019 14:29:50 -0000

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
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/>