Re: [Idr] Changes to draft-ietf-idr-bgp-ls-registry

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Wed, 09 December 2020 18:41 UTC

Return-Path: <ketant@cisco.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 5745F3A170F; Wed, 9 Dec 2020 10:41:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 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_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=WwwU5wSS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=iqrg/3Qx
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 AqIr-IrgsEiQ; Wed, 9 Dec 2020 10:41:32 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374933A1739; Wed, 9 Dec 2020 10:41:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6699; q=dns/txt; s=iport; t=1607539290; x=1608748890; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=T82caohIM54N/VFixoGGN42Kilst6KSuoM+gzO3Ujto=; b=WwwU5wSSKh5nB3tN2z5eQhk+U3RNCb6LAMeaJDvbKNxhGNMREyuENfmq Ch+KkOXxol5oFRnGZZUZhZLt7DFd4O6MaNrqKKQ8xUnveRyDFJdFFslZF FO5JXsEOfnwSEyzN1v+obl+6dSpxm4HACVm4GB39BWbWQyXVmRKY2w2Y5 U=;
IronPort-PHdr: =?us-ascii?q?9a23=3A0MgJWRZTf1tmgBJ2p+xEjyH/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QWVD4ne4uhPzevbr66mXnYPst6Ns3EHJZpLUR?= =?us-ascii?q?JNycAbhBcpD8PND0rnZOXrYCo3EIUnNhdl8ni3PFITFJP4YFvf8XG35CQZXB?= =?us-ascii?q?TyKQQzIf76Scbeis2t3LW0/JveKwxDmDu6Z+Z0KxO75QXcv8Ubm81sMKE0nx?= =?us-ascii?q?DIuXBPPe9RwDBl?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmBQBuGdFf/5BdJa1iHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+BUikoB3VbLy4Kh3wDjWIDmQmBQoERA1QLAQEBDQEBGAs?= =?us-ascii?q?KAgQBAYRKAoF/AiU4EwIDAQELAQEFAQEBAgEGBHGFYQyFcgEBAQECAQEBECg?= =?us-ascii?q?GAQEpAwsBBAcEAgEIEQQBAR8QJwsdCAEBBAENBQgagjlMglUDDiABDqIUAoE?= =?us-ascii?q?8iGl0gTSDBAEBBYFHQYM5GIIQAwaBOIJ0ik8bgUE/gRABQ4FXfj6CXQEBAgE?= =?us-ascii?q?BgSYBEgEjJIMkgiyBTxorLQYpNwQvFA4CWjUHGxg2AQEOA4s4m0yRMwqCdIk?= =?us-ascii?q?egiGJdoYvgySfE5N8ggKJCpYXAgQCBAUCDgEBBYFtI2dwcBU7gmlQFwINjiE?= =?us-ascii?q?MF4NOhRSFRHQ3AgYKAQEDCXyITwEwYAEB?=
X-IronPort-AV: E=Sophos;i="5.78,405,1599523200"; d="scan'208";a="828504707"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Dec 2020 18:41:28 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B9IfS4h010865 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Dec 2020 18:41:28 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 9 Dec 2020 12:41:28 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 9 Dec 2020 12:41:28 -0600
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 9 Dec 2020 13:41:28 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Gq5G9UUao6VGFTWZC2aFmYFwvxGcYwos5/FXkCV6qEIsByViCtFn9o+KDwkaQfKA8cR4id7Ghl1QsZWPqCxTt4fmubXMMuxQVseCKBQZD5Bn5lyIwwcVa2JhwMWgXCPShpqUIrvIKsvz1jnhIoglCxCBUWn+6xhFy//lKQIYR5ibJUXHj6OrpI4Pfd4/j4T/tD3ZyyuXKRAb+Scwn2fJlNrGiTfuY1zn+g8smn4Hd6ll4e1kdS7N2ZMFuUgtft2GZ+RZR51urc1rFys4ALjkSQBgY1fcEPpb/53qECvR8YhT+hz+MgAoGVxsHbGalZwnCenlZx7E0vL0Cwbgi3M+lA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X9zKznPy1pe0LTHB/LFbGIUA9lorm3Jt1aKcSxRRu04=; b=Dqv/0tS3TecXkLI/al5QBqpj1hZ9S2H3ri/fZvVm9x2VhZa/1LiZuLyvqXMgO8Nd7/jjqevMDXnJT/2Ir3Y0ZfQErGHGVlCWdh4iRy1To8BH5KH363MvhKY+23RlY/eXcMGhqwzzhKqNyEkvYzHkPRZTM4awPyspBR/zs+RPDokAuuvGQZvyLOVyP2PcwFl7KtH3tG4V7aVhRuh4jEmjkAaH4ueNVdfKIPHJD845w24T64K/luCv8lQ3HpHdL2Ynbh+AMNYlohFBn+HLYLo90Wz/LzC6sXh1i9rERMSRqHT7Fax+6Rt+oaMmYWP6OlSUGh8VwYydj/kurY3Dnso9SA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X9zKznPy1pe0LTHB/LFbGIUA9lorm3Jt1aKcSxRRu04=; b=iqrg/3QxOoSUWFTWT6WRcqbY/N2mxG9qdwzT+xWtuBaDzMVS/6pp/1Ah+dK63Gci7Qv2lfIwYZGadpUuF5NqtyHyl21LqhpeCHFEtqULd4PQDkr4xHff2Hh8dvPp8wkNi2Dp0uGxRmL2Z4+/Vc2PqGHMwcwIQ7EzqklO+CrznNE=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by CO1PR11MB5153.namprd11.prod.outlook.com (2603:10b6:303:95::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Wed, 9 Dec 2020 18:40:13 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d1b1:838a:7ea7:539c]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d1b1:838a:7ea7:539c%3]) with mapi id 15.20.3632.021; Wed, 9 Dec 2020 18:40:13 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "'IDR List'" <idr@ietf.org>
CC: "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Thread-Topic: [Idr] Changes to draft-ietf-idr-bgp-ls-registry
Thread-Index: AdbNdXrNuLehXBdpQRWHs5x1f3cxYQAUJVqAABIxKYAAErI9EAAAQrBg
Date: Wed, 9 Dec 2020 18:40:13 +0000
Message-ID: <MW3PR11MB4570B7BF7ACC27F77A16D3A5C1CC0@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <0e3501d6cda2$fbf19d40$f3d4d7c0$@olddog.co.uk> <BY5PR11MB433720102FC1C9D8E97E0014C1CC0@BY5PR11MB4337.namprd11.prod.outlook.com> <0f0901d6ce0e$d5a08860$80e19920$@olddog.co.uk> <BY5PR11MB4337E63BC17404A5D862F67CC1CC0@BY5PR11MB4337.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB4337E63BC17404A5D862F67CC1CC0@BY5PR11MB4337.namprd11.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [72.163.220.4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c34c7d30-1be6-44b3-4e6f-08d89c71dd64
x-ms-traffictypediagnostic: CO1PR11MB5153:
x-microsoft-antispam-prvs: <CO1PR11MB51532B8E24D262AB0047A483C1CC0@CO1PR11MB5153.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: YHTQ60fm5zb1DMRJ4AFMF/fzqdcwbaBW90/V+MKkzFy5BVKFRjsJ4KQaauDCWR/0/CrAvj8cq+SdPdwnXrUMNDxUYEpjRgp1t08RnoSGgY6LeDdOXXolweTWoNPYzwN3Ylft+nL5BUYh7GZJNr20lLeBmoPw5Tz40IXKMZbhbI/NriN5wDnBHbkI0LCXp6ote5Ih1ON55nHdc9EPM/0VLXuZVUkPq37cbqSkB4kJgq//Dr9bYDndk35iUaYn3A7cg20neQzilgVrgbJxVwQcDpiinruO9tzRaePgoZh3GkdxmX9w3mrgpQw0muoTr9hS8ykHnvvcsDDVlPYOQHSNLH0PGyX/HXtQI7FG7vd7djhl7BMR5lWe9bPU2/GoUsRLhq3iN3msbg4JjtnlGg/u1Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(346002)(376002)(39860400002)(396003)(64756008)(66476007)(66446008)(66556008)(66946007)(26005)(53546011)(6506007)(4326008)(83380400001)(316002)(186003)(76116006)(7696005)(966005)(8936002)(86362001)(55016002)(9686003)(33656002)(8676002)(71200400001)(52536014)(478600001)(5660300002)(2906002)(110136005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?8NUCJydzR5FDLLiiy+mroNrvslnRQxTRU41p9KairPksw56q48dIcvZOSCYk?= =?us-ascii?Q?Sz9pcsx0nlUk1YnahKoT3yJytzoUZgbQ1ycgEFchSk4GLuL+hzmdw8pwhOBR?= =?us-ascii?Q?6rqR915aOOwhNsduXhELR1t1g2M/I5If8ljJ1xGqVUmm9/es3VRXkIvRyOFK?= =?us-ascii?Q?GZwyrc378cZVUDD85tJS9ajqitHsVyN9kwYtZpuRt17nsVhTgiYMO9PMA+JL?= =?us-ascii?Q?EPv4w/g1d0xw874GBJLc18CP9aIXy35cQxn97aly/EGkVYGApukduNuxhyjj?= =?us-ascii?Q?oOXxpe4tAV7zICVWqBtdDAaRBSUgGj3TRxDUTjn2blHo5jj5EMKc4M0PPOl3?= =?us-ascii?Q?qfr8oBCprzRUQa6XrVxP+o1rxwoZ6yD6BD1BG/VSbiS5poxq929WBWyd7f3b?= =?us-ascii?Q?5kRil26IgXSFs6x8ACnCDZuyphMwzr2Ff/6Jir3XHkXMfaH+Im/OcAaoLh9w?= =?us-ascii?Q?djKfeR6t97MesqujAkBFYTnOuTjyIr2tAZ6nk7cBvK5+EYIgG3Y6fX8KJEnf?= =?us-ascii?Q?CgNQ72u+JPk64Dk60ZkOcWlmnHk156HDUe8E0G1vHq62OyBuRW2XMDibzn20?= =?us-ascii?Q?UcSWNdsmn8suKepMpxbPbGlp4864dV4+tHyTc2j0e81Wu/TJBcmGm4FTLg4n?= =?us-ascii?Q?gCABFGNxZtGAU4UhH9yEFChlihNSsY9Tv5AIyoITfguhIz3LhRa98etzsZlE?= =?us-ascii?Q?WMyXc3PPHYI34FomeZEfw/xhwRytfIwtu2EvPBjO7N08cPQRSGFD5yA9pZU4?= =?us-ascii?Q?JnkrJNzJpBbZI/atgzOa5jvYbJkVDqmLX8ew3BVqpIF7miARx4s4NGNFemx5?= =?us-ascii?Q?20FZJ11MRncMCpsHLBEH5h4wSRw3kkz1H29RI+k36REjmGpK7RPaKiwE74Yk?= =?us-ascii?Q?qYKgucyzaUlUWRb6KWRTmJMmePg0vz1TIAeg6QsM+lG2jt5T4lP97NjL0YXQ?= =?us-ascii?Q?fZKymo2MgP4N8yTj97kkDWsKfvhdH/MHcrL76oLTves=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c34c7d30-1be6-44b3-4e6f-08d89c71dd64
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2020 18:40:13.1495 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: kYfZHHywvqt3y6LFyJ0tFKbzH+yv7DTL3sGgBtrQFtXLToP8HajRe26qLerWz0xB4Xg3nkfPxttF2up2PPOU/Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB5153
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Vx2mEeNXC4k25ktpnaUq6tXNXFg>
Subject: Re: [Idr] Changes to draft-ietf-idr-bgp-ls-registry
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, 09 Dec 2020 18:41:43 -0000

Hi Adrian,

+1 as well for the new/proposed text change.

Thanks,
Ketan

-----Original Message-----
From: Idr <idr-bounces@ietf.org> On Behalf Of Les Ginsberg (ginsberg)
Sent: 10 December 2020 00:06
To: adrian@olddog.co.uk; 'IDR List' <idr@ietf.org>
Cc: idr-chairs@ietf.org
Subject: Re: [Idr] Changes to draft-ietf-idr-bgp-ls-registry

Adrian -

Inline.

> -----Original Message-----
> From: Adrian Farrel <adrian@olddog.co.uk>
> Sent: Wednesday, December 09, 2020 1:37 AM
> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>om>; 'IDR List' 
> <idr@ietf.org>
> Cc: idr-chairs@ietf.org
> Subject: RE: [Idr] Changes to draft-ietf-idr-bgp-ls-registry
> 
> OK, thanks Les.
> 
> Best to start with "why aren't these early allocations?"
> 
> Early allocation is a process to get around Standards Action, IETF 
> Review, and RFC Required by setting rules under which code points from 
> those types of registry can be allocated in advance of the completion 
> of the RFC process. 7120 includes that IANA timestamps the 
> allocations, and that early allocations expire automatically. They 
> also require that I-Ds are sufficiently stable that the meanings of 
> code points will not change before the RFC is published.
> 
> My understanding of the wishes of the IDR WG is that they consider 
> early allocation to be too restrictive. Firstly, it comes too late in 
> the process (IOW the stability of the draft normally requires that a 
> code point cannot be allocated until close to WG last call). Secondly, 
> the process involves the chairs and AD signing off along with the DEs, 
> and so is too heavy and laborious (aka slow). And additionally, early 
> allocation requires that attention is paid to renewing the allocations 
> every year until the RFC is published.
> 

[Les:] I think what  the draft is proposing is "early allocation". There are just some processes as defined in RFC 7120 that you do not want to follow - which I think is fine. IS-IS did much the same in RFC 7370.
To me, the more apt description is "early allocation with IDR specific guidance to the DEs".
But perhaps this is quibbling.


> The change, therefore, was to make the registries Expert Review 
> precisely to not use 7120.
> 
> I agree "similar" is a Bad Word (TM). It was my intention only to 
> indicate that the use of deprecation was similar to deprecation in 
> 7120, but in this case, more words would be better. So...
> 
> OLD (-02)
>    8.  In the event that the document fails to progress to RFC, the
>        Working Group chairs or AD SHOULD contact the Designated Expert
>        to coordinate with IANA over marking the code points as
>        deprecated following similar principles to Section 3.3 of
>        [RFC7120].
> NEW
>    8.  In the event that the document fails to progress to RFC, the
>        Working Group chairs or AD SHOULD contact the Designated Expert
>        to coordinate with IANA over marking the code points as
>        deprecated.  A deprecated code point is not marked as allocated
>        for use and is not available for allocation in a future document.
>        The WG chairs may inform IANA that a deprecated code point can be
>        completely de-allocated (i.e., made available for new
>        allocations) at any time after it has been deprecated if there is
>        a shortage of unallocated code points in the registry.
> END
> 

[Les:] I am good with this revised text.
Thanx.

   Les

> Cheers,
> Adrian
> 
> -----Original Message-----
> From: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> Sent: 09 December 2020 01:12
> To: adrian@olddog.co.uk; 'IDR List' <idr@ietf.org>
> Cc: idr-chairs@ietf.org
> Subject: RE: [Idr] Changes to draft-ietf-idr-bgp-ls-registry
> 
> Adrian -
> 
> Thanx - as always - for your diligence.
> I think this revision is consistent with the outcome of the email 
> discussion.
> 
> I am concerned about Section 2.1 #8:
> 
> "In the event that the document fails to progress to RFC, the
>        Working Group chairs or AD SHOULD contact the Designated Expert
>        to coordinate with IANA over marking the code points as
>        deprecated following similar principles to Section 3.3 of
>        [RFC7120]."
> 
> I think the phrase "similar principles" leaves the door open to lots 
> of ambiguity. If you do not want to follow RFC 7120 Section 3.3, what 
> do you want to do? How much deviation from RFC 7120 Section 3.3 before "similar"
> does not apply? I do not think leaving this a bit vague is desirable.
> 
> I am also not clear on why you say (below) that we are not doing early 
> allocations. If these aren't early allocations, what are they? Which 
> also makes me wonder why you could not simply say "follow RFC 7120 
> Section 3.3"??
> 
>   Les
> 
> 
> 
> > -----Original Message-----
> > From: Idr <idr-bounces@ietf.org> On Behalf Of Adrian Farrel
> > Sent: Tuesday, December 08, 2020 12:45 PM
> > To: 'IDR List' <idr@ietf.org>
> > Cc: idr-chairs@ietf.org
> > Subject: [Idr] Changes to draft-ietf-idr-bgp-ls-registry
> >
> > Hi,
> >
> > Thanks to all for the useful input and sorry for the long delay 
> > while "things" got in the way.
> >
> > I made some changes to the draft according to Alvaro's comments and 
> > then updated the DE guidance per the discussions on list.
> >
> > Ketan noted that point 6 of the guidance in RFC 7370 talks about
> "timeouts"
> > per RFC 7120. That only applies to early allocations, and that's not 
> > what we're doing. I think it is still worth carrying text about what 
> > happens if the document never becomes an RFC, so I have retained 
> > something similar, but different. I hope this is consistent with 
> > what Les said.
> >
> > Acee additionally suggested that code point requests should be 
> > "fully transparent to the LSR list". I haven't added this, but it 
> > would be simple to do if there is support for it.
> >
> > Since the text changes are pretty much the whole draft, the easiest 
> > thing seems to be to post an update and then invite you to review 
> > and
> comment.
> > So
> > that's what I have done.
> >
> > https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-registry
> >
> > Cheers,
> > Adrian
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr