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

Kristian Larsson <> Wed, 17 April 2019 19:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4C9A12003E for <>; Wed, 17 Apr 2019 12:19:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 92DYsBrpz9aP for <>; Wed, 17 Apr 2019 12:19:42 -0700 (PDT)
Received: from Mail1.SpriteLink.NET ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 39D24120131 for <>; Wed, 17 Apr 2019 12:19:42 -0700 (PDT)
Received: from mbp.local ( []) by Mail1.SpriteLink.NET (Postfix) with ESMTPSA id CB9613FA6C; Wed, 17 Apr 2019 21:19:38 +0200 (CEST)
To: Martin Bjorklund <>,,,
References: <> <> <> <> <>
From: Kristian Larsson <>
Message-ID: <>
Date: Wed, 17 Apr 2019 21:19:38 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [netmod] 6991bis: address-with-prefix-length
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Apr 2019 19:19:44 -0000

On 2019-04-02 20:48, Juergen Schoenwaelder wrote:
> On Tue, Apr 02, 2019 at 08:27:32PM +0200, Martin Bjorklund wrote:
>>> I
>>> think that I also now agree with Martin that this is really merging
>>> two values into one leaf.
>> And for the record (again, perhaps), I think this is a bad idea in
>> general, and I am not sure an exception is needed in this case.
> This format is used and convenient where it is used (and I do
> sometimes miss it at other places where it is not used). I would not
> be religious about this combination of values. Note that even
> ip-prefix is a combination of a prefix length and an address
> 'pattern'. So ip-address-and-prefix is actually three values in
> one. ;-)

I agree that it's useful and please avoid religious. Though I think 
ip-address-and-prefix-length is still two values at max. ip-prefix is 
two values in the common storage form since we typically use a fixed 
length 32 bit integer for storing an IP address and then need a second 
field to tell us how many bits are significant for the prefix. A more 
natural way of storing it could have used a variable length field in 
which case a /8 network really would only be 8 bit long (but then again, 
variable length field typically are stored as TLV or LV, so two values 
again... but way below our abstraction level now).

> We have yang:date-and-time, a combination of date and time (we are
> adding these right now). yang:date-and-time actually clumps together
> year, month, day, hours, minutes, seconds, optional subseconds,
> timezone. For me, it seems useful to adopt commonly used formats.

This rings very true to me. Even if the IETF interfaces-ip model doesn't 
use these types, they are being used by Cisco, Juniper etc in their 
proprietary models, it's just that the type is currently string or 
something like that - if they could use a common IETF data type then it 
would be easier to cast this to a proper data type in a programming 
language, so like when you parse the config you'd get a Python 
ipaddress.IPv4Network object out of this or similar.