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

Adrian Farrel <adrian@olddog.co.uk> Thu, 25 March 2021 15:04 UTC

Return-Path: <adrian@olddog.co.uk>
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 7168B3A24E0; Thu, 25 Mar 2021 08:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9N7euHykf0o; Thu, 25 Mar 2021 08:04:47 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22BAF3A24DA; Thu, 25 Mar 2021 08:04:46 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 12PF4X1m032413; Thu, 25 Mar 2021 15:04:33 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 47A7D2204A; Thu, 25 Mar 2021 15:04:33 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id 315F722044; Thu, 25 Mar 2021 15:04:33 +0000 (GMT)
Received: from LAPTOPK7AS653V ([84.93.109.31]) (authenticated bits=0) by asmtp2.iomartmail.com (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: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Lars Eggert'" <lars@eggert.org>, "'Rob Wilton \(rwilton\)'" <rwilton@cisco.com>
Cc: "'Ketan Talaulikar \(ketant\)'" <ketant=40cisco.com@dmarc.ietf.org>, "'The IESG'" <iesg@ietf.org>, <idr@ietf.org>, <draft-ietf-idr-bgp-ls-registry@ietf.org>, "'Susan Hares'" <shares@ndzh.com>, <idr-chairs@ietf.org>
References: <161661295805.2977.9359905854244102147@ietfa.amsl.com> <0dea01d720e5$57d670f0$078352d0$@olddog.co.uk> <A9CD655E-9EA9-4259-977F-460B8990DA5D@eggert.org> <MW3PR11MB4570A7F7DB70BEF35ACD716DC1629@MW3PR11MB4570.namprd11.prod.outlook.com> <MN2PR11MB4366DC7D110C598A43514F78B5629@MN2PR11MB4366.namprd11.prod.outlook.com> <F0072E12-CD48-4164-8B36-AC1F1BBD0939@eggert.org>
In-Reply-To: <F0072E12-CD48-4164-8B36-AC1F1BBD0939@eggert.org>
Date: Thu, 25 Mar 2021 15:04:30 -0000
Organization: Old Dog Consulting
Message-ID: <00a501d72188$2997c4c0$7cc74e40$@olddog.co.uk>
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-Originating-IP: 84.93.109.31
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-26050.007
X-TM-AS-Result: No--7.839-10.0-31-10
X-imss-scan-details: No--7.839-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-26050.007
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: <https://mailarchive.ietf.org/arch/msg/idr/qCByw7uSwjM2f241sqJHMzPtxL8>
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: Thu, 25 Mar 2021 15:04:53 -0000

Lars,

Thanks.

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.

Cheers,
Adrian

-----Original Message-----
From: Lars Eggert <lars@eggert.org> 
Sent: 25 March 2021 13:15
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org>rg>; The IESG
<iesg@ietf.org>rg>; idr@ietf.org; draft-ietf-idr-bgp-ls-registry@ietf.org;
adrian@olddog.co.uk; Susan Hares <shares@ndzh.com>om>; idr-chairs@ietf.org
Subject: Re: [Idr] Lars Eggert's Discuss on
draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)

Hi,

On 2021-3-25, at 14:51, Rob Wilton (rwilton) <rwilton@cisco.com> 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?

Thanks,
Lars