Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)

Lars Eggert <lars@eggert.org> Wed, 24 March 2021 20:56 UTC

Return-Path: <lars@eggert.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE2E3A0976; Wed, 24 Mar 2021 13:56:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
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 AHOku3By4lx1; Wed, 24 Mar 2021 13:56:33 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FBD3A0975; Wed, 24 Mar 2021 13:56:32 -0700 (PDT)
Received: from [IPv6:2a00:ac00:4000:400:9507:e9f6:f26d:fc6a] (unknown [IPv6:2a00:ac00:4000:400:9507:e9f6:f26d:fc6a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 59F2B60030E; Wed, 24 Mar 2021 22:56:21 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1616619381; bh=drzx0od8hPI7UVEdn3MwqCPhz8T+mbwvZONrJxZN9+g=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=LeN6MQ4N6uPS5iUCO84VAT1t0Ca7ODq2XS5Tebvx+QHfY9zIJOohqz8h/X5JYOkLA LL80WgscREdBeZ3htIuBRNy5orKibkah+hf6AK2nOH3k0yXANvyNuocpoYdTGz0NS+ 8PLIHR9ZStuPWd0DO3fx/YgxzISS1IHCx7zn4TSY=
From: Lars Eggert <lars@eggert.org>
Message-Id: <A9CD655E-9EA9-4259-977F-460B8990DA5D@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_AD6426C1-8502-4339-90EE-AD743191419B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Wed, 24 Mar 2021 22:56:20 +0200
In-Reply-To: <0dea01d720e5$57d670f0$078352d0$@olddog.co.uk>
Cc: The IESG <iesg@ietf.org>, idr@ietf.org, Jie Dong <jie.dong@huawei.com>, idr-chairs@ietf.org, Alvaro Retana <aretana.ietf@gmail.com>, draft-ietf-idr-bgp-ls-registry@ietf.org, Susan Hares <shares@ndzh.com>
To: adrian@olddog.co.uk
References: <161661295805.2977.9359905854244102147@ietfa.amsl.com> <0dea01d720e5$57d670f0$078352d0$@olddog.co.uk>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
X-MailScanner-ID: 59F2B60030E.A1F1D
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ShsamsGor7wPh55TaZi229i8TqE>
Subject: Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Mar 2021 20:56:39 -0000

Hi,

On 2021-3-24, at 21:39, Adrian Farrel <adrian@olddog.co.uk> wrote:
>> DISCUSS:
>> 
>> I'm putting in a "discuss" DISCUSS that I expect to clear during the
>> call. Several other ADs raised issues that deserve discussion. While they may
>> not fall under the "discuss criteria", they also don't fall under the "discuss
>> non-criteria" and I want to make sure we spent some time on discussing them.
> 
> That's perfectly reasonable.
> 
> I wish there was a way for the IESG to table something for discussion without using the "Discuss a document" hook which makes the authors (and the watchers) feel that *they* should be part of the discussion. But, anyway, it seems that there is something here that the IESG needs to discuss, so "whatever works."

I wish so, too, but we're limited by the current toolchain here, as you know. I guess I could have put an explicit "non-ADs ignore this" into the text above...


> COMMENT:
>> 
>> Section 2.1, paragraph 4, comment:
>>>   In all cases of review by the Designated Expert (DE) described here,
>>>   the DE is expected to check the clarity of purpose and use of the
>>>   requested code points.  The following points apply to the registries
>>>   discussed in this document:
>> 
>> The process outlined in the rest of this section seems to define rules that are
>> basically equivalent to doing an RFC7120 "early allocation" for these
>> registries. Why is that existing process not sufficient?
> 
> It achieves a similar end with some slight variations. I can't speak for the WG as to why they preferred this approach, but:
> - 7120 requires a stable WG I-D. Thus:
>   - an early WG I-D doesn't qualify

RFC7120 requires:

   c.  The specifications of these code points must be stable; i.e., if
       there is a change, implementations based on the earlier and later
       specifications must be seamlessly interoperable.

It seems one would want this sort of stability here, too?

>   - a non-WG I-D doesn't qualify

It's not clear to me that RFC7120 requires this. Also, this document says "SHOULD only consider requests that arise from I-Ds that have already been accepted as Working Group documents..." which is a similar limitation.

>   - a non-IETF document doesn't qualify

RFC7120 also applies to "Specification Required" registries for which no IETF document is needed.

> - 7120 allocations have to be renewed
>   - this is extra effort
>   - only one renewal is allowed unless the IESG is invoked "under rare circumstances"
>   - the code point "expires" if someone forgets to renew

Fair point. But this document defines a mechanism whereby chairs and the ADs are tasked to remember to make IANA deprecate the codepoints when a document isn't published (or I guess published with incompatible changes to the revision for which the allocation was made). That seems to suffer from similar drawbacks.

Thanks,
Lars