Re: [netmod] 6021 ipv4-prefix

Kristian Larsson <kristian@spritelink.net> Fri, 26 April 2019 15:08 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 19D641204AD for <netmod@ietfa.amsl.com>; Fri, 26 Apr 2019 08:08:01 -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 bUuTcmDZSE4J for <netmod@ietfa.amsl.com>; Fri, 26 Apr 2019 08:07:57 -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 871BB12045D for <netmod@ietf.org>; Fri, 26 Apr 2019 08:07:57 -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 602FA3F482 for <netmod@ietf.org>; Fri, 26 Apr 2019 17:07:53 +0200 (CEST)
To: netmod@ietf.org
References: <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> <20190426111829.6wkml53a72swxt4b@anna.jacobs.jacobs-university.de>
From: Kristian Larsson <kristian@spritelink.net>
Message-ID: <56a9b51c-d143-6436-7ebe-8db5f66b2fff@spritelink.net>
Date: Fri, 26 Apr 2019 17:07:52 +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: <20190426111829.6wkml53a72swxt4b@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/2UhzuJoIxU6yCe2hHU9-sOklvuo>
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:08:11 -0000


On 2019-04-26 13:18, Juergen Schoenwaelder wrote:
> On Fri, Apr 26, 2019 at 12:56:57PM +0200, Kristian Larsson wrote:
>>
>> 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?
>>
>> Or does 6021+6991 say such a value MAY be treated as valid input? And if it
>> does accept it, it must then store or at least always return it in the
>> canonical format?
> 
> I do not find anything in 6021+6991 that says 2001:db8::1/64 is
> illegal input. If it were illegal, we would not need the definition of
> the canonical format that is in 6021+6991. Apparently text could have
> been more explicit but if you connect the bits and pieces, I think the
> conclusion must be that 2001:db8::1/64 is allowed input, i.e., you do
> not have to clear the bits that are irrelevant but the server will do
> this since it has to return the value in canonical format.

Thanks for your time in answering this Juergen, much appreciated.

I think the canonical representation is quite clear as is the part that 
the server must return data (and conceptually store) in canonical 
format. What is much less clear is the allowed input formats which then 
includes 2001:db8::1/64. I think it could be worthwhile to explicitly 
state this as it is a bit surprising. Unlike say the uintX types, there 
is no "lexical representation" section for ip-prefix (I presume because 
they are not basetypes and so the lexical presentation follows the base, 
string in this case + the pattern) that explains things in any detail. 
Do you think we could add some clarifications, perhaps to the 
description of the type about this? Or could we even add a lexical 
representation section with examples? Or just an examples section?

Kind regards,
    Kristian.