Re: [Idr] Robert Wilton's No Objection on draft-ietf-idr-bgp-ls-registry-04: (with COMMENT)

"Rob Wilton (rwilton)" <rwilton@cisco.com> Mon, 22 March 2021 13:08 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 396943A1434; Mon, 22 Mar 2021 06:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.696
X-Spam-Level:
X-Spam-Status: No, score=-7.696 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=O8koenpx; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=aGvOpEzO
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 1AR7yHVNQyU4; Mon, 22 Mar 2021 06:08:24 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB88F3A142F; Mon, 22 Mar 2021 06:08:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9370; q=dns/txt; s=iport; t=1616418503; x=1617628103; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qZbT4yc8zs05MAmzWczbC83cipyFWt3Lm6Y+Nk5p4Gg=; b=O8koenpxa10oiG7CRGxajqTrAAY57/YlceMYmqcjkJUCwHl81pjhwf/7 4qPeMEwJzbbKeLHJzhmJ9LgzxQ7nVAmvDcvsszHXSbS8syFEUbtoJg5Na BWrgw9yIi4a///vRZk0IU7m5JMb8sVrOWxDmywxUOl38OB58hq55DlRFw w=;
IronPort-PHdr: A9a23:8r4sQRcTbt9D1tzpe5OgxRzTlGM/S4qcDmYuwpM6l7JDdLii9J3+PUvZoO9gl0LNQZ6zw/VAh+bRvObrXiod4sXJvHMDdclKUBkIwYUTkhc7CcGIQUv8MLbxbiM8EcgDMT0t/3yyPUVPXsqrYVrUry616TIeHRq5Pg0zO+emUoLXht68gua1/ZCbag5UhT27NLV1Khj+rQjYusQMx4V4LaNkwRrSqXwOcONTlgtV
IronPort-HdrOrdr: A9a23:9+HwMaif/Cd3Z4c4R+Mh5Ko5jXBQX6tx3DAbvn1ZSRFFG/Gwv/uF2NwGyB75jysQUnk8mdaGfJKNW2/Y6IQd2+gsFJ+Ydk3DtHGzJI9vqbHjzTrpBjHk+odmu5tIW5NVTOf9BV0St6nHySGzGdo43Z2j+Kenme/Rwx5WPH5XQotLhj0JbTqzOEtwWQVAGN4dHJ2T+sJIq1ObCAoqR+68AWQIWPWGmsbCk4jobQVDKxks7gSPij3A0s+6LzGz2BACXzRThYoz6GStqX222oyPkdGejiXd2Wja8ohMlLLaqudrKcSQhqEuW07RoymyYoAJYczmgBkUp6WV5E8ugJ3wpX4bTrhOwlfwWk3wnhf3wQnn118Vmj/f4HuVm2Hqr8C8ZB9SMbs6uatjfhHU61UtsbhHucohtQ/0xvknby/opyjz68PFUBtnjCOP0AcfuNQOhH9SW5Z2Us42kaUj/VhYGJpFPCX25JFPKpgXMOjg5e1beV7fUnbBvmMH+q3UYl0PGH69Myw/k/3Q9wITsGFyzkMeysBatGwH7ogBR55N4PmBGrh0lZlVJ/VmLp5VNaMke4+aG2bNSRXDPCa5OlL8DpwKPHrLttre/Kg13ue3Y5YFpaFC2qjpYRd9jyofakjuAcqB0Nlg6RbWWliwWjzr14V464VmvKb/AJ7mKzeKRlxrs8bImYRbPuTrH9KIfL5GCf7qKmXjXaxT2RflZpVUIX4CFMIPvNI2XE+Pv9LLJoXmuvezSoeVGJPdVRIfHk/vCHoKWzb+YO9a6FqwZ3P+iB/NH3PhE3aPu65YIez/xaw+2YINPopDvkw+klKi/PyGLjVEr+gzdEt6K7X3j7OjqQCNjD/1xlQsHiAYIlde4b3mXX8PjxQNKVnIfbEKvMjaf3tT0nuBLhp2VNjXDwZbulRy9cuMXtit7BFnL+jiHnORjnMVqn7PZYwbgLe/6cDsfY59EowrQ7VrFQLAFwV8nAFjrGsrUn5dembvUhfVzYm1hp0dA+/SM+RmiACwOMhOtDb0rkOHv/wiQXMdQh+jWcOamhwVWjJRn1F9mpVv24aoqHKKEy8fiP59GEBQYG6XaYg2fTitVcFxoPTXXy1eCU2NnieXjhkvfHGCzTRjukXRaQuOef/KBVJBvGt/yaiCyiIvSkytO2Rtd3t9rYpxUUPBt3ob657WWoODl02Md1AF3uYRdAvgXAJXCAZvy9ervSTlxQqqHWk6x5koI+zWBKkidbaWwX+2NIiUj8g9boxp1YcgO9b0vuARV+WDPweTMTPjEussnxeYv3A/JUBP2TQZuOKt3B3u926j2nEjRfLUPVR9XrkeSuvspFTMVrKN0J9ji8gysvb1OmLtasSewaWSazJYMBvcrSq3SO4vwKok954apf92H5PBVyHP22wC1BIiLN3snEdbWb9l+tn6S/lSVt1Xfzgc8ksildyJIkduugvqAvUmdVVoi3PAJduG77fBtLJHODzMmCLgfV2EtyFN9fbMWCWOkaQXDK89OmxaYkkx4nYKxpLLS6TATAGxM+1T9luzNXGwNKJHQK+eALMKs1J05cqLk+L/TVu25CnA+T9gZqRA/GasTZnsXEaCGetU/8e7PlrJiK2w+8K3hCr2Tzz+a0lwv/wwSWUAKsBYzj8lh8kr1yL3TKr9qEcsiUFf7jFqjUSF4Pnu3E7LWUVddRTEiZBXVyRJOneGjc7Z4fGVvU6NlQRtyN3GDgNMZdlAFNgbU5jvIypvIcYWuqS0/6BHuFU1XD4+S2gmiD782Ot63bC2nPXKMteSe0vVBQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DwAQDplVhg/5xdJa1aGwEBAQEBAQEBBQEBARIBAQEDAwEBAUCBUIFTIwYoB4FQNjEKhDiDSAOFOYhAA4EJiSKEeYoRglMDVAsBAQENAQEyAgQBAYRQAheBZgIlOBMCAwEBCwEBBQEBAQIBBgRxhWENhkQBAQEDASMRDAEBKQ4BCwQCAQgRBAEBAwImAgICHxEVCAgCBAENBQgMghGDIQMOIQEDoVYCih53gTKDBAEBBoUVDQuCEwmBDyqCdoN5EIZEJhyBSUKBEUOCJDU+gh6CJIMUNYIrgU91BgEqOQEDLx8ZUh8TNDMDAQ+RHoJ7AUGLJ4kikH5bCoMGjAOEaIY9hVSDRIpqlhGVAY5ujyschEQCBAIEBQIOAQEGgWsjgVlwFYMkUBcCDY4fNoM5illzOAIGCgEBAwl8jBosgQoBMV0BAQ
X-IronPort-AV: E=Sophos;i="5.81,268,1610409600"; d="scan'208";a="605949678"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Mar 2021 13:08:22 +0000
Received: from mail.cisco.com (xbe-rcd-002.cisco.com [173.37.102.17]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 12MD8M5Q014955 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 22 Mar 2021 13:08:22 GMT
Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-rcd-002.cisco.com (173.37.102.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 22 Mar 2021 08:08:22 -0500
Received: from xfe-aln-004.cisco.com (173.37.135.124) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 22 Mar 2021 08:08:21 -0500
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Mon, 22 Mar 2021 08:08:21 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BUgjQbX4yKTf8/nuf8+ZZI3g6NHFj/XOCsDsSqfktcvvX41/yFFnx5i2FPZwLJgAcqsUJy/dOan3eziDQW+Mbp7jUBSToixsYY4uFjyVsKL09vfAEQ0OfJ+TTjNr8Y6oYP6QUK6WNXo366EKrHRVMQeMJdjNbMHgXXrUgFQKoPRZzbgXrXZ63jLyPsB4m0Iw3U8eqNin7CSw/1cSN/oSiBARtFaZ3DZ/hu4m0sakt3we0PPuqc6SQxtrmTvw4NFh3z/nFXE+mELydTigTezMiLwKKMEwLzlWHDqndS/xbyb2v0iAe7yaPZAArAqnnb/F8LI5/K1Demf4nRGsOfwWyQ==
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=qZbT4yc8zs05MAmzWczbC83cipyFWt3Lm6Y+Nk5p4Gg=; b=kB399eOiUOCzATYZLjF2ohTlpEOm8tjbNZg6bmv5qkWOrKTg9n1xMcbouVZuZMpdDwXkOJUxgiuHoIekGpnHvLD/G2RqOYmOSp2bKsNwWCgM6ADaqE5Lkz8evY+wI4g2cFF48kIzi140Q0noxnPowDdaZdhOb+hwqkqMgLh47MnsFgf+WbhuP6cCYuEDZVfEdlvD5wzoC+ivJybJEL/kETHT3ptzdxJ9v0upqAzZYNenZTbx25GPsPXn+zUytjRzJ7AQ7kbimAYr3Pm2pP8uxcWWy13LW6gppBNLFAtUe6Q7NgIhrD2hKa/zeEEK9R76YzO8SV8qyGkZmUYqgDivxQ==
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=qZbT4yc8zs05MAmzWczbC83cipyFWt3Lm6Y+Nk5p4Gg=; b=aGvOpEzOq2DzrSq7av7f8rpbjTj2mVlKytqD0s2R+k8xsATh6riBz9X8YaK3QdQsKWkOlP/xJaODoChnvUIjQsismisuGGw031qVOtSNuv9RuhPlQbV37VFEzTMQxGD1X2ag/qqPbDe2gvl3X2QChdFAyNuurPtMppzEK0nwzao=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3106.namprd11.prod.outlook.com (2603:10b6:208:7a::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Mon, 22 Mar 2021 13:08:20 +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.3955.027; Mon, 22 Mar 2021 13:08:20 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'The IESG' <iesg@ietf.org>
CC: "draft-ietf-idr-bgp-ls-registry@ietf.org" <draft-ietf-idr-bgp-ls-registry@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>, 'Susan Hares' <shares@ndzh.com>, 'Jie Dong' <jie.dong@huawei.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
Thread-Topic: Robert Wilton's No Objection on draft-ietf-idr-bgp-ls-registry-04: (with COMMENT)
Thread-Index: AQHXHwTl+D496TRfok+qCQSILcKoOqqP26OAgAAJsxA=
Date: Mon, 22 Mar 2021 13:08:19 +0000
Message-ID: <MN2PR11MB4366763012DE55C700DCA0BDB5659@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <161640836955.18618.16180119509370731142@ietfa.amsl.com> <09f501d71f0c$d895e610$89c1b230$@olddog.co.uk>
In-Reply-To: <09f501d71f0c$d895e610$89c1b230$@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: [82.12.233.180]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b4dc4075-e2ed-448e-53e4-08d8ed3390b9
x-ms-traffictypediagnostic: BL0PR11MB3106:
x-microsoft-antispam-prvs: <BL0PR11MB3106FABE7FD27CF7B87F3829B5659@BL0PR11MB3106.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: FHG/sb+mCQnLzonv5UVj2GEUHJz6vIenQg/JVL6hmuTp9MLA4OQZpHpKe+H5zU/58jYpMjjqyDlGxrADSrHnO/1+LPZ6F9m75v/6z/nooNmAgHlWpYS1e6qQfUH83FIZnZUb20Dar/iwcrYs/k/yVPCFe9H2W082+iaWDbAgd6NtwZbpvymtqntqZ4CMcTkhUD12/2KOrSJ/BxI0ub6nwIPHRnpDXIVhnh7un6kdR4eqXghji4hPsSQ+KHJ7tUTMir6c3ttTWXV+nH7q4z5JH2idtSE+RlzrdSvLVU31i6zz0p6/h1fEmAZZ2045heBfx0NikTHoKMKRZ0S9hFskToukY2SJMJV3YSLrGJ9jYmruwiKvOmz3xxfOAiPWsYZc0b7WLbvP7erdxooB4UdBJvawCCK0QRBmxwNH9uomIqtY5vNlD4OWwAvyzjUQVCQ8YzWksi93ufaUmyBnfkGBVQwUuraCVPAO2BCIJ27o8MAq8x0C+FyffnDDP7695TybmUlspYpNas1pGNycH26InzRxK1bbM9yzuDfB3FDtHXEoQbru3dMuu/r2L8r7jJzrttbvMi+K1MqlGc/XWFN2cX8rakZ8AHHiy6pkZWFqb9GiaWzInHTmj5nDRTImZ3+z5VQt63nU2odk8CjJqO6yO9La/UQZm1OOOVxkn8M5bUQ=
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:(396003)(366004)(39860400002)(136003)(346002)(376002)(4326008)(66574015)(38100700001)(8936002)(2906002)(71200400001)(83380400001)(26005)(55016002)(5660300002)(7696005)(66446008)(53546011)(86362001)(54906003)(316002)(8676002)(33656002)(52536014)(478600001)(9686003)(66556008)(110136005)(66946007)(186003)(66476007)(6506007)(64756008)(76116006); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: onoJF+KRMkyaRFaHCVK/6URzOrCG5HlckiAGxQyIQrLYwkF9bZ0dtZIgrNz2zfoWy3gzpcuru5yg5+gBavVxWWyx7xAMQFZvfDjNTdqRqH32gNhHHHGxG0PDehc8Y2ghq1FHuZVdiEUAXCoJtwa66bG3ZZbuWUszCn9q7NYwEscLzZMKULymyyLILi7jCuK/D8SxY72KkpLsXU0aa1tPnwx7Dhrk3Me7/Pwdj/+lbviKDtgIi92RJkd7c0bGHI3p5Q+suEGjpQL6kKNEKAra3QwuMpAwDbvol3B7yVIpmtvSMjB1B78X+OWSkiVLc0eRFf6S9bSR0OH7HzVIoKcKE/Qsez2G5H8JoSOBHW3wmAuMQsuMblAbBinWlL/eIWM4XZwQaDE61SVeTnQGpIkuDBJmTKXFbSBlPbOHY/1UjdVGHAjheeRs6xzHa2GGPuhZ1qDKXouj0RjFTvO/XGS7E+tujbRswCfGiSeGlYfQRUKEQJzM+htI5Nogxh2YLoA8yR6pORQdUy7g+bcSLB27DkHtWvc5a/5nkHs3WQZmVv0/MLw+XMGoRR+R3YDL+1+xVVpMN400jxodosQuaFDgimT9ySa2lEOrRAlM5F+XJzSLN75PlHwqCt9MZFfUul13GA76xS68fOisdPAyTRCnfsrmx8B1/LUMHOPrNe8LaZ/eARCGvlJRxxF0q/WVU83RbiOkuiThx640lAbwoHbq+QhhwKjmiLu0jNY/DThGtTyOVaUOrIIqGpMjYzmODwWfnxNpm2X+jD7lbIGShLRKkYQQhlthdXY+Gqul4pTvQBA/8IjG15TCa69RgSR6ioxzQbZbmXYj4Fy2GMQIIct02pfJEAL6scanncAEKP3Crk5IMji3Q5nlOeSRgHorKPhKLtFRxZ+3BIDoqE4j4ERitNCsCWSSYTkL3Gph7eJFpr6rhDYnq0Hyt8xqmMApWxjBD7lC11KQ7Utp6+/X35As+MlLVWKgl1C+h0C3XxTMui55tz9mjiw0sE5BL4tSjjvUqpUoNiNu2f/J+tiEMd7msR3i20St6q/75URt/pzWr2yPjedItiZuVtiTwuik39cw2vQ/UwIOh2FStsUycc0qMYndvNsJ1YAeDnlGFimovaF3WB1JnUzENc/np1h6phwnVpb2rUykGWyp2gqOd6ygxd7CZVdUyzBqI8YbuTsKVs4ZuIlzV4eESIRhF+R30SFRCvZaEKxYO7iKMxzc4jiMRPmnTpt6rDw+Cd1v8nsPtlghrTLgrctDXarMRvmtYyBIAyhTp5aOWlj/iiVj4lG10N0sMGdDAAsQ8+joA0AghO/8hEQj1jHbtn1lpb1FLyav
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: b4dc4075-e2ed-448e-53e4-08d8ed3390b9
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 13:08:19.6926 (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: UqdBu3Hsl2Mn30hctiov8YEoL+cZ0afFrIrw+citKcoLBm7TemG76UuttPE03v0H1lzJP/dW/GPCXWMzOSYGVA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3106
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.17, xbe-rcd-002.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/OB2_6Y5cZovfTxl5RJTpbLJlNwA>
Subject: Re: [Idr] Robert Wilton's No Objection on draft-ietf-idr-bgp-ls-registry-04: (with 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: Mon, 22 Mar 2021 13:08:28 -0000

Hi Adrian,

Please see inline ...

> -----Original Message-----
> From: Adrian Farrel <adrian@olddog.co.uk>
> Sent: 22 March 2021 11:17
> To: Rob Wilton (rwilton) <rwilton@cisco.com>; 'The IESG' <iesg@ietf.org>
> Cc: draft-ietf-idr-bgp-ls-registry@ietf.org; idr-chairs@ietf.org;
> idr@ietf.org; 'Susan Hares' <shares@ndzh.com>; 'Jie Dong'
> <jie.dong@huawei.com>; aretana.ietf@gmail.com
> Subject: RE: Robert Wilton's No Objection on draft-ietf-idr-bgp-ls-
> registry-04: (with COMMENT)
> 
> Hi Rob,
> 
> Thanks for chatting.
> 
> > My first observation on this document is that it does not really explain
> why
> > this change is being made.  I think that it would be helpful  for
> readers if
> > the introduction briefly explained why the allocation policy is being
> changed.
> 
> Answer is similar to that I gave Martin: we don't normally explain how we
> chose IANA policies in our documents, although there is often heated and
> confused debate about which policies to apply and how large ranges should
> be.
> 
> In this specific case, as pen-holder, I'm not sure I can put my finger on
> exactly why the WG felt it important to change, only that this is the
> result they wanted to end up with.
[RW] 

Okay.


> 
> But...
> 
> > However, I have the same concern that Martin raised, i.e., this uses an
> IANA
> > "Expert Review" classification where the instructions to follow are
> broadly
> > "IETF Review" or "Standards Action", and I don't understand why one of
> those
> > classifications isn't being used instead.
> 
> Both "IETF Review" and "Standards Action" generally require completion of
> the RFC process before allocation can be made. This is annoying for
> implementers in registries where new codepoints are being assigned thick
> and fast. It encourages squatting and conflicts.
> The "Early Allocation" procedures allow this to be salvaged, but those
> procedures come at a cost that the WG thought was too much:
> - the document making the assignment must be a WG document
> - the WG document must be "stable"
> - early allocations must be renewed yearly with the intent of a 2-year
> maximum
> OTOH, "Expert Review" allows assignment to be made once only, and also for
> "less mature" documents.
[RW] 

   8.  In the event that the document is a Working Group document or is
       AD Sponsored, and that document fails to progress to publication
       as an RFC, the Working Group chairs or AD SHOULD contact IANA to
       coordinate about 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.

But in section 2.1, step 8 (text above), my interpretation is that the expert review assignment is effectively only temporary until the document gets published as an RFC, and otherwise the assignment gets undone.  I.e., I still regard this approach as being a broadly equivalent approach to IETF Review + Early allocation.

> 
> But...
> 
> > Section 4.11 of RFC8216 explains that the use of well-known policies
> aids
> > community experience and wide understanding, and that the policies are
> in
> > increasing order of strictness.  But the use of "Expert Review" does not
> match
> > what I would naturally expect that IANA policy to mean.
> 
> I think it is not commonly understood that for "Expert Review", "The
> required documentation and review criteria, giving clear guidance to the
> designated expert, should be provided when defining the registry"
> [RFC8126]. Very many legacy registries don't have proper guidance for the
> DEs, but it is a fundamental part of the concept of "Expert Review" and
> this can be gauged by the size of Section 5 of RFC 8216 (10% of the whole
> document).
> 
> In terms of increasing order of strictness, do you think that this
> document has elevated "Expert Review" above the next category which is
> "Specification Required"?
[RW] 
My interpretation from reading this document was that it is logically equivalent to IETF Review + IANA early allocation, but aiming to have less IANA early allocation process overhead.

But it may depend on how this paragraph is interpreted:

   2.  The Designated Experts SHOULD only consider requests that arise
       from I-Ds that have already been accepted as Working Group
       documents or that are planned for progression as AD Sponsored
       documents in the absence of a suitably chartered Working Group.

I.e., what are the scenarios when the above SHOULD it not a MUST?  Is the intent here to allow a non WG draft to have a code point assigned?  Or is the intent that a non IETF organization is allowed to request an allocation (if the IDR WG agrees, as per step 4)?




 There is a debate to be had here about whether
> "Specification Required" includes the use of an Internet-Draft when it
> says "permanent and readily available public specification". This seems to
> me to be a Big Debate (TM) that the IESG might want to lead the IETF
> community through, but perhaps one that we don't want to use to gate the
> progression of this document. FWIW the arguments seem to centre around:
> - can an expired I-D be found in a permanent and definitive repository?
> - does the registry include the revision number for an I-D?
> - the I-D contains boilerplate explicitly stating that it is inappropriate
> to reference it
> - 8126 suggests that an RFC is an ideal means of meeting the requirement
> 
> But apart from that, 8126 says that "Specification Required" is the same
> as "Expert Review" with the addition of the requirement for a publicly
> available and stable spec.
> 
> I don't think that this document brings "Expert Review" close to the next
> in line which is "RFC Required".
[RW] 

Hum, it is interesting that I seem to have quite a different interpretation!

But perhaps the difference is when the allocations are made vs under what circumstances allocations are allowed to be made.


> 
> 
> So, all these words written and in brief, is there any action we should
> take for this document?
[RW] 

Obviously, I think that getting clarity on what the actual rules mean is probably important.

But otherwise, I intend to wait and see what the rest of the IESG thinks of the approach being taken here.  BTW, if you know it, please can you share the reference to the ISIS RFC that you cited as a precedent for this approach.

Thanks,
Rob



> 
> Cheers,
> Adrian
>