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:15 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 944FA3A23A6; Thu, 25 Mar 2021 07:15:58 -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 IvQBF4Kri_8Q; Thu, 25 Mar 2021 07:15:54 -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 167263A23A4; Thu, 25 Mar 2021 07:15:53 -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: "'Ketan Talaulikar (ketant)'" <ketant@cisco.com>, 'Lars Eggert' <lars@eggert.org>, 'The IESG' <iesg@ietf.org>
Cc: idr@ietf.org, idr-chairs@ietf.org, draft-ietf-idr-bgp-ls-registry@ietf.org, adrian@olddog.co.uk
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>
In-Reply-To: <MW3PR11MB4570A7F7DB70BEF35ACD716DC1629@MW3PR11MB4570.namprd11.prod.outlook.com>
Date: Thu, 25 Mar 2021 10:15:37 -0400
Message-ID: <00d901d72181$54bdc660$fe395320$@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/f8Xap6tfAw
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/WApmADv5WKrmuXyJRyh2oidywII>
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:15:59 -0000
Ketan and IESG: <WG chair hat on> Ketan has correctly summarized the WG discussion. The WG goal is to enable the 2 implementations to occur prior to standardization, and to allow the implementations to keep those values. If other WGs have not seen this problem, perhaps it is because they do not require 2 implementation before standardization. We are adding this additional registry work to make this process easier for the implementers. <WG chair hat off> [personal opinion] If the process occasion creates a conflict, I believe it is worth the risk. It is critical to get early implementations of protocols with stable values. Running code and rough consensus is a slogan I truly believe in. Sue -----Original Message----- From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] Sent: Thursday, March 25, 2021 7:54 AM To: Lars Eggert; The IESG Cc: idr@ietf.org; idr-chairs@ietf.org; draft-ietf-idr-bgp-ls-registry@ietf.org; Susan Hares; adrian@olddog.co.uk Subject: RE: [Idr] Lars Eggert's Discuss on draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT) Hello, I believe Adrian has made all these points already in his responses on these threads, and so perhaps this is just an effort at summarizing them for the IESG Discussion. (Request the WG Chairs to correct if they see this different from the WG consensus view). 1) The "Specification Required" policy is currently in place for this registry per RFC7752. The WG was informed that Internet-Drafts (even WG drafts) do not meet the criteria of "permanent and readily available" thanks to the boiler-plate text (below) that exists in Internet-Drafts. i.e. WG could not get IANA allocations based on WG drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." 2) As a result of (1), the WG has had to follow the early allocation procedures of RFC7120 for a large set of allocations and documents (BGP-LS is a bit busy!). IDR requires 2 implementations to publish drafts as RFCs. Things take time. The WG, chairs, AD and in some cases the IESG have to do a lot of process work to retain the allocations when there are delays in getting to publication. 3) The WG was looking for IANA allocation based on WG documents. With the guidance of WG chairs, our AD and participants with more experience in IANA allocations, we (the WG) took a step back to "Expert Review" so as to avoid the early allocation process overheads. Please note that we have sufficient code-point space. 4) The guidance to DE was only improved/enhanced but that, IMHO, is more secondary in nature and something that happened over the course of review of the document to improve it. Finally, thanks again to Adrian for coming up with the solution (i.e. the draft) and taking it through the process for the WG! Thanks, Ketan -----Original Message----- From: Idr <idr-bounces@ietf.org> On Behalf Of Lars Eggert Sent: 25 March 2021 02:26 To: adrian@olddog.co.uk Cc: idr@ietf.org; idr-chairs@ietf.org; The IESG <iesg@ietf.org>; draft-ietf-idr-bgp-ls-registry@ietf.org; Susan Hares <shares@ndzh.com> Subject: Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT) 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
- [Idr] Lars Eggert's Discuss on draft-ietf-idr-bgp… Lars Eggert via Datatracker
- Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr… Adrian Farrel
- Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr… Lars Eggert
- Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr… Ketan Talaulikar (ketant)
- Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr… Rob Wilton (rwilton)
- Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr… Lars Eggert
- Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr… Alvaro Retana
- Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr… Ketan Talaulikar (ketant)
- Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr… John Scudder
- Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr… Susan Hares
- Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr… Susan Hares
- Re: [Idr] Lars Eggert's Discuss on draft-ietf-idr… Adrian Farrel