Re: [netmod] An abundant amount of IANA if types...

"Bogaert, Bart (Nokia - BE/Antwerp)" <> Fri, 06 April 2018 08:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D95B9126D74 for <>; Fri, 6 Apr 2018 01:12:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id piCNMoSJM9hp for <>; Fri, 6 Apr 2018 01:12:20 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fe02::71d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 300E8124B17 for <>; Fri, 6 Apr 2018 01:12:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PqdLwMA0Qf9Nte6n2r1aoKAGjHZ1SaETjbLGsEgTNKo=; b=TUihyCrlzlDDy7JU4JPwrwrYASgZk5BOwrIhOugpgSB8iNPkwdGVQmOe/Rw7O0FF+5FNGGXMOoVc6uiZz6bzMUQkHb8Fg6/2mxwBpAbHjsLQ4Y+MD+2ZdQQpVnbSoCwFb/rkebGWhnm0NgmaY2h8DO7qTkpsEz+hejBqnkHVEs0=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.4; Fri, 6 Apr 2018 08:12:17 +0000
Received: from ([fe80::c15e:ad7a:a11e:eff4]) by ([fe80::c15e:ad7a:a11e:eff4%5]) with mapi id 15.20.0653.014; Fri, 6 Apr 2018 08:12:04 +0000
From: "Bogaert, Bart (Nokia - BE/Antwerp)" <>
To: Ladislav Lhotka <>, Alex Campbell <>, "" <>
Thread-Topic: [netmod] An abundant amount of IANA if types...
Thread-Index: AdPMtsq1NhXOIRliRzmEujzHOstMAwAxc+1cAABYHzA=
Date: Fri, 6 Apr 2018 08:12:03 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR07MB1379; 7:a33rr1BNx52lEBNXVfqm3uvf/BLtoop5E4Gj0+Qvd2NpZAXtGvK37l7AdKnLvh9i56fqs4a6DoOkFwK7qj/rRY/wVqcAKe02Dn61nuqSGTOwKmi8v94Qgf0w9kLlFMrWUqNuRVxDYOaE3OyDsii3uWBfDlE5dS7TKPRmAP9brglsIEz6TcO6M+ghCz94NyznjvTfdTgtEZd+p1t7fpg3V7MQn8xuD1l3+nrzMPpNuR6cThqkz1lEVEY4Rt2TZqx6
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 800fdfed-424b-4733-5b1e-08d59b9614e6
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:AM4PR07MB1379;
x-ms-traffictypediagnostic: AM4PR07MB1379:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(82608151540597);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(3231221)(11241501184)(806099)(944501327)(52105095)(10201501046)(93006095)(93001095)(6055026)(6041310)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:AM4PR07MB1379; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1379;
x-forefront-prvs: 0634F37BFF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(346002)(39860400002)(376002)(39380400002)(13464003)(199004)(189003)(377424004)(2906002)(3280700002)(105586002)(446003)(6246003)(25786009)(186003)(97736004)(26005)(6306002)(3846002)(9686003)(102836004)(476003)(229853002)(55016002)(86362001)(6116002)(53936002)(7736002)(486006)(478600001)(114624004)(3660700001)(6436002)(5250100002)(33656002)(59450400001)(81156014)(8676002)(8936002)(966005)(81166006)(74316002)(66066001)(305945005)(2900100001)(53546011)(106356001)(6506007)(2501003)(7696005)(99286004)(76176011)(5660300001)(68736007)(110136005)(11346002)(316002)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1379;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: IrxQbmOYslE5RLthGEt5GJJa6kY/K0i1eD1aUZPbjG/LdYDbFfJFNVMh2wh++E0A+HPX4uKDHM4Y/sBWmBbUBpwEChYlXRNZn34BpTvnJw+09Yc9Gdx+xbxmTcs4AdmyzUGPHpRKCcXMy1BVBA1UfT6iAjS0+54HrU4DWD0cXJuu3gooBzr9RGUkJ4z1G94dDztoHRHsIq6VTQZnam8ogq8VpVbBdjmdXL309dlIjAm876AAA4nl1ZA8dmq7JaaAQxBmIwo5frGQytI4PFVUAuuEeSQRIaVSw6qYSLl02zEMugOySirE4v77iwQqF6utFrD8f+M9aULGU2coK5GZ4hTOCNVDmqQnV0rQ8U0S2e6DBj3taKDIICTOR7fjj/4yhnL1dRez49vCES2oGWR/BdQZ9PUF/V46JYLQguxGpol/Z/7+kjjFBvxJg880j/yYwfT06hWSwNx5YqOd0sN9MA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 800fdfed-424b-4733-5b1e-08d59b9614e6
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2018 08:12:03.9792 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1379
Archived-At: <>
Subject: Re: [netmod] An abundant amount of IANA if types...
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Apr 2018 08:12:23 -0000


Not sure if this only has to do with "practical limitations providing a CLI interface"...   In a machine-to-machine interface this is less of a problem but in a human-to-machine interface it seems a bit impractical to me to find a solution for a problem to scroll through a list of 100+ completions if an operator would ask for the possible completion in case he does not know what to provide as input.  There are ways to limit this output but it can be solved on a modelling level as well.  As I indicated identities can be conditional to a feature and if implementations choose not to implement a set of interface-type related features the list becomes (a whole lot) shorter "by itself".  Now iana-if-type is just a collection of all interface types that have been defined once without any kind of "structure".

Regards, Bart

-----Original Message-----
From: Ladislav Lhotka [] 
Sent: Friday, April 6, 2018 9:55 AM
To: Alex Campbell <>;; Bogaert, Bart (Nokia - BE/Antwerp) <>;;
Subject: Re: [netmod] An abundant amount of IANA if types...


I have argued several times in the past that the IANA interface list (and, for that matter, the iana-if-type module) is a useless pile of rubbish because

- for some interface classes (Ethernet, tunnels) it is way too coarse-grained

- on the other hand, it contains a lot of stuff that nobody will ever use

- using the cabalistic (and wrong, in fact) name "ethernetCsmacd" for Ethernet is outright stupid

- YANG identities allow for encoding important relationships in interface types,in the flat list all this information is lost 

- as you say, implementing the iana-if-type module means that all interface types listed therein become valid.

So yes, I do believe that it would be useful if authoritative expert groups develop a better structure of interface type identities.

On Thu, 2018-04-05 at 23:59 +0000, Alex Campbell wrote:
> I haven't seen any previous discussions on the topic, but we have a 
> similar problem.
> Note this is not really to do with YANG itself, so much as the 
> practical limitations of the software package that provides our CLI interface.
> In NETCONF, the existence of extra unused identities doesn't pose any problem.
> From: netmod <>; on behalf of Bogaert, Bart 
> (Nokia -
> BE/Antwerp) <>;
> Sent: Thursday, 5 April 2018 8:21 p.m.
> To:
> Subject: [netmod] An abundant amount of IANA if types...
> Hi,
> We were wondering if it would make sense to introduce features in the 
> IANA if types YANG model to enable grouping of related interface 
> types.  This would allow implementations to include only the types it 
> really requires (by supporting the related features but not the 
> others) and (in case of a CLI
> interface) would reduce the possible completions if an operator would 
> ask for the possible values of the type of an interface.
> Has this ever been considered/discussed?
> Best regards,
> Bart
> _______________________________________________
> netmod mailing list
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67