Re: [netmod] 6021 ipv4-prefix

Kristian Larsson <kristian@spritelink.net> Fri, 26 April 2019 15:16 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 5167E12043F for <netmod@ietfa.amsl.com>; Fri, 26 Apr 2019 08:16:21 -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 0NbPAgSLwlJS for <netmod@ietfa.amsl.com>; Fri, 26 Apr 2019 08:16:19 -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 D25A31204AD for <netmod@ietf.org>; Fri, 26 Apr 2019 08:15:52 -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 AEFF93F482 for <netmod@ietf.org>; Fri, 26 Apr 2019 17:15:49 +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> <24fff697cde3ac2e0c9a09cf2dfa1153ca61bd90.camel@nic.cz> <5d6b915d-2b6b-2844-6343-5e42abe01e3b@spritelink.net> <fad9a5504320aeca0c0bfbd5249c31ef20d3bcbd.camel@nic.cz>
From: Kristian Larsson <kristian@spritelink.net>
Message-ID: <23a278bd-f88c-afe7-4fb8-e0fa586bcd07@spritelink.net>
Date: Fri, 26 Apr 2019 17:15:49 +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: <fad9a5504320aeca0c0bfbd5249c31ef20d3bcbd.camel@nic.cz>
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/41PkjgSpkvOkshnd03jAakgibVQ>
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: Fri, 26 Apr 2019 15:16:22 -0000


On 2019-04-26 13:28, Ladislav Lhotka wrote:
> On Fri, 2019-04-26 at 12:56 +0200, Kristian Larsson wrote:
>>
>> On 2019-04-26 09:39, Ladislav Lhotka wrote:
>>> On Thu, 2019-04-25 at 23:51 +0200, Juergen Schoenwaelder wrote:
>>>> On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:
>>>>> 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.
>>>
>>> Agreed. The description only says (and only for ipv6-prefix
>>
>> I think it says it for ipv4-prefix too:
>>
>>     ...
>>     The canonical format of an IPv4 prefix has all bits of
>>     the IPv4 address set to zero that are not part of the
>>     IPv4 prefix.";
> 
> This defines the canonical format, and Juergen explained its role earlier in
> this thread.

Ah yes, I see now, you're right.



>> error? Ambiguity of what you are referencing makes it impossible for me
>> to parse your sentence. Please elaborate.
>>
>> I'm having trouble unifying the following:
>> - Juergen says RFC6021 and 6991 consider 2001:db8::1/64 to be valid
>> input that can safely be interpreted to mean 2001:db8::/64
>> - NSO instead treats 2001:db8::1/64 as a syntax error
>>
>> If 6021+6991 says it is valid input, then NSO must accept it, no?
> 
> I am not familiar with NSO. If it uses the the types from ietf-inet-types and
> refuses to accept such input values from a NETCONF/RESTCONF client, then it
> looks like a bug to me.

It does use these types so filing bug report I guess.

>>   
>> it does accept it, it must then store or at least always return it in
>> the canonical format?
> 
> RFC 7950 says in sec. 9.1 that the server MUST return values in the canonical
> form and that the values are conceptually stored in the canonical form (in a
> datastore).

Thanks for the reference, it helps! :)

Kind regards,
    Kristian.