Re: [auth48] AUTH48: RFC-to-be 9524 <draft-ietf-spring-sr-replication-segment-19> for your review
"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Tue, 13 February 2024 18:49 UTC
Return-Path: <zzhang@juniper.net>
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 31F9FC14F6B6; Tue, 13 Feb 2024 10:49:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b="wo9W1SIv"; dkim=pass (1024-bit key) header.d=juniper.net header.b="Lq6YE+7H"
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 4U6Yheqmrv8q; Tue, 13 Feb 2024 10:49:24 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 300F4C14F61F; Tue, 13 Feb 2024 10:49:24 -0800 (PST)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 41DCLlUW014319; Tue, 13 Feb 2024 10:49:15 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h= from:to:cc:subject:date:message-id:references:in-reply-to :content-type:content-transfer-encoding:mime-version; s=PPS1017; bh=JS3rcwjpCFdirG6mSImZ9kCRyNenxdDRDhCWUjkOkWY=; b=wo9W1SIvQE1a oe0xlwS0esot5gr0ms8kQ3POsI4Sl2LS8Gzp5hBj3yoohxay1+9aomBGMzYgH6RQ Iqup6gsF8qbW7f575lX2A2s6tP0lHGJZdpyFeGzTJWBSaQL0pE9XBgCObBLntNAN TXGzaO/pEBx+OsXM5Adp9liGw0uiIekQf4Rc1BJxJSsEK8X/077voct/thHOeokm EYUaJQ6yngW9A6QQp9qmSl3Go+Zk+AXhi+1XmJPdlRJkaNRn5G4CUg8f1OggnaSu t4ENBD/hsRPSgw72tVXFH3o5WrEYij1Ra79gTj8GubGwWOFf2Cev5J9hH5EZVWfX BJGP7M4/CQ==
Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazlp17012018.outbound.protection.outlook.com [40.93.11.18]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3w691jdhaj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Feb 2024 10:49:15 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FO4AGB0+ctbm6t9/OpsE5XgaCfmayyMy1XohfeW9Lv/jXlAxiNzeL0CQZykIqSBV1tDeUFFhgfQgXgTl7eAsCytyWjQm2lGxhbLHP1eHXLMfrEtrhiWRZfpZR9CEd8ItTIHt647D5dDDjwSvdZiAKkyW2uJYaMayPnuufkellSwsteXd9WqO37OqL0imUiqAe4hvFSKxnaY16+11F6uLiMiNGC7JrIPesIJP/n+EDW9i20vr85i8k8pC9ZmPa9xSM1eWBxv+X+NhjXghytcjqg4w+/ATw9QHMMGkG01eLsd6FmFItE7bvDQkJfgF8qtlp9qmyC2FXuYKhpeuXzn7Ag==
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=JS3rcwjpCFdirG6mSImZ9kCRyNenxdDRDhCWUjkOkWY=; b=b8glcpdikNStg8XZOrH0gMuG0q1znaOCz0vKA3ePgZFulCoyERNeTrvS1THEVldq7Pl99hodEdWasdS1yHw3z8MDIXmJwe+nJZBV2CMR84Ec4DtnGbjPmJcvokUKRPRoZm9AHETmQ2odM71PJbtANolIox15EUQkkSCfwfC+VcYPrs3zM8Q9fIyK4wkln5hNiVOI5oPrvGUFPQmJzYbIFCn3KOBBMfEctnboAF6YMuwj1yBFBGRenABGYop21ykK+tJShsjoQ5zyNuLMih1p40gZLVxepwg27n3N8xgvzUAO8Nuu2tppPp7ztBVtJ16vkdVF4qpbMwaVYNzySn9iMg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JS3rcwjpCFdirG6mSImZ9kCRyNenxdDRDhCWUjkOkWY=; b=Lq6YE+7H62bA4jbywM3RQXLr3EPe2PWslJZHpVzPyWPggor5Tt0v6NwBwjy5lqhhbKUuUqIOyAFId9gyeLOc4WxkG/YuxqsubqhuFdOPLEc5uSpIQo6u/Gicxu5pplpZrNh/2W6m9lOWaUKc6NnGQ3+WC2lTuVSzbyi4b+0GxvU=
Received: from IA1PR05MB9550.namprd05.prod.outlook.com (2603:10b6:208:426::16) by SJ0PR05MB7216.namprd05.prod.outlook.com (2603:10b6:a03:286::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7270.24; Tue, 13 Feb 2024 18:49:12 +0000
Received: from IA1PR05MB9550.namprd05.prod.outlook.com ([fe80::4c5d:def9:3e54:e076]) by IA1PR05MB9550.namprd05.prod.outlook.com ([fe80::4c5d:def9:3e54:e076%4]) with mapi id 15.20.7270.036; Tue, 13 Feb 2024 18:49:11 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "Rishabh Parekh (riparekh)" <riparekh@cisco.com>, Megan Ferguson <mferguson@amsl.com>
CC: "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "daniel.voyer@bell.ca" <daniel.voyer@bell.ca>, "Clarence Filsfils (cfilsfil)" <cfilsfil@cisco.com>, "hooman.bidgoli@nokia.com" <hooman.bidgoli@nokia.com>, "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: AQHaSwvHdPNGCsj/+0mdpmi/Xg4+87Ds7ZoAgA+tZICABiz7AIAEdQGAgAF/FACAAAh9kA==
Date: Tue, 13 Feb 2024 18:49:11 +0000
Message-ID: <IA1PR05MB955019E967379A50649A6770D44F2@IA1PR05MB9550.namprd05.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> <BYAPR11MB3000AC0211B495E33F67BB97DE4F2@BYAPR11MB3000.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB3000AC0211B495E33F67BB97DE4F2@BYAPR11MB3000.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=652a46cd-b9c2-4b33-8b4c-57fc1e0a6577; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2024-02-13T18:49:04Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: IA1PR05MB9550:EE_|SJ0PR05MB7216:EE_
x-ms-office365-filtering-correlation-id: 461b6aaa-f0ba-46b4-fc7b-08dc2cc477fd
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: x9AaNQhoHqHMROaS52JWGXR1XfVyVkMjzANDSV9mQliYwquQ4smMsMWQ889q0pwN7jQy3VYV8gIcgj5lM4IXR2e9ODlkxjkpeUxT4dTqpHfhQjZB0mGeGfN0+Wip5QxomDsAlSDQCSwhlBIIJkJjY+b9nSFiGOWDhiFJIKtVznCVnOKAmHq8jCiJJz57R9CsMNix886LDm/UNH0sMZSYD+ehBVzL6fWsRrB6Ty05JRv7jYwRV/kw1Xar7maqbeno6q2XJ1K7dnW93lSTU8y4oIsp9eJIrkq50PXidwp4viO+3DQL16T8obEFbG5eHVCETXNbgXLM/md0CgWuCuYxl3w/o12o1U2THIOpKCwodT9tdOahi/57jdYqyGzQQuXMw33Ks813ZtC/ma1HUwMm6kteht0rCZPuwN4fgVRsw8/0XhudRXLNuDUlZbLPYGf+/Yz4ejXOWYWw76OYUn25CDq+Otk71HPaBbyczQyYO7yykPkaOBqZPn84BeDn7rEpcQYWqY95RXQ8IEqdj0rEZMBV0VOfuToahFLYvShz8w+LtQCRK8Rq6QudgGMhnhd3HTJIpuT6q0hdLyJu99OHXpFN0U4FgMkhuHIJRJSCBDAyWYReXcBD+y3D6QOwmcoGf01qhC8nS7IhwTNad9Q16g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:IA1PR05MB9550.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(136003)(396003)(39860400002)(376002)(346002)(366004)(230922051799003)(230273577357003)(451199024)(186009)(1800799012)(64100799003)(38070700009)(55016003)(9686003)(316002)(66476007)(7416002)(19627235002)(64756008)(6506007)(7696005)(76116006)(30864003)(66946007)(66556008)(66446008)(2906002)(966005)(53546011)(5660300002)(122000001)(33656002)(54906003)(478600001)(110136005)(38100700002)(4326008)(86362001)(71200400001)(8676002)(41300700001)(52536014)(8936002)(83380400001)(26005)(579004)(559001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: nBEsc3A/Inm/QZH0VHXEaOYuZ/ypns7OPgaU/zD6gnAoUnQPw5XFrUZpy1KYjXcSeASafbLHBkaga+B/oNbZc0aHxIOxbZAotWAGkjnEOb8oTS2Bh506iypuDOWQ5CHCGjZacHZ6n/BeMfPbvZJJZQao7pdB7tXX/YLKetwemcxQo9oGtktkU2PP/9RAlZrsNgAfKKc2E5ugslRCN4oFHdbBgd1AgY8umOd5ui2gMiiopi4UZP6m2ZNPMp4MQj5nFskiHUFFdPG2PW05a1C7FJUz1oUZvjb7BGNn+yFRh/OaKhCsSozXRXjfX7Q7DM9daJIQTdvUxOkJN3V4LDK9ehg6H4OPRq/t/fGeD4/Whaurb6WMWAHX10apNo3vvzibn1mrvmP8JRPf8Nwl9KeMxAIUKlSCez2jTHnJxzccEi6dFYY0S00Ym9pjL3J0VML5woMcLC60aBw5XI0D1Y2zQSmjZkXIZin/f4xMoFuCMZy7BLqjVJVdi/Vd1QQ0ufSEwrCfyGSzFqYV3lUEXRA1ikQfEl1sPDXN4QGWc4DrQeQdjemzcFoaRVap9K1Bp4EliSJV0KeUqntimeJP4qQ1hDmcaHNGh/cQsXxyTGrER1KmPnhb3CiKn7WJoSqoYw+iFy95KjS2JwG9CqLZXgtlqSRrqgIKhdUWXRIvo66Ko7i/phkO+KZ+50XR4WiJUOWeeqM9Bw3BDAtG8gCgGQL5y81VE9WKN6sOfh7GuqMZ/enDUI1d+fD+E+0e2QiKKDGOiLc+VQc26NSoEZ4kaXm3qzVhplJs4Ev7qu/PB7TVSDjNbJYx86upC0hYZDPaBJmtKlq0H0G2WQN/UJAbN4mt2c+mhF0k7BvbeMivbtYwMQ1NtOuIJr57XfUAuCwzSFp6Rr/OCiY/KG4oPisWgQUvPnDaW3DWFSHSyE4OssGluDBmvRoq5/ESJJdUla47DfgSmpJWQ2r3OccXQDtgGqvDfbrjpEMHlQEH75FsIWltPySRih89i8FClYJVXkepBNClJF1MrVME7/zYe1dEroujBAbCIl+Z9+vaGhH44pElY+w3D4p/uvYGJP3odiuz1UJ4rPZ4LrmdsN5LwrasnEjLU5dgAGL3hlmFo1iU6BtfBvNm9LQPkrQaOzdnYnMNZJ1tt5TpsuAPxqL/gbwafnux3FUBr7+N3URQexmpCXl7ipDO9B2JOO3OFZDuUIWqsXL61RqQpgx922pEgaroHEP7iGfXc84lFBSLFsyUdV00kobocfpyFHMq01BqN2JovSeoB9uWA+Cs4rC4Z6DxYNoBdosTvIwWOhk2f2k3NjClczTfoTFagPBC3npVYGPKvi0xE4jMJWLG62sgJBT0LwvxYA9s3/s3qLgRYNKAAyYGVkcfPLpfnqFRqTpiIHPalp3ucvcAjkqPMoA1cAwKH4yvj6gcxrIVbpCgBYRLJBtpfNOWz7Ary/5ldSd6609GKfqjEMAe+T2rx9692oZ0Ihw7J2kNDbWiIr4NG8YrO/qQMZA0a6UaPiOigbiCYSwvqPHY/vexK+x/FklNeWgaXYQ26GZi6kWxMrcE1gmRRR1nVninAhVdSvg8XevPu3GEN2Rk
Content-Type: text/plain; charset="utf-7"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: IA1PR05MB9550.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 461b6aaa-f0ba-46b4-fc7b-08dc2cc477fd
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2024 18:49:11.7538 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 7azOoVJQNTsbgKq2sI4oJRRmffWIJddOpTif08xFnNuut+7HuIMRAU5+O2fIMCfxonknCNtG7yzgwwbwwer9+w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR05MB7216
X-Proofpoint-ORIG-GUID: _hbCu3I_S36um1fJ66djmotBupIHC-R9
X-Proofpoint-GUID: _hbCu3I_S36um1fJ66djmotBupIHC-R9
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-02-13_11,2024-02-12_03,2023-05-22_02
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxlogscore=999 suspectscore=0 mlxscore=0 bulkscore=0 priorityscore=1501 lowpriorityscore=0 adultscore=0 clxscore=1011 phishscore=0 impostorscore=0 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2401310000 definitions=main-2402130147
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/Mh77WGslse3jSN_6dW_FHv8WVoQ>
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: Tue, 13 Feb 2024 18:49:28 -0000
I approve the changes. Juniper Business Use Only -----Original Message----- From: Rishabh Parekh (riparekh) <riparekh@cisco.com> Sent: Tuesday, February 13, 2024 1:19 PM To: Megan Ferguson <mferguson@amsl.com> Cc: rfc-editor@rfc-editor.org; daniel.voyer@bell.ca; Clarence Filsfils (cfilsfil) <cfilsfil@cisco.com>; hooman.bidgoli@nokia.com; Jeffrey (Zhaohui) Zhang <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 [External Email. Be cautious of content] I have reviewed the document and I approve the publication of this document. Thanks, -Rishabh > -----Original Message----- > From: Megan Ferguson <mferguson@amsl.com> > Sent: Monday, February 12, 2024 11:28 AM > 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9524.txt__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2AhtzhN6C$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9524.pdf__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2At5wdyZF$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9524.html__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2AvmGJHPb$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9524 > .xml__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbjolTKN > MMy8BVgZ0dyvedjeZr4wWw2ArSmpQv9$ > > The relevant diff files have been posted here (please refresh): > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9524-diff.html__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2AoqVGCVg$ (comprehensive diff) > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9524 > -rfcdiff.html__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHH > pDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2An30MYC9$ (comprehensive side- > by-side) > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9524 > -auth48diff.html__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGL > AHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2AhsKNSCP$ (all AUTH48 > changes) > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9524-lastdiff.html__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2AgwhUJWb$ (last version to this) > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9524 > -lastrfcdiff.html__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNG > LAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2AsNtdFVD$ (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://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9524_ > _;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbjolTKNMMy8B > VgZ0dyvedjeZr4wWw2Akmvkl_4$ > > 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9524.txt__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2AhtzhN6C$ > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9524.pdf__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2At5wdyZF$ > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9524.html__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2AvmGJHPb$ > >> > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 > >> 524.xml__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDb > >> jolTKNMMy8BVgZ0dyvedjeZr4wWw2ArSmpQv9$ > >> > >> The relevant diff files have been posted here (please refresh): > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9524-diff.html__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2AoqVGCVg$ (comprehensive) > >> > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 > >> 524-rfcdiff.html__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OB > >> NGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2An30MYC9$ > >> (comprehensive side- > >> by-side) > >> > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 > >> 524-auth48diff.html__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i1 > >> 7OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2AhsKNSCP$ (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://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc95 > >> 24__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbjolTK > >> NMMy8BVgZ0dyvedjeZr4wWw2Akmvkl_4$ > >> > >> 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://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2As449bGc$ . > >>>> --> > >>>> > >>>> > >>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/materials/sourcecode-types.txt__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2AuFW70Lo$ ) 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://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2AqfHJG1q$ > > >>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2AnFwjjVv$ ). > >>>> > >>>> 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://urldefense.com/v3/__https://trustee.ietf.org/license-info/__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2AlwOtJJ0$ ). > >>>> > >>>> * 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2AhU4LM48$ >. > >>>> > >>>> * 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg > >>>> /ietf-announce/yb6lpIGh-__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNp > >>>> SgJa-i17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2Ai-EJ00P$ > >>>> 4Q9l2USxIAe6P8O4Zc > >>>> > >>>> * The archive itself: > >>>> > >>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/bro > >>>> wse/auth48archive/__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i > >>>> 17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2Am4j-wyt$ > >>>> > >>>> * 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rf > >>>> c9524.xml__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAH > >>>> HpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2ArSmpQv9$ > >>>> > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rf > >>>> c9524.html__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLA > >>>> HHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2AvmGJHPb$ > >>>> > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rf > >>>> c9524.pdf__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAH > >>>> HpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2At5wdyZF$ > >>>> > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rf > >>>> c9524.txt__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAH > >>>> HpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2AhtzhN6C$ > >>>> > >>>> Diff file of the text: > >>>> > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rf > >>>> c9524-diff.html__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17O > >>>> BNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2AoqVGCVg$ > >>>> > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rf > >>>> c9524-rfcdiff.html__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i > >>>> 17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2An30MYC9$ (side by > >>>> side) > >>>> > >>>> Diff of the XML: > >>>> > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rf > >>>> c9524-xmldiff1.html__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa- > >>>> i17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2ArLv5iLm$ > >>>> > >>>> The following files are provided to facilitate creation of your > >>>> own diff files of the XML. > >>>> > >>>> Initial XMLv3 created using XMLv2 as input: > >>>> > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rf > >>>> c9524.original.v2v3.xml__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpS > >>>> gJa-i17OBNGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2Aj1xRUzb$ > >>>> > >>>> XMLv3 file that is a best effort to capture v3-related format > >>>> updates > >>>> only: > >>>> > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rf > >>>> c9524.form.xml__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OB > >>>> NGLAHHpDbjolTKNMMy8BVgZ0dyvedjeZr4wWw2ArNWAJdl$ > >>>> > >>>> > >>>> Tracking progress > >>>> ----------------- > >>>> > >>>> The details of the AUTH48 status of your document are here: > >>>> > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc > >>>> 9524__;!!NEt6yMaO-gk!GWPPJyb44g4oCcOOyZSPtpNpSgJa-i17OBNGLAHHpDbj > >>>> olTKNMMy8BVgZ0dyvedjeZr4wWw2Akmvkl_4$ > >>>> > >>>> 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