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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Fri, 06 April 2018 12:29 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 B0836126DED for <netmod@ietfa.amsl.com>; Fri, 6 Apr 2018 05:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 ozRj7aYgjY0Q for <netmod@ietfa.amsl.com>; Fri, 6 Apr 2018 05:29:03 -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 9CACF1201FA for <netmod@ietf.org>; Fri, 6 Apr 2018 05:29:03 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 65BD1CDD; Fri, 6 Apr 2018 14:29:02 +0200 (CEST)
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 OcD0Iv2YoUS4; Fri, 6 Apr 2018 14:29:01 +0200 (CEST)
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; Fri, 6 Apr 2018 14:29:02 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E37A20031; Fri, 6 Apr 2018 14:29:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PTBNtt_qKjmG; Fri, 6 Apr 2018 14:29:01 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F24520035; Fri, 6 Apr 2018 14:29:01 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 5EE2042AB51D; Fri, 6 Apr 2018 14:29:01 +0200 (CEST)
Date: Fri, 6 Apr 2018 14:29:01 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: netmod@ietf.org
Message-ID: <20180406122901.yayqpgrvxmjzu4eo@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, netmod@ietf.org
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> <87h8oora3f.fsf@nic.cz> <20180406113639.rgmxofccvsn7gzw5@elstar.local> <2d13795de2ba190878afaf8b1dd94e9d9495a6a7.camel@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2d13795de2ba190878afaf8b1dd94e9d9495a6a7.camel@nic.cz>
User-Agent: NeoMutt/20171215
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/n3NDz0H1QYAAW33hqFkSqNFVdJs>
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 12:29:06 -0000

On Fri, Apr 06, 2018 at 02:01:30PM +0200, Ladislav Lhotka wrote:
> On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote:
> > On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
> > > 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
> > 
> > Whatever module organization you come up with, it won't work for all
> > implementations. 
> > 
> > > - using features
> > 
> > Making every identity a feature will turn the feature system upside
> > down. This is similar to making every leaf a feature.
> > 
> > > - using deviations (even though vendors frown on them)
> > 
> > If my implementation only supports A and B and C, then a deviation may
> > state exactly that and the problem is solved. Hoping that my specific
> 
> In fact, deviations cannot delete identity values because they aren't schema
> nodes, so they are of no use.

Putting today's limits of YANG syntax aside for the moment, I still
believe implementations need to publish the identities they support
without requiring matching features or module definition.

> > combination of A and B and C matches a set of modules or some set of
> > features is in my view an illusion.
> 
> An implementation that supports, say, a given type of tunnel interface will
> implement the module that covers this tunnel type. If the identity for this
> tunnel interface type is defined in the same module, then all is good. I don't
> get why this should be an illusion. On the contrary, I think it is the cleanest
> available solution to this conformance specification problem.
> 
> > 
> > Vendors not shipping proper deviations are essentially telling their
> > customers that they have not yet understood model driven management.
> > We need to change the mindset here instead of polluting our data
> > models with hundreds or thousands of fine grained 'features'.
> 
> I agree that zillions of features aren't nice but it seems to be the only
> solution that we currently have for modules of the iana-if-type style.
> 
> Having an bulky set of identity values, most of which are of no interest, is IMO
> much worse and could also be a security issue if implementors aren't careful
> enough.

If an implementation does not check input, then the code is broken,
regardless whether we restrict the identities somewhere or not. I do
not buy the security point.

/js

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