Re: [netmod] 6021 ipv4-prefix

"Rob Wilton (rwilton)" <rwilton@cisco.com> Mon, 29 April 2019 15:58 UTC

Return-Path: <rwilton@cisco.com>
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 CECE6120374 for <netmod@ietfa.amsl.com>; Mon, 29 Apr 2019 08:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 g1KDyVVWQNA3 for <netmod@ietfa.amsl.com>; Mon, 29 Apr 2019 08:58:06 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656391201BE for <netmod@ietf.org>; Mon, 29 Apr 2019 08:58:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9344; q=dns/txt; s=iport; t=1556553486; x=1557763086; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BiYXFRa8MjKuKB3I29XApddoeXlSgjttYvgVltq/EDw=; b=HFquAs4zxpHExiPf+psC8WcP9G6G7wP015RofqS/bDk1yAa3AKHaU0O7 EgwPt+3LE1ABvA8StzcPqYzZwS1UTkHfbfdmX1HTC4ZjZZvsxmZEkqYaV 8EhA6iovWk7dfpPDjIYuprRCgWFHL6oIEyeCqwAz0BuqqBvLCYlbdy7u7 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAAFHsdc/4MNJK1jAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYIQaIEEKAqEBogcjRKYUIF7DgEBGAu?= =?us-ascii?q?EBEYCF4YbIzQJDgEDAQEEAQECAQJtHAyFSgEBAQMBAQEhEToLDAICAgEIEAE?= =?us-ascii?q?EAQEBAgImAgICGQwLFQgIAgQOBQgTgwiBeQ8PrX6BL4olBgWBBicBi0kXgUA?= =?us-ascii?q?/hCM+gmEBAYE6ES0KJoJDglgEin0yggmMO40ECQKCCZIrI4INhjSJFINSoFo?= =?us-ascii?q?CERWBMB84gVZwFTuCbIIbF4N/hGGFP0ExkW6BMYEhAQE?=
X-IronPort-AV: E=Sophos;i="5.60,410,1549929600"; d="scan'208";a="551083559"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Apr 2019 15:58:04 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x3TFw4ro010677 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Apr 2019 15:58:04 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Apr 2019 10:58:03 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Mon, 29 Apr 2019 10:58:03 -0500
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Ladislav Lhotka <lhotka@nic.cz>
CC: NETMOD WG <netmod@ietf.org>
Thread-Topic: [netmod] 6021 ipv4-prefix
Thread-Index: AdT0l4zGpLjvUofYRmmSWqlDWwoAHABSPgGAAAHDNYAAA12WgAABgE0AAAD0FQAAAKy0gAF1SI2AAAERvAAAFIrFgAAG4xuAAADAhYAACALZAAAA/vaAAAK/LwAAATq3AAB768IgAAtOeIAACmVD4P//tfSAgABTU/D//+IngIAAUdRQ//+41wCAAFEEMP//vSgAAApr51AACSwEAAAcvraw
Date: Mon, 29 Apr 2019 15:58:03 +0000
Message-ID: <0875c548bfb84cf2b0ecf838f1541572@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> <def7cc0f4a4c9b3c2ef09bc4b4f6eb4353141c72.camel@nic.cz>
In-Reply-To: <def7cc0f4a4c9b3c2ef09bc4b4f6eb4353141c72.camel@nic.cz>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.63.23.60]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/0r6Uu3zOhvmPccGtxAFGroSXqT8>
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:58:09 -0000


> -----Original Message-----
> From: Ladislav Lhotka <lhotka@nic.cz>
> Sent: 29 April 2019 16:51
> To: Rob Wilton (rwilton) <rwilton@cisco.com>
> Cc: NETMOD WG <netmod@ietf.org>
> Subject: Re: [netmod] 6021 ipv4-prefix
> 
> 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.

But according to RFC-7950, from a language POV, I think that it is reasonable to interpret the canonical format of ipv4-prefix to match that of its base YANG type, i.e. string.

9.4.2.  Canonical Form

   The canonical form is the same as the lexical representation.  No
   Unicode normalization of string values is performed.

Section "9.1.  Canonical Representation" does not state that the canonical format of a type may be overridden by a description statement.

Thanks,
Rob


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