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

Kristian Larsson <kristian@spritelink.net> Wed, 17 April 2019 19:19 UTC

Return-Path: <kristian@spritelink.net>
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 C4C9A12003E for <netmod@ietfa.amsl.com>; Wed, 17 Apr 2019 12:19:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92DYsBrpz9aP for <netmod@ietfa.amsl.com>; Wed, 17 Apr 2019 12:19:42 -0700 (PDT)
Received: from Mail1.SpriteLink.NET (Mail1.spritelink.net [195.182.5.127]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D24120131 for <netmod@ietf.org>; Wed, 17 Apr 2019 12:19:42 -0700 (PDT)
Received: from mbp.local (c-bb9de253.014-82-73746f13.bbcust.telenor.se [83.226.157.187]) by Mail1.SpriteLink.NET (Postfix) with ESMTPSA id CB9613FA6C; Wed, 17 Apr 2019 21:19:38 +0200 (CEST)
To: Martin Bjorklund <mbj@tail-f.com>, rwilton@cisco.com, acee@cisco.com, netmod@ietf.org
References: <ebdf44cb1f47475fb44a51e01c9a809e@XCH-RCD-007.cisco.com> <ABA52E74-E523-4E83-90FA-581EAEA3657F@cisco.com> <ac7c6d8ab85446dca55d6878af2b065b@XCH-RCD-007.cisco.com> <20190402.202732.675061704668916086.mbj@tail-f.com> <20190402184813.dbfqm47zsxxqyhbs@anna.jacobs.jacobs-university.de>
From: Kristian Larsson <kristian@spritelink.net>
Message-ID: <0aaa5e37-79f8-497a-a008-01fc59e863a4@spritelink.net>
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: <20190402184813.dbfqm47zsxxqyhbs@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/h-fbaoAkw254VciaBa_unB2CmXY>
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: 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.

    kll