Re: [netmod] 6021 ipv4-prefix

Mikael Abrahamsson <swmike@swm.pp.se> Wed, 01 May 2019 13:12 UTC

Return-Path: <swmike@swm.pp.se>
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 0E27A120128 for <netmod@ietfa.amsl.com>; Wed, 1 May 2019 06:12:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 XL3lXybrwysw for <netmod@ietfa.amsl.com>; Wed, 1 May 2019 06:12:50 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 335461200E3 for <netmod@ietf.org>; Wed, 1 May 2019 06:12:50 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 57CE7AF; Wed, 1 May 2019 15:12:47 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1556716367; bh=p4hZuR5uCT05xv3t7szuo8BWgbYhHdTU2lMbHIv9S9I=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=yfxHfKGnkL2F9XmrrdPO599OiGm8MKZJDWNGLsD3ThG/uNU0j/FLEZDL2wHKQdqQS wHTHPAEbPCxnI/pZr5YkyAJse09Rj1dLyfmUq3ajNq0emPgPqg4ztwPcE394XCGIUi a+zNuwP8CA2U6wSE4lhSfLC2N+rRH/oS6kuTk+/c=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 55A059F; Wed, 1 May 2019 15:12:47 +0200 (CEST)
Date: Wed, 1 May 2019 15:12:47 +0200 (CEST)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
cc: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
In-Reply-To: <20190501111712.347bpz26br6ox3jp@anna.jacobs.jacobs-university.de>
Message-ID: <alpine.DEB.2.20.1905011456580.1824@uplift.swm.pp.se>
References: <20190429134615.f32zkbia6fqwk3to@anna.jacobs.jacobs-university.de> <b404565930694fd8af93326b5e754a2b@XCH-RCD-007.cisco.com> <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>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/0Zi0Uint2JFe1PEOCbZAUUow54o>
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 13:12:53 -0000

On Wed, 1 May 2019, Juergen Schoenwaelder wrote:

> I personally do take the standpoint that irrelevant bits do not matter
> for the value of a prefix, i.e., 192.168.0.1/24 and 192.168.0.0/24 are
> two different representations for the same prefix. You seem to take
> the standpoint that 192.168.0.1/24 and 192.168.0.0/24 are different
> prefixes since bits that are irrelevant do differ.

No, I am saying this is underspecified or actually wrongly specified in 
the current documents + proposed text regarding what canonical format is 
and isn't, and how the server and clients handle this.

I am fine with the current proposed text to specify this for ipv6-prefix, 
but I am also pointing out that I think when YANG 1.2 is specced, the 
definition for "canonical format" needs more/changed text.

> Apparently there are different views that people have concerning
> prefixes. I think I have seen the following three alternatives:
>
> a) non-prefix bits that are set to one are illegal in a prefix
> b) non-prefix bits are irrelevant but they need to be preserved
> c) non-prefix bits are irrelevant, ignore them and the canonical
>   representation has non-prefix bits set to zero
>
> The RFC 6991 definitions do c). If there is consensus that c) is
> wrong, we need to deprecate the definitions and create new ones after
> finding consensus on either b) or a).

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.

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

I am fine with us continuing with c) above, I have long stopped arguing 
for anything else. What I am though saying is that I want 
https://tools.ietf.org/html/rfc7950#section-9.1 (or elsewhere) to have 
better text on this matter when the documents are revved next time.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se