Re: [Lsr] John Scudder's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 19 May 2021 04:33 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 914693A1D97; Tue, 18 May 2021 21:33:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.595
X-Spam-Level:
X-Spam-Status: No, score=-9.595 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, RCVD_IN_DNSWL_BLOCKED=0.001, 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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=W1whOcM4; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OF/7mdL+
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 2_Qlx9M6DO1h; Tue, 18 May 2021 21:33:34 -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 917753A1D96; Tue, 18 May 2021 21:33:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17128; q=dns/txt; s=iport; t=1621398807; x=1622608407; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=x5+IzqAcSxXEPyu6qcuS/+zHIlhbDLW+FkKeO/P5468=; b=W1whOcM4IUpYHxuAHCr4v0fJ/n86j4jugdXdQE/ljIexa6r5Zv4OM/nZ XtMsGG5KNhatO32p5F3Thlhjs9v1NEfpDLKIpj1L6gdHe3524B0PVxran zElP08bz9mH2YJZP2oMkUsVa/dL1W3aaRE2S55E+FrFVDInnWZWFW1iQD c=;
X-IPAS-Result: =?us-ascii?q?A0ABAACvk6Rgl5pdJa1aGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQFAgUMEAQEBAQELAYFSIy5+WjYxhEeDSAOEWWCIdAOKP?= =?us-ascii?q?oUEiimBLhSBEQNUCwEBAQ0BASoPBgIEAQGETwIXgV0CJTQJDgIEAQEBAQMCA?= =?us-ascii?q?wEBAQEFAQEFAQEBAgEGBBQBAQEBAQEBAWiFUA2GRAEBAQEDASIRDAEBMAcBC?= =?us-ascii?q?wQCAQgRAwEBAQECAhkKAwICAh8RFAEICAIEAQ0FCIJpAYJVAy8BDp0TAoofe?= =?us-ascii?q?oEygQGCBwEBBgQEgTgDAYNbDQuCEwMGgRAqAYJ6hA6BE4VHJxyBSUSBFUOCX?= =?us-ascii?q?z6BUk1CBIEoHBwVgwA2gi2BWBFbBgE9JgEDU0grCAQZGEwFAgE4OJBSI4J6A?= =?us-ascii?q?UKIOp14WwqDFpEthlUEhVwRgjCBKpE4kC6VN4IWjRaQCIRUAgICAgQFAg4BA?= =?us-ascii?q?QaBVDiBW3AVO4JpUBcCDo4fDA0JFYM5hRSFSXMCNgIGAQkBAQMJfIl2AQE?=
IronPort-PHdr: A9a23:4FVcVxdKKyY6ZVS8DYOKQqgclGM/r4qcDmcuAtIPgLNVeaPl9JPnb wTT5vRo2VnOW4iTq/dJkPHfvK2oX2scqY2Av3YPfN0pNVcFhMwakhZmDJuDDkv2f/XrdCc9W s9FUQwt83SyK0MAHsH4ahXbqWGz6jhHHBL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4=
IronPort-HdrOrdr: A9a23:fyWSlaF8UR9Ezt6spLqFPZHXdLJyesId70hD6qkvc31om52j+f xGws516fatskdvZJkh8erwX5VoMkmsi6KdhrNhfItKPTOW9ldASbsD0WKM+UyaJ8STzJ856U 4kSdkDNDSSNyk7sS+Z2njDLz9I+rDum8rE6Za8vhVQpENRGtxdBmxCe2Cm+zhNNXF77O0CZe OhD6R81l6dUEVSSv7+KmgOXuDFqdGOvonhewQ6Cxku7xTLpS+06ZbheiLonSs2Yndq+/MP4G LFmwv26uGIqPeg0CLR0GfV8tB/hMbh8N1eH8aB4/JlaAkEyzzYIbiJaYfy+wzdk9vfrmrCV+ O8+ivICv4Dr085uFvF+ScFlTOQiwrGoEWSuGNwyUGT0fARAghKUfaoQeliA0fkA41KhqAg7E sD5RPri7NHSRzHhyjz/N7OSlVjkVe1u2MrlaoJg2VYSpZ2Us4ckWUzxjIeLH47JlO21GnnKp gmMCjW3ocYTbpbVQGTgoBL+q3bYp0eJGbzfqEygL3c79ENpgEN86Ix/r1pop4vzuNOd6V5
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.82,311,1613433600"; d="scan'208";a="721422201"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 May 2021 04:33:26 +0000
Received: from mail.cisco.com (xbe-aln-004.cisco.com [173.36.7.19]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 14J4XQcK014184 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 19 May 2021 04:33:26 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xbe-aln-004.cisco.com (173.36.7.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Tue, 18 May 2021 23:33:25 -0500
Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Wed, 19 May 2021 00:33:24 -0400
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Tue, 18 May 2021 23:33:24 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z5vBcHcniak0kO9o6TOpdSLeG0IwJlt+K0cDNknet0hYq7hI2q2KgHxP44SHUp2YaAorENDCqem/JmZT9XmGC/NZfbpOywDGVS5pXuxUwUbiea5D0CRmxl1kzeOQNiZwAaRIV48/g5/w9X9kckKwl9aIhi76Oa64Uzw1scoqYQcQkA0y5MaoQkaVsWePTFlatFIzt9aPeHIfja2hpH+ExlnoPzpvXLAQdYeAklf47+1vx8+zo4oljfCgWIFsCxCkoBFmw1zsrbTKWV8c1Wc+zsf5NWcLjWhhkHEjV17VhUED572cYI8aR6bHbQuSjyX+dPSxk7fgj7TbF9dKqinJ3g==
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=x5+IzqAcSxXEPyu6qcuS/+zHIlhbDLW+FkKeO/P5468=; b=Xaj/z8b71CMHuhhzP0wK4ONrg4kyeGiH6uqBDRJMOKQSpfjFQ6tWIFZpFS/q9x6s61tLKiwDuLMq2AUNcj6Ffjfxso25dcDiNGP4N55V1VH3Y0mr2WVBPy8TDyfqjEDd5Jmo3C8VrMtsmrUMQuJHj+iXtCcSAuCld8fveDRuMA1lHl0t5bydtcCuJKNRt0SEZ5NWIEe9LOe0h+thBrxmaYApJuc62ac8Oicfdx9WDGh9kNpWGb8PsrQT4v4AgRAchB+4lyKoZjz61NSWjU4tEV8tW2gP+fa/h4wCuI1ztdcsBg+G4Ua5XDdsmL8O2mwOycaIVYvc3k2EUPTkXkXOpw==
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=x5+IzqAcSxXEPyu6qcuS/+zHIlhbDLW+FkKeO/P5468=; b=OF/7mdL+LO3bNl069tBkOLoeVcM4gbPaCZFf7feHDUP7xEn7gYguIixF/qe0KI8Ek+fdF+lWrbzJwo3NC1L28d5Rc0S5Yxrr2Z+FcAT/iAdQsp9m+K7OfYQr3hYcQTxv8rYn5YShI7UKiWN9iNaIDccIuI5XsVTONi3AmVqrVXE=
Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by SJ0PR11MB4863.namprd11.prod.outlook.com (2603:10b6:a03:2ae::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.26; Wed, 19 May 2021 04:33:23 +0000
Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::5df9:c2f0:149e:56d2]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::5df9:c2f0:149e:56d2%4]) with mapi id 15.20.4129.032; Wed, 19 May 2021 04:33:23 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, John Scudder <jgs=40juniper.net@dmarc.ietf.org>
CC: Alvaro Retana <aretana.ietf@gmail.com>, John Scudder via Datatracker <noreply@ietf.org>, "draft-ietf-lsr-isis-srv6-extensions@ietf.org" <draft-ietf-lsr-isis-srv6-extensions@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, The IESG <iesg@ietf.org>, Christian Hopps <chopps@chopps.org>
Thread-Topic: John Scudder's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
Thread-Index: AQHXSCH+AH2CXfS+gE6KJPhpz9S1kKrhxjnggAW8Q4CAAANWAIAAGDuAgAAHeoCAAAI6gIAAAx+AgAAPeICAAn18gA==
Date: Wed, 19 May 2021 04:33:23 +0000
Message-ID: <BY5PR11MB4337B6F0E98672F7A3250A11C12B9@BY5PR11MB4337.namprd11.prod.outlook.com>
References: <162092059520.16031.2606295470570253120@ietfa.amsl.com> <CAMMESsw7V4YrsgUf9RR7GOqmTrc9T0gxVs7omF4E34zg0R2RgQ@mail.gmail.com> <8702605F-CF59-4F1E-B4CE-02951B894D1F@juniper.net> <BY5PR11MB4337994AA5C89060CAEE3E2FC1519@BY5PR11MB4337.namprd11.prod.outlook.com> <ddcfb6db-f5e4-1aa7-e45f-c9b5905de147@cisco.com> <CAMMESsyk0=ro8V3bVQddU=kn+Z7howEiCZ6mGP7bmFnWvMqXOA@mail.gmail.com> <CF010668-3238-4C01-BAC3-EB8A349EA169@cisco.com> <66662452-4BC0-4A8D-9392-12D1A3DAFF7E@juniper.net> <DB87B31E-22AD-468E-9EA9-4702BB270BE0@cisco.com> <a5991c52-1536-8d1d-6289-66d8fe2ae713@cisco.com> <BF31A944-CE8D-4598-A0CE-0971D93C4DFF@cisco.com>
In-Reply-To: <BF31A944-CE8D-4598-A0CE-0971D93C4DFF@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
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: [2602:306:36ca:6640:8cd7:5304:f62a:b1e]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2458f298-0e53-40b9-c049-08d91a7f3cde
x-ms-traffictypediagnostic: SJ0PR11MB4863:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <SJ0PR11MB48636B94DA45FD2C64D17C1CC12B9@SJ0PR11MB4863.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: tOeK/aeHr7iOiq3cR8/oYQ453Ki9FE6khLQG0hZJ1qv8S1QID/D6kQPrgbxeFv79ma6mqUgYMaTqYQYllaPDSBRfIuiCqQX+z9FSmKcgK2w18GGI3yU7gERy8q02Fdhg8A9Up98bnIME2IL2cpUCVoDal7reCaFr+mX/a8oFd/8dVUs/UuQQSP/nWz4oUNY1KVRpwC919GpMj9eTzCRnaMqiNV1uE7JGvxIzV9EpX7Ir0GzE+8BpxStYGAX2H/91XiWniNpvuZcw29j/EA8QNicbUZTipkj0CDiZQYvOJLpsq305ti7D8oad+LxuytArdJ2Ul0qoI4Marl8N6EJtxHO7OI2NZjO7Cn0HY/EyfZz4YJRuKr1vB+zDRaYJAGg2fV3IcLT/a7EcaSjfZzLtzq/F7kfaCK3paIH5MNwuxXqStH2mjnxTowcYoB3W+DrCM7a/WJbFFCmnQIX0Okl2ARDjDCPmFEYJs1qnjUhV4ICD2sLD5vVVNcvLpqr6133+Bybd9LFIKtxuAZjrzBQAyY6PY4W4utio0T8lbXGQ7lhsJW6mcvq8nrVcnWUiJjuDlUQEzClzm8nEEMfAiEFDU6TRdoZPf6PaHgdIjxaic3JckwGh66imPt0PgvEtbJFXqRpftI0787E2bMrXfNjBoB+QBOCilWKofw5dqUWjn/lWJz6ZWDzjE6fiNAWQUy/qQEF+5eoRnZic7cJ4MZ6B1g==
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:(396003)(39860400002)(346002)(366004)(136003)(376002)(7696005)(6506007)(53546011)(66476007)(54906003)(66556008)(966005)(110136005)(5660300002)(71200400001)(66446008)(64756008)(122000001)(186003)(52536014)(4326008)(33656002)(316002)(38100700002)(8936002)(9686003)(2906002)(83380400001)(66946007)(478600001)(86362001)(8676002)(55016002)(76116006); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?SXFtYlpGUWZRd2VhUGMxcWt4QVJ6cEhaeVBMcUdtNFBJd29CemEyQUJicG5E?= =?utf-8?B?YitFMWs4YUUvWUlIbzlnSE1mMExKVXN2MyswNEErN3dVUVJoWEY4b2xlRjJj?= =?utf-8?B?a1ROcms2Zm5CYU93c1Y4VEZhR0VyU3pIeVZyQ2s4NzVFYmtKY1d6RmlrMHJK?= =?utf-8?B?UXc1SHpZRXVXV2k1UmFTZWxOZkROeWtlem1EVGlnMVdqWms0QTNvOU5taWkv?= =?utf-8?B?UzNRdW9KZFhhTUg0aC94NmVnT1RWRHNGbnc1MWptNVQ4WkMyZ1NwdUUvenBU?= =?utf-8?B?VDdkdFJBelRESTVDYnRkYWphb1dwcTlEa1lhaXMvOFNTdDJJOE5hV0JzS2cw?= =?utf-8?B?cjVrOFpGTGVaRCtXaFdDT29WOFNReklUby9wQkswUm5TZ1Bmby93akhyMXVa?= =?utf-8?B?Z0U1VDRoN3IxclBiN3dDdGxhYnZHaklZaFlXWWlYdWVhVjZEWGFCMHZBQy9T?= =?utf-8?B?a2xlZXBjS3lZVzRWT2NjWDVQMzJtTlNGSlRSc1RGdlZZbUwwNVRtK21Oc3lS?= =?utf-8?B?bmhxRmRIanZDNHM3TGhUOU5TWGROa0N2WS9rQXdwc0QzamFlcG1YeUkrWFBP?= =?utf-8?B?M3ViWFJDdFZEK3h3NmE2U1hncmk5M1g4aWxhbXNYTXZrYUc1YmsvelhkaTJP?= =?utf-8?B?ZUpxVVIvUXZrdXFuaDgwU1hFbXc2SlorK3NyL3R6cDR4dFdCY2hZV3RwaGoz?= =?utf-8?B?UlhmUWY3M3FVM2E4OEdKd3RKeHp0Q00zZ2creHZwbkRFcVMwYUVHSmRtZjRq?= =?utf-8?B?Q05uanN0bFZkRlpTNERtcEROdnQ1UHRIMTB1ZEhGaEE0OVpGUU9mQVpHVVpj?= =?utf-8?B?a01Bd3phOUgvWGtIcURXclBvUG41YU9oTjBxQzBpekZoWjIrNW0xNGJtREFo?= =?utf-8?B?bmJvLzFXMXFqYytRVWJOOFNvRUUzazdlZXdyNmR4M284alQ2Y01FVWovb3Qx?= =?utf-8?B?eEZmWmNId0cwMy83TkFZTHVNSmxKaWNDalhRdGlQSUMvTnozUEliSjd1S0Yv?= =?utf-8?B?UXlpd1VQRit2UEJFZm04eFpqTnVOOTJDcnU1bElUUUZHSmdlL2lKMlpQSUNo?= =?utf-8?B?dTVJWjh4SWc1eENEby91QXpIOWF3NURob1VxTTVjRjltUm8rSndyeklqN3VI?= =?utf-8?B?a0U5UHF2L3Uzd0VaQjBESjJYZk1rZ0tjeUpFdW1paWdvUVlOYTg5WHRIR2lx?= =?utf-8?B?amw4M0FRb25Udk5EY0ZSQUxldG9VYWsyZjNKSVNrNVZtS3ptc01hajRRV0Mv?= =?utf-8?B?TTBqNTBXYko5TUhCK3dHOFkvUHp3TVFXMWZkNkw4VWphckZTQWhzbVpXWk16?= =?utf-8?B?ZmlxL3hseGRhaUxwT0dPWW9MbmcyemNkSDBiTkM2MlBKb0dKb0ZwVUxsZHZF?= =?utf-8?B?ZnorS0cyWEh4VUdCNjhPYUhnTE0xMFFQeUNJREFzR2pwUmlHMkh0cWErYUNx?= =?utf-8?B?eXpkdzBOTndLaVVneC9sNDdSNXdXTC9QcVFjcWVXRnNRRmNxcXhIalNienRC?= =?utf-8?B?cVVWNmEzalpQaW1QbkZuSm9ubVZoeDM5RG5TT3NRNko2TVhMQS9wYTFxbU9v?= =?utf-8?B?Y3hydDBBaVRSek1adWMzZ2hiRWVvTVhWQWlhcUE3WGlDMjBwVDM0clkwdU80?= =?utf-8?B?VGE2UHlnOVZ4andlaDV2V3MybmY0d2w0dEF4SXFpa2RxeUMzczBwdWgreGlm?= =?utf-8?B?UlczdXJrclFSN3hQWVZpVFVRV3Q0S25qdDV0N1dDZlZsa0tQWk9MY01LMFBI?= =?utf-8?B?M3lMN0txbzlscml5K2I2V0QxSGwvbVlybEJmaDhvWGpVaTM4cUdrSEZ6U2lv?= =?utf-8?B?K0NxVngxMVY3YkNZdDhuV3J3eXMxclRycnMxNUZzUW9BNEtRS3lNYmt4am4z?= =?utf-8?Q?xqzk32H1lgESY?=
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: BY5PR11MB4337.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2458f298-0e53-40b9-c049-08d91a7f3cde
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2021 04:33:23.1627 (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: EYLd+/kx/A7kv7JVIhcEXR750SqKwWnzwBuXBIlyoZPjV4VgzKAFwUAzJDyzmtHK05beAxGvJ0keGZhvdDId1Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4863
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.19, xbe-aln-004.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/crR4oGq8YsiEJx_pdN6Kh3IuHTw>
Subject: Re: [Lsr] John Scudder's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
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: Wed, 19 May 2021 04:33:39 -0000

Sorry folks - one more attempt to correct what I see as inappropriate dependencies.

Codepoint registries are created in part precisely to avoid having to update pre-existing documents when we need to add additional codepoints to the registry. The registry is the living entity and when additions are required we update the registry - not older documents which have contributed to the existing contents of the registry. Nor do we have to generate a new document to present the updated contents of the registry. All of that is handled simply by updating the registry.

The only legitimate reason to update an older document would be if we are actually changing in some way one or more of the existing codepoints already defined in the registry. That is not happening here.

The suggestion that RFC 7370 needs to be "updated" because draft-ietf-lsr-isis-srv6-extensions requires additions to an existing registry first created by RFC 7370 stands the dependency relationship between a registry and the document(s) which specify entries in the registry on its head.

The argument here seems to be that we are "changing the name of the registry" - hence the document that first created the registry with the existing name has to be considered as updated. This is illogical. The renaming of the registry in no way alters any of the existing codepoints.
This is certainly not what was done when RFC 8668 modified https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223  - another registry created by RFC 7370.

Perhaps the somewhat unfortunate choice of the name of the registry - which inserts the codepoint for all the TLVs supported by the registry into the registry name - feeds into this confusion.
If so, I would suggest renaming the registry to:  "Sub-TLVs for TLVs advertising NLRI".
The registry name would then never have to be changed and we could more easily avoid being drawn into an inappropriate use of "update".

   Les



> -----Original Message-----
> From: Acee Lindem (acee) <acee@cisco.com>
> Sent: Monday, May 17, 2021 7:03 AM
> To: Peter Psenak (ppsenak) <ppsenak@cisco.com>om>; John Scudder
> <jgs=40juniper.net@dmarc.ietf.org>
> Cc: Alvaro Retana <aretana.ietf@gmail.com>om>; Les Ginsberg (ginsberg)
> <ginsberg@cisco.com>om>; John Scudder via Datatracker <noreply@ietf.org>rg>;
> draft-ietf-lsr-isis-srv6-extensions@ietf.org; lsr@ietf.org; lsr-chairs@ietf.org;
> The IESG <iesg@ietf.org>rg>; Christian Hopps <chopps@chopps.org>
> Subject: Re: John Scudder's No Objection on draft-ietf-lsr-isis-srv6-
> extensions-14: (with COMMENT)
> 
> Hi Peter,
> 
> On 5/17/21, 9:07 AM, "Peter Psenak" <ppsenak@cisco.com> wrote:
> 
>     Hi Acee,
> 
>     On 17/05/2021 14:56, Acee Lindem (acee) wrote:
>     > Hi John,
>     >
>     > Yes – I think “updates” should be removed. Registries are created
>     > explicitly for the purpose of tracking extensions and every document
>     > that adds to a registry should not update the document creating that
>     > registry. Now if the definition or application of the registry were
>     > changed, which I don’t believe is the case here, then we could consider
>     > “updates”.
> 
>     RFC 7370 created the registry by merging multiple existing registries.
>     It did not really defined any new functionality.
> 
>     We are changing the name of that merged registry. Given that RFC 7370
>     did not define anything new, just defined the merged registry, one can
>     consider the name change as an update to RFC 7370.
> 
> Ok - I missed that. I agree with that it updates RFC 7370 since the registry
> name changed as opposed to simply adding code points.
> 
> Thanks,
> Acee
> 
>     thanks,
>     Peter
>     >
>     > Thanks,
>     >
>     > Acee
>     >
>     > *From: *John Scudder <jgs=40juniper.net@dmarc.ietf.org>
>     > *Date: *Monday, May 17, 2021 at 8:48 AM
>     > *To: *Acee Lindem <acee@cisco.com>
>     > *Cc: *Alvaro Retana <aretana.ietf@gmail.com>om>, "Les Ginsberg
> (ginsberg)"
>     > <ginsberg@cisco.com>om>, "Peter Psenak (ppsenak)"
> <ppsenak@cisco.com>om>, John
>     > Scudder via Datatracker <noreply@ietf.org>rg>,
>     > "draft-ietf-lsr-isis-srv6-extensions@ietf.org"
>     > <draft-ietf-lsr-isis-srv6-extensions@ietf.org>rg>, "lsr@ietf.org"
>     > <lsr@ietf.org>rg>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>rg>, The IESG
>     > <iesg@ietf.org>rg>, Christian Hopps <chopps@chopps.org>
>     > *Subject: *Re: John Scudder's No Objection on
>     > draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
>     >
>     > Acee,
>     >
>     > I think you are saying you prefer to remove the “updates”. Is that
>     > right? It was a little confusing given the reply chain.
>     >
>     > (I’ve already given my opinion but said I’m not going to go to the mat
>     > over it.)
>     >
>     > —John
>     >
>     >
>     >
>     >     On May 17, 2021, at 8:21 AM, Acee Lindem (acee)
>     >     <acee=40cisco.com@dmarc.ietf.org> wrote:
>     >
>     >     That we be my preference as well. We’ve had several discussions on
>     >     what constitutes “update” and I believe that the consensus was that
>     >     a document isn’t “updated” unless the current behavior is changed.
>     >     If we’ve done our jobs, protocols are designed to be extended and
>     >     these extensions shouldn’t constitute updates.
>     >
>     >     Thanks,
>     >
>     >     Acee
>     >
>     >     *From: *Alvaro Retana <aretana.ietf@gmail.com>
>     >     *Date: *Monday, May 17, 2021 at 6:55 AM
>     >     *To: *"Les Ginsberg (ginsberg)" <ginsberg@cisco.com>om>, "Peter Psenak
>     >     (ppsenak)" <ppsenak@cisco.com>om>, John Scudder
>     >     <jgs=40juniper.net@dmarc.ietf.org>
>     >     *Cc: *John Scudder via Datatracker <noreply@ietf.org>rg>,
>     >     "draft-ietf-lsr-isis-srv6-extensions@ietf.org"
>     >     <draft-ietf-lsr-isis-srv6-extensions@ietf.org>rg>, "lsr@ietf.org"
>     >     <lsr@ietf.org>rg>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>rg>, The
>     >     IESG <iesg@ietf.org>rg>, Christian Hopps <chopps@chopps.org>
>     >     *Subject: *Re: John Scudder's No Objection on
>     >     draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
>     >     *Resent-From: *<alias-bounces@ietf.org>
>     >     *Resent-To: *Yingzhen Qu <yingzhen.ietf@gmail.com>om>, Christian
> Hopps
>     >     <chopps@chopps.org>rg>, Acee Lindem <acee@cisco.com>
>     >     *Resent-Date: *Monday, May 17, 2021 at 6:54 AM
>     >
>     >     Peter:
>     >
>     >     Hi!
>     >
>     >     As John mentioned, "Since for better or worse we don’t have a firm
>     >     definition of when we do, and don’t, use “updates”, it comes down to
>     >     a matter of personal taste in the end.”
>     >
>     >     I rather you leave it in.
>     >
>     >     Thanks!
>     >
>     >     Alvaro.
>     >
>     >     On May 17, 2021 at 6:42:48 AM, Peter Psenak (ppsenak@cisco.com
>     >     <mailto:ppsenak@cisco.com>) wrote:
>     >
>     >         John, Alvaro,
>     >
>     >         do we have a consensus whether we need the update to RFC 7370 or
>     >         not?
>     >
>     >
>     >         thanks,
>     >         Peter
>     >
>     >
>     >
>     >         On 13/05/2021 21:12, Les Ginsberg (ginsberg) wrote:
>     >          > Alvaro –
>     >          >
>     >          > FWIW, I agree w John here.
>     >          >
>     >          > There are many examples – to cite a few:
>     >          >
>     >          > Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS
>     >          > reachability, IS Neighbor Attribute, L2 Bundle Member
>     >         Attributes,
>     >          > inter-AS reachability information, MT-ISN, and MT IS Neighbor
>     >         Attribute
>     >          > TLVs)
>     >          >
>     >          > …
>     >          >
>     >          > Reference
>     >          >
>     >          >     [RFC5305][RFC5316][RFC7370][RFC8668]
>     >          >
>     >          > RFC 8868 is not marked as updating RFC 7370.
>     >          >
>     >          > RFC 7370 is not marked as updating RFC 5316/RFC 5305.
>     >          >
>     >          > Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP
>     >         reachability, MT
>     >          > IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)
>     >          >
>     >          > …
>     >          >
>     >          > Reference
>     >          >
>     >          >     [RFC5305][RFC7370]
>     >          >
>     >          > Again, RFC7370 is not marked as updating RFC 5305.
>     >          >
>     >          > I think it is sufficient to request that IANA add the new RFC
>     >         to the
>     >          > list of References for the modified registry.
>     >          >
>     >          >    Les
>     >          >
>     >          > *From:* Lsr <lsr-bounces@ietf.org
>     >         <mailto:lsr-bounces@ietf.org>> *On Behalf Of *John Scudder
>     >          > *Sent:* Thursday, May 13, 2021 11:00 AM
>     >          > *To:* Alvaro Retana <aretana.ietf@gmail.com
>     >         <mailto:aretana.ietf@gmail.com>>
>     >          > *Cc:* John Scudder via Datatracker <noreply@ietf.org
>     >         <mailto:noreply@ietf.org>>; Christian Hopps
>     >          > <chopps@chopps.org <mailto:chopps@chopps.org>>;
>     >         lsr-chairs@ietf.org <mailto:lsr-chairs@ietf.org>; The IESG
>     >         <iesg@ietf.org <mailto:iesg@ietf.org>>;
>     >          > draft-ietf-lsr-isis-srv6-extensions@ietf.org
>     >         <mailto:draft-ietf-lsr-isis-srv6-extensions@ietf.org>;
>     >         lsr@ietf.org <mailto:lsr@ietf.org>
>     >          > *Subject:* Re: [Lsr] John Scudder's No Objection on
>     >          > draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
>     >          >
>     >          > On May 13, 2021, at 1:20 PM, Alvaro Retana
>     >         <aretana.ietf@gmail.com <mailto:aretana.ietf@gmail.com>
>     >          > <mailto:aretana.ietf@gmail.com
>     >         <mailto:aretana.ietf@gmail.com>>> wrote:
>     >          >
>     >          >   This documents updates RFC 7370 by modifying an existing
>     >          > registry.
>     >          >
>     >          > Also, this doesn’t seem to me like an update to RFC 7370. It’s
>     >          > normal for an
>     >          > RFC to update an IANA registry, without saying it updates a
>     >          > previous RFC that
>     >          > established that registry. I think the “updates” just confuses
>     >          > matters and
>     >          > clutters things up, and should be removed.
>     >          >
>     >          >
>     >          > In this case the document is not only registering a value.
>     >         It is
>     >          > changing the name of the registry, adding an extra column, and
>     >          > updating all the other entries (§11.1.*).  The Updates tag is
>     >         used
>     >          > because it significantly changes the registry.
>     >          >
>     >          > Still seems unnecessary to me, registries are moving targets,
>     >         citation
>     >          > of all the relevant RFCs in their references should be
>     >         sufficient. So,
>     >          > the registry would be updated so that it cited both this spec
>     >         and 7370,
>     >          > and someone wanting to know “how did the registry get this
>     >         way?” would
>     >          > be able to work it out.
>     >          >
>     >          > I’m not going to fight about it; the “updates” is not very
>     >         harmful. I
>     >          > say “not very” because the diligent reader might be led to
>     >         think they
>     >          > need to go read RFC 7370 in order to properly understand this
>     >         spec, and
>     >          > waste some time realizing that isn’t true. Since for better
>     >         or worse we
>     >          > don’t have a firm definition of when we do, and don’t, use
>     >         “updates”, it
>     >          > comes down to a matter of personal taste in the end.
>     >          >
>     >          > $0.02,
>     >          >
>     >          > —John
>     >          >
>     >
>