Re: [netmod] 6991bis: address-with-prefix-length

Ladislav Lhotka <lhotka@nic.cz> Thu, 18 April 2019 08:41 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 AA031120094 for <netmod@ietfa.amsl.com>; Thu, 18 Apr 2019 01:41:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 GYyWiCRq6Dbr for <netmod@ietfa.amsl.com>; Thu, 18 Apr 2019 01:41:14 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 DBCC0120041 for <netmod@ietf.org>; Thu, 18 Apr 2019 01:41:13 -0700 (PDT)
Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:fc73:fa64:57e6:2115]) by mail.nic.cz (Postfix) with ESMTPSA id 7DB5E636E3 for <netmod@ietf.org>; Thu, 18 Apr 2019 10:41:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1555576871; bh=r6j7MPO0RM752HnOgxeSsBATtZx+LFIY3iDzGclsPn4=; h=From:To:Date; b=Pi0wOUW2kKjXAlEfT66goJxYhfQ3U9S5l+Lpmf8HM1N761f2P0ijlms79DRZ+S2vL h69Gvq2+rPDFHCCxPM05/u9Ff0pYtqe1WJYkzU7SNawSfSOKcyMJThubvIZliHd/rY x4ml7MytXorKVJZpLtR09NuqxhBAiGDf6uWYtmCs=
Message-ID: <9ffbaa76105f00cc57bf071d432299e55f024544.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: netmod@ietf.org
Date: Thu, 18 Apr 2019 10:41:11 +0200
In-Reply-To: <4ef7deb6-9904-6ce1-5b84-4cd18a48256d@spritelink.net>
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>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/_SQyyyAnSgb7GKv-pVo26C5Go9Q>
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 08:41:17 -0000

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.

>  
> 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.

Lada

>  
> models but at least using standard datatypes allows us to easily parse 
> the data into sensible datatypes on our end, like Python's 
> ipaddress.IPv4Interface.
> 
>    kll
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67