Re: [Idr] Next steps: Debate about IANA assignment policies for BGP-LS registries

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Thu, 03 December 2020 07:44 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 0ABF03A0962; Wed, 2 Dec 2020 23:44:29 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=N8ICF+ZR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0DFGz/sc
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 P21XwQPXyh3l; Wed, 2 Dec 2020 23:44:24 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5063A0940; Wed, 2 Dec 2020 23:44:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=83993; q=dns/txt; s=iport; t=1606981464; x=1608191064; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VXUWMYIBVFKQKqn0pLuFwcsLhmOsO3FzsL6vYiMM1PA=; b=N8ICF+ZR+4UZS/YqyR7gPVuZ3r8WEIsjctsyy15oTWkGRHWwj1y12aL5 lF0KREw+QR/gKk/4EmifdPPfSx9mbDmDW9uzXOm27NDFMXaoW70LzP171 uU+VJGHhcgxGAiNpITTV/YM8cIlouRWkRllMs0Zkzc0GgNyD3TE1k73jf 0=;
X-Files: image001.jpg : 356
X-IPAS-Result: =?us-ascii?q?A0AuCQAZlchffZxdJa1fA4N7LyMGKHxbLy6EPINIA41ci?= =?us-ascii?q?heEcol/gUKBEQNPBQMBBwEBAQoBAgEBGAEKCgIEAQGESgIXgX0CJTgTAgMBA?= =?us-ascii?q?QEDAgMBAQEBBQEBAQIBBgQUAQGGPAyFcgEBAQEDAQEDAQwICQIIARIBASUEA?= =?us-ascii?q?QIIAwELBAIBBgIHCgQBAQYBAgoOAQYDAgICBRABCQMCAQsUCQgCBAENBAEGA?= =?us-ascii?q?gYNB4I5TIJVAy4BDo9ZkGsCgTyIaXaBMoMEAQEFgUdBgyANC4IJBwmBOIJzg?= =?us-ascii?q?2gOgQYzhR4bgUE/gRABQ4FXUC4+ghtCAQECAQGBQQEbFQoFBwkICYJQM4Isk?= =?us-ascii?q?DUhNQOCdYcmgVKKVINRhGIDXodFVwqCcoc7AoFcSoVRUoYWhTqDIYohF5IVg?= =?us-ascii?q?jaSBYFtggKJBoJ1jkwcAYQvAgQCBAUCDgEBBYFtISyBLXAVO4JpCUcXAg2OW?= =?us-ascii?q?IM6hRSFRHQCNQIDAwEJAQEDCXyPKAEB?=
IronPort-PHdr: =?us-ascii?q?9a23=3ABfhykRLnEc7Rn5z6A9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvKk/h17SVoKd4PVB2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkNUA835IVbVpy764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D=?= =?us-ascii?q?3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,388,1599523200"; d="jpg'145?scan'145,208,217,145";a="629602656"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Dec 2020 07:44:22 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B37iMfg021717 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Dec 2020 07:44:22 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 3 Dec 2020 01:44:22 -0600
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 3 Dec 2020 02:44:20 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 3 Dec 2020 01:44:20 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hkj0fNF6MjgStri8nbyocfRbaeIgvCtUDMIpY3NibJi6TZDXkqozdYiDxBM9aXZD/OkY+9TrgeBY0Hfe9HX4dp8iXFBzCtHf9ZQ9g3PmG5oGuToOb7WIzX80c4wR7hJT+DoviLkesa/qpFtIoHjACrMIuEzwhJYf2FHRwIyUHYWP6zJh9FUbNon6GnHR4bO1q9MfajqdFVFX1fa9B1CkSXDCniNk6YwXE1TH0O05vuMJIPO+NUB3HpGGppfHH9P1V4K7PDxgl38DcCf9OwdaMbB7wotTWzjplg6JKtGOarKk+YtTjif3TNShJEghj32GUbxrxZ9FBGg1y3T2ltfiuA==
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=+tkzh/zGwId9E2KxXwgDRhghz75nsfj/hawlmAcCVOg=; b=DpmuE5C8M006SkS5BueUgoC1Mh7YPLIMd7ioRU8ca86exb4stW+bp8EU/ICh2rQjT3kMs00dRMFAB37nwADyWTf2rIY7nHr+DQWo1CrViPzqx2d/h1zjbqOTEuZSihgt5BSyE9+M3DAvmwhaqS5dSFMAuWVLbgAY/v4SaeNE6DYAgy/MNDnOipR7Q9Emc1RPr2Io+rCtHPSP6AovbZwbdZQcwsC1XwcdB8KrSFZpmz7aiIvW+0TC5O3h7PlG2t53QmA1v2orJmvLx9TnSp+JTzJxLJuyGFSv0z7RbtFtmD7W3oHU8EWYByd4jenzGwRuPLqdyR/NwoPqknyhGF4i6A==
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=+tkzh/zGwId9E2KxXwgDRhghz75nsfj/hawlmAcCVOg=; b=0DFGz/scLwxFCbdmwlBT9SwncZHK/0JVEMvC+XAEhTtrr5AVpMYB/W0VKOr03QNxerQLZFpoG0X+dOK95DZxPxq50jidWUWtdGJJshYWhQ8fhlVzSUSxUbs4f1zkNLVeZ6B8bo8posCZpk5dQoRWAvquGgeznTRAEDQMqyER9K4=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4747.namprd11.prod.outlook.com (2603:10b6:303:2f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.25; Thu, 3 Dec 2020 07:44:19 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::bcfe:ddee:3f3e:577]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::bcfe:ddee:3f3e:577%5]) with mapi id 15.20.3611.034; Thu, 3 Dec 2020 07:44:19 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "idr@ietf.org" <idr@ietf.org>
CC: "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Thread-Topic: [Idr] Next steps: Debate about IANA assignment policies for BGP-LS registries
Thread-Index: Ada/AWPycnIQml0wTw+2ZUstQODBDQAAvCUgAAKh8GAAAxybkAACiKdgAA8JtLACeUe8sA==
Date: Thu, 3 Dec 2020 07:44:19 +0000
Message-ID: <MW3PR11MB4570B02C01A91DA0B1CCCFF4C1F20@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <00f901d6bf01$68e18150$3aa483f0$@olddog.co.uk> <BY5PR11MB433731C2C9C0A53918ADEC1FC1FF0@BY5PR11MB4337.namprd11.prod.outlook.com> <MW3PR11MB4570F71F76295EA42170D732C1FF0@MW3PR11MB4570.namprd11.prod.outlook.com> <MN2PR11MB4352A0BCA93741BE33DEB693C1FF0@MN2PR11MB4352.namprd11.prod.outlook.com> <MW3PR11MB4570F0196E47FE82658517EAC1FF0@MW3PR11MB4570.namprd11.prod.outlook.com> <BY5PR11MB433700F48B127431A1B1C49CC1FF0@BY5PR11MB4337.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB433700F48B127431A1B1C49CC1FF0@BY5PR11MB4337.namprd11.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2405:201:1006:a0b3:8cc3:4f89:193f:f394]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ce272b17-7d65-475a-3e43-08d8975f3e23
x-ms-traffictypediagnostic: MW3PR11MB4747:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MW3PR11MB4747EF8CC681F0A84F522ED4C1F20@MW3PR11MB4747.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: t61VGxozwcZOq4pFWe0l1mbDEKDLBliPgXCAA/F04sZvz2lKcG7cHGT9gTfrbPb3fXB4LbnmJft3DxAjArofk87PspnpwtsZcdsJm5g5h608DavMivnoNZFvrwEHwQVt+4XaaSNNTOIt/GK31OlaRv86hAuORjizN0SZQ9hyQUgHjPBBabE0NY8ir+hNj3zVRnGEI825FDTT0rY+b7IShpRcvnRtsA5VHpB4wmEuUEZCY8vd9MpmNs/lpwkUaKDlUHJz/yS7nTtyqzhza/0cyUAUYi59zb9JHELO6Ko8BaGC2/1q6J5RVdLZUl6g/x89olqzmwX6U4B3ku7ZoAiErgMqigovatIMHHzQtwlh8CojXsbgE+IacFm+DPe3lsuY8p3SkJ/tAUTqCASwAcWunA==
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:(39860400002)(136003)(396003)(346002)(376002)(366004)(478600001)(4326008)(52536014)(55016002)(5660300002)(110136005)(9686003)(7696005)(6506007)(8676002)(66574015)(30864003)(83380400001)(966005)(186003)(99936003)(71200400001)(9326002)(166002)(8936002)(66476007)(76116006)(86362001)(53546011)(66556008)(64756008)(66946007)(33656002)(2906002)(66616009)(316002)(66446008)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?UGNFMmkvU1pSdm9HK2RaSlV2YUY3WkU2eU1WT3BYaTNtTERxNGJXK0ZId0Vq?= =?utf-8?B?TnFhOVFBY1M4UVd5eHBPbzhrcVJTK2QwQmNJbTFoSWlUZ2d1RDRTTFRVcFht?= =?utf-8?B?Y2ExVzNBWkkvVzhtdnN4dDlvc1FHOHRXM3FuMjRmNGZIZnBERm9mNmdCdWxO?= =?utf-8?B?Tll1UUdYeTIyNWJ5cy9sSzJ0UVdDb2ZYQWpXbGJkanRXNURuNDI3OEhjcHBW?= =?utf-8?B?MkZ3ZUhHNWx6NnNpNDZNaVRZWkZocDJNdGhScXg1M1lvYnM0WC9CQlVqZjVr?= =?utf-8?B?NCtieDFjQzcrdkJ2RXVsK2pJRXlMSmVNRytTc1J6ejNtdjYxd3k0eVUvVWtP?= =?utf-8?B?V0V3bzNyQXVaNEE3VnlKL0ZXR1lKTExMaHdGRitPRG4xS0p4NG9VaUp4U2FG?= =?utf-8?B?a1lTdFErcGsrMWx5YWRHTkRHQVlrT1BEUy94dXR2cWdpY1pxNDJyR1VqSUE1?= =?utf-8?B?dXBIQ2RaNGcrVVp2WW1KUi9vUG1USkYxVk56b0hndGxmSm5FVTk1Tm84M014?= =?utf-8?B?aWgxZ0hrWU03RmEwdldGRWozYjJTZ2t4OHMrUFZjZ015QWVKazhTa0daZW85?= =?utf-8?B?WEpJbWE0NWoyVGdEL2VYeERvZEhHbmdGWCs3VEFoQTlrZyt0a1N0QkRWUEpw?= =?utf-8?B?cHU0Zmg4QWNrMGpkczIxUDh1OXpyRzRaOW91RDM4U0pOREp5R3dxZTl6WEdn?= =?utf-8?B?c2FKMlNuOWU2TjBkTW40c3hzclF0UHI3Z3RkNnZkZzZrSXA1SXgxeTQzN2hF?= =?utf-8?B?SlZid3lTMU9EaGs4eFZiem5Nd2k1QUpraWRrcmlESi9hdDVjSSs3dVVuc2Vr?= =?utf-8?B?b21nZXlVemNBYUpONGdkZGRsOEEzd3lxUFZhUlZmRnlITlgvdWpQMDBWOExZ?= =?utf-8?B?ZWhsVEpzNGJ1TklEeGNBU214a3o4b1gzSmRHblFMbFdhdllCUVR3M0pCZUVz?= =?utf-8?B?d0ZseGUwOUJ2Zk84U3piYi8ybS9wSnJMamRKalRJaGpLUE45NFFiK0xiVnN2?= =?utf-8?B?R2c3ZGdCNzVTMUhxTTV3bWswOGVhNG1VbEpwV2l0UlE0Y2RPM2ZGV2lXQ0Jn?= =?utf-8?B?QlFUMU4vOU1NSVVWRnYxb0xna2pCaFlNWVQ0ZisrYnovOG9nQ3FwdlZySUd2?= =?utf-8?B?bkQ5ZGNmT1lYMkczWFYrVTVucy81Um5YNTNVNjl1QklyMUdIZ0U3eVdCdS84?= =?utf-8?B?U3RXUVRkaVBrQ2h0SG1jdG5jK05vcEl3ZjlVNzIrV2FYRXduNkpadEtRcVJz?= =?utf-8?B?QzBaaXlaOHhKTVc0NFpsMkQ2amRMUTlwZjlKc1k4SjAyVFFONnI5T3FORHRZ?= =?utf-8?B?eXFXMTllZ0xCaVhoVWd5MUY5V3BiVVI5TmpzNzBKQ1ZWdzN1MkJWT3diYlJU?= =?utf-8?Q?25P9QyzNLDUo4aYexgEenIXxNRrZZbWc=3D?=
Content-Type: multipart/related; boundary="_004_MW3PR11MB4570B02C01A91DA0B1CCCFF4C1F20MW3PR11MB4570namp_"; type="multipart/alternative"
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: ce272b17-7d65-475a-3e43-08d8975f3e23
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2020 07:44:19.2800 (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: hFYlkK1x9pzL9fDQWEKjMjkwhmdl0idD2ME8PYEHsFFW5q0A3K5N5sezf6OHoHcMvPkEIi1v+FmD8nMXtI9kxA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4747
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/RInoRAQs0zP90LkBV81iNHutWlM>
Subject: Re: [Idr] Next steps: Debate about IANA assignment policies for BGP-LS registries
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, 03 Dec 2020 07:44:29 -0000

Hi Les,

Please check inline below.

From: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
Sent: 20 November 2020 22:59
To: Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org>rg>; Ketan Talaulikar (ketant) <ketant@cisco.com>om>; adrian@olddog.co.uk; idr@ietf.org
Cc: idr-chairs@ietf.org
Subject: RE: [Idr] Next steps: Debate about IANA assignment policies for BGP-LS registries

Ketan –

We might have to “agree to disagree” here – but a few comments inline.

From: Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org<mailto:ketant=40cisco.com@dmarc.ietf.org>>
Sent: Friday, November 20, 2020 2:19 AM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>; idr@ietf.org<mailto:idr@ietf.org>
Cc: idr-chairs@ietf.org<mailto:idr-chairs@ietf.org>
Subject: RE: [Idr] Next steps: Debate about IANA assignment policies for BGP-LS registries

Hi Les,

While I agree with you that garbage collection is hygienic it might be fraught with challenges specifically in the case of BGP-LS. We need to remember that unlike protocols like IS-IS, in BGP-LS most of the information is carried opaquely in BGP itself.

[Les:] I am amused by your use of the word “hygienic”. In this context we are not cleaning up things because they are in some way “dirty”. They are simply no longer useful.
Perhaps “recycling” is a more apt term?
[KT] Agree – bad choice of word!

There is a high potential to trip up implementations. While the option of just letting them be (even if un-used) is less harmful and certainly will not be disruptive.

[Les:] I don’t think there is a rush to reclaim, but you are advocating a “never reclaim” policy. On that we do not agree.
[KT] Let me correct myself – never say never 😊. My point was that RFC7370 points to RFC7120 for the deallocation process and that process requires renewals and is too “aggressive” IMHO in its recycling approach (Ref https://tools.ietf.org/html/rfc7120#section-3.3). That brings us back to the process overhead and pain with early-allocation that I thought we are trying to avoid for BGP-LS. Therefore, for BGP-LS, we do not need this part. The IDR WG group, at some point in the (hopefully distant) future, can publish a very short RFC to “reclaim/recycle” deprecated or un-used code points. That would be my suggestion.

Thanks,
Ketan

Coming to operators asking vendors for implementations – I would recommend that they look at the reference column in the registry to the document (and its status) where the allocation is made. That should give an appropriate indication and I can only be hopeful that operators don’t use IANA registries to put together RFPs 😉

[Les:] Good luck with that. 😊
Customers who closely follow IETF work won’t have issues. But there is a much larger population of folks who do not closely follow IETF work, but rely on the normative output to drive their RFPs. Certainly a codepoint registry is a normative output.

   Les

Thanks,
Ketan

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Les Ginsberg (ginsberg)
Sent: 20 November 2020 14:31
To: Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org<mailto:ketant=40cisco.com@dmarc.ietf.org>>; adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>; idr@ietf.org<mailto:idr@ietf.org>
Cc: idr-chairs@ietf.org<mailto:idr-chairs@ietf.org>
Subject: Re: [Idr] Next steps: Debate about IANA assignment policies for BGP-LS registries

Ketan –

For me, reclaiming codepoints associated w documents which do not progress is not about minimizing assigned codepoints – it is about garbage collection.
Otherwise, when you look at the registry(s) you see a bunch of allocations for things that never gained support – but folks (especially customers) wonder whether it is important to ask vendors to support it.

  Les


From: Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org<mailto:ketant=40cisco.com@dmarc.ietf.org>>
Sent: Friday, November 20, 2020 12:42 AM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>; idr@ietf.org<mailto:idr@ietf.org>
Cc: idr-chairs@ietf.org<mailto:idr-chairs@ietf.org>
Subject: RE: [Idr] Next steps: Debate about IANA assignment policies for BGP-LS registries

Hi Adrian,

On top of what Les has suggested below, I would like to provide just one comment.

The point (6) in the RFC7370 text would not (IMHO) be applicable for BGP-LS where we have an abundant amount of TLV space (unlike IS-IS). I would suggest this be dropped – so once allocated stays allocated. We could add some text instead that allows the requester to deprecate some TLVs (down the line) or for the WG to do the same via the usual RFC process.

Thanks,
Ketan

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Les Ginsberg (ginsberg)
Sent: 20 November 2020 11:46
To: adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>; idr@ietf.org<mailto:idr@ietf.org>
Cc: idr-chairs@ietf.org<mailto:idr-chairs@ietf.org>
Subject: Re: [Idr] Next steps: Debate about IANA assignment policies for BGP-LS registries

Adrian –

I think the text from RFC 7370 should be used.
Only thing I might add (between #4 and #5) is:

The Designated Experts must ensure that any other request for a code point does not conflict with
   work that is active or already published within the IETF.

   Les


From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Adrian Farrel
Sent: Thursday, November 19, 2020 9:53 PM
To: idr@ietf.org<mailto:idr@ietf.org>
Cc: idr-chairs@ietf.org<mailto:idr-chairs@ietf.org>
Subject: [Idr] Next steps: Debate about IANA assignment policies for BGP-LS registries

Hi all,

[Replying top of thread]

This is very promising: thanks for the input so far. I’ll try not to be so bold that I take four emails as overwhelming consensus, but it looks good.

The next step would be to wordsmith the DE guidance text. Currently we have:

   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.  Additionally, the DE must verify that any
   request for one of these code points has been made available for
   review and comment within the IETF: the DE will post the request to
   the IDR Working Group mailing list (or a successor mailing list
   designated by the IESG).  If the request comes from within the IETF,
   it should be documented in an Internet-Draft.  Lastly, the DE must
   ensure that any other request for a code point does not conflict with
   work that is active or already published within the IETF.

Issues appear to be (in no particular order):

  *   Alvaro thinks using 8174 language would be appropriate
  *   Do we require an I-D for *all* requests?
  *   What level of review from the WG / mailing list do we have?

     *   How long does it last?
     *   Does the DE have to listen to the review?
     *   Does the DE have to engage with the review?
     *   How are differences of opinion handled?
     *   Is WG consensus required?
     *   How are registry conflicts handled?

  *   Given the timing, do we now just wait for rfc7752bis?
  *   Should assignments that reference an I-D also include the
version number of the I-D?

For reference, the text in RFC 7370 is:

   When new I-Ds are introduced requiring new codepoints, it is
   advantageous to be able to allocate codepoints without waiting for
   them to progress to RFC.  The reasons this is advantageous are
   described in [RFC7120].  However, the procedures in [RFC7120] for
   early allocation do not apply to registries, such as the "IS-IS TLV
   Codepoints" registry, that utilize the "Expert Review" allocation
   policy.  In such cases, what is required is that a request be made to
   the Designated Experts who MAY approve the assignments according to
   the guidance that has been established for the registry concerned.

   The following guidance applies specifically to the "IS-IS TLV
   Codepoints" registry.

   1.  Application for a codepoint allocation MAY be made to the
       Designated Experts at any time.

   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.

   3.  In the case of Working Group documents, the Designated Experts
       SHOULD check with the Working Group chairs that there is
       consensus within the Working Group to make the allocation at this
       time.  In the case of AD Sponsored documents, the Designated
       Experts SHOULD check with the AD for approval to make the
       allocation at this time.

   4.  The Designated Experts SHOULD then review the assignment requests
       on their technical merit.  The Designated Experts SHOULD NOT seek
       to overrule IETF consensus, but they MAY raise issues for further
       consideration before the assignments are made.

   5.  Once the Designated Experts have granted approval, IANA will
       update the registry by marking the allocated codepoints with a
       reference to the associated document as normal.

   6.  In the event that the document fails to progress to RFC, the
       Expiry and deallocation process defined in [RFC7120] MUST be
       followed for the relevant codepoints -- noting that the
       Designated Experts perform the role assigned to Working Group
       chairs.

Best,
Adrian


From: Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>
Sent: 20 November 2020 04:03
To: Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@dmarc.ietf.org>>
Cc: Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org<mailto:ketant=40cisco.com@dmarc.ietf.org>>; adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>; idr-chairs@ietf.org<mailto:idr-chairs@ietf.org>; idr@ietf.org<mailto:idr@ietf.org>
Subject: Re: [Idr] Debate about IANA assignment policies for BGP-LS registries

Hi Adrian

I agree with Ketan as well on option #3.

Thanks

Gyan

On Thu, Nov 19, 2020 at 9:29 AM Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:
Hi Adrian,
I agree with Ketan and would vote for #3 - I thought the last thread was just wordsmithing the DE guidance and not grounds for a document reset.
Thanks,
Acee

On 11/19/20, 8:34 AM, "Idr on behalf of Ketan Talaulikar (ketant)" <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org> on behalf of ketant=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:

    Hi Adrian,

    First, thanks for doing this.

    You've provided 3 options:
        1. Leave the assignment policies and DE instructions in place per 7752 and state that they do what we want.
        2. Leave the assignment policies in place per 7752, but change the DE instructions to give explicit advice about Internet-Drafts.
    KT> I don't believe the first two options can solve/address the main issue why we went down this path. i.e. the "permanency" point for "Specification Required" in RFC8126 and what is there today in the I-D boilerplate. That is a different battle.

        3. Change the assignment policies to be simply "Expert Review" and change the DE instructions to describe what the DE must do.
    KT> I would vote for this one. "Expert Review" is what is already there in draft-ietf-idr-bgp-ls-registries. The only change required is the text for DE guidance and for that the text in RFC7370 (i.e. the way it is done in IS-IS) looks apt to me for BGP-LS.

    If there is more tweaking that the WG requires, then let us remember that https://datatracker.ietf.org/doc/draft-ietf-idr-rfc7752bis/ is following up right behind (hopefully very soon).

    The goal of draft-ietf-idr-bgp-ls-registries was to get a "quick point fix" RFC for the allocation scheme for BGP-LS code-points. IMHO stretching it out much further just defeats its purpose.

    Thanks,
    Ketan

    -----Original Message-----
    From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Adrian Farrel
    Sent: 19 November 2020 13:56
    To: idr@ietf.org<mailto:idr@ietf.org>
    Cc: idr-chairs@ietf.org<mailto:idr-chairs@ietf.org>
    Subject: [Idr] Debate about IANA assignment policies for BGP-LS registries

    Hi,

    You may have noticed some recent debate about draft-ietf-idr-bgp-ls-registries on the IDR list.

    It is possible that, notwithstanding WG last call, the draft doesn't correctly capture what the working group wanted.

    Since I hold the pen for the draft and am one of the Designated Experts for the registry, I will try to set out my understanding of what we currently have, what the document says, and what questions the WG may need to address next.

    [For the avoidance of doubt: I'm just trying to serve the WG and clarify the instructions to the DEs, I don't have much of an opinion about this.]

    The registries were created by RFC 7752 and currently make assignments according to "Specification Required." RFC 8126 (which post-dated RFC 7752) defines these terms in section 4.6. "Specification Required" includes the requirement for:
    - review by a Designated Expert
    - documentation in a permanent and readily available public specification

    Debate rages about the meaning of "permanent" in this context. Does an Internet-Draft count, does it expire, or is it archived by the tools page?
    Does an individual I-D count, or does it need to be adopted first? Does IANA track the I-D version, and if not what does it mean when a new version changes the meaning of a code point?

    As Alvaro, our AD remarks, IDR is not the place to have this debate. It is probably an IETF-wide debate and anyone is welcome to take it up with IANA and the IESG.

    What we need to do is decide what we want as our policy for these registries to be, and then work out how to achieve it. We can then set the DE guidance (see section 5.1 of RFC 7752) to achieve the right results.

    It seems, from various discussions on the list, that the WG (or some of its more vocal participants) want to be able to assign code points based on I-Ds and without requiring to do early allocation (RFC 7120). There seem (to me) to be three ways to approach this:

    1. Leave the assignment policies and DE instructions in place per 7752 and state that they do what we want.
    2. Leave the assignment policies in place per 7752, but change the DE instructions to give explicit advice about Internet-Drafts.
    3. Change the assignment policies to be simply "Expert Review" and change the DE instructions to describe what the DE must do.

    The current draft seeks to implement option 3.

    I'd note that a secondary issue arises about requests for codepoints arising from outside the IETF. Suppose another SDO or a vendor wants a code point:
    Do they have to write an I-D? Does it have to gain adoption in the WG?



    The chairs have a slide on this for the meeting on Friday. I'll leave it to them to decide whether there is time in the meeting to discuss the topic, but the agenda was previously full. Perhaps a discussion on this list would be better.

    Best,
    Adrian

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

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

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr
--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD