Re: [netmod] 6021 ipv4-prefix

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 01 May 2019 15:53 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 CBB9E12008A for <netmod@ietfa.amsl.com>; Wed, 1 May 2019 08:53:32 -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 WRl5NWFHjq6K for <netmod@ietfa.amsl.com>; Wed, 1 May 2019 08:53:30 -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 4F9D112006E for <netmod@ietf.org>; Wed, 1 May 2019 08:53:30 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id EA788DA9; Wed, 1 May 2019 17:53:28 +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 yJRJ7X7jKHMJ; Wed, 1 May 2019 17:53:28 +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; Wed, 1 May 2019 17:53:28 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id AA2E9200E0; Wed, 1 May 2019 17:53:28 +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 PLylnt3Tm1bh; Wed, 1 May 2019 17:53:28 +0200 (CEST)
Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (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 20049200DE; Wed, 1 May 2019 17:53:28 +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; Wed, 1 May 2019 17:53:27 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 6530A3008B81DA; Wed, 1 May 2019 17:53:24 +0200 (CEST)
Date: Wed, 1 May 2019 17:53:21 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Mikael Abrahamsson <swmike@swm.pp.se>
CC: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <20190501155321.v4qz6twsom45y62f@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Mikael Abrahamsson <swmike@swm.pp.se>, "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <0c4265d31adbf208a680f76216cc4bc42c766eae.camel@nic.cz> <959ed1a8092f4798ac0b923384962049@XCH-RCD-007.cisco.com> <20190429153643.oxfcq7ze6ttdihb4@anna.jacobs.jacobs-university.de> <alpine.DEB.2.20.1904300713100.3490@uplift.swm.pp.se> <20190430061737.vvxghxyacd57k73i@anna.jacobs.jacobs-university.de> <alpine.DEB.2.20.1904301038570.3490@uplift.swm.pp.se> <20190430090905.qsa3r4dwauilsxur@anna.jacobs.jacobs-university.de> <alpine.DEB.2.20.1905011051160.1824@uplift.swm.pp.se> <20190501111712.347bpz26br6ox3jp@anna.jacobs.jacobs-university.de> <alpine.DEB.2.20.1905011456580.1824@uplift.swm.pp.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.20.1905011456580.1824@uplift.swm.pp.se>
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/A-N4Y4n1gGPx1n5xOCKzJI0mBKE>
Subject: Re: [netmod] 6021 ipv4-prefix
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, 01 May 2019 15:53:33 -0000

On Wed, May 01, 2019 at 03:12:47PM +0200, Mikael Abrahamsson wrote:
> 
> I am fine with c), but I am also saying I disagree with your view that this
> this behaviour has been specified "since the beginning". This might have
> been obvious to you from the beginning, but it's not wrotten down properly
> (at least I haven't seen text that makes me clearly understand the expected
> behaviour). I think the text specifying what "canonical format is" referring
> to "same *value*" is wrong. +17 and 17 is the same integer, 192.168.0.1/24
> and 192.168.0.0/24 are not the same *value*. It's misleading to refer to the
> canonical form having the *same* *value* when we're throwing away
> information.
>

The basic disconnect here may be that for me the prefix is the value
while for you the value is the prefix plus the unused bits.

> If you write 2001:db8:0:1 as 2001:db8::1 then you're compressing the text
> form without throwing away actual information. It's the *same value* buth
> *different text representation*. 2001:db8::/64 and 2001:db8::1/64 is *not
> the same value*.

With your definition of 'value' it is not the same, with my definition
of 'value' it is the same.

For me, the value space of the ipv6-prefix type is the set of all
possible ipv6-prefixes. And with this, 2001:db8::/64 and
2001:db8::1/64 are two different textual representations that resolve
to the same prefix, i.e., the same value in the value space. I would
go even further and make the following distinction between

- textual representations of values of a type
- the value space of a type
- internal representations of values of a type

I think we have this discussion because you likely map the textual
representations of a prefix into an internal representation that can
capture details that are (in my model) not relevant for the value
space itself.

(Even for the case of simple signed integers, it depends on my internal
number representation whether normalizing +7 to 7 causes a change of
the internal representation or not.)

Once we add support to YANG for binary encodings, we will get
additional complexity since we will map the value space to multiple
'external' representations and for the same type (=value space), there
may be differences how 'external' representations map to the value
space. A binary representation of an IPv6 address may have a 1:1
mapping to the value space while our textual representation already
has a n:1 relationship. Or we go into the direction to require that
all 'external' representations must only have 1:1 relationships, i.e.,
only textual representations in canonical format will be legal. We
will see...

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