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

Susan Hares <shares@ndzh.com> Thu, 25 March 2021 14:18 UTC

Return-Path: <shares@ndzh.com>
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 251283A23B9; Thu, 25 Mar 2021 07:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.948
X-Spam-Level:
X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 lVVhZc8fI_26; Thu, 25 Mar 2021 07:18:43 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 B2DBA3A23B7; Thu, 25 Mar 2021 07:18:42 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.107.124.96;
From: Susan Hares <shares@ndzh.com>
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, adrian@olddog.co.uk, 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 10:18:29 -0400
Message-ID: <00e901d72181$bb3d3f10$31b7bd30$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHIl4swlFyxdRFcHjpjLXjh/JqINAIuu7BNAezF3c0Cx/f8XQM6p7oQAln2SamqThNTUA==
Content-Language: en-us
X-Antivirus: AVG (VPS 210324-0, 03/24/2021), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/rW845cDLwS6Ux1sLu1X97N85pGM>
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 14:18:47 -0000

Lars: 

On your comment: 
  - for others, task chairs/ADs; is this workable?
    - how would we do this last point for non-IETF specs
======
On the last point, in the past the IDR chairs have work IANA on
deprecations. 

Cheers, Sue 

-----Original Message-----
From: Lars Eggert [mailto:lars@eggert.org] 
Sent: Thursday, March 25, 2021 9:15 AM
To: Rob Wilton (rwilton)
Cc: Ketan Talaulikar (ketant); The IESG; idr@ietf.org;
draft-ietf-idr-bgp-ls-registry@ietf.org; adrian@olddog.co.uk; Susan Hares;
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