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

Andy Bierman <andy@yumaworks.com> Fri, 06 April 2018 16:03 UTC

Return-Path: <andy@yumaworks.com>
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 4E322120724 for <netmod@ietfa.amsl.com>; Fri, 6 Apr 2018 09:03:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 amlyCOcWzpco for <netmod@ietfa.amsl.com>; Fri, 6 Apr 2018 09:03:38 -0700 (PDT)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361A31204DA for <netmod@ietf.org>; Fri, 6 Apr 2018 09:03:38 -0700 (PDT)
Received: by mail-lf0-x229.google.com with SMTP id v207-v6so1252262lfa.10 for <netmod@ietf.org>; Fri, 06 Apr 2018 09:03:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.46.56.2 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: <4c3be475-0b9c-5837-5d08-115201b43305@cisco.com>
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> <4c3be475-0b9c-5837-5d08-115201b43305@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 6 Apr 2018 09:03:35 -0700
Message-ID: <CABCOCHQ5SegNXOruRERvpG0EHu+irgYbewiUBzV3fDXNQMVaDA@mail.gmail.com>
To: Robert Wilton <rwilton@cisco.com>
Cc: Ladislav Lhotka <lhotka@nic.cz>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="089e0823d90cddc7c505693032a1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/i4CrCUe57fuWGigjsH6KIiEJ2gI>
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 16:03:41 -0000

Hi,

All of these suggested solutions seem OK if one were looking for the most
disruptive
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
probem:

  rpc get-allowed-if-types {
    description
      "Retrieve the interface types allowed by the server.";
    input {
      leaf name {
         type if:interface-ref;
         description
            "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;
            }
            description
              "Specifies a supported interface type";
        }
    }
 }


Andy


On Fri, Apr 6, 2018 at 6:55 AM, Robert Wilton <rwilton@cisco.com>; 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 <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.
>>>
>> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>