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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 18 April 2019 16:02 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 1615A12041B for <netmod@ietfa.amsl.com>; Thu, 18 Apr 2019 09:02:36 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 VuSrd6COwxK5 for <netmod@ietfa.amsl.com>; Thu, 18 Apr 2019 09:02:32 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A04C1203F9 for <netmod@ietf.org>; Thu, 18 Apr 2019 09:02:32 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 257E76B6; Thu, 18 Apr 2019 18:02:31 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id DqVSCt4J2TIq; Thu, 18 Apr 2019 18:02:30 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 18 Apr 2019 18:02:30 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id D3B6B200CC; Thu, 18 Apr 2019 18:02:30 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id xy1JaNYMSJ4M; Thu, 18 Apr 2019 18:02:30 +0200 (CEST)
Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 7F59C200CA; Thu, 18 Apr 2019 18:02:30 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Thu, 18 Apr 2019 18:02:29 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 9E7BB300866453; Thu, 18 Apr 2019 18:02:29 +0200 (CEST)
Date: Thu, 18 Apr 2019 18:02:28 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Per Hedeland <per@hedeland.org>
CC: Ladislav Lhotka <lhotka@nic.cz>, <netmod@ietf.org>
Message-ID: <20190418160228.6ggya5ay6vvil5wl@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Per Hedeland <per@hedeland.org>, Ladislav Lhotka <lhotka@nic.cz>, netmod@ietf.org
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> <ff7ac95a-3544-5485-c9d6-ff2b57ecf5cd@hedeland.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ff7ac95a-3544-5485-c9d6-ff2b57ecf5cd@hedeland.org>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/kNweKws5fhjdVlukGrOP-h0UX8g>
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 16:02:44 -0000

On Thu, Apr 18, 2019 at 03:14:20PM +0200, Per Hedeland wrote:

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

The property relevant for the network is the _prefix_, not the
prefix-length. The prefix-length 12 does not tell the system the
network prefix that is valid on the link, the prefix tells it. In
other words, you have a single value that gives you an address and a
prefix, hence ip-address-and-prefix. The question is whether we name
it according to the pieces that go into the combined value or whether
we name it according to the meaning of the combined value. What goes
in is "address + prefix length" and the meaning is "address + prefix".

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

Some bundled types are widely used and practically useful. See the uri
type, which is a big complicated combination of many different pieces.
Yes, filtering for a port number in a uri is likely not easy. These
are tradeoffs. The notion that "bundles types" are generally bad is I
think not true. I am not saying we should make it an art to create
"bundled types", I am just challenging the idea that they are
generally bad.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>