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

Ladislav Lhotka <lhotka@nic.cz> Fri, 06 April 2018 08:52 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC23912EAA4 for <netmod@ietfa.amsl.com>; Fri, 6 Apr 2018 01:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 aFk5RcDNIYgK for <netmod@ietfa.amsl.com>; Fri, 6 Apr 2018 01:51:53 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id EA60812E8C2 for <netmod@ietf.org>; Fri, 6 Apr 2018 01:51:52 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id D1B0E1820073; Fri, 6 Apr 2018 10:50:46 +0200 (CEST)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id A41F01820051; Fri, 6 Apr 2018 10:50:44 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Bogaert\, Bart \(Nokia - BE\/Antwerp\)" <bart.bogaert@nokia.com>
Cc: Alex Campbell <Alex.Campbell@Aviatnet.com>, "netmod\@ietf.org" <netmod@ietf.org>
In-Reply-To: <20180406081830.go3hfajpr4hp6svm@elstar.local>
References: <AM4PR07MB1716AECAC144285D98B0E1EE94BB0@AM4PR07MB1716.eurprd07.prod.outlook.com> <1522972773708.26374@Aviatnet.com> <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> <AM4PR07MB1716DDB1796AA320616F7C0F94BA0@AM4PR07MB1716.eurprd07.prod.outlook.com> <20180406081830.go3hfajpr4hp6svm@elstar.local>
Mail-Followup-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Bogaert\, Bart \(Nokia - BE\/Antwerp\)" <bart.bogaert@nokia.com>, Alex Campbell <Alex.Campbell@Aviatnet.com>, "netmod\@ietf.org" <netmod@ietf.org>
Date: Fri, 06 Apr 2018 10:51:48 +0200
Message-ID: <87h8oora3f.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ey2KUlZP6_0NmwJJJJ3U_HvKqCg>
Subject: Re: [netmod] An abundant amount of IANA if types...
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Apr 2018 08:52:06 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:

> If we would have a mechanism to deviate an identityref to a subset of
> identity values supported by an implementation, we would have solved a
> more generic problem. Yes, the IANA list could be 'nicer' but it will
> never be 'nice'.

Three mechanisms can be used for this:

- splitting the identities into separate modules
- using features
- using deviations (even though vendors frown on them)

I also proposed in the past to define the relevant identities in small
batches in the same module that defines other data (configuration, state
etc.) for the given interface type(s), rather than maintaining the
interface types as a separate registry.

I do admit that it is also useful to have such a registry but it can be
automatically compiled from the existing modules (for example, YANG
Catalog could do this).

Lada

>
> /js
>
> On Fri, Apr 06, 2018 at 08:12:03AM +0000, Bogaert, Bart (Nokia - BE/Antwerp) wrote:
>> Alex,
>> 
>> 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 [mailto:lhotka@nic.cz] 
>> Sent: Friday, April 6, 2018 9:55 AM
>> To: Alex Campbell <Alex.Campbell@Aviatnet.com>om>; Bogaert, Bart (Nokia - BE/Antwerp) <bart.bogaert@nokia.com>om>; netmod@ietf.org
>> Subject: Re: [netmod] An abundant amount of IANA if types...
>> 
>> Hi,
>> 
>> 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.
>> 
>> Lada
>>   
>> 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 <netmod-bounces@ietf.org> on behalf of Bogaert, Bart 
>> > (Nokia -
>> > BE/Antwerp) <bart.bogaert@nokia.com>
>> > Sent: Thursday, 5 April 2018 8:21 p.m.
>> > To: netmod@ietf.org
>> > 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
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> -- 
> 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/>

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67