Re: [mpls] Erik Kline's No Objection on draft-ietf-mpls-lsp-ping-registries-update-08: (with COMMENT)

Loa Andersson <loa@pi.nu> Mon, 15 February 2021 10:38 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 B715E3A1108; Mon, 15 Feb 2021 02:38:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.001, 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 PqBd0zzx5LQB; Mon, 15 Feb 2021 02:38:33 -0800 (PST)
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 5F10E3A1106; Mon, 15 Feb 2021 02:38:33 -0800 (PST)
Received: from [192.168.1.11] (unknown [124.104.184.212]) (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 3C2C1326109; Mon, 15 Feb 2021 11:38:28 +0100 (CET)
To: Erik Kline <ek.ietf@gmail.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-mpls-lsp-ping-registries-update@ietf.org, mpls-chairs@ietf.org, mpls@ietf.org, Adrian Farrel <adrian@olddog.co.uk>
References: <161337241617.28337.3130335778228495780@ietfa.amsl.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <702b2d4d-e107-177e-1d95-0ca5ed067fc5@pi.nu>
Date: Mon, 15 Feb 2021 18:38:27 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
MIME-Version: 1.0
In-Reply-To: <161337241617.28337.3130335778228495780@ietfa.amsl.com>
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/i2LzI-qWi0nfAtFo8dnOPVJVKP0>
Subject: Re: [mpls] Erik Kline's No Objection on draft-ietf-mpls-lsp-ping-registries-update-08: (with COMMENT)
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: Mon, 15 Feb 2021 10:38:36 -0000

Erik,

inline please.

On 15/02/2021 15:00, Erik Kline via Datatracker wrote:
> Erik Kline has entered the following ballot position for
> draft-ietf-mpls-lsp-ping-registries-update-08: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-registries-update/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> [[ comments ]]
> 
> [ section 1.2.1 ]
> 
> * I find it slightly odd that this section even exists.
> 
>    RFC 8126 section 1 seems to provide a definition for "namespace" and
>    for "assignment"/"registration".  My reading of 8126s1's definition
>    of namespace doesn't seem to quite match this document's use of namespace
>    (seems more like the definition of registry without the existence of
>    a definition for "sub-registry"), but maybe I haven't spent enough time
>    thinking about it.

I kind of agree that it is kind of odd - one would think that something 
as important as the nomenclature around IANA restrings would be set in 
stone. When we started to write this document we found that we were 
talking past each other when talking about different "levels" of IANA 
registries. So we wrote something that could work for THIS dcument, 
without being a suggestion for an IANA registries nomenclature.

I would certainly be willing to work on such a nomenclature, and I find 
it encouraging that IANA have started to talk about the hightest level 
of registries listed on https://www.iana.org/protocols as categories and 
seem to be willing to introduce  sub-categories.

/Loa
> 
>    If IANA review is fine with this text here, I've no objection.
> 
> 
> [[ nits ]]
> 
> [ section 1 ]
> 
> * "there hav been" -> "there have been"
> 
> 
> 

-- 

Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert                          loa.pi.nu@gmail.com
Bronze Dragon Consulting             phone: +46 739 81 21 64