[RTG-DIR]Re: RtgDir Last Call review: draft-ietf-pals-ple

"Christian Schmutzer (cschmutz)" <cschmutz@cisco.com> Sat, 08 June 2024 09:16 UTC

Return-Path: <cschmutz@cisco.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBA1C14F6A0; Sat, 8 Jun 2024 02:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.585
X-Spam-Level:
X-Spam-Status: No, score=-14.585 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=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 header.b="SxnSNXZN"; dkim=pass (1024-bit key) header.d=cisco.com header.b="Nai0oPDS"
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 pN2TYrCwacSE; Sat, 8 Jun 2024 02:16:22 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (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 DEBBCC14F69B; Sat, 8 Jun 2024 02:16:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; i=@cisco.com; l=35011; q=dns/txt; s=iport; t=1717838182; x=1719047782; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wBWKyryd1gbcB7O9r6ECvyr+PV9KIBSmET/bJEIU4wc=; b=SxnSNXZNuh1YpmHZ3F8oCOM8WxK6aXfXkA9l5SOkFxrEXYYVWhm1Bhlb JK8/o9VsTFfqMeE5dFsm/zToymzhCSIff+udNEWstzvPqztPRSS9kFVTw hg472NffriNXraOetq+CgcSIaqOzHm8QZSbRleemJ7Bb0spB2OjO8B8ZC Q=;
X-CSE-ConnectionGUID: v5F58SS6Tf6RIAAz2coV4w==
X-CSE-MsgGUID: ivVI/hIMS6GAA3PeTAuD5w==
X-IPAS-Result: A0AXAADiIGRmmJFdJa1aHQEBAQEJARIBBQUBZYEWCAELAYFxUnoCgRxIhFWDTAOETl+IboEWik6ME4E4hGAUgREDVg8BAQENAQE5CwQBAYUGAhaITwImNAkOAQICAgEBAQEDAgMBAQEBAQEBAQYBAQUBAQECAQcFFAEBAQEBAQEBHhkFDhAnhXQNhloCAQMSER0BASkOAQ8CAQYCEhsVAgICHhEXDgIEDgUigl4BghwUAzEDARCSeI9QAYFAAoooeoEygQGCDAEBBgQF2xsNgk8JgUgBiBIEGgEFH0hpAgKEBYIrgjMnG4FJRIEUAScbgjA4PoIfQgEBgRkfDhk/AYMcOoIviAwBhHlEQAoRHQ+CWyNBgRY6LluBHUOCMho6D4EobQUNDn2CQ4IdFYJ2fyYLQ1sQiTlKCmUSIgMmMyECEQFVEw0KCz4dAhYDGxQEMA8JCyYqBjkCEgwGBgZZNAkEIwMIBANCAyBxEQMEGgQLB3aBcYE0BBNHgTeJcQyBe4E0KYFLKYELgw1LbBODcIFrDBJPiHEFgQstgRGBJEIBghSBRlOBSx1AAwsYDUgRLBQhFBsGPm4Hpw4EOIJyUjZNAQMLJBQQIAI1SSUHAQ0jBgEDDBkFAQVAkkYkAgKDDEmLLaIVTGULCoQTimuBJI8uhg4EL4QFjQCYUGSYZY12hAGRFyogTgGEOQIEAgQFAg8BAQaBZTqBW3AVOyoBgjwJNhMZD44hDA0Jg1iFFGDFEXgCOQIHAQoBAQMJiG+BeQEB
IronPort-PHdr: A9a23:FwxgDBQuZcJYRrBdpMPHrAVLLNpso3fLVj580XJvo6hFfqLm+IztI wmGo/5sl1TOG47c7qEMh+nXtvX4UHcbqdaasX8EeYBRTRJNl8gMngIhDcLEQU32JfLndWo7S exJVURu+DewNk0GUN3maQjqq2appSUXBg25MAN0IurvHYuHhN+81+Wv54/7aARTjz37arR3f 126qAzLvZwOiJB5YuYpnwHEoHZDZ6xaxHg9I1WVkle06pK7/YVo9GJbvPdJyg==
IronPort-Data: A9a23:GT0g0qjB6w0LoGdLDAZ7Rm3nX161tBAKZh0ujC45NGQN5FlHY01je htvUWqHOqvfazP1fox0b9/k/EkD6sTWmtA1TwQ9ryAwRXljpJueD7x1DKtf0wB+jyHnZBg6h ynLQoCYdKjYdleF+1H1dOCn9CEgvU2xbuKUIPbePSxsThNTRi4kiBZy88Y0mYcAbeKRW2thg vus5ZWPULOZ82QsaD5MtfrT8EoHUMna4Vv0gHRvPZing3eG/5UlJMp3Db28KXL+Xr5VEoaSL woU5Ojklo9x105F5uKNyt4XQGVTKlLhFVTmZk5tZkSXqkMqShrefUoMHKF0hU9/011llj3qo TlHncTYpQwBZsUglAmBOvVVO3kWAEFIxFPICWbin5HD9HaYT3Wy+dRHJVNsNoompvkiVAmi9 dRAQNwMRgqIi+Tzy7WhR6w9wM8iN8LseogYvxmMzxmAUq1gGs+FEv6MvIMFtNszrpgm8fL2b NESaT9ycAboaBxUMVBRA5U79AutriOuKWwH+QzP9MLb5UDS0jJQl7jMFeGLVfWjHv1Yom+Fi j/ZqjGR7hYyb4HHlmHfrRpAnNTnhz/0HY4TDpW5++JkxlqJyQQ7BAcfW0f+oPSlhAumUtZEb lQQ9wIvoLQ8skuxQbHVRxS8u1aFswISHd1KHIUS8AiJ0e/f4w+YHHMsTzNdZpohrsBebSY22 RqAk8jBBDFzvvuSU331y1uPhSm5NS5QJmgYaGpVCwAE+NLk5oo0i3ojU+qPDoar0/OoSQrLn QyE8hIfrpwB18UM6fmkqAWvby2XmrDFSQs85wPyV22j7x9kaIPNW2BOwQaChRqnBNjAJmRtr EQ5d96iAPfi5KxheQSXS+kLWbqu/fvAYXvXgEVkGN8q8DHFF5+fkWJ4vm8WyKRBa5psldrVj Kn74l85CHh7ZybCUEOPS9jtY/nGNIC5fTgfatjab8BVfr96fxKd8SdlaCa4hj+0zxd8zPlgZ c7GIK5A6Er274w6nFJaoM9AjtcWKtwWmgs/uLiilkX6ieLODJJrYe5fagvmgh8FAFOs+1iNr I0FaKNmOj1UUfb1ZWHM4JUPIFURZXk9DtaeliCkXrDrH+aSI0l4U6W56ep4I+RNxv0J/s+Wp SvVchEDlzLCaYjvdF/ihoZLMu2/BP6SbBsTYEQRALpf8yJyPd7yvPZDKsNfkHtO3LUL8MOYh sItIq2oKv9OUT/AvT8aaPHAQEZKLXxHWSrm0/KZXQUC
IronPort-HdrOrdr: A9a23:CK4Da6PNYBuCi8BcT4f255DYdb4zR+YMi2TDiHoBKiC9I/b5qy nxppUmPEfP+UcssREb9expOMG7MArhHO1OkPks1NaZLUfbUQ6TXeNfBOTZskDd8kHFh4lgPO JbAtZD4b7LfBlHZKTBkXWF+r8bqbHtntHM9IPjJjVWPH5Xgspbnn9E43OgYzdLrX59dOEE/f Snl6x6jgvlU046Ku68AX4IVfXCodrkqLLKCCRtOzcXrCO1oXeN8rDVLzi0ty1yb9pI+9gf2F mAtza8yrSosvm9xBOZ/XTU9Y5qlNzozcYGLNCQi+AOQw+cyTqAVcBEYfmvrTo1qOag5BIBi9 /XuSotOMx19jf4Yny1mx3wwAPtuQxeqUMKiGXoxEcLk/aJAw7SOPAxw76xtSGpsnbIiesMlJ 6jGVjp76a/QymwxxgVrOK4JC2C3nDE00bK19Rjz0C2leAlGeJsRUt1xjIOLL4QWC3984wpC+ 9oEYXV4+tXa0qTazTDsnBo28HEZAV/Iv8XKnJyz/B9/gIm10yR9XFojvA3jzMF7tYwWpNE7+ PLPuBhk6xPVNYfaeZ4CP0aScW6B2TRSVaUWVjibmjPBeUCITbAupT36LI66KWjf4EJ1oI7nN DEXElDvWA/dkryAYmF3YFN8BrKXGKhNA6dhv129tx8oPnxVbDrOSqMRBQnlNahuewWBonBV/ O6KPttcrfexKvVaM90NiHFKu9vwCMlIbkoU/4AKiWznv4=
X-Talos-CUID: 9a23:rbyN9Gzqb9/avwH8vUNjBgUKR+54IkbmkkvefXWZIE97EraSdwOPrfY=
X-Talos-MUID: 9a23:2gj2RQZqANIDaOBTtiHSpXZiFeJTvYuHIRs1nKkvpuXZKnkl
X-IronPort-Anti-Spam-Filtered: true
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2024 09:16:20 +0000
Received: from rcdn-opgw-1.cisco.com (rcdn-opgw-1.cisco.com [72.163.7.162]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 4589GKKB001279 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 8 Jun 2024 09:16:20 GMT
X-CSE-ConnectionGUID: F5dqU/rsQiCK5s9jvLjWSw==
X-CSE-MsgGUID: VW9J7X3kT8y9rZTevwnakg==
Authentication-Results: rcdn-opgw-1.cisco.com; dkim=pass (signature verified) header.i=@cisco.com; spf=Pass smtp.mailfrom=cschmutz@cisco.com; dmarc=pass (p=reject dis=none) d=cisco.com
X-IronPort-AV: E=Sophos;i="6.08,222,1712620800"; d="scan'208,217";a="11966392"
Received: from mail-dm6nam10lp2101.outbound.protection.outlook.com (HELO NAM10-DM6-obe.outbound.protection.outlook.com) ([104.47.58.101]) by rcdn-opgw-1.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2024 09:16:20 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y/dXopO72vBsLg4jjNzaYEowXidt6SLS/tMSCfwGz6//esdeECRvyyoPO7dAXeh31y4dQWTm1GuPFHlXGJYaku0734DF+XGHq/bu6ufQSvzMcyF/uBk02YibU6VFY/EJyv8OQrn+Ba3wejIJOp/gKfda29NMV+aLJBojQrmHsKZ4qdWEJd9CqK/SUxaxscZIEWP5GSTXTNz4LfdWjazm2POdzSnAigfacPntC1Tp+KEV4qYiKhR6NxkqZJF9uzMSPMwzBiJzsPbda6RuLKKsEX7H3t8Si1mBdxoV3UZ3QuQj+rSEQ02ougH3I+PO1IAVhMcmNQWKCW8WyFuvK4+Z+Q==
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=wBWKyryd1gbcB7O9r6ECvyr+PV9KIBSmET/bJEIU4wc=; b=HAqjwmX4dacFjW5L4OGPJEwH8tj5DhmH5b6R76hH70zCsLm+wkEdlvkI6PP7yO3FHKNlwU/G2GUIcIvxRnHau8ytQ7HrpuHULOWvtHsFTqsow+XoGdjg9bOD9jAsU5FcZkalOtLDHn25aiKfji+h6+f4gagNooQTG1A1hd1vk5bo8yxZ3ABLD0fmPutzg4SsnZFbD93OahDRQJX9tv3UQNDSnmQXQh8tdPdRH7kiSI7d4I47/e37e0BVt0KbTRpfvTGFClDAKzKDrBEIgD5xXP/oHd3RmP7ZrusYXTWOOUnTmuU6ihNF7MV2J4+pbsAhMi0t5QjuxGCZiMvbX7Ov0Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wBWKyryd1gbcB7O9r6ECvyr+PV9KIBSmET/bJEIU4wc=; b=Nai0oPDS3Tbbw2onifHfAKgnGRbQnfDocYcnHtgImzXb0/gYM4N42WuUuGfcJWBCIAA1s1d4Q3K6/HR8VS2+qV5KA8RaQVRYBq5OAYRinwgS88R14KpLkkq5PrzkItwXylKQqhbmCHHDWG01cEiZjMgMtG/KsbYa9Rzdb7JY71s=
Received: from LV3PR11MB8696.namprd11.prod.outlook.com (2603:10b6:408:216::14) by DS0PR11MB7558.namprd11.prod.outlook.com (2603:10b6:8:148::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7633.27; Sat, 8 Jun 2024 09:16:18 +0000
Received: from LV3PR11MB8696.namprd11.prod.outlook.com ([fe80::18b4:3d58:9f3a:610d]) by LV3PR11MB8696.namprd11.prod.outlook.com ([fe80::18b4:3d58:9f3a:610d%3]) with mapi id 15.20.7633.033; Sat, 8 Jun 2024 09:16:12 +0000
From: "Christian Schmutzer (cschmutz)" <cschmutz@cisco.com>
To: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Thread-Topic: RtgDir Last Call review: draft-ietf-pals-ple
Thread-Index: AQHapqDGP6YjkURmXUWCHSj9po4+JrG9u7SA
Date: Sat, 08 Jun 2024 09:16:12 +0000
Message-ID: <8DB06D5B-E2E5-4BC9-ACA2-EBE552E51266@cisco.com>
References: <CABUE3Xn7XyqQAUJpr9qGx-yG3Au=OX00sgX8uZ4vOBHLpLdhrw@mail.gmail.com>
In-Reply-To: <CABUE3Xn7XyqQAUJpr9qGx-yG3Au=OX00sgX8uZ4vOBHLpLdhrw@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3774.600.62)
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: LV3PR11MB8696:EE_|DS0PR11MB7558:EE_
x-ms-office365-filtering-correlation-id: fe47e08b-4890-4160-c079-08dc879ba463
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230031|376005|1800799015|366007|38070700009;
x-microsoft-antispam-message-info: d+HNOi5PcgsEZfm6LB/7WdlYTwobCU5+855yw9vG0++p4r9m3d3zmwUVkgPo7QJ9d/+e9+2m/UU8sLtRtbfvicG2OlvxFSR23OllXT70ErNyc1Jn7F/kCrHAFmB5owbUoxzYZhd7l8JO8GWIzIh/fk/+H0omsVluRfGxMo+SNHrBkaZJk2w76TYHRFrz3l0y8jAyuAp8SO6cZWunMOvwvjNKVc8pO+ePJJsStGtsa7OwHbh0ESlv9Kk7O30Gjl4RT1zGngesSoy0rhTp7+z6fmuYtOyTP/bdM6R+aGdMFKKCM0Kz5Xqf7Rbqu792lfzlQbCAX8z4UXYT/cXdQ/ew+nqGDhkeiFjuizcia+qCIyYUjG6CL0C/1dA/WzotxtL8gsKPHXPG15T0dd/CSSfgF4chb8rpgejbrbMuq9bR0rWkguq7IgU0Vh7fG1xG1AhFjNCYNFAlq+rGTzVqjeTQIpRN729Ar5E9+gJt0xQPKJ82+EQtakNymYH2Z9gNcPdugfyH0rP34HCD2CpuS2i1e3t3CDqiFCS37MKgyfPLRvqPwKWwtyPmQIIjoAZSRpIVM9U12F2fRssFJrxcTPvvzH+KdxV5aTJBdYpP7ejUIdui9J2TocqX1p3yuxscYWrINMmDX7fvBzcD/fclzaU8tK120Vdcl5kLM0n/sN3rhSoQQxWbkJ0CQ8ennEtC4a/ULIyKzitLGekOGN8/gw1l+Tp0sdbYwhIFXRXvR4HZ7maq4pg7JV7gbMLzkOkOMtlaLw4uWOPC5cPPEwp1d5mgU+Z9uMf8kSF9tK3B35+iib8NEmkGcjiMV8hx9aTblJwQthfWobXxiZJM5bYCXazHhrUEJCq4YQmPMz1sM8rvvNT0VU5vtx982Xxx7twvBumOjyTqjh99HSHceolIDRlD4wK5smToER+uopGvIFlu7C17iQivPrMj/yKyOX5tjhW5ixGcyql4LihFiCXbW6ybMazS7AuwIXfXydtYFxV417RqfWe/6L/vqmmyaAmBnIOHe9U0TwpvtkEtQFj5oxyvfy+S0HRT+35uiFl/aUxgP+u6a1HaEF+fdfY5sq3eZtCaARnCClxRv2f8BvF0vvDKg0VuSGiRIDGUmgJ9AAGtsap8mE5/b7zQVd0FyJEAH4BWX+gLPXnr3YyTGUY4rMJ5pHfv0b6gC1j8jV2fnioPvXWzVp2o75duGY/9aueb3+guFiwg19T2kTnCOiXdpj9pGODaY6vaVFF+YXfh99ddawO/Ql4hMVAVEYrjRV68tC9SoXyKzSk2WPqcJdi7Yy60g2RLZrqEzj9DTy8lKlolPfAr8HXqacSX4pXWsjebxz8H
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR11MB8696.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005)(1800799015)(366007)(38070700009);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: oUUVMGtpHOPh97P+MPj0cktDc9x4jp10Qr1TcUUbYIToij00wA1EVmezKjt9ejhy9nHV1Y1wXZiqAXgy5rYcaMbk1z/b2PIVhusMTe7AwhwzCk5ZLyuRYofOA/mkyhHSW5ctTRfEF7Xl8VXyvlYKzuFkObC7+g11+2bZczVfFWSkhpRQHsoTOWETWqpxFcxwMIQiOLetLqaFV4SmDbAQbRXXaC/KpGTVS/BxL9LJ2Df67NGIgMM14W+yDMNoVxgiIRt4W3oqRXOMNo1N0cqeUZ98/lNvD+WIpSTnzyyF/6Qyprww6ACW7buevLXTa0UbrFmp0oSokiWNlAt8VH2txZliYySa3D+DqaKnn6jBP8KvXsDXbqKqeXyvQ6H8F2vnDbHllYOlDtiuWvrpeaRTqP0ApBMqgmvYQR+Bwzf2XuiWaNrm5MXALq1YFOwLEgbpRSoTJQEvktWoQtJY0CwhR1h9+DJuo0P/VWbJoGYf1HRD1zyJHRvZszVK3EM9ap1dyTcVc9vqJa9Ih5hoM641MsxYauZTgBN+5KGO+V7qnCfAljiZTNUIp+ke+ZYH4AR0v8ly8MdCgYOn5xrjjZCv4u1arPbo+th//TbTYYTJwfCZ+V1A0Ez0Jr0g0U2jNCYHJF7+qi//yilSs5CkTa+PunpLndCLS/9pk98M6NR3VLqHyO9MA/mc7sKku1k7v8wGc3KyLf33bOAPW/RgZL+hZ7xAh0LrJH8xMVAzzpOr32QsaUPjuzjQxQuqZiIIMXXBeHOZPezRGYVQN44rwul5eKb4jYiA1QkU84O4c1J6MlQPi6Naxc6r9XsSh+xC7Xmf4LhtSPyFYMLuF0zij4m3iFo2aPnWifnPs9/Pht06B3jjq7zPVYWUCuLsZEDc/3WFYl1JrNPAlo9J1VQiVdOkGuvAVVwDSJ/2ffgc/AQkiBolCOpC6oKLl5Hmb3sFfu1jC0sVZkrzlfolKbPwkYosIZaZGN4a4ah5+mdmZKmRKH12kDONh0ogYGmRKjq8J5M1M2kWJa0zwmvv+JvTS967yfcoOP7xo8jXOfp0xk8/Ch9BSqpLTFtAgFI6ieJZlUNDU9UeGU42clUCsb2hV3kW9F0yIBGkXo9VG0CkJSfR/xNkI7Diyw5se5uyFjOV+w2nZnbyi1B7Wo9fx0Zl9XrEX3aveeN+mcZM8KcUbh6nL3Kosg6WTqMzNHjCOTN/mW5NiMFsHpiCRTmFA2SFGbOKPYfjTBGUleVQ/NubjZMrbsJySPArmyZvX+UpyxVDsJxtd5AywtDhZPxFHxnDsrbqz7+G4vUPuMptg73s84W/zxmuJ20rnpKC47+V9Ryj4ZGDzgvXD0j1APJmUSGEpnCes2I2QuRFrU/2Rw1nDA4s7omsSP0xKphMqwp1syL1gpwhTsDczWKRj5Z9ZotdPJ8CN4XdBBhCXPwyfTvwqSAjk6Q3DyhHj7BMhUjcVn8sxXirgyvU8xrK/C3MvEqZsD/pp79eYeGdluOLotX2xUH3B9qS8FicQOOCYZSQWOXaS9D1TguNlsMZakOnWrJKS4cuHI7k62Y/B4v4iNUfJiEEtYJRI5Q60WZGhzursrm2fNV5
Content-Type: multipart/alternative; boundary="_000_8DB06D5BE2E54BC9ACA2EBE552E51266ciscocom_"
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: LV3PR11MB8696.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fe47e08b-4890-4160-c079-08dc879ba463
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2024 09:16:12.6863 (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: zB2KH5VDfnhl4n/hkgMtvBYGY7LkSsLpRqkkc//tFnltiFZYIht4jomb3EsQK1XLE69QqXygOfmpyak4rp41iA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB7558
X-Outbound-SMTP-Client: 72.163.7.162, rcdn-opgw-1.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Message-ID-Hash: AX64KPNHRHWJOXPE5D44RSD77QNG3NAQ
X-Message-ID-Hash: AX64KPNHRHWJOXPE5D44RSD77QNG3NAQ
X-MailFrom: cschmutz@cisco.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtg-dir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "Christian Schmutzer (cschmutz)" <cschmutz@cisco.com>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "pals-chairs@ietf.org" <pals-chairs@ietf.org>, "pals@ietf.org" <pals@ietf.org>, "draft-ietf-pals-ple@ietf.org" <draft-ietf-pals-ple@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [RTG-DIR]Re: RtgDir Last Call review: draft-ietf-pals-ple
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/uYKaTQ8eVTeyzwjx9x98Vdw3oZY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Owner: <mailto:rtg-dir-owner@ietf.org>
List-Post: <mailto:rtg-dir@ietf.org>
List-Subscribe: <mailto:rtg-dir-join@ietf.org>
List-Unsubscribe: <mailto:rtg-dir-leave@ietf.org>

Hi Tal,

Sorry for taking so long. Below our comments and proposal for addressing your issues.

Can you please let us know your thoughts. Upon your feedback we will work towards uploading a new version addressing the issues.

regards
Christian

On 15.05.2024, at 01:20, Tal Mizrahi <tal.mizrahi.phd@gmail.com> wrote:

Hello,

I have been selected as the Routing Directorate reviewer for this
draft. The Routing Directorate seeks to review all routing or
routing-related drafts as they pass through IETF last call and IESG
review, and sometimes on special request. The purpose of the review is
to provide assistance to the Routing ADs. For more information about
the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-pals-ple-04
Reviewer: Tal Mizrahi
Intended Status: Standards Track

Summary:
I have some concerns about this document that I think should be
resolved before publication.

The draft is well-written and clear from a grammatical and structural
perspective. However, there is a very long list of normative
references that are cited in almost every paragraph of the document,
making it very difficult to follow for a reader who is somewhat
familiar with the area but is not an expert in the area.

[cs]
PLE has a lot of similarities with RFC 4553 and other referenced specifications. We felt references are better as it avoids duplication of text across documents, but I see your point. We will work through the document and add a bit more text / context before calling out a RFC reference.

Here an example from the introduction section. Will do something similar for other sections.

before:
The mechanisms described in this document follow principals similar to [RFC4553] but expanding the applicability beyond the narrow set of PDH interfaces (T1, E1, T3 and E3) and allow the transport of signals from many different technologies such as Ethernet, Fibre Channel, SONET/SDH [GR253]/[G.707] and OTN [G.709] at gigabit speeds by treating them as bit-stream payload defined in sections 3.3.3 and 3.3.4 of [RFC3985].

after:
The mechanisms described in this document follow principles similar to Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) defined in [RFC4553]. The the applicability is expanded beyond the narrow set of PDH interfaces (T1, E1, T3 and E3) to allow the transport of signals from many different technologies such as Ethernet, Fibre Channel, SONET/SDH [GR253]/[G.707] and OTN [G.709] at gigabit speeds. The signals are treated as bit-stream payload which was defined in the Pseudo Wire Emulation Edge-to-Edge (PWE3) architecture in [RFC3985] sections 3.3.3 and 3.3.4.


Where applicable we will remove the reference and just have appropriate text. Once example

before:
Similar to [RFC4553] and [RFC5086] the term Interworking Function (IWF) is used to describe the functional block that encapsulates bit streams into PLE packets and in the reverse direction decapsulates PLE packets and reconstructs bit streams.

after:
The term Interworking Function (IWF) is used to describe the functional block that encapsulates bit streams into PLE packets and in the reverse direction decapsulates PLE packets and reconstructs bit streams.


Issues:
- The target audience of the document should be clarified, preferably
in the abstract. On a related note, throughout the document it is a
bit difficult to distinguish between requirements defined for
operators vs. requirements defined for implementers. Perhaps the
authors could give some thought as to whether this issue can be
mitigated.

[cs]
the target audience is implementers. We adjusted the abstract to reflect that

before:
This document describes a method for encapsulating high-speed bit-streams as virtual private wire services (VPWS) over packet switched networks (PSN) providing complete signal transport transparency.

after:
This document describes methods and requirements for implementing the encapsulation of high-speed bit-streams into virtual private wire services (VPWS) over packet switched networks (PSN) providing complete signal transport transparency.

- The security considerations should be more detailed. The cited
references are a good start, but the following issues should also be
discussed:
 - The requirement for synchronization is potentially a
vulnerability. An on-path attacker may compromise the synchronization,
and thus compromise the service. You may want to take a look at RFC
7384.
 - The requirements for low jitter, low loss and bandwidth
reservation (section 8) are also potentially an attack vector. You may
take a look at RFC 9055 for example.

[cs]
We have added a couple of sentences to provide more details, plus referred to respective RFCs for more information

before:
As PLE is leveraging VPWS as transport mechanism the security considerations described in [RFC7432] and [RFC3985] are applicable.


after:
As PLE is leveraging VPWS as transport mechanism the security considerations described in [RFC7432] and [RFC3985] are applicable.

PLE does not enhance or detract from the security performance of the underlying PSN. It relies upon the PSN mechanisms for encryption, integrity, and authentication whenever required.

A data plane attack may force PLE packets to be dropped, re-ordered or delayed beyond the limit of the CE-bound IWF's dejitter buffer leading to either degradation or service disruption. Considerations outlined in [RFC9055] are a good reference.

Clock synchronization leveraging PTP is sensitive to Packet Delay Variation (PDV) and vulnerable to various threads and attacked vectors. Considerations outlined in [RFC7384] should be taken into account.


- The following two endpoint behaviors are defined in the IANA
considerations section, but not defined anywhere in the document.
These endpoint behaviors should either be removed or specified in
detail:
End.DX1 with NEXT-CSID
End.DX1 with REPLACE-CSID

[cs]
Good point and I realised we have also forgotten to add the required encaps description. We have reworded this section as follows (in markdown syntax)

When a SRv6 PSN layer is used, a SRv6 service SID does provide the demultiplexing mechanism and the mechanisms defined in {{?RFC8402}} and {{?RFC9252}} section 6 do apply. Both SRv6 service SIDs with the full IPv6 address format defined in {{?RFC8986}} and compressed SIDs (C-SIDs) with format defined in {{?I-D.draft-ietf-spring-srv6-srh-compression}} can be used.

Two new encapsulation behaviors H.Encaps.L1 and H.Encaps.L1.Red are defined in this document. The behavior procedures are applicable to both SIDs and C-SIDs.

The H.Encaps.L1 behavior encapsulates a frame received from an IWF in a IPv6 packet with an SRH. The received frame becomes the payload of the new IPv6 packet.

* The next header field of the SRH MUST be set to TBA1.

* The push of the SRH MAY be omitted when the SRv6 policy only contains one segment.

The H.Encaps.L1.Red behavior is an optimization of the H.Encaps.L1 behavior.

* H.Encaps.L1.Red reduces the length of the SRH by excluding the first SID in the SRH of the pushed IPv6 header. The first SID is only placed in the destination address field of the pushed IPv6 header.

* The push of the SRH MAY be omitted when the SRv6 policy only contains one segment.

Three new "Endpoint with decapsulation and bit-stream cross-connect" behaviors called End.DX1, End.DX1 with NEXT-CSID and End.DX1 with REPLACE-CSID are defined in this document.

These new behaviors are variants of End.DX2 defined in {{?RFC8986}}, End.DX2 with REPLACE-CSID defined in {{?I-D.draft-ietf-spring-srv6-srh-compression}} and End.DX2 with NEXT-CSID defined in {{?I-D.draft-filsfils-spring-net-pgm-extension-srv6-usid}} and all have the following procedures in common.

The End.DX1 SID MUST be the last segment in an SR Policy, and it is associated with a CE-bound IWF I. When N receives a packet destined to S and S is a local End.DX1 SID, N does the following:

~~~~
S01. When an SRH is processed {
S02.   If (Segments Left != 0) {
S03.     Send an ICMP Parameter Problem to the Source Address
         with Code 0 (Erroneous header field encountered)
         and Pointer set to the Segments Left field,
         interrupt packet processing, and discard the packet.
S04.   }
S05.   Proceed to process the next header in the packet
S06. }
~~~~

When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DX1 SID, N does the following:

~~~~
S01. If (Upper-Layer header type == TBA1 (bit-stream) ) {
S02.    Remove the outer IPv6 header with all its extension headers
S03.    Forward the remaining frame to the IWF I
S04. } Else {
S05.    Process as per {{Section 4.1.1 of RFC8986}}
S06. }
~~~~


- Regarding the following paragraph, I wonder whether it is necessary
to define the exact clock frequency in an IETF document. Even ITU-T
G.8261 and IEEE 1588 do not define a specific clock frequency.
Interoperability does not necessarily require both endpoints to have
the same clock frequency.
     For bit-streams up to 200 Gbps the frequency of the
     clock used for generating timestamps MUST be 125 MHz based on a
     the common clock I.  For bit-streams above 200 Gbps the frequency
     MUST be 250 MHz.

[cs]
For differential clock recovery (DCR) to work the peer node must know which clock was used to create the timestamps. RFC4553 section 4.3.2 is pretty clear about this as well and we are following the same approach here in specifying this aspect for PLE.

"The frequency of the clock used for generating timestamps MUST be …”

“options associated with its usage (the timestamping clock frequency, the timestamping mode, selected PT and SSRC values) MUST be agreed upon between the two SAToP IWFs …”


Nits:
- "principals" => "principles" ?

[cs]
Thanks, will take care of it when publishing the next version