Re: [mpls] Review of draft-ietf-mpls-lsp-ping-registries-update-01
Loa Andersson <loa@pi.nu> Thu, 02 April 2020 10:31 UTC
Return-Path: <loa@pi.nu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A3D3A0F70; Thu, 2 Apr 2020 03:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 EhcP-6GDvsNH; Thu, 2 Apr 2020 03:31:29 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D19B3A0F6D; Thu, 2 Apr 2020 03:31:29 -0700 (PDT)
Received: from [192.168.1.7] (unknown [122.2.101.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id C7FBE365214; Thu, 2 Apr 2020 12:31:23 +0200 (CEST)
To: adrian@olddog.co.uk, draft-ietf-mpls-lsp-ping-registries-update@ietf.org
Cc: mpls@ietf.org
References: <0f5701d60847$ed2a2230$c77e6690$@olddog.co.uk>
From: Loa Andersson <loa@pi.nu>
Message-ID: <021fe116-b0f2-25f4-b9ee-55bce86d61f5@pi.nu>
Date: Thu, 02 Apr 2020 18:31:20 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <0f5701d60847$ed2a2230$c77e6690$@olddog.co.uk>
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/mpls/bW58FWTSNrYs-Wy_gyrYLO_OpUY>
Subject: Re: [mpls] Review of draft-ietf-mpls-lsp-ping-registries-update-01
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2020 10:31:32 -0000
Adrian, This is to address your comment on "Private Use" and "Experimental Use", we will review the rest of the comments and update as needed. On 02/04/2020 01:06, Adrian Farrel wrote: > Hi all, > <snip> > > I have a number of small editorials and some larger questions and issues > set out below. I also have one question that has broader scope: > > For [IANA-MT] and [IANA-Sub-6] you now have both 'Private Use' and > 'Experimental Use'. I struggle to see how this makes sense. The uses > decribed in RFC 8126 are sufficiently similar that it is unusual to > have both categories defined for a single registry. I don't see anything > in the descriptive text in this document that makes clear why you need > both categories and how an implementation would decide which range to > select a code point from. <snip> You are right I've been struggling with these two type of code points also, but came to a slightly different conclusion than you did. RFC 8126 says: 4.1. Private Use Private Use is for private or local use only, with the type and purpose defined by the local site. No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways. IANA does not record assignments from registries or ranges with this policy (and therefore there is no need for IANA to review them) and assignments are not generally useful for broad interoperability. It is the responsibility of the sites making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). Examples: Site-specific options in DHCP [RFC2939] Fibre Channel Port Type Registry [RFC4044] TLS ClientCertificateType Identifiers 224-255 [RFC5246] 4.2. Experimental Use Experimental Use is similar to Private Use, but with the purpose being to facilitate experimentation. See [RFC3692] for details. IANA does not record assignments from registries or ranges with this policy (and therefore there is no need for IANA to review them) and assignments are not generally useful for broad interoperability. Unless the registry explicitly allows it, it is not appropriate for documents to select explicit values from registries or ranges with this policy. Specific experiments will select a value to use during the experiment. When code points are set aside for Experimental Use, it's important to make clear any expected restrictions on experimental scope. For example, say whether it's acceptable to run experiments using those code points over the open Internet or whether such experiments should be confined to more closed environments. See [RFC6994] for an example of such considerations. Example: Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers [RFC4727] It seems to me that "Private Use" are intended for private networks, where care is taken that the code points are not leaked into the Internet, but there the network itself is a production network, that will be run for an unforeseeable amount of time. And that "Experimental Use" code points are for short lived experiments. This is different. I'm very uncertain whether it is sufficiently different to motivate two different types. If the working group thinks there should be only one code point, I would argue to keep the code points for "Experimental Use". If we converge on "one type of code point only, I think this has a wider impact than this document, and we should probably update RFC 8126 (again). I'd like to invite comments on this on the mpls wg list. /Loa -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64
- [mpls] Review of draft-ietf-mpls-lsp-ping-registr… Adrian Farrel
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Carlos Pignataro (cpignata)
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Adrian Farrel
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Carlos Pignataro (cpignata)
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… tom petch
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Mach Chen
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Adrian Farrel
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Carlos Pignataro (cpignata)
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Adrian Farrel