Re: [netmod] 6021 ipv4-prefix

Mikael Abrahamsson <swmike@swm.pp.se> Wed, 01 May 2019 19:46 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 C67C61201B8 for <netmod@ietfa.amsl.com>; Wed, 1 May 2019 12:46:48 -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 5fEWt5LnKfkK for <netmod@ietfa.amsl.com>; Wed, 1 May 2019 12:46:46 -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 3575B12020A for <netmod@ietf.org>; Wed, 1 May 2019 12:46:46 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1125DAF; Wed, 1 May 2019 21:46:44 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1556740004; bh=QmqOVSzPwEjeRK/oAc/lBoa4Cs4UmxW2+aDeWm/kk5s=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=bNiQaOsaG3U4+1pL9sCISdyn9tpKhwVtykjr/2/nglbZqLbnburWEXfRYXl8dvdyK p9USR7xYbiPndj1NCiW4KDO2QK07dLrqu7UYzXn2ErdSvjEgLZpTjAgj4PM1SkUGc+ KTU++jezMUVIv9XeeIaeFHvy7BwHuqPgpO1Ogl/Y=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0D68D9F; Wed, 1 May 2019 21:46:44 +0200 (CEST)
Date: Wed, 01 May 2019 21:46:44 +0200
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: <20190501155321.v4qz6twsom45y62f@anna.jacobs.jacobs-university.de>
Message-ID: <alpine.DEB.2.20.1905012137310.1824@uplift.swm.pp.se>
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> <20190501155321.v4qz6twsom45y62f@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/WdUXc9PRxHo2ZCUuwHAs8xd61_o>
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 19:46:49 -0000

On Wed, 1 May 2019, Juergen Schoenwaelder wrote:

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

My disconnect is what the server should do when it encounters a value 
where the bits are non-zero.

Where is the text that tells the server implementor whether to throw an 
error when client commits non-zero bits, or to just throw the bits away 
and store the value in the canonical format?

> (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.)

I think this example is not relevant to this discussion. +7 and 7 doesn't 
change any integer backend representation. It's the same value.

Again, I have no problem with the server throwing away the bits at commit 
time, I just want it to be clear from the specs that this is the correct 
behaviour and what the server should do when the above text is not true:

"The IPv6 address should have all bits that do not belong
       to the prefix set to zero."

Throw an error or "fix it"? It seems it should "fix it", so we should have 
text that reflects this. I have no idea where this text should go, though.

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