Re: [netmod] An abundant amount of IANA if types...
Ladislav Lhotka <lhotka@nic.cz> Mon, 09 April 2018 10:45 UTC
Return-Path: <lhotka@nic.cz>
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 EF87E126DCA for <netmod@ietfa.amsl.com>; Mon, 9 Apr 2018 03:45:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 TI7ubShnAuR5 for <netmod@ietfa.amsl.com>; Mon, 9 Apr 2018 03:45:15 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AEC2E126BF6 for <netmod@ietf.org>; Mon, 9 Apr 2018 03:45:14 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 7C4D11820071; Mon, 9 Apr 2018 12:43:50 +0200 (CEST)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 380BC1820051; Mon, 9 Apr 2018 12:43:48 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Andy Bierman <andy@yumaworks.com>, Robert Wilton <rwilton@cisco.com>
Cc: NetMod WG <netmod@ietf.org>
In-Reply-To: <CABCOCHQ5SegNXOruRERvpG0EHu+irgYbewiUBzV3fDXNQMVaDA@mail.gmail.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> <CABCOCHQ5SegNXOruRERvpG0EHu+irgYbewiUBzV3fDXNQMVaDA@mail.gmail.com>
Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, Robert Wilton <rwilton@cisco.com>, NetMod WG <netmod@ietf.org>
Date: Mon, 09 Apr 2018 12:45:10 +0200
Message-ID: <87in90odzd.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ZWbf1uxVPKZXfVHOnHH8yQOyAqQ>
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: Mon, 09 Apr 2018 10:45:18 -0000
Andy Bierman <andy@yumaworks.com> writes: > 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. I think nobody is suggesting to dump iana-if-types, just create an alternative hierarchy of identities. So it's not disruptive at all. > > First, this is a server capabilities problem, so it is related to the > implementation, not the schema. I disagree, it is also a data modelling problem. What's needed is to be able to define parameters that are common to e.g. Ethernet interfaces in one place and let them be inherited by all Ethernet-like interfaces. The flat list of identities - even if the contents was much better than it currently is - allows to do it only in a way that's clumsy and non-scalable. > > 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 { But this is an ad hoc solution that works only for this particular registry. Lada > 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 >> -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
- [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