Re: [netmod] 6021 ipv4-prefix

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 29 April 2019 15:36 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 ACB461200F9 for <netmod@ietfa.amsl.com>; Mon, 29 Apr 2019 08:36:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 7_MjImwCplsa for <netmod@ietfa.amsl.com>; Mon, 29 Apr 2019 08:36:47 -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 0B45D120025 for <netmod@ietf.org>; Mon, 29 Apr 2019 08:36:47 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A1306B46; Mon, 29 Apr 2019 17:36:45 +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 LqxiJnn6mmb5; Mon, 29 Apr 2019 17:36:45 +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; Mon, 29 Apr 2019 17:36:45 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 61541200E0; Mon, 29 Apr 2019 17:36:45 +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 quogG8SFgaXO; Mon, 29 Apr 2019 17:36:45 +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 E794C200DF; Mon, 29 Apr 2019 17:36:44 +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; Mon, 29 Apr 2019 17:36:44 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 03CD430089FFC4; Mon, 29 Apr 2019 17:36:43 +0200 (CEST)
Date: Mon, 29 Apr 2019 17:36:43 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
CC: Ladislav Lhotka <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <20190429153643.oxfcq7ze6ttdihb4@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, Ladislav Lhotka <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org>
References: <20190426173014.klub4kxbzucgfmyc@anna.jacobs.jacobs-university.de> <f582ccc854ae446291d6020822fae9dd@XCH-RCD-007.cisco.com> <20190429100213.vukmmbdsz5zlw6w5@anna.jacobs.jacobs-university.de> <bbf252aaca86418ca80b3bf04a910aff@XCH-RCD-007.cisco.com> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <959ed1a8092f4798ac0b923384962049@XCH-RCD-007.cisco.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB01.jacobs.jacobs-university.de (10.70.0.120) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/8-bUSCWYJ3e0BeVf3SHeS5L8Wik>
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: Mon, 29 Apr 2019 15:36:49 -0000

On Mon, Apr 29, 2019 at 02:53:40PM +0000, Rob Wilton (rwilton) wrote:
> 
> My aim with this text is to:
>  - encourage clients to use canonical format, since that seems to cause the least problems.
>  - align the v4 and v6 definitions.
>  - retain the existing flexibility for servers to choose what they support, noting that any change in behaviour here will be non-backwards compatible.
>

The 'should' text is of limited value since the 'should' text does not
change what is allowed. I hope the newly proposed text spells out more
clearly that a server turns values into canonical format that are not
in canonical format and implementors can then conclude that using
canonical format in the first place is perhaps a good idea - or it is
convenient to have the conversion done by the server.

Note that the canonical format for IPv6 prefixes has much more to it
than setting the non-prefix bits to zero, see RFC 5952 for all the
details that affect the text representation of the address part.

I believe we are not in the position to tell clients that they should
or should not do. If I push the config value 2001:DB8::/64 (since my
database has values stored using uppercase characters) and it comes
back as 2001:db8::/64, then so be it; it might be convenient for me to
be allowed to push 2001:0DB8:0:0:0:0:0:0/64 and not having to worry
about how to produce the RFC 5952 representation in my glue code that
ties into my database backend. Why would we say clients should not
send values in non-canonical format? Why would we say clients have to
take the pain to ensure everything is turned into 2001:db8::/64 (to
continue the example) before sending values to the server?

Note that the ipv6-address definition has the same canonicalization
properties (if we consider the address portion of ipv6-prefix) and
there is no text saying you should send 2001:db8::1 instead of
2001:0DB8::1.

I think our mission instead is to make it clear what the canonical
format is and that servers will turn lexical representations they
accept into canonical lexical representation. This way people can take
informed decisions about what is appropriate for their specific
clients.

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