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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Thu, 25 March 2021 12:51 UTC

Return-Path: <rwilton@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 DF2CC3A2057; Thu, 25 Mar 2021 05:51:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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_NONE=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=XhYnrTHX; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Nt1vZNyA
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 DgUi3415WwgL; Thu, 25 Mar 2021 05:51:50 -0700 (PDT)
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 A8D4B3A2056; Thu, 25 Mar 2021 05:51:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7073; q=dns/txt; s=iport; t=1616676709; x=1617886309; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EOQ1r9I26ZJaKINbMSmx9hgOPm2311jmt4H0Zl7rqq4=; b=XhYnrTHX7Dudmf/SxbzW/Z4rRs6T1i+aRAIcCSmz15WZzVsI76rIJG73 eeMMdzea0Mw10nr4I1hwR/ZS+xWB2R0k/s6rjiey97PTxgKc63jnXPomP oPV+BVRSpc5bgHIm+kQJhxKAKkjT+XHMe6Qz12zXRakR3bDMyoPVp8Sg6 g=;
IronPort-PHdr: A9a23:SHrRGBUTUU8G3d1WSVJI1AUFoRfV8K0AAWYlgqEPgq9Scqml45XpNVDe4vMollLSQIHH8Jpsh+/fqaumWGEc79CGqn9ROJBPVhpQj8IQkkRgBcOeEkT0IbbsaDByB8VNUlJpvhTZeUhYEcrzfRve93u16zNBFhD2LwEzJ+npFMjVlcvkn+y38ofYNgNPgjf1aLhuLRKw+APWsMRegYZrJqsrjBXTpX4dcOVNzmQuLlWWzH7B
IronPort-HdrOrdr: A9a23:NpWo569uDwpJrc5/aZluk+Gpcb1zdoIgy1knxilNYDRvWIixi92ukPMH1RX9lTYWXzUalcqdPbSbKEm8ybdc2qNUGbu5RgHptC+TLI9k5Zb/2DGIIUPD38Zn/+Nbf6B6YeeeMXFTh8z3+RT9Nt4mzsWO/qzAv5ag815GZ2hRGsZdxi1+DRuWFVAzYQFAC4YwGpb03Ls4mxOLf3MLYsOnQkQfV+/YqNHR0L7gaxgKBxkogTP+zA+Awrj8DhSew1MiQypCqI1Sv1Ttvi7YwuGYs/+9wgLBzGO71fRrsfbo19crPr32tuE7MTPp4zzYAbhJe7rHhzwtpfHq1VBCqqixnz4FH+Ber0zcZXu0pxyF4Xih7B8L52X5wVGVxVvPyPaJPg4SMMZKiYJHfhax0SNJ17sQvNMprgCknqFaAh/akCP268KgbWAWqmOPvXEgneQP5kYvN7c2Vb5LoYQTuGNTHZsQdRiKkLwPLeh0AMnQoMtRaFORBkqpx1VH/drEZAVWIj62Bmw5/uCF2Tlfm350i2ECwtYEo3sG/JUhD7FZ+uXtKM1T5fJzZ/5TSZg4KPYKQMOxBGCIawnLKniuLVPuE7xCE27RqqTw/K4+6IiRCd415ap3vK6EfEJTtGY0dU6rI9aJxod3/hfER3j4ejjx1MdE5dxctqfnTLTmdQ2PIWpe1veIkrE6OIn2SvyzMJVZD7vINm31A7tE2AX4Rt1cMn8bXMoJussqWl6Hr87RQ7ea8dDzQbL2Hv7AADwkUmTwDj8oRz7oPvhN6UitRzv5jXHqKjXQU3262ag1PLnR/uAVxoRIHJZLqBIphVOw4dzOLTVDt6cxbVZvOb+PqNLjmUCGuULzq0l5MBtUCUhYpJ/6VWlRmAMMO0ToNbAZu9uefmhW1GCdJgB2St7XFAI3nSUyxYuHa7irgQwyAdOuNWyXy1EJomiRcpsakqqfodv+doggFZYgUqxpHQDNHxh48Dwa8FtrWUshfAvyBznugaKqgNgoH+nZbcB7mxruC9VTs2jjuUKVotwPSnMXUyW1a9OehR8jSlNv9wZM2p5apIDFuD60bUMjnewzMTR3GRWqKYMDKD7AWaJ5tfTAfhpqQWKDmDqA4itDClbCxgE1nWzuLSqdZPfRJEFS00ooiJrCwRdTaniXeV52ZzRct4BwfF625kpb4Kusere51XeXZx855twldBvBYTcUP2pVto2K/RaIhTePEmgnzJ0yPurbSK8uaa3Xx2nFEvz6qYgWW/BT55prL9bor6sCVv+eYRacKHfiB/ouwBH9nAdpBABk7H0lm+jvwhvr8Syx22M+G+PbJD1dNvomCsDZ62jvXPCT1pplydozoOurK230LtqL07veYTIGKhTdpweNPqsVgIERuaI5r71oGZbHFTPOyXFcxR07aN7ui1l2etUM3JnRfot0O8ACcSNQ+VQk0NyJMUswqwTzRuszZ0skgXPXN86AioC45YYHEwmEvk/9KFOf+ypS87PeUyyP2aUTBqgwLW5VAXJMoEhK7aeHbcndGQ+qf+ZM8B6mKXe7aqZaU7XAFrMKrBp2iuv40NO/Zm79wkTXsjR6KK4VrDriTsO2HQ6WGelHt9a9Ik+Bh6O24Mi1yDf7IAHLH3gwlMlAbwgXaM8GlzwpyIsw2SK2Qrbsok0kn0BFiAsX32LFy8yj+iPDAUpCMQfFmZ1YUjlYL2iQga3+gJ2l/WW45CIAxILKG0hRdMxfAtQcToD4KCF1NMgb1YTYiJYHk2BEexchD2k1lTD70adnxN6CqYfvZ9E=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CnAABmhlxg/5FdJa1aHAEBAQEBAQcBARIBAQQEAQFAgT4FAQELAYFSUQeBUDYxCogAA4U5iEUDgQmOGooRgS6BJQNUCwEBAQ0BATICBAEBgRYBgzkCgXwCJTYHDgIDAQELAQEFAQEBAgEGBHGFYQ2GRAEBAQQ6BgEBKQ4BCwQCAQgRBAEBAR4QMh0IAgQBDQUIE4UrAy8BA0ifWwKKHnWBNIMEAQEGhRkYghMJgTkBgnWCcRI+gxqDciYcgUlCgREBQ4IkNT6ECg0rJIMlgiuCSgI8JgEDGggNKBAMAisCSTQyAQQBDjkaD5AlgxeUJJA9ggoKgwadA4NIimyWGpUGniMgAQKEQwIEAgQFAg4BAQaBIzgLKIFZcBWDJFAXAg2OHzaDOYpZczgCBgoBAQMJfIQpgTYBgQ4BAQ
X-IronPort-AV: E=Sophos;i="5.81,277,1610409600"; d="scan'208";a="876414122"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Mar 2021 12:51:48 +0000
Received: from mail.cisco.com (xbe-aln-006.cisco.com [173.36.7.21]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 12PCplpv028276 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 25 Mar 2021 12:51:48 GMT
Received: from xfe-aln-005.cisco.com (173.37.135.125) by xbe-aln-006.cisco.com (173.36.7.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 25 Mar 2021 07:51:47 -0500
Received: from xfe-aln-002.cisco.com (173.37.135.122) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 25 Mar 2021 07:51:47 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Thu, 25 Mar 2021 07:51:47 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JLcggJhFKbCMzjvjzWTRF/xeFhIc7uTYvUrQi5s2/ZEhU6LxtkZlKn1I1V7AF1vQbgsmT+iIpmfAx/rHfd1MSWEyTrOuXPawiTjdWL35sLOheLTwiq50A0hJioj9k2jiqrdp9T+4DJ1y3QuVjUBKrNIWWfivdjSFlEu0qtWAYY9+ztHpehh5fH46tLGq0XrjQMgrj2b3srctIbELsFppkrkpIEXUIKaotNU6RStvCh66GbNH/jeK6ivXRo6XOLrRaHjw/CM+oc4PN4QwgBxXfpsy8Fqvdh2gdcuIsClDGLkLzSm12MY3Ah4RjB59GTK2WZiG2lYIYLKQ/xo9FFvVRQ==
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=xj6nP9rJnRIQqtmHpTgX7IyIlB89wXFzmKD39LQWPSM=; b=d8xysQfwU92dSy2DZTGRzUKdMa7qR68KhgaVuCdO+90cNOHq0TCc9x9wc5hjsdNLahPBzAwUu+CWOZjngZPo525g4VNtKg/frYdKM534CNIt/ZOLvTM+dFK7l+KpjXaEFQ4fE0jLp7vftS/u3KKLm8XJ1TJW0EY0bwOXikNc7WD3TtBht7lUqfVxxxZEHOODsZFBj5ifCNBp36DlIka1Ui1RN27Id2Q2gHsgzzqJSRSzEvLeHPIr0ezvxE8cDrPY37+kdLelhR8lUuoOuxXnhVV4QZhXFnh45KgZOblyqnWMTbSZyo9ccl6QfZvFD43gsUvaOja9UHuD+F0OvFf8OQ==
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=xj6nP9rJnRIQqtmHpTgX7IyIlB89wXFzmKD39LQWPSM=; b=Nt1vZNyAPYN8YkxSwsiUQgU90u23171jiVdJOxx+IODWOPrVPLQsi0gcdvVSuafKFsjBfk8OCLcwn18p1+lGYz2QMsxxbw4rGdbAv/x7i+lsJ4JbsZSfeDRciSeSixnkpmWzcLwd27Yo7fJE9GlkleaphGo/PSLWfQz/mKUrDK0=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB2929.namprd11.prod.outlook.com (2603:10b6:208:75::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.24; Thu, 25 Mar 2021 12:51:45 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510%2]) with mapi id 15.20.3977.024; Thu, 25 Mar 2021 12:51:45 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>, Lars Eggert <lars@eggert.org>, The IESG <iesg@ietf.org>
CC: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-bgp-ls-registry@ietf.org" <draft-ietf-idr-bgp-ls-registry@ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, Susan Hares <shares@ndzh.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Thread-Topic: [Idr] Lars Eggert's Discuss on draft-ietf-idr-bgp-ls-registry-04: (with DISCUSS and COMMENT)
Thread-Index: AQHXIOE4EhPUduMKMUSoQYPakDkPZaqTiOoAgAAVmwCAAPrxgIAAB/6w
Date: Thu, 25 Mar 2021 12:51:45 +0000
Message-ID: <MN2PR11MB4366DC7D110C598A43514F78B5629@MN2PR11MB4366.namprd11.prod.outlook.com>
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>
Accept-Language: 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: [82.12.233.180]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b50c6ad0-7918-4cfa-aef6-08d8ef8cbf5a
x-ms-traffictypediagnostic: BL0PR11MB2929:
x-microsoft-antispam-prvs: <BL0PR11MB2929C4DAD6E634A3F67F8F2DB5629@BL0PR11MB2929.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: Ri64h4Fpz515zryGsHYl6YEusmdFQNQIkLMzlAF5A7qN5QrhV2un8UZxAHjeuGFuqMXL/+A9o29eYvgJqL3cNBLpuQqtgDG3xFbUzSrJ8bRvaiCfmhN1T+x3mzg0sqKgSeQcGSPZdgRfoI2byPYAMrjJALtytZ2Vdu7VhxWY75ooxatdVTwmCdQV3MJGiEtVrWB9j2VTP27etfg8ivgWa6R56qjHa0rzxgq2XJu48TVL3i+mRYs/ExytJjqmmvIDDPq+EUHkkehYTf6kChxcebeo5N0AExQn3297IBwja5Fpkp2K6vD8A2VWoYZbWUQ4YOQI0BJ9mOcWqjIGhXRj8FDHifVl1U4vjLjHx+iUm3GEryFR6mCTCSDZlocJREZPQPnzDyN2rvVSkMagm4WAZzd3LZePBbDg+CEG5rY51pvVcpXiYUONbZ90B3X/g0UElON1Btgh79h42YQTFf0z19EC6N0jZfemX99EBNJ96hbw6+GW8mn/F7nNK6NNM85p5bFqmHLbVSS3elS32fuPCVtnaNA4uf/Zc/IfsTZDkZWfixe6ucYV/Qx+ZbK70vB+YWRfTxkNNlI7D+1F4POEe0nIFtOIUZbklrpxYEZ1xeKINVyYQ2P1iKVk+xnD0dnkBwqzBxEt5rsnIiWiNu+6ziRoKcjWlhRLSNf+QBBtDOM=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(136003)(396003)(366004)(39860400002)(346002)(54906003)(55016002)(52536014)(6506007)(86362001)(2906002)(4001150100001)(53546011)(71200400001)(478600001)(38100700001)(9686003)(316002)(186003)(8676002)(76116006)(110136005)(7696005)(66446008)(4326008)(66946007)(33656002)(66556008)(5660300002)(64756008)(26005)(66574015)(66476007)(8936002)(83380400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: OO6N9grG9BxnmVyGxus3ZnI9Ys6hf4CMiEuGBAsgRWTjbQ4Tq04Mrag3zkUHlUQlwjTHcNla1SmttJ4xjh29awdNvdyD5yzR4O98kHyeHVAjLYnubERfjRkz9Ksp4+oJuYYvOZxwn/ClR6ZfTLkWcoSqHkGDBTJ3rvGdvOK8SGCXltCDmSfNBTNKYrdsHL774NNpNnZwNKH4U9Ubz+Lz15H72BXFXpZ9ygDMMu60JcNVobux1Ht4sGntlRLA1vxoCaNcIe2uGVHf/06KyiAU7OzlVV3lfhhRqKwQxGU3ijMDYsbs95WGA6dImPYMRrq2a5nW85Ct8kuykkaPFu8v6njHKtQS/46a/RDvxJaBiINIvMVlwOxcPSyenGQHkMnQySoPBldRgp+IMUAK7zEl95/1BUo8MpVYGzNSBRICO6gWQ2BE7riStHNZkyS6i0DJHj/glF7O4rc7ghEVBH9kYUqS4dKJHrICGWuKoW5ArV70crVz7A2mPFXq5zGphpjpw6Y+Kyd0T3s6fp+u6GLRuS5qic+S9gxJCg1+oxiAUhQ32RQ+PqN5SaRi9CaRMq1h6WivS3tfwpIAZbFU++5cFVC1t6vkREUfBes6M0LG6JLz3oeiwCe+IuSS+do0Sh8BD9c+ZVWHaiVfs9ilT7aBGLGBruvpjHTBPrD/1mw+TZNU7tlmBkXnlACOMOVBvUyP5ShStx63B7EP1hmrb0ePVfwiWBQrlEh/M0nX56deXGMR6JJWzP93VhUmNBFGlMFFk1XJcjZWsdJKbSIN56s4WfkEcWHUL70AAnRSUVBO0GzRuevbEPpby4+kLYXiuuU2iYTluRLXQoTLiDDO9FnOTvSKKHXRWK6wKp3zrRAsPNhp2X+co8wzL5DAqmAZ+tkoa4SvyLNyGM1U4/yQsivTdIG5tDLuv63Ph3MLW3ZHa7WAJRmSNeUnWRSDl7Tq6m8NI7xSOqLluLyxdzzh2oqSF8R2l1/SCOIhYQ5NKKo2PfmMqdc9kBfZavXuH2vvEgvlSoBgj4dczGebmFk15YLbIUGNar4A5v4CBAAfSJiDD8cX7ebntkfEyqAiukaotxWBBr75jvS+hsscyI+YbfEGqTdFvPkz0zfDE08QUReHF+Rxds+K3IJTd9K/35vjfB+msKoW95CPACa4/JKiV2Jn2EiUVrqZim2zpH5vJYex0gDea8PV19hk3QdYMd3nrVhdVsm3AoE9KTtnOpc11EgvulozlEVf+6ARGoRPgSOV5edei1u+zlb43EfyjvuzRt0kjYL4iwkqzbwO3yOwGiGpaZWPEibKkBOfY3XVXEYjKmDU/3TOLnMp/nHJ95E+YTnz
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: MN2PR11MB4366.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b50c6ad0-7918-4cfa-aef6-08d8ef8cbf5a
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2021 12:51:45.6267 (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: 2Fb10PjYZUtPwL+YeFFbLh46L8yKfrJD1zFDqeXvMdU5hX6qTX1YF9lQF2d8hPXx0ZPPCz7G1DktObGwsbJqWQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB2929
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.21, xbe-aln-006.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/gTtisOjQEFfxkW3s9VNS_TI43WU>
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 12:51:56 -0000

To summarize my thoughts on this:

This document works around an issue rather than fixing it at source.  I.e., is every WG going to have these registry change documents to change their registries to Expert Review to make early allocation easier?  This seems like it will create a lot of unnecessary process work & RFCs, and I think that it will muddy the waters for what the registry classifications actually mean.

So, I think that the IETF needs to figure out how to make the process of getting IANA assignments easier for the WGs.

Given that IDR is finding this process to be unnecessarily burdensome now, and we don't know how long, or even if, IETF will find a general solution, then I'm supportive of the general efforts to streamline their process for producing technical standards now.

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.

Regards,
Rob


> -----Original Message-----
> From: iesg <iesg-bounces@ietf.org> On Behalf Of Ketan Talaulikar (ketant)
> Sent: 25 March 2021 11:54
> To: Lars Eggert <lars@eggert.org>; The IESG <iesg@ietf.org>
> Cc: idr@ietf.org; draft-ietf-idr-bgp-ls-registry@ietf.org;
> adrian@olddog.co.uk; Susan Hares <shares@ndzh.com>; idr-chairs@ietf.org
> 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