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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 09 December 2020 18:36 UTC

Return-Path: <ginsberg@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 982BC3A10FA; Wed, 9 Dec 2020 10:36:36 -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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=T+eVj4NU; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=aj4wDta1
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 rPYUr9Z_kCkM; Wed, 9 Dec 2020 10:36:34 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57DEB3A10EC; Wed, 9 Dec 2020 10:36:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6161; q=dns/txt; s=iport; t=1607538994; x=1608748594; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sg7+/ZTO1jNWQ0DZ7jmP01D81TxifqKXpG8L+qeYDkQ=; b=T+eVj4NUmDoO3aGEFN9lvXgwP+MQ4mmO7VLIzoYbLfgOKoSWz0A3j994 pyvVmKogzd7nsuKS7knN4o3Eij0OafWPsgPLEog/wUYit3GHzC9jIRqtc pOyY7JuIMqi95G6elxFR3vYAJh0eIgxo7Z1DVYDN32UGaTvbjQIR9ZoAZ g=;
IronPort-PHdr: =?us-ascii?q?9a23=3Ah3Ucsx1Oe/GwP0g5smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWFvadqiFPFWoqd4PUClumF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGH8Lya1rd5Ha1qyMRSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ClBQC3GNFf/5pdJa1iHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+BUikoB3VbLy6IBgONYgOZCYFCgREDVAsBAQENAQEYCwo?= =?us-ascii?q?CBAEBhEoCgX8CJTgTAgMBAQsBAQUBAQECAQYEcYVhDIVyAQEBAQIBAQEQKAY?= =?us-ascii?q?BASkDCwEEBwQCAQgRBAEBHxAnCx0IAQEEAQ0FCBqCOUyCVQMOIAEOohgCgTy?= =?us-ascii?q?IaXSBNIMEAQEFgUdBgzsYghADBoE4gnSKTxuBQT+BEAFDgVd+PoJdAQECAQG?= =?us-ascii?q?BJgESASMkgySCLIFPGistBik3BC8UDgJaNQcbGDYBAQ4DizibTJEzCoJ0iR6?= =?us-ascii?q?CIYl2hi+DJJ8Tk3yCAokKlhcCBAIEBQIOAQEFgW0jZ3BwFTuCaVAXAg2OIQw?= =?us-ascii?q?Xg06FFIVEdDcCBgoBAQMJfIkAYAEB?=
X-IronPort-AV: E=Sophos;i="5.78,405,1599523200"; d="scan'208";a="837296722"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Dec 2020 18:36:18 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B9IaINa003441 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Dec 2020 18:36:18 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 9 Dec 2020 12:36:18 -0600
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 9 Dec 2020 13:36:17 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 9 Dec 2020 12:36:17 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MlcthxTnxNMZdRj4ueXxiUtzd7Usr0D4RZ+jBS90fhR38VOcV4Xv9WVzC8RMFPpNgX/5t+WYbpn9dR1HumRh7YfMn0Uz6bQOBLdMTvvFX50CpzOA/XvG4K6ZSbnKDNX4JZKSXHNTSNYhRrWAj5cayK97zsRd1rI7GGADAfSIDoRXZrXt7+5qFFQ+yoWWDwoxaJzKR1BEf/vfYrQbzRgVI4t4ulGTsjcBAcNfiFEoXX1eJQ7/uJxkqxlcIj80sHez4+YvqQ4Jt5ab1cPtOVIqVbnsSruWGJjcHcZpqtDCR0PDuAWlp28tVSFxFi+pfXDYYuF++Tskp0D1R5elVUMyAA==
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=7pCgRm2IZUgkaqYzzP2zpJn5cG/EeTYxpC2qTNgFdnE=; b=ZYgkDCxG+qA+LI8SWRufywG4Vft7ZGmiayQLPzQQTxLv+lVwYqNMKlnxQbaRoA4zNlX5RFP6PRUAJDgru2703/rawopa8ZxaSiXTQjQYKdP6EBI6v1IMIUX4lpAl0sCDLtzfzndxbnaYCltw1PlN0eAvJ4PC1mYj8ZPw76yurY7ZEJgfMcb9Up9+fN7+vkXsVrk57wvH0LTD8jhvgqU40FmcZrt+ElI5o+H1tZN6yTcKJySkS9RWamsY1pVtyqNEqfy4zbQ4/fLK78hYyfvGiN0BNE9aSg3ALhIEhouTxc1LhgvecLzizV/biSPY9XxUnXwQu7qOvP2TTjzQRL8vmw==
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=7pCgRm2IZUgkaqYzzP2zpJn5cG/EeTYxpC2qTNgFdnE=; b=aj4wDta1GgMqhn8YGx5zhFeNNPyQlzK4rplyNOAkmybo+cTq/mYS4ex1yVEmK5AjpRANCQC3taEmgZraNv+S3TCgVQqsqXPzdQCNIh9wVAC0eXYbGdTJqT7K0hSPrXu9rCFy55yRn9D0Jajt3p9IHW+2BHQ0dliJC/zSxFpBHYs=
Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by SJ0PR11MB5166.namprd11.prod.outlook.com (2603:10b6:a03:2d8::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.13; Wed, 9 Dec 2020 18:36:16 +0000
Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::e063:fc51:b359:2f39]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::e063:fc51:b359:2f39%7]) with mapi id 15.20.3632.021; Wed, 9 Dec 2020 18:36:16 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "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: AdbNdXrNuLehXBdpQRWHs5x1f3cxYQAUJVqAABIxKYAAErI9EA==
Date: Wed, 9 Dec 2020 18:36:16 +0000
Message-ID: <BY5PR11MB4337E63BC17404A5D862F67CC1CC0@BY5PR11MB4337.namprd11.prod.outlook.com>
References: <0e3501d6cda2$fbf19d40$f3d4d7c0$@olddog.co.uk> <BY5PR11MB433720102FC1C9D8E97E0014C1CC0@BY5PR11MB4337.namprd11.prod.outlook.com> <0f0901d6ce0e$d5a08860$80e19920$@olddog.co.uk>
In-Reply-To: <0f0901d6ce0e$d5a08860$80e19920$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: olddog.co.uk; dkim=none (message not signed) header.d=none;olddog.co.uk; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2602:306:36ca:6640:c98e:8f45:15f1:c01a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2048fa0c-2011-47cd-0f1d-08d89c71504d
x-ms-traffictypediagnostic: SJ0PR11MB5166:
x-microsoft-antispam-prvs: <SJ0PR11MB5166D191FFCE54CC2F64864DC1CC0@SJ0PR11MB5166.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: x4FkrlRQcqwCfQPo5bEohl4LPCEKHvsKcxtYdTrO+nxxJT20gOUzU2rhTRmWrzHgtEa0Qmu5L3YV0wwc/XPanLVgAY8dorImyCUAv5Wa9jtxsemw6IHYwNxpcT/144Cpz80S/SEgboF0P3f+8vnxrEY9ZNhtNvXl2JkAm5vUgHYA24kaaifZNKCD9Pr7KVXBGpShItKS50hvDEIKs1PQnIOB6zU3LTu9bSpfE4+gTtEeqZCkZxjNFptKMaWI7//T+TExCpXX+ZTe9MPbrTQh8TvSF4MvdM7YV/vC94C2QzcEq9k+W2Q8UAYkme5lZgCBdN0JWFQ9AuDj+H6nsg6cXkyaNnONG6wrQZbzv2KmV4XpwiixHNfmkOmo5AtWiXyqcB8RYYVWWQon9i5qP1LPxg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4337.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(136003)(346002)(8936002)(5660300002)(7696005)(186003)(33656002)(76116006)(83380400001)(52536014)(86362001)(9686003)(55016002)(2906002)(4326008)(110136005)(66476007)(66946007)(6506007)(66446008)(53546011)(66556008)(64756008)(508600001)(8676002)(966005)(71200400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?R6uY3FljkHXb1hTnvHvUJZWJWgviK18CVXV1YcI5jxC+dsHGOFtDhDvRzFqj?= =?us-ascii?Q?kDvXqNMqs5VWXNjPg/6Swqq1PCWBHagwYv2mH0gm4SI7F26dMwsgrrmHnkCH?= =?us-ascii?Q?hc3MjHoXP2NNQsLrgnuqRiMTklcp8vl0+sxAULfwg8F8n7b8WjCFx2lNEQfe?= =?us-ascii?Q?vgYLtu/U3UXMffnLGflQA5993lDtufGu5t2O+sBQTNDDxjmHZZmCCyop4uyx?= =?us-ascii?Q?Ry52rcgZcF3JuohQLPuMvewBQkUU49AXr/cJc6d9x4D0dTgjX/k99XxlmpHk?= =?us-ascii?Q?5rUOgJeunbd8kynBwy/Rl95GQtBOiinMplnK4cZbTSfibX+dus87iFtTFPPA?= =?us-ascii?Q?GW1MeN5YIIvNjTwS6bIHHS6UpWOC61t116UyhfA2fDevXmkWTqtruE4R3YR+?= =?us-ascii?Q?0qbW2DSuWkCbaF+t11ijtD2uP6I2ynJNpY05Eb73Ze4TlVuTJmFlYexfve2G?= =?us-ascii?Q?VKCPbWHzDbFT6ypBEY2iFcZCVE1uObc7RqMbJYxHrcqb0Nuc72Gk1c4sOOvi?= =?us-ascii?Q?IL1gFZdQDXnnpk1n7sbLvo4QvE0+PCJu444mbGhV1vPDUGFv15I59kkBKLPC?= =?us-ascii?Q?V1A6fAkpjVK13dWlXiul3QIzz2ft9IV8sahibAegfzW0qQQ9TReuTDqfmafP?= =?us-ascii?Q?3tKdI9ol88fl4x0/85v4dTknWYmT5klEq50VJxAJ7Jc3/w6Qk+wf1UwK3sfV?= =?us-ascii?Q?9TXnyAHjGpuiJILSKLSFCcXRIP8KO0bMGe1BztMCxc0G8exrMmo5235zqZDc?= =?us-ascii?Q?4nn+MPfarkD0ENs3wB29OyNaPsCzWaxzHSoAQFv3qv0cHDEUhegrEZaXLH4L?= =?us-ascii?Q?FU+y9kSe9je2JvvYhRlqogCHpbF47HQp1hiimuCIXhHMERosJUTxv1Qje7SP?= =?us-ascii?Q?8YM7i8C01xcshh93DcwWpUy9Nmsm1FXs6o+1ILk9JXaIDr2Q3Iz4l/UpSrL9?= =?us-ascii?Q?jGJEKNdrfOaF+dwJ9tL4MkjPPsx2kBp8I+3tXAA9CZxwBjPrytPyf7fHxbDw?= =?us-ascii?Q?sD9hgwjudC4Grc0bMjaZXHO9EtX6Ytuze/OFhP828D/YTq4=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: BY5PR11MB4337.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2048fa0c-2011-47cd-0f1d-08d89c71504d
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2020 18:36:16.4530 (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: GGWivcfaa4r9owzqkuIoWJ/hG12OkF0LbKeixCUHn3IrbpmjDrjWIWEvAltrTzMEw/DQKUziLQESyvBRGp1aQQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5166
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/NmDgQjbtb2mDWmi6X0xAhjkuVYo>
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:36:37 -0000

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