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

Ladislav Lhotka <> Fri, 06 April 2018 12:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6BAEF124B18 for <>; Fri, 6 Apr 2018 05:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] 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 Cn4kTiv7XOlg for <>; Fri, 6 Apr 2018 05:01:32 -0700 (PDT)
Received: from ( [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 11E0A1201FA for <>; Fri, 6 Apr 2018 05:01:32 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:4431:4fff:fe6e:1c10]) by (Postfix) with ESMTPSA id 6AB0162433 for <>; Fri, 6 Apr 2018 14:01:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1523016090; bh=jklWU7zyDrQt1ylp2A2orh79dXfyoWaE0tDdDrF+rkg=; h=From:To:Date; b=CyG/s9IQx92Lqw6AU/GG/p2wBpcF+4J7x1+EOYYB3GyE2JpklzcXbck2Ez/9t6tsE OdkLDDd+5pbNCylqdlv4UmBZH/Y0nqCAPUh6JYE4bjOZNy7kH4ov2D+28UdZp4MEok WmRLVkiNE1tpUjAitlnyNNAvRTp3wpNFGmyhaxAQ=
Message-ID: <>
From: Ladislav Lhotka <>
Date: Fri, 06 Apr 2018 14:01:30 +0200
In-Reply-To: <20180406113639.rgmxofccvsn7gzw5@elstar.local>
References: <> <> <> <> <20180406081830.go3hfajpr4hp6svm@elstar.local> <> <20180406113639.rgmxofccvsn7gzw5@elstar.local>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.1
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
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 12:01:39 -0000

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 <>; 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.

> 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


> /js
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67