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

Adrian Farrel <> Thu, 25 March 2021 15:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7168B3A24E0; Thu, 25 Mar 2021 08:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x9N7euHykf0o; Thu, 25 Mar 2021 08:04:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 22BAF3A24DA; Thu, 25 Mar 2021 08:04:46 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 12PF4X1m032413; Thu, 25 Mar 2021 15:04:33 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 47A7D2204A; Thu, 25 Mar 2021 15:04:33 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 315F722044; Thu, 25 Mar 2021 15:04:33 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 12PF4VtR005105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Mar 2021 15:04:32 GMT
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Lars Eggert'" <>, "'Rob Wilton \(rwilton\)'" <>
Cc: "'Ketan Talaulikar \(ketant\)'" <>, "'The IESG'" <>, <>, <>, "'Susan Hares'" <>, <>
References: <> <0dea01d720e5$57d670f0$078352d0$> <> <> <> <>
In-Reply-To: <>
Date: Thu, 25 Mar 2021 15:04:30 -0000
Organization: Old Dog Consulting
Message-ID: <00a501d72188$2997c4c0$7cc74e40$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHIl4swlFyxdRFcHjpjLXjh/JqINAIuu7BNAezF3c0Cx/f8XQM6p7oQAln2SamqTg5PMA==
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--7.839-10.0-31-10
X-imss-scan-details: No--7.839-10.0-31-10
X-TMASE-Result: 10--7.839400-10.000000
X-TMASE-MatchedRID: 9d2LtCNB3NLxIbpQ8BhdbI61Z+HJnvsOIiTd2l7lf6EW6M2A15L1QCOq N0W6x+gkrgSGsMirwkLaniYv5xmEzAvpaofpaZfeMpVOsYwN78PIEQTlh1/QMcuSXx71bvSLBkH lMrspJL44d1POMf0tSXeM+t1Lk5J5mw72jSYg2inJokkUx2UM1wv/9UzFeXITrGgVRjGm0JdfIJ HZr74P9oCioarK0AM2MdvR8+YLzFCTJmKcU73tjLlRS/TbY0kCGbJMFqqIm9x1D3qk2LfE7zya5 RyZT3Su/ye/3Hc9K1qf1nIMfLPWHSLLtGVKmy9t/sUSFaCjTLxXjjsM2/DfxrC4oAwPxab1GjDs M7wByqdHqemudHU/to5UtHpq3n4WnIIsGIOYi3zlCjTeYR3AAabsRRaTaNLRYxDgISSqWZ43mzD 4Iw1FZV5X3fMn62jyq8N/2dAsL1/WHEKTA610z7rbxxduc6FPfS0Ip2eEHny+qryzYw2E8Avgps XypsAMDMq3z/Y/gtXfd+P6wwCt81KV6oMVdTepfDc/J8BOvDtzoKuC37993NhqVHTQ6LY1yFlP5 /yLZSAJ0WiCynQSfX7cGd19dSFd
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Mar 2021 15:04:53 -0000



I think you have captured a good starting point for discussion.

Can I just note that FCFS suffers the same moving target problem of a code
point that is assigned to a draft where the draft may change the meaning on
a later revision.

Some of this is simply "buyer beware." If you use a code point referenced by
an I-D then expect things to go wrong.

But it might also be helpful for IANA to track against an I-D version, not
just the I-D name.


-----Original Message-----
From: Lars Eggert <> 
Sent: 25 March 2021 13:15
To: Rob Wilton (rwilton) <>
Cc: Ketan Talaulikar (ketant) <>rg>; The IESG
<>rg>;;;; Susan Hares <>om>;
Subject: Re: [Idr] Lars Eggert's Discuss on
draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)


On 2021-3-25, at 14:51, Rob Wilton (rwilton) <> wrote:
> Hence, my preference is to publish now, but we should work out how to fix
this properly before we get a flood of similar documents.

that is a reasonable way forward.

To scope this potential revision of RFC7120, let's briefly make sure we
capture the issues that at least IDR has identified, so someone has a
starting point to work off of:

- would like early allocation for specs before they are "stable"
  - open question on what to do about non-interoperable changes?

- would like to do early allocation for non-IETF specs

- would like early allocations to not time out
  - or at least time out much later than after one year?
  - for large registries, may not need to deprecate outdated early
allocations at all
  - for others, task chairs/ADs; is this workable?
    - how would we do this last point for non-IETF specs?