Re: [netmod] 6021 ipv4-prefix

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 02 May 2019 11:35 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 145FC120112 for <netmod@ietfa.amsl.com>; Thu, 2 May 2019 04:35:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=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 m95eHtWasJig for <netmod@ietfa.amsl.com>; Thu, 2 May 2019 04:35:47 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 641571200B9 for <netmod@ietf.org>; Thu, 2 May 2019 04:35:47 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id AABBEB0; Thu, 2 May 2019 13:35:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1556796943; bh=/gxpuwQZkrpDLkK35ByIQiolxS3HJpUd+lRWu5k0a30=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Zk/VZQCBBFaHqlJNR9+o4osumu2xzcfyrEY1rMp63qfOQXtdi4rUrJmtvdOtjyswq GK+OTPBqxfRkRNR2vb0rjUUCdpfjsGnY5W9ugGdU1q1N3l8u5/dOadVIThg8VKj+YH eLO+7CMeqVAiueTWqvo8sjZwyYn3KAlrr/F83Zf8=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A8E3FAF; Thu, 2 May 2019 13:35:43 +0200 (CEST)
Date: Thu, 2 May 2019 13:35:43 +0200 (CEST)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Randy Presuhn <randy_presuhn@alumni.stanford.edu>
cc: netmod@ietf.org
In-Reply-To: <5CCA58DA.3030801@alumni.stanford.edu>
Message-ID: <alpine.DEB.2.20.1905021330140.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> <alpine.DEB.2.20.1905012137310.1824@uplift.swm.pp.se> <5CCA58DA.3030801@alumni.stanford.edu>
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/5YM7BjTNOZ6P0QWCSFqToqU7q90>
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 11:35:50 -0000

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 
asking for it to be added. Either this should go into an update to 
https://tools.ietf.org/html/rfc7950#section-9.1 or it should go into each 
and every definition of types (or both of them).

>> It seems it should "fix it", so we should
>> have text that reflects this.
>
> False dichotomy.  An implementation might actually preserve
> those bits, though of course they'd never be seen again (at
> least not on a netconf interface) since the netconf server
> will always behave as though the value were in its canonical
> form, regardless of the internal representation.

Again, I am talking about what goes on the wire, what is seen when issuing 
"get" or "edit-config" etc.

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