Re: [netmod] 6021 ipv4-prefix

Mikael Abrahamsson <swmike@swm.pp.se> Wed, 01 May 2019 08:55 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 33CB6120074 for <netmod@ietfa.amsl.com>; Wed, 1 May 2019 01:55:45 -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 ZtYtgmq06OVq for <netmod@ietfa.amsl.com>; Wed, 1 May 2019 01:55:42 -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 49179120041 for <netmod@ietf.org>; Wed, 1 May 2019 01:55:41 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 809D8AF; Wed, 1 May 2019 10:55:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1556700938; bh=vdKZoq6fhvu+5YBvKHaBm8PbA+MqVBiR9XzAR4HclqA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=LZSOTG2r98r9w+5QnS/eNJ5cXQWX7p05QZeRbmmuhFudq91dPaV+dCjgcw6fJTHcV iQm0+NzT14lyDdYM3Gjy9831hWpG9ltmSyzY8Ut4AlHZ6IwYcpwwJd8FkFLt+nhJLi VNaGlC/ETCewYuKQ5XpmEAsgoqrGx3e4A4wE8jTU=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7D66C9F; Wed, 1 May 2019 10:55:38 +0200 (CEST)
Date: Wed, 1 May 2019 10:55:38 +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: <20190430090905.qsa3r4dwauilsxur@anna.jacobs.jacobs-university.de>
Message-ID: <alpine.DEB.2.20.1905011051160.1824@uplift.swm.pp.se>
References: <20190429103451.yink4bdvvmlh7ohe@anna.jacobs.jacobs-university.de> <c03aa9a27ed544c5be88fd0750d782e3@XCH-RCD-007.cisco.com> <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>
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/6o_W5-I4_DMrERwTf61iY6wwhPo>
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 08:55:45 -0000

On Tue, 30 Apr 2019, Juergen Schoenwaelder wrote:

> On Tue, Apr 30, 2019 at 10:46:34AM +0200, Mikael Abrahamsson wrote:
>> On Tue, 30 Apr 2019, Juergen Schoenwaelder wrote:
>>
>>> I think we go in circles in this thread and I will stop explaining
>>> things again and again. I suggest people look at the next revision
>>> and if anything remains unclear, people can send concrete edit
>>> proposals.
>>
>> You don't have to explain it. Let me try in a different way.
>>
>> https://tools.ietf.org/html/rfc7950#section-9.1
>>
>> "For most types, there is a single canonical representation of the
>>    type's values."
>>
>> Is it generally ok that the canonical value potentially represents a
>> different bit field/value than what the client sent?
>
> Yes. I explained that the canonicalization of IPv6 addresses is much
> more involved than clearing some unused bits in an IPv6 prefix.

The canonicalization of IPv6 addresses doesn't change the resulting 128 
bit pattern. Canonicalization of IPv6-prefix *does* change the bit 
pattern. Also, it doesn't say in 
https://tools.ietf.org/html/rfc7950#section-9.1 whether the server should 
accept bit-fields that do not adhere to the canonical representation or 
not.

So while you seem to think I am not reading your text, it seems to me 
you're not reading what I am saying either. You're not responding to the 
points I am trying to make anyway.

https://tools.ietf.org/html/rfc7950#section-9.1

This talks about *values*. If you drop bits in IPv6-prefix, then it's not 
the same *value* anymore.

So https://tools.ietf.org/html/rfc7950#section-9.1 should be changed 
in future revisions to avoid confusion.

> We are not 'fixing' anything. The canonical format is nothing new. The
> text aims at explaining things better. Yes, there are many more types
> that have a canonical representation. Read the other email messages in
> this thread or simply search for 'canonical' in the type definitions.
>
> I think the descriptions are actually all quite clear (but then I am
> biased of course).

There are lots of implications that are *not* clear in 
https://tools.ietf.org/html/rfc7950#section-9.1.

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