Re: [netmod] 6021 ipv4-prefix

Kristian Larsson <kristian@spritelink.net> Thu, 25 April 2019 22:07 UTC

Return-Path: <kristian@spritelink.net>
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 B356C120343 for <netmod@ietfa.amsl.com>; Thu, 25 Apr 2019 15:07:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 OgLcr2HJ4DyL for <netmod@ietfa.amsl.com>; Thu, 25 Apr 2019 15:07:39 -0700 (PDT)
Received: from Mail1.SpriteLink.NET (Mail1.SpriteLink.NET [195.182.5.127]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A34120354 for <netmod@ietf.org>; Thu, 25 Apr 2019 15:07:35 -0700 (PDT)
Received: from mbp.local (c-bb9de253.014-82-73746f13.bbcust.telenor.se [83.226.157.187]) by Mail1.SpriteLink.NET (Postfix) with ESMTPSA id 3518A3F5C3 for <netmod@ietf.org>; Fri, 26 Apr 2019 00:07:32 +0200 (CEST)
To: netmod@ietf.org
References: <003301d4f498$4f593640$ee0ba2c0$@gmail.com> <alpine.DEB.2.20.1904180906360.3490@uplift.swm.pp.se> <20190418080643.gcdi5x4dtn64adwc@anna.jacobs.jacobs-university.de> <alpine.DEB.2.20.1904181128480.3490@uplift.swm.pp.se> <20190418102604.y5wyqflcudiywj2i@anna.jacobs.jacobs-university.de> <alpine.DEB.2.20.1904181251000.3490@uplift.swm.pp.se> <20190418111241.5csf5kkgwgxwtsnm@anna.jacobs.jacobs-university.de> <227a2452-69f9-6786-2643-822e70dc636d@spritelink.net> <20190425215134.pabdl3bbbjoivbaj@anna.jacobs.jacobs-university.de>
From: Kristian Larsson <kristian@spritelink.net>
Message-ID: <01894841-bbf5-ce19-1a60-4737bc717311@spritelink.net>
Date: Fri, 26 Apr 2019 00:07:31 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <20190425215134.pabdl3bbbjoivbaj@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/w440moOiJYYoc7tDPJDDPzLDdVA>
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, 25 Apr 2019 22:07:41 -0000


On 2019-04-25 23:51, Juergen Schoenwaelder wrote:
> On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:
>>
>>
>> On 2019-04-18 13:12, Juergen Schoenwaelder wrote:
>>> On Thu, Apr 18, 2019 at 12:53:22PM +0200, Mikael Abrahamsson wrote:
>>>> On Thu, 18 Apr 2019, Juergen Schoenwaelder wrote:
>>>>> On Thu, Apr 18, 2019 at 11:43:05AM +0200, Mikael Abrahamsson wrote:
>>>>> +17.4 is not an integer, so this is an error (not because of the + but
>>>>> because of the . followed by additional digits). +17 is I think a valid
>>>>> integer value but the + will be dropped in the canonical representation.
>>>>
>>>> Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of the
>>>> prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be rounded
>>>> if an integer input is expected?
>>>
>>> The non-prefix bits are irrelevant for the prefix and the canonical
>>> format has the non-prefix bits all set to zero. I understand that you
>>> prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
>>> consider this as valid input that can be safely interpreted to mean
>>> 2001:db8::0/64.
>>
>> Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax
>> error, is that implementation incorrect?
>>
> 
> I think so. The types do not require that non-prefix bits are zero
> when a value is received. However, a server must report the canonical
> value, in this case 2001:db8::/64.

Cisco NSO treats 2001:db8::1/64 as a syntax error for a leaf of type 
ip-prefix (or ip6-prefix).

It would be interesting to hear Martins opinion on this.

Kind regards,
    Kristian.