Re: [netmod] 6991bis: address-with-prefix-length
Per Hedeland <per@hedeland.org> Thu, 18 April 2019 13:14 UTC
Return-Path: <per@hedeland.org>
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 31037120323 for <netmod@ietfa.amsl.com>; Thu, 18 Apr 2019 06:14:28 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outbound.mailhop.org
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 nZ5ZHpCw4Oue for <netmod@ietfa.amsl.com>; Thu, 18 Apr 2019 06:14:26 -0700 (PDT)
Received: from outbound1g.eu.mailhop.org (outbound1g.eu.mailhop.org [52.28.6.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E553812031C for <netmod@ietf.org>; Thu, 18 Apr 2019 06:14:25 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1555593263; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=mulgI2VK2BVbu+fOpICdpskgXVhrjjQpfUbZSWQ3GD6Em36dRuTGR2AgMgUl9tEhvsoNxecguE+bF T6oyXn/GjQbLMEtEIjiDop75LSq04RHt0KmtAcu3Qjm6cZ0vjZXDVvWqHHlo/weAyEkuXtgXb11jp2 JsQasMgdvf/yxNctsi/d/DHOwVqNyVddqHuMWmuFE2harnSdQlR5A1eGCFLsSYhxXa4zmX9RHKM9D7 0XP0GSz0C6P9YVQw+teFAbUWCayarV4PlNApdQ3XV2kw0/3h6SsE2IqhliZpzdMOAr3gnICoCWYMW1 WEHLTaVdnLRW4jmFKSoIWwEzVmxPI6w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:cc:references:to:subject:dkim-signature:from; bh=RZavx03IkKU4wqMgQCWSraKzkryjlEigcakmpzXw2Z8=; b=WpTSBRWF3RQjHb8baZ+Bv3xs0sxS7UCj9r1cy0gnns1H86++hpnDDUX5FyU7d9typnFxcCnf1CP0D Ru4V+LEvzyr6KexAp+qFaJJFWlVJeVc0od2BTZPQkyB6Uuj/btKt5Bh+QL8mva6EBlyydHzOYQ1G8n KlCkUKEjZIbVr8SQESYgDUDs8l3LA0C2g+fipZq298DzEqaUdMHodBcYbftjsxuhlE5oG5H6reM3Y/ uf85kNwhCLPiRRa9Gd5YOThKMtVv4B99JWl+fIs9zEd5LzqXWMeioL3zGLTQR1rmV3dhGqNP7cH3bA xvFnEUGLP//7r7vxTQPtncIG32uGx3Q==
ARC-Authentication-Results: i=1; outbound3.eu.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.155.78; dmarc=none header.from=hedeland.org; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:cc:references:to:subject:from; bh=RZavx03IkKU4wqMgQCWSraKzkryjlEigcakmpzXw2Z8=; b=eEd0gVA0kbpGN8vCRhGG3Kn8iGNMbOVYIGbs5BpBMPez5fr71kJGLNz7MIz4Agk7lbtkDt5Ze7aNm 6sbVSC6AUU+Dzry6hY/mARLbJzx0i2w0mnh3aB8sb9PtbtabxLmCftb5jdO8e6Sl5gL2opLH4PQXKx jK/Y8xbvFXLPd3qD9v/ar0lZs5MpGN7LtcB/FKo8Igmy4CV/+12uMg29cFfV/hgiPD5MaqMY5b5Lhk IvMd2VBc0wStijfLGtbkRXBJpgzdoligLeHJodfh7dwo8+kFjqZ37N4NjFAi5jsuPj1JAqhXGUScgk UEpD3Wssfazk+eoqGh6oMiSuS1h0x3w==
X-MHO-RoutePath: cGVyaGVkZWxhbmQ=
X-MHO-User: e0db71dc-61db-11e9-908b-352056dbf2de
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 81.228.155.78
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from hedeland.org (unknown [81.228.155.78]) by outbound3.eu.mailhop.org (Halon) with ESMTPSA id e0db71dc-61db-11e9-908b-352056dbf2de; Thu, 18 Apr 2019 13:14:21 +0000 (UTC)
Received: from pluto.hedeland.org (pluto.hedeland.org [10.1.1.5]) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPS id x3IDEKYQ072714 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 18 Apr 2019 15:14:20 +0200 (CEST) (envelope-from per@hedeland.org)
To: Ladislav Lhotka <lhotka@nic.cz>
References: <10d3413c-df96-6e7d-df82-5542bb02348d@spritelink.net> <20190401161321.seiodlfsmjjvjcp5@anna.jacobs.jacobs-university.de> <699d2c10-9b08-97f1-69d9-f66e3a83c643@spritelink.net> <20190417192013.zdhz4e5fwakm3x4a@anna.jacobs.jacobs-university.de> <048ecdb8-759e-2905-11a8-4c1caedc9371@spritelink.net> <20190417195437.gpnvh6woidqkkqtt@anna.jacobs.jacobs-university.de> <874l6vsqvi.fsf@nic.cz> <4ef7deb6-9904-6ce1-5b84-4cd18a48256d@spritelink.net> <9ffbaa76105f00cc57bf071d432299e55f024544.camel@nic.cz>
Cc: netmod@ietf.org
From: Per Hedeland <per@hedeland.org>
Message-ID: <ff7ac95a-3544-5485-c9d6-ff2b57ecf5cd@hedeland.org>
Date: Thu, 18 Apr 2019 15:14:20 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <9ffbaa76105f00cc57bf071d432299e55f024544.camel@nic.cz>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/DD3gPO0QEKg3VlGjfQEKn8Rhy-8>
Subject: Re: [netmod] 6991bis: address-with-prefix-length
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 18 Apr 2019 13:14:28 -0000
On 2019-04-18 10:41, Ladislav Lhotka wrote: > On Thu, 2019-04-18 at 10:09 +0200, Kristian Larsson wrote: >> >> On 2019-04-18 09:40, Ladislav Lhotka wrote: >>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes: >>> >>>> On Wed, Apr 17, 2019 at 09:35:51PM +0200, Kristian Larsson wrote: >>>>> I wonder though, isn't ipX-address-and-prefix-length the clearer name, >>>>> or if >>>>> we do want to shorten then ipX-address-and-plen. I think Martin stated >>>>> the >>>>> case for ipX-address-and-prefix but that is IMHO not the way this is >>>>> typically perceived by people. >>>>> >>>>> 1.2.3.4/24 >>>>> ^^^^^^^----- ipv4 address >>>>> ^^^-- ipv4 prefix length >>>>> >>>>> now, taking the prefix-length you know that 1.2.3 is the prefix but does >>>>> that mean the above is an IPv4 address and a prefix? Or is it just that >>>>> you >>>>> can infer the prefix from the above? It's just different ways of looking >>>>> at >>>>> it. My experience tells me ipX-address-and-prefix-length is the clearer >>>>> way >>>>> of conveying what this is. >>>>> >>>> >>>> I guess this is somewhat subjective. The prefix length is the number >>>> used to convey what the prefix is. So you are effectively defining an >>>> address and the prefix that this address belongs to. ;-) >>> >>> Strictly speaking, what is being defined by the number is a subnet mask. >> >> Heh, amazing how something so binary can turn out to be so subjective ;) >> This sort of turns into philosophical questions and I'm not sure we need >> to straighten it all out. I'd still call the prefix-length the >> prefix-length. It directly maps to the typical subnet mask >> representation and as you say, they can be thought of as the same thing. >> >> Does this mean you prefer ipX-address-and-subnet-mask? Because I think > > No. > >> that when someone reads that they are going to expect a value that looks >> like 1.2.3.4/255.255.255.0 rather than 1.2.3.4/24, which is why I still >> think ipX-address-and-prefix-length (possibly s/prefix-length/plen/) is >> the better name :) >> >> >>>> Given that we already have ip-prefix (which does as well use a prefix >>>> length to convey what the prefix is), it seems ip-address-and-prefix >>>> is more consistent with the existing RFC 6991 definitions. Being >>>> consistent with what we have was the main reason for me to prefer >>>> ip-address-and-prefix. >>> >>> I am not in favour of adding this type. Having ip-prefix next to >>> ip-address-and-prefix is confusing. >> >> Confusing or not, they are NOT interchangeable and actually do different >> things, which is why both are needed. There's plenty of precedence to > > I actually agree with you. It is a historical accident that these two different > things got mixed up (and some vendors contributed to this). I would argue that > > - IP prefix is a set of IP addresses, and as such can be thought of as a single > entity. > > - IP address and subnet mask/prefix are two separate things, the latter being an > instruction for routing to *other* destination addresses. Agreed - except the not entirely minor nit that the thing after the "/" is not a prefix but a *prefix-length*. Another way of putting it is that the IP address is a property of an interface, while the prefix-length or subnet mask is a property of the network that an interface is connected to. So this would clearly be two separate values "bundled" into one, and despite the similar syntax, it is radically different from the existing ip*-prefix types, which really do represent a single value - as Kristian pointed out earlier in the thread, the value is the initial N bits of a set of IP addresses - i.e. a prefix, as the name says. Thus if these types should be added, I don't think there is any reason to have a naming that is "consistent" with the existing ip*-prefix types - rather the naming should highlight the difference. And since the two values given are an IP address and a prefix-length, the natural choice would be ip*-address-and-prefix-length. Using ip*-address-and-prefix would be both inaccurate (neither of the two values is a prefix, although they can of course be combined to compute a one) and IMHO confusing due to the similarity in naming of the existing ip*-prefix types. If ip*-address-and-prefix-length is considered too verbose/clunky (although I don't know why this matters for a type name), a reasonable shorter form could IMHO be ip*-address-and-length - the prefix-length is of course a length, but it is not a prefix. Kristian's ip*-address-and-plen is of course even shorter, and could be considered to have more information, but I believe we generally try to avoid at least non-obvious abbreviations in the YANG modules. >> this, like postgresql has data types (cidr and inet) that map exactly to >> this behaviour, i.e. both store something that looks like an IP address >> and a prefix-length but one (cidr for pg) forces bits in host portion to >> be set to all 0. Python ipaddress has the same with IPv4Address and >> IPv4Interface. >> >> >>> Moreover, the most natural use for >>> this type would be the address specification in the "ietf-ip" module, >>> but we already have two leaves there: ip and prefix-length. >> >> Like I said in another mail, I think it is nice if these common >> datatypes become used by vendors and implementors. Many use proprietary > > That's fine, but we can also define a *grouping* of IP address and subnet prefix > length. And if we stick to the leaves "ip" and "prefix-length", this grouping > can be used in the next revision of RFC 7277. This would be my preferred > solution. From a data modelling perspective, having separate leafs for separate values should be the natural choice, and I don't think anyone is suggesting that the "bundled" type, if added, should be used in e.g. RFC 7277. A grouping could be nice, but it is still two separate leafs. This is no solution to Kristian's problem, which as far as I understand is about having a YANG model for existing devices that already *use* the "bundled" type, i.e. it "needs" to be a single leaf in the YANG module. Whether this need is enough motivation to actually add these types to ietf-inet-types I don't really know. There is no real cost in doing it per se, but it could have the negative consequence that it is taken as an encouragement/"blessing" to use these types when writing new modules that *don't* "need" to use them. Bad from a data modelling perspectve, and bad for the operational reasons that Martin gave an example of while I was writing this. But maybe the 'description' statement could warn against this. --Per
- [netmod] 6991bis: address-with-prefix-length Kristian Larsson
- Re: [netmod] 6991bis: address-with-prefix-length Juergen Schoenwaelder
- Re: [netmod] 6991bis: address-with-prefix-length Acee Lindem (acee)
- Re: [netmod] 6991bis: address-with-prefix-length Acee Lindem (acee)
- Re: [netmod] 6991bis: address-with-prefix-length Martin Bjorklund
- Re: [netmod] 6991bis: address-with-prefix-length Acee Lindem (acee)
- Re: [netmod] 6991bis: address-with-prefix-length Michael Rehder
- Re: [netmod] 6991bis: address-with-prefix-length Michael Rehder
- Re: [netmod] 6991bis: address-with-prefix-length Martin Bjorklund
- Re: [netmod] 6991bis: address-with-prefix-length Kristian Larsson
- Re: [netmod] 6991bis: address-with-prefix-length Kristian Larsson
- Re: [netmod] 6991bis: address-with-prefix-length Mahesh Jethanandani
- Re: [netmod] 6991bis: address-with-prefix-length Kristian Larsson
- Re: [netmod] 6991bis: address-with-prefix-length Acee Lindem (acee)
- Re: [netmod] 6991bis: address-with-prefix-length Mahesh Jethanandani
- Re: [netmod] 6991bis: address-with-prefix-length Kristian Larsson
- Re: [netmod] 6991bis: address-with-prefix-length Christian Hopps
- Re: [netmod] 6991bis: address-with-prefix-length Jeff Tantsura
- Re: [netmod] 6991bis: address-with-prefix-length tom petch
- Re: [netmod] 6991bis: address-with-prefix-length Juergen Schoenwaelder
- Re: [netmod] 6991bis: address-with-prefix-length Rob Wilton (rwilton)
- Re: [netmod] 6991bis: address-with-prefix-length Kristian Larsson
- Re: [netmod] 6991bis: address-with-prefix-length Rob Wilton (rwilton)
- Re: [netmod] 6991bis: address-with-prefix-length Martin Bjorklund
- Re: [netmod] 6991bis: address-with-prefix-length Juergen Schoenwaelder
- Re: [netmod] 6991bis: address-with-prefix-length Rob Wilton (rwilton)
- Re: [netmod] 6991bis: address-with-prefix-length Acee Lindem (acee)
- Re: [netmod] 6991bis: address-with-prefix-length Rob Wilton (rwilton)
- Re: [netmod] 6991bis: address-with-prefix-length tom petch
- Re: [netmod] 6991bis: address-with-prefix-length Rob Wilton (rwilton)
- Re: [netmod] 6991bis: address-with-prefix-length Reshad Rahman (rrahman)
- Re: [netmod] 6991bis: address-with-prefix-length Martin Bjorklund
- Re: [netmod] 6991bis: address-with-prefix-length Mahesh Jethanandani
- Re: [netmod] 6991bis: address-with-prefix-length Juergen Schoenwaelder
- Re: [netmod] 6991bis: address-with-prefix-length Christian Hopps
- Re: [netmod] 6991bis: address-with-prefix-length Alex Campbell
- Re: [netmod] 6991bis: address-with-prefix-length Christian Hopps
- Re: [netmod] 6991bis: address-with-prefix-length Kristian Larsson
- Re: [netmod] 6991bis: address-with-prefix-length Kristian Larsson
- Re: [netmod] 6991bis: address-with-prefix-length Juergen Schoenwaelder
- Re: [netmod] 6991bis: address-with-prefix-length Kristian Larsson
- Re: [netmod] 6991bis: address-with-prefix-length Juergen Schoenwaelder
- Re: [netmod] 6991bis: address-with-prefix-length Ladislav Lhotka
- Re: [netmod] 6991bis: address-with-prefix-length Kristian Larsson
- Re: [netmod] 6991bis: address-with-prefix-length Ladislav Lhotka
- Re: [netmod] 6991bis: address-with-prefix-length Juergen Schoenwaelder
- Re: [netmod] 6991bis: address-with-prefix-length Martin Bjorklund
- Re: [netmod] 6991bis: address-with-prefix-length Juergen Schoenwaelder
- Re: [netmod] 6991bis: address-with-prefix-length Martin Bjorklund
- Re: [netmod] 6991bis: address-with-prefix-length Per Hedeland
- Re: [netmod] 6991bis: address-with-prefix-length Martin Bjorklund
- Re: [netmod] 6991bis: address-with-prefix-length Juergen Schoenwaelder
- Re: [netmod] 6991bis: address-with-prefix-length Kristian Larsson
- Re: [netmod] 6991bis: address-with-prefix-length Kristian Larsson
- Re: [netmod] 6991bis: address-with-prefix-length Martin Bjorklund
- Re: [netmod] 6991bis: address-with-prefix-length Rob Wilton (rwilton)
- Re: [netmod] 6991bis: address-with-prefix-length tom petch
- Re: [netmod] 6991bis: address-with-prefix-length Ladislav Lhotka
- Re: [netmod] 6991bis: address-with-prefix-length Kristian Larsson