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, 06 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 >
- [netmod] An abundant amount of IANA if types... Bogaert, Bart (Nokia - BE/Antwerp)
- Re: [netmod] An abundant amount of IANA if types.… Alex Campbell
- Re: [netmod] An abundant amount of IANA if types.… Ladislav Lhotka
- Re: [netmod] An abundant amount of IANA if types.… Martin Bjorklund
- Re: [netmod] An abundant amount of IANA if types.… Bogaert, Bart (Nokia - BE/Antwerp)
- Re: [netmod] An abundant amount of IANA if types.… Juergen Schoenwaelder
- Re: [netmod] An abundant amount of IANA if types.… Ladislav Lhotka
- Re: [netmod] An abundant amount of IANA if types.… Juergen Schoenwaelder
- Re: [netmod] An abundant amount of IANA if types.… Juergen Schoenwaelder
- Re: [netmod] An abundant amount of IANA if types.… Bogaert, Bart (Nokia - BE/Antwerp)
- Re: [netmod] An abundant amount of IANA if types.… Ladislav Lhotka
- Re: [netmod] An abundant amount of IANA if types.… Martin Bjorklund
- Re: [netmod] An abundant amount of IANA if types.… Ladislav Lhotka
- Re: [netmod] An abundant amount of IANA if types.… Robert Wilton
- Re: [netmod] An abundant amount of IANA if types.… Andy Bierman
- Re: [netmod] An abundant amount of IANA if types.… Mahesh Jethanandani
- Re: [netmod] An abundant amount of IANA if types.… Andy Bierman
- Re: [netmod] An abundant amount of IANA if types.… Ladislav Lhotka
- Re: [netmod] An abundant amount of IANA if types.… Andy Bierman