Re: [netmod] 6021 ipv4-prefix

"Rob Wilton (rwilton)" <rwilton@cisco.com> Thu, 02 May 2019 16:32 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 9466D120424 for <netmod@ietfa.amsl.com>; Thu, 2 May 2019 09:32:54 -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 k-j1VvSzq5uW for <netmod@ietfa.amsl.com>; Thu, 2 May 2019 09:32:53 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C9F120437 for <netmod@ietf.org>; Thu, 2 May 2019 09:32:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2477; q=dns/txt; s=iport; t=1556814762; x=1558024362; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4Tz0cSnGSwQWGOrouhSrNyKYYcNevW0YDVhJiOvwxu4=; b=SRf4ID8c+2w8hybDult0GVzs7hrkBM8ycfVioqidgthH8wWaYLOFM7wq bENQlHPBxNeKnxBkYQea6p4kvTSlFggaM4NOFyjST7PwR/0Z6knCHKMKl oMTESRhwH2lRnqGKX2Zy1ODzA9HBM+fH6Zw7e75nQDiVtqcalzYm1Zrye I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AHAAABG8tc/4MNJK1lDgsBAQEBAQEBAQEBAQEHAQEBAQEBgVMCAQEBAQELAYIQgW0oCpkpmFCBew4BAYRtAoYzIzYHDgEDAQEEAQECAQJtKIVKAQEBBDo/DAQCAQgRBAEBAR4QMh0IAgQBDQUIhSWvWIovgTIBi0sXgUA/hCM+hC6FeASLDAqcDgkCggmSOCOVQYwWlGMCERWBMCYNJIFWcBWDJ5AWO0ExkzyBIQEB
X-IronPort-AV: E=Sophos;i="5.60,422,1549929600"; d="scan'208";a="265906797"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 May 2019 16:32:41 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x42GWftC017486 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 May 2019 16:32:41 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 2 May 2019 11:32:40 -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; Thu, 2 May 2019 11:32:40 -0500
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Ladislav Lhotka <lhotka@nic.cz>, Mikael Abrahamsson <swmike@swm.pp.se>, Randy Presuhn <randy_presuhn@alumni.stanford.edu>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] 6021 ipv4-prefix
Thread-Index: AdT0l4zGpLjvUofYRmmSWqlDWwoAHABSPgGAAAHDNYAAA12WgAABgE0AAAD0FQAAAKy0gAF1SI2AAAERvAAAFIrFgAAG4xuAAADAhYAACALZAAAA/vaAAAK/LwAAATq3AAB768IgAAtOeIAACmVD4P//tfSAgABTU/D//+IngIAAUdRQ//+41wCAAFEEMP//wy6AABznDYAAAdzWgAAFM7gAAADJUIAAMdJaAAAE8bQAAAQJZoAABZuUgAAIJpwAAA58TQAAEqhFgAACMveAAALl7LA=
Date: Thu, 02 May 2019 16:32:40 +0000
Message-ID: <76a384e8d3f7487e865e7dd6ad0e4c4f@XCH-RCD-007.cisco.com>
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> <alpine.DEB.2.20.1905012137310.1824@uplift.swm.pp.se> <5CCA58DA.3030801@alumni.stanford.edu> <alpine.DEB.2.20.1905021330140.1824@uplift.swm.pp.se> <87v9yt58vi.fsf@nic.cz>
In-Reply-To: <87v9yt58vi.fsf@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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/-C4N3ZrMwTcYOLdrIJsCVWz9fMQ>
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: Thu, 02 May 2019 16:32:55 -0000


> -----Original Message-----
> From: netmod <netmod-bounces@ietf.org> On Behalf Of Ladislav Lhotka
> Sent: 02 May 2019 13:39
> To: Mikael Abrahamsson <swmike@swm.pp.se>; Randy Presuhn
> <randy_presuhn@alumni.stanford.edu>
> Cc: netmod@ietf.org
> Subject: Re: [netmod] 6021 ipv4-prefix
> 
> Mikael Abrahamsson <swmike@swm.pp.se> writes:
> 
> > On Wed, 1 May 2019, Randy Presuhn wrote:
> >
> >> Hi -
> >>
> >> On 5/1/2019 12:46 PM, Mikael Abrahamsson wrote:
> >> ....
> >>> 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?
> >>
> >> Such text would be an inappropriate constraint the server's internal
> >> representation.  We should only specify the externally-visible
> >> behaviour: that the reported value will be in the canonical format.
> >> Whether an implementation preserves extraneous cruft in its internal
> >> representation is purely an implementation decision, and not subject
> >> to standardization.
> >
> > I am talking about what goes on the wire. If the client does an
> > edit-config with ipv6-prefix 2001:db8::1/64, should the server convert
> > this into 2001:db8::/64 or throw an error on the edit-config operation.
> >
> > Jurgen seems to say it should convert it and not throw an error, and
> > I'd like text to say that indeed, this is proper behaviour. Nobody has
> > so far been able to tell me where this text currently is, so that's
> > why I'm
> 
> If we agree that a type defines the set of legal on-the-wire values (possibly
> modulo representation - JSON/XML/...), then section 4.2.2.1 in RFC 7950 says:
> 
> [A leaf instance] has exactly one value of a particular type ...
> 
> So why should a server throw an error if this is satisfied?

I don't think that there is text for a derived type that defines a canonical representation that:
(i) The server must internally treat the data as if it were in the canonical form
(ii) If the data is returned then it must be in the canonical form.

We should fix this in YANG 1.2 so this is clearer, but YANG 1.2 isn't going to be here for a while.  I don't think that we can do this as an erratum, but perhaps the 6991bis could, for each type state that the it is handled equivalently to RFC 7950 section 9.1.  Or would that just end up being noise?

Thanks,
Rob