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

Andy Bierman <> Fri, 06 April 2018 16:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E322120724 for <>; Fri, 6 Apr 2018 09:03:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id amlyCOcWzpco for <>; Fri, 6 Apr 2018 09:03:38 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 361A31204DA for <>; Fri, 6 Apr 2018 09:03:38 -0700 (PDT)
Received: by with SMTP id v207-v6so1252262lfa.10 for <>; Fri, 06 Apr 2018 09:03:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9H4KD/bvx/9PLFONUhqmQckl9ee35KbL+YrMO2+kwu0=; b=WRJWHstsXAa324Ied8f5lJOhD3+gBJJu1s4rltzsJBMBS3UgG5Z08svwh2mrec9BL+ EbKLp/JBf9tTFZ6qa5bvGu/xNmiUNnOv75R5l00CwPiK1XQL3VgzK9FfWyxPOSerZmoz lIzZ+KEVfV0tNOVgPoMggJtF87Pjcw39q5TZece5qc5J+98gEYoT8yEe8Xk22v7JboqT fkBj0FPcj5HnH1MQ8+z0w11qPaSG4281Y5njDiRVQRRBWs2p5RjjVb4ZDHls4U4UdKeE lu3JfsngivVaryRWJFkbzvkFuqHPcNNSel0Unq2Y6fDN08WVmUBIELBOJ9lPjvZFQhw4 nGpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9H4KD/bvx/9PLFONUhqmQckl9ee35KbL+YrMO2+kwu0=; b=hbGUP1BGHVYIZ55oBWXgjqFWYX4ArciyPlVxhLy96RazXaAk+Tl4+p/VOtZgwciw7y vM2iGhb1D7ibFHFWKBpTU6jy23NUi1u5yTHjmdMQ66GUdGKhmXot7CpldNUqAG/5H+Gv Kek315GD1Q3fv6Hzgt8Jp+upiK3/3EOXnTvbj5mgpE2bwOPxdQNDzzRp5GimWfZtKSuU s5XvjC9fkl4KDfNPFh7EIAyKlP47qIOYjqYFw+2Jm+XRx83EXlo3ZZ4n8yfTMERRAdOL xCaCeu8UNErQLoKCBkWh8vDsD/Olos+f4Oi7gIFvqqPbvw5dxMPhHJJQQ9+aIrrXcYYI 2SvA==
X-Gm-Message-State: ALQs6tCMvV4blPzTzxyHZsmb49WhEsJDdnJmgi0uqhUX9WWS7GZwN9rM OHy9WvVVF2/eLt8qyT96vx7iO5akvM9uh4mCLdaltA==
X-Google-Smtp-Source: AIpwx4+CccAflIpYEcRl7XyNGIC/4owZH/hWd5kxWD/9D+aHxCF1VIp4PgMW+cuEgFtalVTsCuZWsPHEiq44+ecgWNU=
X-Received: by with SMTP id f2mr16606411lja.15.1523030616288; Fri, 06 Apr 2018 09:03:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:5149:0:0:0:0:0 with HTTP; Fri, 6 Apr 2018 09:03:35 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <20180406081830.go3hfajpr4hp6svm@elstar.local> <> <20180406113639.rgmxofccvsn7gzw5@elstar.local> <> <>
From: Andy Bierman <>
Date: Fri, 6 Apr 2018 09:03:35 -0700
Message-ID: <>
To: Robert Wilton <>
Cc: Ladislav Lhotka <>, NetMod WG <>
Content-Type: multipart/alternative; boundary="089e0823d90cddc7c505693032a1"
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 16:03:41 -0000


All of these suggested solutions seem OK if one were looking for the most
way to solve the problem.  Tossing iana-if-types and starting over would
achieve that result.

First, this is a server capabilities problem, so it is related to the
implementation, not the schema.

Second, the if-types that are allowed at any given moment can be specific
to the implementation
and the interface name.

I think this is the 3rd time I have suggested an RPC to solve the actual

  rpc get-allowed-if-types {
      "Retrieve the interface types allowed by the server.";
    input {
      leaf name {
         type if:interface-ref;
            "If present, the server will return allowed interface types for
this interface name only.
             If not present, then the server will return all supported
interface types.";
     output {
         leaf-list type {
            type identityref {
               base interface-type;
              "Specifies a supported interface type";


On Fri, Apr 6, 2018 at 6:55 AM, Robert Wilton <>; wrote:

> At the moment, I would say that the vast majority of the definitions in
> IANA.yang are just noise because they refer to definitions that are
> obsolete.  Our OS seems to use only 10% of the 287+ defined IANA types, and
> that 10% includes technologies such as frame relay, serial, atm, that very
> much seem to be on their way out.
> Using hierarchical identities and interface properties seems like a
> reasonable solution to me (e.g. as described in
> draft-wilton-netmod-interface-properties-00).  E.g. so rather than having
> configuration with a direct when statement on a specific list of interface
> types, instead the when statement can depend on the appropriate interface
> properties.
> I also like Lada's suggestion of trying to spread out the IANA definitions
> to the modules that are defining the technology.  So, if a device
> implements support for PPP configuration/operational state then it would
> also naturally define any PPP related interface identities at the same time.
> If a vendor wants to define their own flavour of Ethernet interface then
> they can do so in their vendor specific module without requiring all
> tooling to become aware of it, and allowing the existing Ethernet
> configuration to work as normal.
> On 06/04/2018 13:01, 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 <>; 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.
>> Yes, getting the root of this structure right is perhaps somewhat tricky,
> but I don't think that it needs to be all encompassing, or perfect.
> - 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
>> enough.
> I'm not sure there is a security concern here, but a long list where most
> of the values are cruft doesn't really seem to help anyone.  It also makes
> it harder to know which is the right type to use.  E.g. will everyone know
> that they should use "ethernetCsmacd" rather than "gigabitEthernet" for an
> optical GE interface that doesn't actually use CSMA/CD ...
> Thanks,
> Rob
>> Lada
>> /js
> _______________________________________________
> netmod mailing list