Re: [Lsr] When is an IANA Registry Required

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Tue, 16 March 2021 22:24 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594CA3A1195; Tue, 16 Mar 2021 15:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.59
X-Spam-Level:
X-Spam-Status: No, score=-9.59 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, T_KAM_HTML_FONT_INVALID=0.01, 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=P3GTgT16; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=w+5Yu9N3
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 gOsVYduzMRLS; Tue, 16 Mar 2021 15:24:22 -0700 (PDT)
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 3EB723A1198; Tue, 16 Mar 2021 15:24:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29878; q=dns/txt; s=iport; t=1615933462; x=1617143062; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BL1goAn67PkpfB+cYr7loraqiv4qWrf4v1qmIruWTgU=; b=P3GTgT1682WDZwy2WTnjauU/VxVP5yntA0Oqr41aRFvY/MIop1EM+Ivc dGvUKo65JD2Q8620oSSjHK/HelZWcVUpMKPqLnYVFeMqgP/WQ17IK3zDF jpWxkloqFKSz/cy7Jxg0NnEQ6UMuP+ptZBkW8w2+anu8K1OQSXF4RWoza g=;
X-IPAS-Result: =?us-ascii?q?A0BZAAC2LlFgkIoNJK1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBgg+BIzAjLn1aNjGEQYNIA4U5iEQDiieEeIoMglMDVAMIAQEBD?= =?us-ascii?q?QEBLAYCBAEBhE0CF4FfAiU4EwIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQEBA?= =?us-ascii?q?YY4DYZEAQEBAQIBIwoTAQE3AQQHBAIBBgIOAwQBASsCAgIfER0IAQEEAQ0FC?= =?us-ascii?q?IJoAYF+VwMOIQEOkSeQagKKHneBMoMEAQEGhSsNC4IUAwaBOYJ2hAcBAYZEJ?= =?us-ascii?q?hyBSkKBEUOCKi4+gh5CBIFfFRaCaTWCK4FYbAY+JgEDQxBQKwoMBxgUPwINl?= =?us-ascii?q?FCHUYxpkHdbCoMClw+FUYIggR6KXJV7lHSCDYxPjywNAYFJgnUCBAIEBQIOA?= =?us-ascii?q?QEGgWshgVlwFYMkUBcCDY4fDA0Jg02FFIVFcwI2AgMDAQkBAQMJfIsoLIIZA?= =?us-ascii?q?QE?=
IronPort-PHdr: A9a23:aVNghhfE2szDYzdfhp5ED0VBlGM/QYqcDmYuwpM6l7JDdLii9J3+P UvZoO9gl0LNQZ6zw/1BguvS9avnXD9I7ZWAtSUEd5pBH18AhN4NlgMtSMiCFQXgLfHsYiB7e aYKVFJs83yhd0QAHsH4ag7dp3Sz6XgZHRCsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57I Bis6wvLscxDiop5IaF3wRzM8RN1
IronPort-HdrOrdr: A9a23:cPBlwa0Wk/9fW+5yhYHI2wqjBeB2eYIsi2QD101hICF9Wvez0+ izgfUW0gL1gj4NWHcm3euNIrWEXGm0z/9IyKErF/OHUBP9sGWlaLtj44zr3iH6F0TFmNJ1/Z xLN5JzANiYNzdHpO7x6gWgDpIEyN6I7KiniY7lvghQZCtBApsQiDtRIACdD0FwWU1iDZ02CJ KT6qN81kSdUF4Qadm2AWRAYvjbq7Tw5dzbSDMlJzpi0gmBiju09KX3eiL54j4yWy5CqI1Sil TtvBf+4syYwpSG4z/ak1Te9pFH3Obmo+EzePCkrugwBnHShh2zZIJnMofy/QwdhO208l4lnJ 3tjn4bTr5OwkjcdG20vhfhsjOIuF1FhhOSqi77vVLZrcP0Xz48AcZa7LgpDyfx0VYqv913zc twrgSknqdXFh/JkWDc4NXFRnhR5zKJiEciiuIagjhjV5IfYtZq3PUi1X5Sea1weB7S2cQCKq 1DHcvc7PFZfRexdHbCpFRix9SqQzAaAgqGalJqgL3U7xFm2FRCi2cIzs0WmXkNsLgnTYNf2u jCOqN00JlTU84ta75nDutpe7r1NkX9BTb3dE6CK1XuE68Kf1jXrYTs3bkz7Oa2PLsF0YU1g5 aEdF9Dr2Y9dwbPBKS1rd922yGIZF/4cSXmy8lY6ZQ8kKb7XqDXPSqKT01rnNCnp/kZH83HS/ e+MJ9bGJbYXC/TMLcM+ze7d4hZKHEYXsFQkM08QUiyrsXCLZCvtuGzSoeVGJPdVRIfHk/vCH oKWzb+YO9a6FqwZ3P+iB/NH3fkekn1+4NsALHXltJjjrQlB8lpiEw4mF657saEJXlpqaotZn ZzJ7vhj+e8vmm5/WHB6m1zIRpDBkNJ4LHtOkk64DMiAgfRS/Iuqt+fcWdd0D+sPRlkVf7bFw ZZuhBq466tNoeRwiojEtqjNWqfgxIo1Su3ZqZZvpfGydbue5s+AJpjZbd4Eh/TEQdp3Sxwrn 1YVQMCTkjDNz/nhKm/lqYIDOXHe9QUunbyHedk7Vbk8WSVv4UGW2YSVT/Ga7/nvS8eAx5vwm BX34BaqryagjqrIXY4m40DQS1xQVXSJqlHAgSDbJhTgZbxdmhLPDy3rA3frQ0vcWz38EhXoW rtIUSvCKz2K2sYnGxE2aD3914xTEGhRgZbb3B3tpAVLxWdhl96zfKLaq2v02GYd1sFxaUHPC vYZCYJSzketOyfxVqbni2PGm4hwYhrNuvBDK47e7WWwX+1LpaU/Jt2UsN87dJgNNr0tPUMXv /acwiJLCngA+dB4X3fml81fC11omIji/XmxVns63W5xmc2Bb7XLE59T78WZ9Ga4G6MfYfD7L xpydY0t/C3KGP/d5qPzrzWdSdKLlfLunGtJttY36x8rOY3rv9+DpPbWTzH2DVO2wg/Nt79kA cbTL5g6L7MN4dzd6UpCm5k10tskM7KIFogswTwDON7Z10rgnPBN96C4rbDq9MUcwW8jRq1PU Pa/zxW/v/DUSfGyKUTDLgoJ39KLEc783Zv8Yq5BsLtIRTvc/sG+lW0MnWwKuAADKeEHKgdtR Z87ZWDmfSNey/xxQDXun96L8t1ghKaaNL3BBjJH+hCt8G+MxCLhKCh5caoljf5STehcS0j9M R4XF1Vat4GkyUoiY08zzO7RaP2qF80ilc220ATqnf9noy9pHrBFU5IMQfFkoxbUDlaPH+Pl9 nE+4GjpQPAySkA34LCGkdWdsxPHNZVTpGfFVYdFfQt
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,254,1610409600"; d="scan'208,217";a="685934176"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Mar 2021 22:24:20 +0000
Received: from mail.cisco.com (xbe-rcd-006.cisco.com [173.37.102.21]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 12GMOK2W024932 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 16 Mar 2021 22:24:20 GMT
Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xbe-rcd-006.cisco.com (173.37.102.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Tue, 16 Mar 2021 17:24:20 -0500
Received: from xfe-aln-004.cisco.com (173.37.135.124) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Tue, 16 Mar 2021 17:24:20 -0500
Received: from NAM04-MW2-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; Tue, 16 Mar 2021 17:24:19 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AcY9kUGOyYwowF5MLZKO7PU/9Igdbn7iJ2w3DmbHrjgQJ39QWRPA2jap8Lk+Hzqj+N9tB8uqD8j4r4u2GDrV4klcQ4RepGAbokm9CrUU+q7qmZRXwQYpKmDcf3lTz/WpCWK8DG2CJaUn/C97pqEHUb5UxIPq45FgKkfnrsk1oW1UhsM9sOY5pXqVAOEDHL5t9MJYqExRwPVT1FcCo8dDcBKV23z8wSVlwmhWSXLDkiliGpnGXqDwOvcUrLfYOe3t01glkTz9ERoHLB8bn+JoHeXor5jBoh/JbegI0uPpppc/Ge/jF1P/fD0M4hJl6O9gCh910QdLqFRyUoHvgqj0bg==
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=BL1goAn67PkpfB+cYr7loraqiv4qWrf4v1qmIruWTgU=; b=JuvPLwztG9oZsHM3PzgdOfmU9NQ0JDfw7aBUmrmVLj1sswtXw+F5gzeWIAwgDaotitgFPDgDCWe4q/NemdKohJKViTkpVjB1ucnG6JQQw4hn+61V7zyfWAidl1oz0bJiJvpjahBaJTjXmESJ2Vzq6v3wVAXSUuA931q6i7piH0IdKr5ILdDd8w9kdEoXNiggiWnDMpiLM7bQMHWWaGwfijOhqFz7wHsR9hbAFr9uuIuVaPfkw3Ip8AKjlopvVGHcFJeRnOaJb/ZIRpK5NJWJ8QH1FFnsqlx+bn/CQV05VK7FiW67uRo8du4gvcYh8L/LTL3ohT8K5q2m6BF2nE4+EQ==
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=BL1goAn67PkpfB+cYr7loraqiv4qWrf4v1qmIruWTgU=; b=w+5Yu9N3vwfC4/OPSqJ9HhpyRPSmHTLy3w7PDKkZPsQrycxm7F953xLUA9dNNu5jI1tfiSLGxqndVpCWRDS5zM5L/+zGBZTFCg0flpvDGXvx1yl67UQYCKqKBJJiWyaiHTzM0MNf1AFuexK4dIW528ADsfUWI+OBCMaKczgbWLk=
Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by BYAPR11MB3368.namprd11.prod.outlook.com (2603:10b6:a03:1b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.31; Tue, 16 Mar 2021 22:24:17 +0000
Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::b456:145d:f7fd:13ec]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::b456:145d:f7fd:13ec%7]) with mapi id 15.20.3933.032; Tue, 16 Mar 2021 22:24:17 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, "draft-ietf-lsr-isis-srv6-extensions@ietf.org" <draft-ietf-lsr-isis-srv6-extensions@ietf.org>
CC: John Scudder <jgs@juniper.net>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, Christian Hopps <chopps@chopps.org>
Thread-Topic: When is an IANA Registry Required
Thread-Index: AdcNLYhLNez6TE0ySSi5QWbUfILY7wNbnCuAAAONKZA=
Date: Tue, 16 Mar 2021 22:24:16 +0000
Message-ID: <BY5PR11MB4337AB9127DCEBDC780B52F0C16B9@BY5PR11MB4337.namprd11.prod.outlook.com>
References: <BY5PR11MB433721C068856ECE2AE4EC5DC19C9@BY5PR11MB4337.namprd11.prod.outlook.com> <CAMMESsyrUTPgkjEPy13W6DRv6ofbW9o_=H9C5bZD3cinGYDD_w@mail.gmail.com>
In-Reply-To: <CAMMESsyrUTPgkjEPy13W6DRv6ofbW9o_=H9C5bZD3cinGYDD_w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2602:306:36ca:6640:3549:95e5:d916:6e1a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cb013378-f0d7-43cb-f2ed-08d8e8ca3cab
x-ms-traffictypediagnostic: BYAPR11MB3368:
x-microsoft-antispam-prvs: <BYAPR11MB3368C313412EFACFC3B62AB4C16B9@BYAPR11MB3368.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6G8qJUXox/kXecWB9X5/tdhQfbBpuunHtBaq5uHYAgxpSlNiN5N7EDS2KeM9sxUIYWr2MQwjEUphTEttU/DhxFNKG9659juoKsycKMGi4HS366vOUcx45thQ4FL9diizOzL81e1/k+LHuOYx9duq11QYeDowfF1AxppmyKnzuZ7T0x454xMbgnZ6J1ZQi7OqBep7hdkkxe8sXBmLXAhIz9/EDRQgSbq4+bsI8/x0HNsJYf+4gMU4KNxSaDlU88H00paQolFNPhcPoQz1Wi4kvrydbbqveTXOhl56nvYrpa5IDGoCOLnG6dCDXZVbjTTjIPMHh0VGpLxwSzg6BLdhVEV9BJostBbZ49FOt62ayC0Av3F+7IdyWliiGhFeRmOPypNDAFouvustMv5oCwTqjk8fXc6hA63y9n5ubWT0zCV0ZnGYcrqo3jfkpU2a9w1z5/qc6NyjqUuo/R4O4xKXX8OYxK3MJfhRG9MOzj36qyKpg3z4Sbhq9tpz8raJ8hQed/rRJ7lNdVrrWO0GCQUZKcT3XrPkSONayeFM3ANyUwCDMQfM/jeuzdfnqWjC3TtA3FWi+wPU5IUs7yVQAa4G8YRLItgw46X9eYCnY6DCQ7/X5ERr9zWaNr36POoCA2rPaAh3rpRQUu6cjUkJx3D31Q==
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:(136003)(346002)(39860400002)(366004)(376002)(396003)(316002)(8936002)(66946007)(52536014)(7696005)(64756008)(76116006)(478600001)(86362001)(2906002)(66556008)(66446008)(166002)(71200400001)(66476007)(5660300002)(186003)(53546011)(6506007)(83380400001)(8676002)(55016002)(110136005)(9686003)(4326008)(33656002)(54906003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?QTNSZnd2ZVE3TlZLK1RocUIrZUtnOWJUak9uNHdtVE53Y1lheUJwQVY1ZDdx?= =?utf-8?B?Um4yYVYyQS9wdzFPTVYweERNNmorZFNmWGtjdVJDK1R4K0REM0o0dFlpZ29R?= =?utf-8?B?eC9vZUg5ZnJyL3BvZENVNzd3SWY2aFlsd3B3YmlyTGtYY0ZTb0JQTmN2YjA3?= =?utf-8?B?emJwY2MveE9JM25zWi8zS041cGgrRUpyUk44WW9mV0hZdWNjYit3UERkZDly?= =?utf-8?B?SjM5NDh1emM1SVhmNlpUbjlybTFYcUtJaUhJeXR2RzdOK3ZXcFRxVGVIZ1pu?= =?utf-8?B?MFQvVitQVnZuK2JVZmlRRmQzbGxkYWRLeHFSMFhkQlJweFQydlJlU3dHVHFa?= =?utf-8?B?ZzUwcXpoVm1NbURETTNDU2dYa3VuWDc4Uk9iSGQrS3V2RXhyYW9KYTZOYm1V?= =?utf-8?B?V2YxcVRrbUhSb00xNTNNYU9xcWVYR2lrSTNiZENhTlc4V0dveEc0QzdINEFI?= =?utf-8?B?dUFxNXdhS3plb2YyZUMyQkxKL1IrMVBQQUE5ZXZxazBWMjYrR09mWjJwRWhY?= =?utf-8?B?SXRsZ2dvaDhVVkpvVDQwZGtMVzJMMFh3OERLNXp2cmdlK0lTUWNmQVpZUW1h?= =?utf-8?B?R2dHR0Q4N1hsUmlQaEtYVVdUMUQwMEZjUGlJRFVWZGFpMHhEMmROa3kyblJB?= =?utf-8?B?SFdSMytzcjZuQUhVMHZjYTE2ZjZPMEszbmI2NUhmMUlMQUdETjR1YVVtQ0dT?= =?utf-8?B?OVREY0ZhOGMyZVUvYU5YY1FoZFQzWXZ4UjA1MnREWW5JYzB2MXVRbWxIZW9j?= =?utf-8?B?MkdmckIzdk13bmo4NkxEZTZWT0loL1Vab1kwdjV1TVlTbjNpd3BaMkNQaG1H?= =?utf-8?B?Rkh2WGxCc2t3MkM3dHBGeXR5TWpnMWZkOVE1Q29JalBlWFVwRTUrb21pS0pS?= =?utf-8?B?bXZ1aEs4by9SMENRR3U5WloxM1I5QXIvR2kxTlRMUUNKd21FVHFhKzczZC85?= =?utf-8?B?cUZTc0MrN002d05EM1BTYlN3aFNDWFlaR0U3K3hCRWI3T2xLeFp4N2U4b25I?= =?utf-8?B?WWpDdytJRDdmS0VxK1E2V3pEVUR6UlNxK09CNGZYVndTN3Z2a0FzWUNSU29B?= =?utf-8?B?VWorS25pdkhQZ2pKVklzMURkYmdJakQwckFRZ0RTdnlUcGVrQUFCQUJrOUU0?= =?utf-8?B?ZnNQNlAxK2hPdlhmdFVMTVFYcllmSzVQMXg5V2wydFhVWVpyY0toRjhIMEFZ?= =?utf-8?B?NlViNlZYN2ZVSi9ncnVyS0gxbGpFSEZ6TDNHKzFpdHpTamRuYWtSOThjUlQ0?= =?utf-8?B?SENXRWZCbUZTQ2NCNW9Rbjg0SFp2bHRLNW82eFFTMUxPYWhHVmtWU1JyeWdX?= =?utf-8?B?WVUwOStTYzFvK0tVOS9tYXlnRXdLK0RweGhiMXJOQ1dmK0Q1VXFpeUJNaWx3?= =?utf-8?B?NVAwcTRvNjAwUkcrWG0xeGlYS3RuKytRc1A3bGNqVTJRQWJHNWZYV0lEKzJM?= =?utf-8?B?Zi9EV0c5SU50VVVIbm82NUUvc1VnblJ6K21VQkszcDNjWjdhQlVpSmFyRU9T?= =?utf-8?B?cTV3UkdGZWtvNXpzcXg3M0FpbDR1dnpQQkE1K2t3VEsxYkFSaHJ3Nm12c0JH?= =?utf-8?B?cXQ3dE0rL0srUGg0UzdKTUlvU3IrSE9vcmpjQUwyK3hmSWgxaE13RjJnOFRJ?= =?utf-8?B?VFQ1azh1L0FOTVRsQUM4YjFkTUJqL1c1cEpSQ25Wck9PbHlFRnNPWWJCaWRJ?= =?utf-8?B?ODNUVVl1cDlpS2h2RHJxSkRseFBZdjIzRzhUclh5THBWU0V1bm1WdURLd2pn?= =?utf-8?B?K2ZGV0tOVGJ4bGN0S0dJeTZqOWtvNldQMGRXNnRLN1Azb3lKRlM0Rk9YVmxo?= =?utf-8?B?SDYzc1ZlaW1wUTFFeHVKaDNJK09OVnBNbFVjTGNsRCtnek40SGJTYm14Vit4?= =?utf-8?Q?nMYnfXay8inQd?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY5PR11MB4337AB9127DCEBDC780B52F0C16B9BY5PR11MB4337namp_"
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: cb013378-f0d7-43cb-f2ed-08d8e8ca3cab
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2021 22:24:16.9526 (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: QO2c607U+AJ87pQ/09Dlg6u21+u1eAmp3BYaqpsEHFw3Ch9zPwPqct29Ly/xcrxkT3uwwHdyj5roZh0laz8bZg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3368
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.21, xbe-rcd-006.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/_YCeMVuZfWAyGWKy6FgmpQVX_V4>
Subject: Re: [Lsr] When is an IANA Registry Required
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Mar 2021 22:24:25 -0000

Alvaro -



Thanx - as always - for the thoughtful response.



I would like to state up front that I would never consider you to be a "casual reader". ๐Ÿ˜Š



I am also glad you are opening this topic up to comments from others - that was my intent as well.



But one thing I find missing in your response is some info on what problem YOU think needs to be addressed?

Do you think there have already been cases where assignment of the bits in the flags field associated w a prefix or a neighbor or other object comparable to the new TLVs defined in draft-ietf-lsr-isis-srv6-extensions (e.g., Locator) has become confusing due to the lack of a registry?

I'd like to think you are motivated by more than a theoretical concern but have at least one example based on your many years of experience working on protocols.

Such an example would help me understand your motivation better and might even convince me that this is a good idea.



Thanx.



   Les







> -----Original Message-----

> From: Alvaro Retana <aretana.ietf@gmail.com>

> Sent: Tuesday, March 16, 2021 12:39 PM

> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>om>; draft-ietf-lsr-isis-srv6-

> extensions@ietf.org

> Cc: John Scudder <jgs@juniper.net>et>; lsr-chairs@ietf.org; lsr@ietf.org;

> Christian Hopps <chopps@chopps.org>

> Subject: Re: When is an IANA Registry Required

>

> On February 27, 2021 at 12:57:12 PM, Les Ginsberg wrote:

>

>

> Les:

>

> Hi!

>

> Sorry for the delay...

>

> ยง4/rfc8126 presents some general arguments for creating registries.

> But let's talk about this specific case.

>

>

> I'm taking the liberty of summarizing your message this way:

>

> > Historically, we have created IANA registries for identifiers which are

> > likely to be needed by a variety of unrelated features supported by the

> > protocol. The expectation in these cases is that multiple documents -

> > largely unrelated to each other - might need to allocate an ID from the

> same

> > space.

> ...

> > What we have NOT done, historically, is create a registry for a flags field

> > which is not provided as a general purpose mechanism, but is specifically

> > scoped for use only within the context of the feature which defined the

> > TLV/sub-TLV. (There are many examples.)

> >

> > It is expected in these cases that if an additional flag is required, that

> > it will be defined in a document directly related to the original feature โ€“

> > either a bis version of the original document or a new document which is

> > marked specifically as an update to the original document.

>

>

> In general, the expectations about the future use of a specific field

> (as you describe them) are not always obvious to the casual reader[*].

> If the intent was clear, and the expectation ("bis...an update") is

> spelled out in the document then I would not ask about the management

> of the bits.  And even better, future specifications (when maybe none

> of us are around anymore) would have clear guidance.

>

> Having said that, and knowing that I am not the responsible AD for lsr

> anymore, I would be very happy if the WG decided on requiring future

> documents to be clear about the intended use and any requirements for

> the allocation of flags or other unassigned bits.

>

>

> Thanks for starting this discussion!  I hope to see other opinions.

>

> Alvaro.

>

> [*] Anyone else besides maybe the authors themselves, including me.

>

>

>

> > Alvaro -

> >

> > In your review of draft-ietf-lsr-isis-srv6-extensions you requested the

> > authors to

> >

> > "Please ask IANA to set up a registry for the Flags."

> >

> > in multiple cases e.g., the flags field defined in the new SRv6 Capabilities

> > sub-TLV.

> >

> > This isn't the first time you have made such a request (I believe I argued

> > against this in the past and you relented โ€“ but only temporarily it seems.

> ๐Ÿ˜Š

> > ).

> >

> > As it is a deviation from historical practice, I think it would be better if

> > the WG discussed whether there is a good reason to change our practices

> > rather than have this request be made based on the personal preference

> of the

> > current AD.

> >

> > Historically, we have created IANA registries for identifiers which are

> > likely to be needed by a variety of unrelated features supported by the

> > protocol. The expectation in these cases is that multiple documents -

> largely

> > unrelated to each other - might need to allocate an ID from the same

> space.

> >

> > Obvious examples are TLV/sub-TLV code points.

> >

> > In the case of flags, there are currently only two such registries:

> >

> > link-attribute bit values for sub-TLV 19 of TLV 22

> > (https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-19of22>

> codepoints.xhtml#isis-tlv-codepoints-19of22<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-19of22>)

> >

> > Bit Values for Prefix Attribute Flags Sub-TLV

> > (https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#prefix-attribute-flags>

> codepoints.xhtml#prefix-attribute-flags<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#prefix-attribute-flags>)

> >

> > In both of these cases the sub-TLVs were defining a general purpose bit

> > field. It was expected (and it has happened) that unrelated documents had

> a

> > need to allocate a bit in these fields.

> >

> > What we have NOT done, historically, is create a registry for a flags field

> > which is not provided as a general purpose mechanism, but is specifically

> > scoped for use only within the context of the feature which defined the

> > TLV/sub-TLV. (There are many examples.)

> >

> > It is expected in these cases that if an additional flag is required, that it

> > will be defined in a document directly related to the original feature โ€“

> > either a bis version of the original document or a new document which is

> > marked specifically as an update to the original document.

> >

> > Management of the flag space in such cases has never required the

> overhead of

> > a registry.

> >

> > You seem to want to change that and I would like to know why?

> >

> > What problem exists that you are trying to solve?

> >

> > IMO, such a policy is not needed, does not add value, but does add

> additional

> > overhead to what is already a considerable set of hoops which drafts must

> > navigate on their way to becoming an RFC.

> >

> > The number of existing TLV/sub-TLVs which have flags fields is significant โ€“

> > and the lack of a registry for these fields has not yet caused any problem.

> >

> > Appreciate if we could have open discussion on this.

> >

> > Les