Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-spring-sr-replication-segment-19> for your review
"Clarence Filsfils (cfilsfil)" <cfilsfil@cisco.com> Wed, 14 February 2024 08:27 UTC
Return-Path: <cfilsfil@cisco.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60466C14F702; Wed, 14 Feb 2024 00:27:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.906
X-Spam-Level:
X-Spam-Status: No, score=-11.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIaAQQGX5eDK; Wed, 14 Feb 2024 00:27:20 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D447CC14F604; Wed, 14 Feb 2024 00:27:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; i=@cisco.com; l=49256; q=dns/txt; s=iport; t=1707899239; x=1709108839; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KSnQc3x380WTpRARDAN+7fE7Y7xwnkEXUb+n8Rq0QDM=; b=iYCeh6uTGilrqpA4NHhXuyYDI7dUKe+BVwrX1p/U5hnzG/JACiWV4xx9 DM4Sv99hfp1ia/YuAQbnmspGo0HYPlukpRh/Bk1OOvblwCQgdFwRb3p00 3yFRJyD6AY02yNjUvPoe5wfjcLkhDkkvqTBGo5kZLscjWdKo1aSCBL/Ww M=;
X-CSE-ConnectionGUID: rKUCC77gT3mbg/XK6sDoNg==
X-CSE-MsgGUID: CPSeIcV5RaG8hmi4jCUBXQ==
X-IPAS-Result: A0ABAAAEeMxlmJ1dJa1aGQEBAQEBAQEBAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAJYEWBAEBAQEBCwGBZlJ6AoEXSIRSg0wDhE5fhkiCIgORQYYtgTiEYBSBEQNWDwEBAQ0BATkLBAEBhQYCFodEAiY0CQ4BAgQBAQEBAwIDAQEBAQEBAQEGAQEFAQEBAgEHBRQBAQEBAQEBAR4ZBQ4QJ4VsDYZPAQEBAQEBARIIAQgEDToEBwwEAgEIDgMEAQEBAgImAgICLxUICAIEAQ0FCBqCXgGCPCMDARAGpSoBgUACiih6fzOBAYIWBbJ+gRouAYgLGgEFZWyDfYIlgjMnG4FJRIEUAUKCaD6CYQIBAYEhBAQBAQsGAQccCgsPgzU5gi8EgRV/gxIpgRYQgQUDgQI7AiVKb4MzYAIlgVw/AYZAAQcVWIVaCUt/HQNdKARaDQUWEB43ERATDQMIbh0CMToDBQMEMgoSDAsfBRJCA0MGSQsDAhoFAwMEgTAFDRoCEBoGDCYDAxJJAhAUAzgDAwYDCjEwVUEMUANkHzIJBzULBAwaAhsbDSQjAixAAxEQAhYDHRYEMhEJCyYDKgY2AhIMBgYGXSMWCQQlAwgEA1QDIXQRAwQKAxMHCwd4ggmBPQQTRgENA4E0ijMMVQNEHUADC209FCEUGwUEIB18BZ1UAYFcARAVCCUfASoHDCYEDQcECgUBCgkWAkYIAiMICgsIKwIZASMBBQYFARgGAQiNN4VFGgoEKoJgSYtmjgSTQwqBMAqEEYplgSOOHIcyF4QFTIwsAwGGcoZFhDiDbYJfZJhXIIIzixyVEBgUBBIKhQMCBAIEBQIOAQEGgWM6a3BwFRohgjMBMwlJGQ+BG40RDQkWgRyHOmCKBXgCAQE3AgcBCgEBAwmGTYIhAScEbWABAQ
IronPort-PHdr: A9a23:yEkktxFT5VORZPzJnR0MeZ1GfuoY04WdBeZdwoAsh7QLdbys4NG+e kfe/v5qylTOWNaT5/FFjr/Ourv7ESwb4JmHuWwfapEESRIfiMsXkgBhSM6IAEH2NrjrOgQxH d9JUxlu+HToeVNNFpPGbkbJ6ma38SZUHxz+MQRvIeGgEYDTi9+51uSa8JzIaAIOjz24Mvt+K RysplDJv9INyct6f7w8yBbCvjNEev8Dw2RuKBPbk0P359y7+9ho9CE4hg==
IronPort-Data: A9a23:9S3XgK6crBjKXaRV1JTrhAxRtBzHchMFZxGqfqrLsTDasY5as4F+v jNJCGGHOP+PY2H3KooiO4jipBsF7Z7Xm9VgSlRqqCBhZn8b8sCt6fZ1gavT04J+CuWZESqLO u1HMoGowPgcFyKa/lH1dOG58RGQ7InQLpLkEunIJyttcgFtTSYlmHpLlvUw6mJSqYDR7zil5 5Wq/aUzBHf/g2QoajhNt/rawP9SlK2aVA0w7wRWic9j5Dcyp1FNZLoDKKe4KWfPQ4U8NoZWk M6akdlVVkuAl/scIovNfoTTKyXmcZaOVeS6sUe6boD56vR0SoPe5Y5gXBYUQR8/ZzxkBLmdw v0V3XC7YV9B0qEhBI3xXjEAexySM5Gq95fdAkWUmpPMwHGddnHjhMVNUloaOqsXr7Mf7WFmr ZT0KRgXZRyFwumx2r/+FK9nh98oK4/gO4Z3VnNIlG6CS615B8GYBfyXure03x9o7ixKNf3QZ s4CZztrRB/BeBZIfFwQDfrSmc/x1iihLG0F+An9SawfyFDowS167uXXOfWFetmLGcd+o2yon zeTl4j+KkpHbIPEk2XtHmiXrubSgSOnCIsIH7256PNCmlOYg2EfCQERTx28u/bRolSwUJdSJ 00I/TAGt6Y5sUGnT8X6RVu/unHsg/IHc8BbH+t/4waXx++KpQ2YHWMDCDVGbbTKqfPaWxQw9 WKitIy2CgA0tbeaDkK+qKy4qhW9bH19wXA5WQcISg4M4t/GqY41jw7SQtsLLEJTpoClcd0X6 23axBXSl4kuYdg3O7JXFG0rbhq2rZTPCwUy/AiSACSu7xhyY8iuYInABbnnARRoctnxorqp5 SRsdy2iAAYmVs7leMulG7VlIV1Rz6zZWAAweHY2d3Xbyxyj+mS4Yadb6yxkKUFiP64sIGCxP x+P6FsBv8MOZxNGiJObharsWqzGKoC9RLzYugz8MbKin7AoLVDXonsyDaJu9z+1yiDAbp3Ty b/ALJ7zVixFYUiW5DG3XOwamaQ63TwzwHibRJbwiXyaPUm2OhaopUM+GALWNIgRtfrcyC2Mq oo3H5XRkX13DrahChQ7BKZOdzjm21BhW8CvwyGWH8beSjdb9JYJVKOBkOl5JNM890mX/8+Rl kyAtoZj4AOXrVXMKB6BbTZob7aHYHq1hStT0fAEVbpw50UeXA==
IronPort-HdrOrdr: A9a23:UgGJRKGygff/mXzwpLqFp5LXdLJyesId70hD6qkvc203TiXIra CTdaogtCMc0AxhJk3I+ertBEGBKUmsk6KdkrNhTItKOzOW91dATbsSobcKrAeQYREWmtQtsZ uINpIOd+EYbmIKw/oSgjPIburIqePvmMvH9IWuqkuFDzsaF52IhD0JczpzZ3cGPzWucqBJbK Z0iPA3wAaISDA8VOj+LH8DWOTIut3Mk7zbQTNuPXQawTjLpwmFrJrhHTal/jp2aV5yKLEZnl Ttokjc3OGOovu7whjT2yv49JJNgubszdNFGYilltUVAi+EsHfpWK1RH5m5+BwlquCm71gn1P PWpQ07Ash143TNOkmovBrW3RX62jpG0Q6g9bbYuwqgnSXKfkN/NyNzv/MfTvIf0TtngDhI6t MP44tejesPMfqPplWk2zGCbWAbqqP9mwtQrQdUtQ0fbWPbA4Uh97D2OyhuYcw9NTO/54Y9HO Z0CsbAoP5QbFOBdnjc+nJi2dq2Qx0Ib1y7q2U5y4WoOgJt7ThE5lpdwNZakmYL9Zo7RZUB7+ PYMr5wnLULSsMNd6pyCOoIXMPyUwX2MF/xGXPXJU6iGLAMOnrLpZKy6LIp5PuycJhNyJcpgp zOXF5RqGZ3cUPzDs+F2oFN73n2MS+AdCWoztsb64lyu7X6SrauOSqfSEo2m8/luPkbCt2zYY fEBHuXOY6VEYLDI/c84+SlYeghFZA3arxhhuoG
X-Talos-CUID: 9a23:WP+6sWlzQQJ29EXeKQqjQe9ScSnXOWf+8Vz7fBC3NT1sQrLSeXzO449jtcU7zg==
X-Talos-MUID: 9a23:a/FIcA9suk+RXxUuQarzL46Qf+xQ2KmPA35Qq5wp68mBNHByEAq3vA3iFw==
X-IronPort-Anti-Spam-Filtered: true
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2024 08:27:18 +0000
Received: from rcdn-opgw-4.cisco.com (rcdn-opgw-4.cisco.com [72.163.7.165]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 41E8RHq5005365 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Feb 2024 08:27:17 GMT
X-CSE-ConnectionGUID: feDuOH9PTO6vrTe4HKjHxg==
X-CSE-MsgGUID: s2EfIpihSY2IC21wI2ffaQ==
Authentication-Results: rcdn-opgw-4.cisco.com; dkim=pass (signature verified) header.i=@cisco.com; spf=Pass smtp.mailfrom=cfilsfil@cisco.com; dmarc=pass (p=reject dis=none) d=cisco.com
X-IronPort-AV: E=Sophos;i="6.06,159,1705363200"; d="scan'208";a="28271280"
Received: from mail-bn7nam10lp2101.outbound.protection.outlook.com (HELO NAM10-BN7-obe.outbound.protection.outlook.com) ([104.47.70.101]) by rcdn-opgw-4.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2024 08:27:16 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EiLA4Ng9AuX2PHIKF2zSiZtoDahxdQyNIunpHcIbi0HXYmbdjz42PiB3bDkpKXuG0mHaEoVS9cSdfEnKxMyO8BLBqJqA35DIRNMLuq+Pq0SL9qvTfX5HgMpCt6ymLbndBfaXqV56IVKK7eadwIkv/VrD4jrqQ6BQUJwTZWZV8XHJSTpgex2o2lftUI/tSldp0BNtfDyBj2TI5CyYssS9a1jwA74b9CtzYY43UM2RC9SnOaAotJ/YR+nMscyWNwhtZUsTr3mbBEhnGeh8GExi+HELI4ZfTzt4uYnyr9w4kDewkHi80FzcD558FalOtdXsl25lLTorHSk27qXShmfcxw==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KSnQc3x380WTpRARDAN+7fE7Y7xwnkEXUb+n8Rq0QDM=; b=UQ3N1O1RK/Bk8DzH/EfTT3FAIC1wOtYKV7u+cEumATrOm52DOO1KWZPJlniDbSbdRGCtSRzkMJF2/J2EZyN3QStsyNtQiQPd6LVutTzeQh4f/8AiY/KuHveUOjq+9FtsCU4dPprvQwcC76OPKm4737eDFg5MN/Ib6ckekT1QqtF/JxtJgMKI+6UH0Ml9QNnAnyMk2Prt/E96taQC/kCMaOk4GWKqJlssrfv0mT0xEO5UnsI3Xr4OgJK/CE5RAQhs2OBbNRhU9y9/rwJJgvxVcJjPM9NX4jfArspkKT9x9DMTtfgVaMzbWupRAxAoG0sz8fRkSnv13DU64pOGEj0rIg==
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
Received: from CYXPR11MB8711.namprd11.prod.outlook.com (2603:10b6:930:d7::9) by SA2PR11MB4986.namprd11.prod.outlook.com (2603:10b6:806:114::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7292.26; Wed, 14 Feb 2024 08:27:14 +0000
Received: from CYXPR11MB8711.namprd11.prod.outlook.com ([fe80::e183:c976:dbb7:6cf3]) by CYXPR11MB8711.namprd11.prod.outlook.com ([fe80::e183:c976:dbb7:6cf3%4]) with mapi id 15.20.7270.036; Wed, 14 Feb 2024 08:27:14 +0000
From: "Clarence Filsfils (cfilsfil)" <cfilsfil@cisco.com>
To: Megan Ferguson <mferguson@amsl.com>, "Rishabh Parekh (riparekh)" <riparekh@cisco.com>
CC: "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "daniel.voyer@bell.ca" <daniel.voyer@bell.ca>, "hooman.bidgoli@nokia.com" <hooman.bidgoli@nokia.com>, "zzhang@juniper.net" <zzhang@juniper.net>, "spring-ads@ietf.org" <spring-ads@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>, "Mankamana Mishra (mankamis)" <mankamis@cisco.com>, "james.n.guichard@futurewei.com" <james.n.guichard@futurewei.com>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Thread-Topic: AUTH48: RFC-to-be 9524 <draft-ietf-spring-sr-replication-segment-19> for your review
Thread-Index: AQHaSwvT3aiPaKNOxEWMPy9tKJdxnrDs7ZoAgA+tZICABiz7AIAEdQGAgAJqgpA=
Date: Wed, 14 Feb 2024 08:27:14 +0000
Message-ID: <CYXPR11MB8711087AED9366FE0C0144FAD04E2@CYXPR11MB8711.namprd11.prod.outlook.com>
References: <20240119191446.5AA721BA43FC@rfcpa.amsl.com> <DM6PR11MB30029089F23C54F39EE8CC70DE782@DM6PR11MB3002.namprd11.prod.outlook.com> <B83E56FB-B989-47D7-9992-6F41B2444664@amsl.com> <BYAPR11MB30004AE15DBC26E7C5F48049DE4B2@BYAPR11MB3000.namprd11.prod.outlook.com> <D9F5FFF4-8EE5-4DE8-BE02-A1D00BD1C737@amsl.com>
In-Reply-To: <D9F5FFF4-8EE5-4DE8-BE02-A1D00BD1C737@amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CYXPR11MB8711:EE_|SA2PR11MB4986:EE_
x-ms-office365-filtering-correlation-id: 59a59419-5aba-4fba-8b9a-08dc2d36bf81
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: nAogj9Ll5hm5olBwl+QGgbu+KWgOW+L+DXx+Src1jikUfhJ+CHUbuFQCksnQ7OaytRk7AQyEj4aE/KtEob3RWcyRs7J0GZvOVxTy6LVTCLZBR/7fAvEVeZBn27gRdtn32Xza1hn+3guGsm/8Fq4uPAPUIGZKq2eOXk8B/C+hvqfaObkalV9bysqMe3Lqf7TXvpeOxL1Gd2qF+t0HmTcOqsTsvDzj673azP1qCLPMvr3AWosaRg2M+/sDDIJ8idiAS4tGDj1gg9T2TwR5ZwvBm3ATf/srBMXKzRmd4yoLw42h4RW5isoYEXwmhgNRjlav9IdcNCD1uFpEsjnh3qRq66kC9HF1uU4jWJ8rUk1KXeNWI+RlTt2T37sN+rN7C1BmuHd8OU5XvkoLwZmLwulriEJMX0MaMkoDitOUGrrmqnDTX3vFQHLxtJcqjZ6L8qmld+G4APrjWn5heWgY+OH/5vJO4okfLQX1qAp4mCm4K2LL9j601U5gIzEK4ISC03iuIuo5f60DjdamXTtHOYDFEiVcIVGzTNoPHW3+q84f8LYb/ke1hUzi+UMrGedvh/x2oUxGRlTwGA3wF29Od9THlvhFTq0NP1Aq8n2IMIqgBgI=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CYXPR11MB8711.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(396003)(376002)(136003)(346002)(39860400002)(366004)(230273577357003)(230922051799003)(64100799003)(1800799012)(186009)(451199024)(86362001)(33656002)(55016003)(64756008)(8676002)(8936002)(5660300002)(66476007)(66556008)(66946007)(66446008)(76116006)(52536014)(30864003)(4326008)(9686003)(966005)(6506007)(7696005)(478600001)(2906002)(83380400001)(26005)(41300700001)(122000001)(38100700002)(19627235002)(316002)(38070700009)(53546011)(71200400001)(6636002)(110136005)(54906003)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: yPXysHF4Nw3hlVfczgdd1KWhZMmzkzMDkq9Wkqj14C5kz1JdRC4rCpzNFAUKwCek5NrlojGC9HBAJB1UQYiMOwC8Dj0jMaxXBGcji3IG/3DjiDaOBrp8DUTSxC0cRMbJ1M5pMP03zm17wmZS5npyQfrBuSnkQ2VgoqBhP4A8yYsOzCJuCLj9+AZUxJBKMIsOt0DHm8NwOG4ESk+ALB/HhcrIcSoWYCUV2CVtR/IyLNXwl2dksjETCo6JEcGloWJO2Z0uT4uXAvIX19PVwxXZ0a8YHzeUIM0gQWUCb/Pb3GS1RgWhDi2+0u16w5tXlLga61QmQe4vJkKMjlE3bcaGbyfq9lScl3R2y+CzQM4UudGLHluO2qRe7wFxQeIa6o/G/DHmIJN+23OReGGgRhUgCq1a8yuoDgTKwhtiYES43pRXS5PaL76dlfk34lnM6LZNJFsZ5LT4Yd/+Tlhj7oN2fR1ads5G+p2Tp36m2NFauw7x4xEOyQ4BbLAOwhu2LbWAddGxsevg0HgHaqoYavVAk5Faun8B7WfBtmIuFiJrMM9YEY0MSa01UhJ/YG9X/90pJHS34hMI/vOFXr6NXpekXviopJW4M+cWG/Hmcg1ieeaB4qabN3lWQWu+LdZkALysC+gW8SMjpzzbn04maorqOFxVhODjoW3pmDrtu5N166oRSqeRzCIdSOn7hxI8hyuKcZ60vfEOMIeiMp8E3SaZw+Og0ZA8T96Xx3HkguwTYTCKz3zxlRSeUdNncWTObRh9k1piY2BduzE5XkDN3sK74m25LD+D3SROkE/uyo+h/dod70T4cvSGsTYPat8n6lwbH7GbgedA8g8KmzUrrNzri+dl26dgoNP+bRXPbiJlNKO77T3VfF81HHAvByRDWxlUEan55QO7Ppz8z20ySaDRJIZdm3F76pBWqgTvc8KelEjvcXE4yVASEQg9Zsr6YBFFIFzt1In1FnRdE9AskGGpK/QuMEq1a+zPLSYBjqkyMer3GZisCxuc0iZMn1FCt2XkFdKZUllOEW5nMJ2jqhSqZgc7Rnv7aBGc+vuCsZjM2k2TJjTTgtqw2gPCLXCh36tSIZXM2KFr9vCoAGirC/lD4cK0XHeZxT0KybDMVGOGYxaSRC6g0f8SZMCve8p04RBF28ZkEINZ+77wBtAJaT3lqOXId1mAAoM597h086SLu57fntDxwfv8b60HW8cKuAyyd18XmkC/TP5KSRd7a9+sDFH2SC/5obBhKYD2QO318MWr9i6pMKnkHIZoJAe4I4MkYNrTRR2+WNCQxQU5jco0MraYzvOn+dfB/ZsqJHBoKTjRW3gex7ItOLj7GLMHML6KsWe7IXCME9ofLw3TusMRZY2pb8bKag/TRkeqT603CZtfrmnTLkVdkyx10ERRmoA9EBijMndrr/1H/Di/qZeFh81OYO2vXxpOorWBVL2pofLPfKl0GSYCH7HrWZcGjl+NT/EFts5iCnN6F+hLx6djYJRzdRYhl4Hrw/obJZBUvQ8HUDUfZ6ruIlo4vUfmbbQu0x+yvpjaIC0RXuAm+Ie6Kb2GOC0E1iBT5QP2nb7gdqczlrcN1qzVSdH8oWKQP6dm
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CYXPR11MB8711.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 59a59419-5aba-4fba-8b9a-08dc2d36bf81
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2024 08:27:14.4125 (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: cErGvTCxfwqI9mV/zDmhBeiAx94PDnAla813hDGuo7MaRTLHuwrupsH51aMuzyciX06M8GG0WOhYg3wuyoklkg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR11MB4986
X-Outbound-SMTP-Client: 72.163.7.165, rcdn-opgw-4.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/5J7v6fxHC46CXurKS6lzhqj55O0>
Subject: Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-spring-sr-replication-segment-19> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Feb 2024 08:27:24 -0000
Hello, I approve publication. Cheers, Clarence > -----Original Message----- > From: Megan Ferguson <mferguson@amsl.com> > Sent: Monday, February 12, 2024 20:28 > To: Rishabh Parekh (riparekh) <riparekh@cisco.com> > Cc: rfc-editor@rfc-editor.org; daniel.voyer@bell.ca; Clarence Filsfils (cfilsfil) > <cfilsfil@cisco.com>; hooman.bidgoli@nokia.com; zzhang@juniper.net; > spring-ads@ietf.org; spring-chairs@ietf.org; Mankamana Mishra (mankamis) > <mankamis@cisco.com>; james.n.guichard@futurewei.com; > auth48archive@rfc-editor.org > Subject: Re: AUTH48: RFC-to-be 9524 <draft-ietf-spring-sr-replication- > segment-19> for your review > > Rishabh, > > Thank you for your reply and the updated file. We have reposted our > version to match. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9524.txt > https://www.rfc-editor.org/authors/rfc9524.pdf > https://www.rfc-editor.org/authors/rfc9524.html > https://www.rfc-editor.org/authors/rfc9524.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9524-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9524-rfcdiff.html (comprehensive > side-by-side) > https://www.rfc-editor.org/authors/rfc9524-auth48diff.html (all AUTH48 > changes) > https://www.rfc-editor.org/authors/rfc9524-lastdiff.html (last version to > this) > https://www.rfc-editor.org/authors/rfc9524-lastrfcdiff.html (last version to > this side-by-side) > > Upon review, please let us know if any further updates are necessary. > Please review the files carefully as we do not make changes after publication. > > We will await approvals from each of the parties listed on the AUTH48 status > page prior to moving forward to publication. > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9524 > > Thank you. > > RFC Editor/mf > > > > > On Feb 9, 2024, at 4:23 PM, Rishabh Parekh (riparekh) > <riparekh@cisco.com> wrote: > > > > Replies inline @ [RP] > > > > I have made some of suggested changes in attached XML file. > > > > -Rishabh > > > >> -----Original Message----- > >> From: Megan Ferguson <mferguson@amsl.com> > >> Sent: Monday, February 5, 2024 5:05 PM > >> To: Rishabh Parekh (riparekh) <riparekh@cisco.com> > >> Cc: rfc-editor@rfc-editor.org; daniel.voyer@bell.ca; Clarence > >> Filsfils (cfilsfil) <cfilsfil@cisco.com>; hooman.bidgoli@nokia.com; > >> zzhang@juniper.net; spring- ads@ietf.org; spring-chairs@ietf.org; > >> Mankamana Mishra (mankamis) <mankamis@cisco.com>; > >> james.n.guichard@futurewei.com; auth48archive@rfc-editor.org > >> Subject: Re: AUTH48: RFC-to-be 9524 > >> <draft-ietf-spring-sr-replication-segment- > >> 19> for your review > >> > >> Hi Rishabh, > >> > >> Thank you for sending along your edited file and responses to our > queries. > >> > >> We have combined the two and posted the updated files below. > >> > >> We also had a few additional questions: > >> > >> 1.) It looks like we missed sending the following question: > >> > >> <!--[rfced] We had a few questions regarding the following text: > >> > >> Original: > >> Given the definition of the Replication segment in this document, an > >> attacker subverting ingress filter above cannot take advantage of a > >> stack of replication segments to perform amplification attacks nor link > exhaustion attacks. > >> > >> a) Would it be helpful to the reader to point them to the section in > >> which they can find the definition of “Replication segment” (i.e., Section > 1.1, Section 2)? > > > > [RP] I don't think it is necessary to refer to the definition. We can assume > the reader has read the preceding sections before the Security section. > > > >> > >> b) It might help the reader to clarify what/where “above” is referring to. > >> We see this as the only instance of “ingress filters” in the document. > >> > > > > [RP] I don't think it is necessary, but if the RFC editors think it will help to > clarify "above", please do so. > > > >> c) (Maybe depending on the response to b above) Should “subverting > >> ingress filter” > >> be made either “subverting ingress filters” (plural) or “subverting > >> an ingress filter”? > >> > > > > [RP] I see that latest XML has changed this to plural "ingress filters" which is > fine. > > > >> —> > >> > >> 2.) And we would like you to further review the use of “Replication state” > vs. > >> “Replication segment state”. > >> > > > > [RP] I have changed text for "Replication segment state" in the attached > XML file. > > > >> 3) In the pseudocode, may we put parentheses around the following? > >> > >> Original: > >> S01. Lookup FUNCT portion of S to get Replication state RS > >> > >> Perhaps: > >> S01. Lookup FUNCT portion of S to get Replication state (RS) > > > > [RP] I have made the change in attached XML file. > > > >> > >> The files have been posted here (please refresh): > >> https://www.rfc-editor.org/authors/rfc9524.txt > >> https://www.rfc-editor.org/authors/rfc9524.pdf > >> https://www.rfc-editor.org/authors/rfc9524.html > >> https://www.rfc-editor.org/authors/rfc9524.xml > >> > >> The relevant diff files have been posted here (please refresh): > >> https://www.rfc-editor.org/authors/rfc9524-diff.html (comprehensive) > >> https://www.rfc-editor.org/authors/rfc9524-rfcdiff.html > >> (comprehensive side- > >> by-side) > >> https://www.rfc-editor.org/authors/rfc9524-auth48diff.html (AUTH48 > >> changes > >> only) > >> > >> Upon review, please let us know if any further updates are necessary. > >> Please review the files carefully as we do not make changes after > publication. > >> > >> We will await approvals from each of the parties listed on the AUTH48 > >> status page prior to moving forward to publication. > >> > >> The AUTH48 status page for this document is available here: > >> > >> https://www.rfc-editor.org/auth48/rfc9524 > >> > >> Thank you. > >> > >> RFC Editor/mf > >> > >>> On Jan 26, 2024, at 6:40 PM, Rishabh Parekh (riparekh) > >> <riparekh=40cisco.com@dmarc.ietf.org> wrote: > >>> > >>> I have made some of the suggested modifications in the attached XML > >>> file. For other questions and concerns, please look for my inline > >>> replies @ [RP] > >>> > >>> Thanks, > >>> -Rishabh > >>> > >>>> -----Original Message----- > >>>> From: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org> > >>>> Sent: Friday, January 19, 2024 11:15 AM > >>>> To: daniel.voyer@bell.ca; Clarence Filsfils (cfilsfil) > >>>> <cfilsfil@cisco.com>; Rishabh Parekh (riparekh) > >>>> <riparekh@cisco.com>; hooman.bidgoli@nokia.com; > zzhang@juniper.net > >>>> Cc: rfc-editor@rfc-editor.org; spring-ads@ietf.org; > >>>> spring-chairs@ietf.org; Mankamana Mishra (mankamis) > >>>> <mankamis@cisco.com>; james.n.guichard@futurewei.com; > >>>> auth48archive@rfc-editor.org > >>>> Subject: Re: AUTH48: RFC-to-be 9524 > >>>> <draft-ietf-spring-sr-replication-segment- > >>>> 19> for your review > >>>> > >>>> Authors, > >>>> > >>>> While reviewing this document during AUTH48, please resolve (as > >>>> necessary) the following questions, which are also in the XML file. > >>>> > >>>> 1) <!-- [rfced] Please note that the title of the document has been > >>>> updated as follows: > >>>> > >>>> a. Abbreviations have been expanded per Section 3.6 of RFC 7322 > >>>> (“RFC Style Guide”). Additionally, please let us know any > >>>> suggestions for reducing the redundancy of "Segment" (see our > suggestion below). > >>>> > >>>> b. We have also removed the hyphen from "Multi-point" for > >>>> consistency with previous RFCs (in the title and throughout). > >>>> Please review and let us know any objections. > >>>> > >>>> Original: > >>>> > >>>> SR Replication segment for Multi-point Service Delivery > >>>> > >>>> Current: > >>>> > >>>> Segment Routing Replication Segment for Multipoint Service Delivery > >>>> > >>>> Perhaps: > >>>> Segment Routing Replication for Multipoint Service Delivery > >>>> --> > >>>> > >>> > >>> [RP] I have changed the tile in the edited XML file. > >>> > >>>> > >>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > >>>> the title) for use on https://www.rfc-editor.org/search. > >>>> --> > >>>> > >>>> > >>>> 3) <!--[rfced] We see the following three similar sentences in close > >>>> proximity: > >>>> > >>>> Original: > >>>> This Replication segment can be either provisioned locally on > >>>> ingress and egress nodes, or using dynamic auto-discovery > >>>> procedures for MVPN > >> and EVPN. > >>>> > >>>> and > >>>> > >>>> Original: > >>>> A Replication segment is a local segment instantiated at a > >>>> Replication node. It can be either provisioned locally on a node > >>>> or > >> programmed by a control plane. > >>>> > >>> > >>> [RP] In this sentence the control plane refers to something like a > >>> PCE rather > >> than MVPN or EVPN (as used for ingress replication). > >>> > >>>> and > >>>> > >>>> Original: > >>>> Replication segments can be stitched together to form a tree by > >>>> either local provisioning on nodes or using a control plane. > >>> > >>> [RP] Again, the control plane refers to PCE in this context as > >>> explained later in > >> the paragraph. > >>> > >>>> > >>>> a) Please confirm our update to the first sentence (see below) > >>>> correctly captures your intent. Our goal is to make the two > >>>> phrases joined by > >> "either" > >>>> symmetrical. > >>>> > >>>> Perhaps: > >>>> This Replication segment can be either provisioned locally on > >>>> ingress and egress nodes or using dynamic autodiscovery procedures > >>>> for MVPN and > >> EVPN. > >>> > >>> [RP] I have rearranged the first sentence to make both options > >>> (local and > >> dynamic) symmetrical. > >>> > >>>> > >>>> b) Please review the three similar sentences listed above and > >>>> ensure that they do not need to be made more uniform and/or review > >>>> if redundancy should be reduced. > >>>> > >>>> --> > >>>> > >>>> > >>>> 4) <!--[rfced] In the following, does "Anycast set" mean "a set of > >>>> Anycast SIDs"? Note: this text occurs two times in the text. > >>>> > >>>> Original: > >>>> * A Replication node MAY use an Anycast SID or a Border Gateway > >>>> Protocol (BGP) PeerSet SID in segment list to send a > >>>> replicated packet to one downstream Replication node in an Anycast > set... > >>>> > >>>> > >>>> --> > >>> > >>> [RP] Anycast-SID is one SID that is shared by multiple nodes in an Anycast > set. > >> I have re-worded the sentence to make this clear. > >>> > >>>> > >>>> > >>>> 5) <!-- [rfced] We had the following questions regarding the > pseudocode in > >>>> Section 2.2.1. > >>>> > >>>> a) The following line exceeds the 72-character limit. Please let us > >>>> know how this line can be modified. > >>>> > >>>> Original: > >>>> > >>>> S03. Discard the packet > >>>> S04. # ICMPv6 Time Exceeded is not permitted (ICMPv6 section > below) > >>>> S05. } > >>>> > >>>> Perhaps: > >>>> > >>>> S03. Discard the packet > >>>> S04. # ICMPv6 Time Exceeded is not permitted > >>>> (ICMPv6 section below) > >>>> S05. } > >>>> > >>> > >>> [RP] Fixed > >>> > >>>> b) Will it be clear what "ICMPv6 section below" in the > >>>> parenthetical in point a) above refers to? Should this be replaced > >>>> by a specific section number. Note this occurs more than once. > >>>> > >>> > >>> [RP] Although it should be clear that this refers to Section 2.2.3, > >>> changing this > >> to an explicit reference is fine. > >>> > >>>> c) We note that there is no space between PPC and its expansion. > >>>> May we make the following updates? > >>>> > >>>> Original: > >>>> S20. Derive packet processing context(PPC) from Segment List > >>>> > >>>> Perhaps: > >>>> S20. Derive packet processing context (PPC) from Segment List > >>>> > >>>> Original: > >>>> S28. Derive packet processing context(PPC) > >>>> > >>>> Perhaps: > >>>> S28. Derive packet processing context (PPC) > >>> > >>> [RP] Fixed. > >>> > >>>> > >>>> d) In the pseudocode, we see Upper-layer Header. In other parts of > >>>> the document, we mostly see Upper-Layer header (but upper layer > >>>> headers also appears). Please let us know if/how these terms may > >>>> be made consistent in both the pseudocode and the body of the > document. > >>>> > >>>> Original: > >>>> S12. # (SR Upper-layer Header Error) > >>>> > >>>> Perhaps: > >>>> S12. # (SR Upper-Layer header Error) > >>>> > >>> > >>> [RP] RFC 8986 uses "Upper-Layer Header" with capital H in title of > >>> Section > >> 4.1.1 and "Upper-Layer header" in rest of the text. I think we can > >> use the same approach. > >>> > >>>> e) Please review our update to the reference to RFC 8986 in the > >>>> pseudocode and let us know any concerns. > >>>> > >>>> Original: > >>>> S09. Execute H.Encaps or H.Encaps.Red with RS.Segment-List > >>>> on packet copy #RFC 8986 Section 5.1, 5.2 > >>>> > >>>> Current: > >>>> S09. Execute H.Encaps or H.Encaps.Red with RS.Segment-List > >>>> on packet copy #RFC 8986, Sections 5.1 and 5.2 > >>>> > >>>> > >>> > >>> [RP] This is fine. > >>> > >>>> --> > >>>> > >>>> > >>>> 6) <!--[rfced] In the first sentence, "transit node" is singular. In the > >>>> second, it's plural (i.e., "The transit nodes..."). Please > >>>> review and let us know if/how updates should be made for clarity. > >>>> > >>>> Original: > >>>> The source can then send the Echo Request packet to a transit > >>>> node's Replication SID. The transit nodes replicate the packet by > >>>> replacing the IPv6 destination address till the packet reaches the > >>>> Leaf/Bud node which responds with an ICMPv6 Echo Reply. > >>>> > >>>> Perhaps: > >>>> The source can then send the Echo Request packet to a transit > >>>> node's Replication SID. The transit node replicates the packet by > >>>> replacing the IPv6 destination address until the packet reaches the > >>>> Leaf/Bud node, which responds with an ICMPv6 Echo Reply. > >>> > >>> [RP] I have made the suggested change in edited XML file. > >>> > >>>> > >>>> --> > >>>> > >>>> > >>>> 7) <!--[rfced] In the following text: > >>>> > >>>> Original: > >>>> Traceroute to a Leaf/Bud node Replication SID is not possible due > >>>> to restriction prohibiting origination of ICMPv6 Time Exceeded > >>>> error message for a Replication SID as described in the section below. > >>>> > >>>> Current: > >>>> Traceroute to a Leaf/Bud node Replication SID is not possible due > >>>> to restrictions prohibiting the origination of the ICMPv6 Time > >>>> Exceeded error message for a Replication SID as described in Section > 2.2.3. > >>>> > >>>> a) Please review our update to make "restrictions" plural. > >>>> > >>>> b) Please also confirm the update to point to Section 2.2.3. > >>>> > >>> > >>> [RP] The changes are fine. > >>> > >>>> --> > >>>> > >>>> > >>>> 8) <!--[rfced] In the following, the close proximity of two occurrences > >>>> of "from" makes this sentence possibly difficult to parse on a > >>>> single read-through. Might the following suggested text be > >>>> acceptable? > >>>> > >>>> Original: > >>>> This is to prevent a storm of ICMPv6 error messages resulting from > >>>> replicated > >>>> IPv6 packets from overwhelming a source node. > >>>> > >>>> Perhaps: > >>>> This is to prevent a source node from being overwhelmed by a storm > >>>> of > >>>> ICMPv6 error messages resulting from replicated IPv6 packets. > >>>> --> > >>>> > >>> > >>> [RP] I have made the suggested change in edited XML file. > >>> > >>>> > >>>> 9) <!--[rfced] Please review the list in the Security Considerations > >>>> section. While most points begin with a verb phrase, a few > >>>> points do not. Please let us know if/how we may make this list > >>>> parallel in structure. > >>>> > >>>> Original: > >>>> > >>>> * For SR-MPLS deployments: > >>>> > >>>> - By disabling MPLS on external interfaces of each edge node or > >>>> any other technique to filter labeled traffic ingress on these > >>>> interfaces. > >>>> > >>>> * For SRv6 deployments: > >>>> > >>>> - Allocate all the SIDs from an IPv6 prefix block S/s and > >>>> configure each external interface of each edge node of the > >>>> domain with an inbound infrastructure access list (IACL) that > >>>> drops any incoming packet with a destination address in S/s. > >>>> > >>>> - Additionally, an iACL may be applied to all nodes (k) > >>>> provisioning SIDs as defined in this specification: > >>>> > >>>> o Assign all interface addresses from within IPv6 prefix A/a. > >>>> At node k, all SIDs local to k are assigned from prefix Sk/ > >>>> sk. Configure each internal interface of each SR node k in > >>>> the SR domain with an inbound IACL that drops any incoming > >>>> packet with a destination address in Sk/sk if the source > >>>> address is not in A/a. > >>>> > >>>> - Denying traffic with spoofed source addresses by implementing > >>>> recommendations in BCP 84 [RFC3704]. > >>>> > >>>> - Additionally the block S/s from which SIDs are allocated may be > >>>> a non-globally-routable address such as ULA or the prefix > >>>> defined in [I-D.ietf-6man-sids]. > >>>> --> > >>> > >>> [RP] The updated text is fine. > >>> > >>>> > >>>> > >>>> 10) <!--[rfced] This sentence may be easier to get through on a single > >>>> read if broken into a list as follows. Please let us know if > >>>> this is agreeable. > >>>> > >>>> Original: > >>>> If an attacker can forge an IPv6 packet with source address of a > >>>> node, Replication SID as destination address and an IPv6 Hop Limit > >>>> such that nodes which forward replicated packets on IPv6 locator > >>>> unicast prefix, decrement the Hop Limit to zero, then these nodes > >>>> can cause a storm of > >>>> ICMPv6 Error packets to overwhelm the source node under attack. > >>>> > >>>> Perhaps: > >>>> > >>>> If an attacker can forge an IPv6 packet with: > >>>> > >>>> * the source address of a node, > >>>> * a Replication SID as the destination address, and > >>>> * an IPv6 Hop Limit such that nodes that forward replicated packets > >>>> on an IPv6 locator unicast prefix decrement the Hop Limit to zero, > >>>> > >>>> then these nodes can cause a storm of ICMPv6 error packets to > >>>> overwhelm the source node under attack. > >>>> > >>> > >>> [RP] I have split up the sentence as suggested in edited XML file. > >>> > >>>> --> > >>>> > >>>> > >>>> 11) <!-- [rfced] Please review the "type" attribute of each sourcecode > >>>> element in the XML file to ensure correctness. If the current > >>>> list of preferred values for "type" > >>>> (https://www.rfc-editor.org/materials/sourcecode-types.txt) does > >>>> not contain an applicable type, then feel free to let us > >>>> know. Also, it is acceptable to leave the "type" attribute not > >>>> set. > >>> > >>> [RP] "pseudocode" type is appropriate. > >>> > >>>> --> > >>>> > >>>> > >>>> 12) <!-- [rfced] We have a few questions regarding the terms used in > this > >>>> document. > >>>> > >>>> a. End.Replicate is treated differently in the two instances below. > >>>> Please review and let us know if/how these should be made uniform. > >>>> Perhaps this term should be added to the Terminology section in > >>>> lieu of the > >> two descriptions? > >>>> > >>>> Original: > >>>> “Endpoint with replication” behavior (End.Replicate for short) > >>>> > >>>> and > >>>> > >>>> Original: > >>>> The "Endpoint with replication and/or decapsulate behavior > >>>> (End.Replicate for > >>>> short) is variant of End behavior. > >>>> > >>> > >>> [RP] I have made changes to make both of this consistent (by using " > >>> Endpoint > >> with replication and/or decapsulate") in the edited XML file. > >>> > >>>> > >>>> b. Regarding hyphenation and capitalization of the following terms: > >>>> > >>>> i. Anycast SID: This term appears without a hyphen throughout the > >>>> document, but in cited RFCs, it appears as Anycast-SID. May we > >>>> update to the hyphenated form for consistency with these previous > RFCs? > >>>> > >>> [RP] Yes, please update. > >>> > >>>> ii. Adjacency SID: This term seems to be "Adj-SID" in RFC 8402. > >>>> Please review this usage and let us know if we can adjust to use "Adj- > SID" > >>>> for consistency with this cited RFC. > >>>> > >>> [RP] Yes, please use "Adj-SID" > >>> > >>>> iii. Replication SID: This term appears both hyphenated and without > >>>> a hyphen (and in lowercase at times) throughout the document. May > >>>> we update all instances to "Replication-SID", for consistency with > >>>> the previous related terms and cited RFCs? > >>>> > >>> [RP] Yes, please update to "Replication-SID" > >>> > >>>> iv. FYI - Related to the above, we see the following terms in the > >>>> document: > >>>> > >>>> Node-SID > >>>> PeerSet SID > >>>> context SID > >>>> > >>> > >>> [RP] RFC 8402 uses "Node-SID" and "PeerSet SID" (without > >>> hyphenation) and > >> we have adopted it from there, but it is fine to use "PeerSet-SID". "context > SID" > >> is introduced in this document and can therefore be changed to "context- > SID". > >>> > >>>> In addition to: > >>>> R-SID > >>>> A-SID > >>>> N-SID > >>>> > >>>> Please consider these when making decisions related to i-iii above. > >>>> > >>>> c. Several terms in this document appear separated with a slash > >>>> (/), but it is unclear whether the slash stands for "and", "or", or > >>>> "and/or". Please review uses of the slash throughout this document > >>>> and let us know how to adjust for clarity. > >>>> > >>> [RP] I have replaced all occurrences of slash (/) in "Leaf/Bud" and > >> "MVPN/EVPN" with "and" or "or" as appropriate. Please let me know if > >> there are any other ambiguous usage of the slash. > >>> > >>>> > >>>> d. Should the following capitalized terms (seemingly node names) be > >>>> changed to lowercase throughout for consistency with previous RFCs? > >>>> > >>>> Downstream > >>>> Root > >>>> Leaf > >>>> Bud > >>>> > >>>> Related: We see both Replication node and Non-replication node. > >>>> Please consider if all node name should be lowercase in light of the > above. > >>>> > >>> [RP] Yes, these can be changed to lowercase. > >>> > >>>> e. We have updated the following terms to use the form on the right. > >>>> Please review and let us know any objections: > >>>> > >>>> Active Segment / active segment (to match RFC 8402) replication > >>>> branch / Replication branch > >>>> > >>> [RP] Change to "active segment" is fine, but I don't think "Replication > branch" > >> change is appropriate because lowercase "replication" is used to > >> signify the act of replication instead of needing a proper noun with > uppercase "Replication". > >>> > >>>> > >>>> f. We see the following terms used inconsistently throughout the > document. > >>>> Please review and let us know if/how these may be made uniform. > >>>> > >>>> Replication segment vs. Replication Segment vs. replication segment > >>> > >>> [RP] I think using "Replication segment" will be consistent. > >>> > >>>> > >>>> f. Please review the following questions about the message names > below: > >>>> > >>>> i. Should "message" be lowercased or capitalized? > >>>> > >>>> Packet Too Big message vs. Parameter Problem Message > >>>> > >>>> ii. We see Parameter Problem both with and without ICMPv6. Please > >>>> review and let us know if/how these uses should be made uniform. > >>>> > >>>> iii. May we make the error codes uniform with regard to capping and > >> ordering? > >>>> > >>>> > >>>> Originals: > >>>> ICMPv6 Parameter Problem with Code 0 > >>>> ICMPv6 Parameter Problem with Code 4 an ICMPv6 error message > >>>> (parameter problem, code 0) Parameter Problem Message, Code 2 > >>>> Parameter Problem Message, code 2 ICMPv6 Error > >> messages. > >>>> > >>>> Perhaps (making assumptions about i, ii, and iii above): > >>>> ICMPv6 Parameter Problem message with Code 0 > >>>> ICMPv6 Parameter Problem message with Code 4 > >>>> ICMPv6 Parameter Problem message with Code 0 > >>>> ICMPv6 Parameter Problem message with Code 2 > >>>> ICMPv6 Parameter Problem message with Code 2 > >>>> > >>> [RP] Above suggestion is fine. > >>> > >>>> --> > >>>> > >>>> > >>>> 13) <!--[rfced] We had the following questions/comments related to > >>>> abbreviations used throughout the document: > >>>> > >>>> a. FYI - We have expanded the following abbreviations upon first > >>>> use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review > >>>> each expansion in the document carefully to ensure correctness: > >>>> > >>>> Destination Address (DA) > >>>> Unique Local Address (ULA) > >>>> Operations, Administration, and Maintenance (OAM) > >>>> > >>> [RP] This is fine. > >>> > >>>> b. FYI - We will update to use the abbreviated form of the > >>>> following terms after the abbreviation is expanded on first use. > >>>> Please let us know any > >> objections. > >>>> > >>>> Destination Address will become DA > >>>> Replication state will become RS > >>>> Segment Routing will become SR > >>>> > >>> [RP] This Is fine. > >>> > >>>> > >>>> c) Please review this use of POP: > >>>> > >>>> Original: > >>>> ...is a Replication SID, the processing results in a POP [RFC8402]... > >>>> > >>>> We do not see POP being expanded as an abbreviation in RFC 8402 or > >>>> any of the normative references. Please let us know if/how we may > >>>> expand > >> it. > >>>> > >>> [RP] POP is not used an acronym here. It signifies a "pop" operation > >>> on the > >> top label of the label stack. > >>> > >>>> d) Please review the expansion and use of IACL/iACL. > >>>> > >>>> While we see the same expansion as used in this document in RFC > >>>> 8754 (see below), we are curious about the 1:1 relationship between > >>>> the initialism and the expansion. > >>>> > >>>> We also note a single use of "iACL" in this document (see below). > >>>> > >>>> Original: > >>>> - Allocate all the SIDs from an IPv6 prefix block S/s and > >>>> configure each external interface of each edge node of the domain > >>>> with an inbound infrastructure access list (IACL) that drops any > >>>> incoming packet with a destination address in S/s. > >>>> > >>>> then later: > >>>> > >>>> Original: > >>>> - Additionally, an iACL may be applied to all nodes (k) > >>>> provisioning SIDs as defined in this specification: > >>>> > >>>> i) Should these uses be made "infrastructure Access Control List > >>>> (iACL)" on expansion and then "iACL" thereafter? Note that we see > >>>> "Infrastructure Access Control List (iACL)" used in RFCs 7404 and 9098. > >>>> > >>>> ii) Or perhaps "infrastructure Access Control List (ACL)" on > >>>> expansion as used in RFCs 6752 and 9252 (and "infrastructure ACL > >> thereafter")? > >>>> > >>>> iii) Or maybe we should switch to using "Infrastructure Access > >>>> Control List (IACL)" with a 1:1 between the expansion and the > >>>> initialism and corresponding capitalization? This form has not > >>>> appeared in any published RFCs to date, but if this is how people > >>>> know it, > >> then perhaps this is the way to go in the future? > >>>> > >>>> We appreciate any guidance you may have. > >>>> > >>> > >>> [RP] I don't think there is an established terminology for ACL and > >>> lowercase > >> "i" or uppercase "I" do not make a difference. It should be fine to > >> use using "Infrastructure Access Control List (IACL)". > >>>> --> > >>>> > >>>> > >>>> 14) <!-- [rfced] Please review the "Inclusive Language" portion of the > >>>> online Style Guide > >>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > >>>> and let us know if any changes are needed. > >>>> > >>>> Note that our script did not flag any words in particular, but this > >>>> should still be reviewed as a best practice.--> > >>>> > >>>> > >>>> Thank you. > >>>> > >>>> RFC Editor/kf/mf > >>>> > >>>> *****IMPORTANT***** > >>>> > >>>> Updated 2024/01/19 > >>>> > >>>> RFC Author(s): > >>>> -------------- > >>>> > >>>> Instructions for Completing AUTH48 > >>>> > >>>> Your document has now entered AUTH48. Once it has been reviewed > >>>> and approved by you and all coauthors, it will be published as an RFC. > >>>> If an author is no longer available, there are several remedies > >>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). > >>>> > >>>> You and you coauthors are responsible for engaging other parties > >>>> (e.g., Contributors or Working Group) as necessary before providing > >>>> your > >> approval. > >>>> > >>>> Planning your review > >>>> --------------------- > >>>> > >>>> Please review the following aspects of your document: > >>>> > >>>> * RFC Editor questions > >>>> > >>>> Please review and resolve any questions raised by the RFC Editor > >>>> that have been included in the XML file as comments marked as > >>>> follows: > >>>> > >>>> <!-- [rfced] ... --> > >>>> > >>>> These questions will also be sent in a subsequent email. > >>>> > >>>> * Changes submitted by coauthors > >>>> > >>>> Please ensure that you review any changes submitted by your > >>>> coauthors. We assume that if you do not speak up that you agree > >>>> to changes submitted by your coauthors. > >>>> > >>>> * Content > >>>> > >>>> Please review the full content of the document, as this cannot > >>>> change once the RFC is published. Please pay particular attention to: > >>>> - IANA considerations updates (if applicable) > >>>> - contact information > >>>> - references > >>>> > >>>> * Copyright notices and legends > >>>> > >>>> Please review the copyright notice and legends as defined in RFC > >>>> 5378 and the Trust Legal Provisions (TLP – > >>>> https://trustee.ietf.org/license-info/). > >>>> > >>>> * Semantic markup > >>>> > >>>> Please review the markup in the XML file to ensure that elements > >>>> of content are correctly tagged. For example, ensure that > >>>> <sourcecode> and <artwork> are set correctly. See details at > >>>> <https://authors.ietf.org/rfcxml-vocabulary>. > >>>> > >>>> * Formatted output > >>>> > >>>> Please review the PDF, HTML, and TXT files to ensure that the > >>>> formatted output, as generated from the markup in the XML file, is > >>>> reasonable. Please note that the TXT will have formatting > >>>> limitations compared to the PDF and HTML. > >>>> > >>>> > >>>> Submitting changes > >>>> ------------------ > >>>> > >>>> To submit changes, please reply to this email using ‘REPLY ALL’ as > >>>> all the parties CCed on this message need to see your changes. The > >>>> parties > >>>> include: > >>>> > >>>> * your coauthors > >>>> > >>>> * rfc-editor@rfc-editor.org (the RPC team) > >>>> > >>>> * other document participants, depending on the stream (e.g., > >>>> IETF Stream participants are your working group chairs, the > >>>> responsible ADs, and the document shepherd). > >>>> > >>>> * auth48archive@rfc-editor.org, which is a new archival mailing list > >>>> to preserve AUTH48 conversations; it is not an active discussion > >>>> list: > >>>> > >>>> * More info: > >>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh- > >>>> 4Q9l2USxIAe6P8O4Zc > >>>> > >>>> * The archive itself: > >>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ > >>>> > >>>> * Note: If only absolutely necessary, you may temporarily opt out > >>>> of the archiving of messages (e.g., to discuss a sensitive matter). > >>>> If needed, please add a note at the top of the message that you > >>>> have dropped the address. When the discussion is concluded, > >>>> auth48archive@rfc-editor.org will be re-added to the CC list and > >>>> its addition will be noted at the top of the message. > >>>> > >>>> You may submit your changes in one of two ways: > >>>> > >>>> An update to the provided XML file > >>>> — OR — > >>>> An explicit list of changes in this format > >>>> > >>>> Section # (or indicate Global) > >>>> > >>>> OLD: > >>>> old text > >>>> > >>>> NEW: > >>>> new text > >>>> > >>>> You do not need to reply with both an updated XML file and an > >>>> explicit list of changes, as either form is sufficient. > >>>> > >>>> We will ask a stream manager to review and approve any changes that > >>>> seem beyond editorial in nature, e.g., addition of new text, > >>>> deletion of text, and technical changes. Information about stream > >>>> managers can be found in the FAQ. Editorial changes do not require > >>>> approval from a > >> stream manager. > >>>> > >>>> > >>>> Approving for publication > >>>> -------------------------- > >>>> > >>>> To approve your RFC for publication, please reply to this email > >>>> stating that you approve this RFC for publication. Please use > >>>> ‘REPLY ALL’, as all the parties CCed on this message need to see your > approval. > >>>> > >>>> > >>>> Files > >>>> ----- > >>>> > >>>> The files are available here: > >>>> https://www.rfc-editor.org/authors/rfc9524.xml > >>>> https://www.rfc-editor.org/authors/rfc9524.html > >>>> https://www.rfc-editor.org/authors/rfc9524.pdf > >>>> https://www.rfc-editor.org/authors/rfc9524.txt > >>>> > >>>> Diff file of the text: > >>>> https://www.rfc-editor.org/authors/rfc9524-diff.html > >>>> https://www.rfc-editor.org/authors/rfc9524-rfcdiff.html (side by > >>>> side) > >>>> > >>>> Diff of the XML: > >>>> https://www.rfc-editor.org/authors/rfc9524-xmldiff1.html > >>>> > >>>> The following files are provided to facilitate creation of your own > >>>> diff files of the XML. > >>>> > >>>> Initial XMLv3 created using XMLv2 as input: > >>>> https://www.rfc-editor.org/authors/rfc9524.original.v2v3.xml > >>>> > >>>> XMLv3 file that is a best effort to capture v3-related format > >>>> updates > >>>> only: > >>>> https://www.rfc-editor.org/authors/rfc9524.form.xml > >>>> > >>>> > >>>> Tracking progress > >>>> ----------------- > >>>> > >>>> The details of the AUTH48 status of your document are here: > >>>> https://www.rfc-editor.org/auth48/rfc9524 > >>>> > >>>> Please let us know if you have any questions. > >>>> > >>>> Thank you for your cooperation, > >>>> > >>>> RFC Editor > >>>> > >>>> -------------------------------------- > >>>> RFC9524 (draft-ietf-spring-sr-replication-segment-19) > >>>> > >>>> Title : SR Replication segment for Multi-point Service Delivery > >>>> Author(s) : D. Voyer, Ed., C. Filsfils, R. Parekh, H. Bidgoli, Z. Zhang > >>>> WG Chair(s) : Bruno Decraene, Alvaro Retana, Joel M. Halpern > >>>> > >>>> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston > >>>> > >>> > >>> <rfc9524-Jan26.xml><rfc9524-Jan26.diff.html> > >> > >> > >> > >> > > > > <rfc9524-Feb09.xml><rfc9524-Feb09.diff.html>
- [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-sprin… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Rishabh Parekh (riparekh)
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Megan Ferguson
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Rishabh Parekh (riparekh)
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Megan Ferguson
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Rishabh Parekh (riparekh)
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Jeffrey (Zhaohui) Zhang
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Clarence Filsfils (cfilsfil)
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Voyer, Daniel
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Hooman Bidgoli (Nokia)
- Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-s… Sarah Tarrant