Re: [netmod] 6021 ipv4-prefix

Ladislav Lhotka <lhotka@nic.cz> Mon, 29 April 2019 15:51 UTC

Return-Path: <lhotka@nic.cz>
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 5F8ED12004E for <netmod@ietfa.amsl.com>; Mon, 29 Apr 2019 08:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 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_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 jARmLqYy20Y6 for <netmod@ietfa.amsl.com>; Mon, 29 Apr 2019 08:50:58 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 010CF120086 for <netmod@ietf.org>; Mon, 29 Apr 2019 08:50:58 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 90E99630D2; Mon, 29 Apr 2019 17:50:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1556553055; bh=SgRA+O1BVg8bJpkbo3sgJeysHAzeCQ0kU50ydv59dWM=; h=From:To:Date; b=Pb0AOJhqBwgVfqOqW1tW/HF9Lrn5k+CGi4PUHv+Kl7nsZWh48dBDoVQlCh+IKIGmf ZTFpmPg6tZ2qeFrBQNfuym4VDgSQcHRNi4jeeL5aGFYVcR0SV8XCY3JCi0QbjHZOtC xIWIQLf2bH/CMn+Hb/8oc+ZYLstRgGvINf4+dmNc=
Message-ID: <def7cc0f4a4c9b3c2ef09bc4b4f6eb4353141c72.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
Cc: NETMOD WG <netmod@ietf.org>
Date: Mon, 29 Apr 2019 17:50:56 +0200
In-Reply-To: <fb1edb59b75745438bfd6d1c4f293d85@XCH-RCD-007.cisco.com>
References: <20190426111829.6wkml53a72swxt4b@anna.jacobs.jacobs-university.de> <56a9b51c-d143-6436-7ebe-8db5f66b2fff@spritelink.net> <20190426153623.wpb4owuqsdfjc5q5@anna.jacobs.jacobs-university.de> <B2FAF932-0BD9-42BF-BBCA-38A37F6B33C9@cisco.com> <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> <3ec0ba130610b31709e1c511e014f9574fccd846.camel@nic.cz> <fb1edb59b75745438bfd6d1c4f293d85@XCH-RCD-007.cisco.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/lvXkzQtaUSw5MurtJ8hTZkCY3-Y>
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:51:01 -0000

On Mon, 2019-04-29 at 15:32 +0000, Rob Wilton (rwilton) wrote:
> BTW, did you mean to drop the alias?

No, my frequent mistake. :-( Putting it back, please see below.

> 
> > -----Original Message-----
> > From: Ladislav Lhotka <lhotka@nic.cz>
> > Sent: 29 April 2019 16:15
> > To: Rob Wilton (rwilton) <rwilton@cisco.com>
> > Subject: Re: [netmod] 6021 ipv4-prefix
> > 
> > On Mon, 2019-04-29 at 14:53 +0000, Rob Wilton (rwilton) wrote:
> > > Hi Lada,
> > > 
> > > > -----Original Message-----
> > > > From: netmod <netmod-bounces@ietf.org> On Behalf Of Ladislav Lhotka
> > > > Sent: 29 April 2019 15:24
> > > > To: netmod@ietf.org
> > > > Subject: Re: [netmod] 6021 ipv4-prefix
> > > > 
> > > > On Mon, 2019-04-29 at 14:02 +0000, Rob Wilton (rwilton) wrote:
> > > > > > -----Original Message-----
> > > > > > From: Juergen Schoenwaelder
> > > > > > <j.schoenwaelder@jacobs-university.de>
> > > > > > Sent: 29 April 2019 14:46
> > > > > > To: Rob Wilton (rwilton) <rwilton@cisco.com>
> > > > > > Cc: Acee Lindem (acee) <acee@cisco.com>om>; netmod@ietf.org
> > > > > > Subject: Re: [netmod] 6021 ipv4-prefix
> > > > > > 
> > > > > > On Mon, Apr 29, 2019 at 01:33:22PM +0000, Rob Wilton (rwilton)
> > > > > > wrote:
> > > > > > > But I'm not convinced that allowing ipv4-prefix values in the
> > > > > > > non- canonical
> > > > > > format is necessarily the right thing to do.  If we were
> > > > > > defining these as a new type today then would we make the same
> > > > > > choice of typedef definition?
> > > > > > > Or is a significant part of your proposal/reasoning to ensure
> > > > > > > backwards
> > > > > > compatibility with what we have today?
> > > > > > 
> > > > > > I am trying to clarify what the existing definition says since
> > > > > > there apparently have been different interpretations.
> > > > > 
> > > > > Given the definition of ipv6-prefix already contains:
> > > > > 
> > > > >       " The IPv6 address should have all bits that do not belong
> > > > >        to the prefix set to zero."
> > > > > 
> > > > > I think that a better solution might be to add the equivalent text
> > > > > to the ipv4-prefix definition:
> > > > > 
> > > > >       " The IPv4 address should have all bits that do not belong
> > > > >        to the prefix set to zero."
> > > > 
> > > > But this still essentially permits the client to send a value with
> > > > those bits set, and the server has to be prepared to handle it.
> > > 
> > > My aim with this text is to:
> > >  - encourage clients to use canonical format, since that seems to
> > > cause the least problems.
> > 
> > It would be good to clarify the implications of sending non-canonical
> > values, and
> > perhaps give recommendations, but not in the description of a particular
> > derived
> > type. I guess it also depends on the character of the client - a curl script
> > cannot
> > be expected to perform extensive normalization.
> 
> I think, for ipv4-prefix, that an existing server could reasonably do any of
> the following:
>  - accept non canonical values and convert them to the canonical format
> internally, or just reject non canonical values
>  - return the canonical value or return the exact value that was configured by
> the client.
>  
> RFC 7950 states that the canonical value is returned for native YANG
> types.  It doesn't say anything about returning canonical values defined in a 

Hmm, my understanding so far has been that the rules for lexical/canonical
values work the same for both built-in an derived types. It is true that these
concepts are defined inside Section 9 (Built-In Types) but I am not sure if this
was really intended to be limited to built-in types. For one, using IP addresses
as list keys would then be impossible.

Lada

> typedef description statements.
> 
> > >  - align the v4 and v6 definitions.
> > 
> > Agreed.
> > 
> > >  - retain the existing flexibility for servers to choose what they
> > > support, noting that any change in behaviour here will be non-backwards
> > compatible.
> > 
> > I am not sure that I understand what you mean. Are you saying that a server
> > can
> > choose to reject a uint8 value like "+7" as invalid? Such a server is IMO
> > non-
> > compliant.
> 
> A server should accept "+7" and return "7", as per RFC 7950.
> 
> I think that this question is about derived type definitions, and the
> ipv4/ipv6-prefix type definition in particular.
>  
> Thanks,
> Rob
> 
> 
> > Lada
> > 
> > > Thanks,
> > > Rob
> > > 
> > > 
> > > > If the goal is to get rid of the difference between ipv4- and
> > > > ipv6-prefix, which makes sense, then I prefer to remove this
> > > > sentence from ipv6-prefix.
> > > > Lada
> > > > 
> > > > > Thanks,
> > > > > Rob
> > > > > 
> > > > > 
> > > > > > /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/>
> > > > > 
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > --
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > 
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67