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

"Christian Schmutzer (cschmutz)" <cschmutz@cisco.com> Mon, 17 June 2024 05:14 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 8CD93C19ECB8; Sun, 16 Jun 2024 22:14:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.894
X-Spam-Level:
X-Spam-Status: No, score=-11.894 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_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, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, 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="SxU5aZO0"; dkim=pass (1024-bit key) header.d=cisco.com header.b="oeD6thZf"
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 UB4fB4fazORJ; Sun, 16 Jun 2024 22:13:58 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (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 9B98EC1840D6; Sun, 16 Jun 2024 22:13:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; i=@cisco.com; l=37355; q=dns/txt; s=iport; t=1718601237; x=1719810837; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LICu+O8WXBtDHw1VJ3kaUKPjlHw/5QpOlvx/CHd5EPU=; b=SxU5aZO0d9d/Ae3lVfvsEnRXYaiFp49av6fZvaBW9bwewuXuTKJtilf8 560UHHsvtt3xFvHGaiNGvzqKT6Ac80OnxY6DOAQF0+AgT5Un837BtK/UI d55afcOnW2TPwLs0vM/maaIfNaCd3ladGwF/S3doIM/LVpYLW0BJ3zAmh s=;
X-CSE-ConnectionGUID: WFcNryBJSymntVPZGZErtw==
X-CSE-MsgGUID: sCsxg+UjSAW5k9PxdCc+aA==
X-IPAS-Result: A0AXAADuxG9mmJxdJa1aHAEBAQEBAQcBARIBAQQEAQFlgRcGAQELAYFxUnoCgRxIhFWDTAOFLYZMgiIDgROKTowTgTiEYBSBEQNWDwEBAQ0BATkLBAEBhQYCFohdAiY1CA4BAgICAQEBAQMCAwEBAQEBAQEBAQUBAQUBAQECAQcFFAEBAQEBAQEBHhkFDhAnhXQNhlkBAQEBAgESCAkdAQEpDgEECwIBCBIGFRIDAgICHhEUAw4CBA4FIoJeAYIcFAMOIwMBEKFBAYFAAoooeoEygQGCDAEBBgQF2xsNgk8JgUgBiBIEGgEFH0hpAgKBbYRDgjMnG4FJRIEVJwsQgjA4PoIfQgEBgRkfDhkuEQGDHDqCL4gMAYR5gQQ4D4JbJEGBFDouW4Ebg0IHD4EobQUbfYJBgUlQFYJ2fyYLQVuLMkoKZRIiAyYzIQIRAVUTDQoLPgkWAhYDGxQEMA8JCyYqBjkCEgwGBgZZNAkEIwMIBANCAyBxEQMEGgQLB3eBcYE0BBNHgTeJbwyBe4E0KYFLJ4ENgw5LbBODb4FrDBJPiG4FgQstgRGBJEIBgg2BQ0yEFh1AAwsYDUgRLBQhFBsGPm4HqEcEOYMDEEI2JyYBAy8UCgYgAjVJOgQfBQIDDBkFBkCSRiQCgw0BSYstohUKQmYLCoQTjA+PLoYOBC+EBY0AmFBkmGWNdoQBkRcqIE+EOQIEAgQFAg8BAQaBZwI2gVtwFTsqAYI8CTYTGQ+OIQwNCYNYhRRgw0N4AjkCBwEKAQEDCYhvgXkBAQ
IronPort-PHdr: A9a23:QBOgtRagGo1VlfzszuGegs7/LTDlhN3EVzX9orI9gL5IN6O78IunZ grU5O5mixnCWoCIo/5Hiu+Dq6n7QiRA+peOtnkebYZBHwEIk8QYngEsQYaFBET3IeSsbnkSF 8VZX1gj9Ha+YgBOAMirX1TJuTWp6CIKXBD2NA57POPwT4XJhMSyyvyg05bSeA5PwjG6ZOA6I BC/tw6ErsANmsMiMvMrxxnEqWcAd+VNkGVvI1/S1xqp7car95kl+CNV088=
IronPort-Data: A9a23:+6hZaahyNmR70SeMz0INaQ/zX161hhAKZh0ujC45NGQN5FlHY01je htvDGCOPKqPZWLzedBzPY+w/B4G78WDx4BkTVY9+ywyQ39jpJueD7x1DKtf0wB+jyHnZBg6h ynLQoCYdKjYdleF+1HwdOGn9SQhvU2xbuKUIPbePSxsThNTRi4kiBZy88Y0mYcAbeKRW2thg vus5ZWPULOZ82QsaD5Mtfvc8EkHUMna4Vv0gHRvPZing3eG/5UlJMp3Db28KXL+Xr5VEoaSL 87fzKu093/u5BwkDNWoiN7TKiXmlZaLYGBiIlIPM0STqkAqSh4ai87XB9JAAatjsAhlqvgqo Dl7WTNcfi9yVkHEsLx1vxC1iEiSN4UekFPMCSDXXcB+UyQqflO0q8iCAn3aMqUn1O1RG3Bk1 8cJLTYRUCixqNCb2q6kH7wEasQLdKEHPasFsX1miDreF/tjHNbIQr7B4plT2zJYasJmRKmFI ZFGL2s0Kk2dPXWjOX9PYH46tOyzjXn6biFKgFmUvqEwpWPUyWSd1ZC3YYWJIIXSHp09ckCwv Und72u6PxMhHePCymu94n6HjazGtHauMG4VPOblrqEx2gL7KnYoIAcKWh63oOORi0OiVZRYM UN80iY0pKYusU2mUte4RxS8uzucuhM0WtdMHas98g7l4rLd5x2xB2UYQHhGctNOnNc/QSdv3 V+AnsnyLT1irLPTTmiSnp+OsTz3MCQOBW4PeSFCShEKi+QPu6kphR7JC91kCqPw05v+GCr7x HaBqy1Wa6gvYdAj6Iuw20rWqRCXt53PUjAN1Crlc3i58VYsDGK6XLCA5V/e5PdGCY+WSFido XQJ8/RyCshTXflhcwTTGY0w8KGV2hqTDNHLbbdS83QJ7T+h/TuoeppdpWw4L0ZyOcFCcjjsC KMyhe+zzMEMVJdJRfYrC25UNyjM5fKwfTgCfquIBueimrArKGe6ENhGPCZ8JVzFnkk2ir0YM pyGa8uqBntyIf04lWrrGb1DgeV1nXlWKYbvqXbTkk3PPV22OSH9dFv5GAfmgh0RtfrV/V2No 76zyePamkQ3vBLCjtn/qtNLcgtQchDX9Lj9qtdccaaYMxF6FWQ6Q/7XyvVJRmCWt/o9qws8x VnkAhUw4AOm3RXvcFzWAlg9M+mHdcgk8hoG0dkEYAzAN44LO9j/tc/ytvIfINEayQCU5acpH qdZJp/aXKQnp/au0211UKQRZbdKLXyDrQmPJCGiJjM4evZdq8bho7cIoiOHGPEyMxeK
IronPort-HdrOrdr: A9a23:7wLRMK1b5uFj8guMAoYQPgqjBH0kLtp133Aq2lEZdPU1SL37qy nKpp8mPHDP5Qr5NEtNpTn4AtjwfZqEz+8L3WBzB8bAYOCFggqVxdpZnO7fKlTbckWVygc678 hdmsNFaOEYY2IVsS/x2njeLz4GqOP3idHR9JyutUtFfEVIT6lh6gtjYzzrbnGePDM2eKbQyv Knl6x6TwLJQwVoUi0RPAh0YwGGnayuqK7b
X-Talos-CUID: 9a23:aLv3CmO3EIP48u5DZwds0lQFMOIeY3jb0EnoEWCKJHx1V+jA
X-Talos-MUID: 9a23:5aw+9wt36dmgHDQtzs2nnxp5JMgr3qaVIX9QksQ+q8WvPm95EmLI
X-IronPort-Anti-Spam-Filtered: true
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2024 05:13:56 +0000
Received: from rcdn-opgw-2.cisco.com (rcdn-opgw-2.cisco.com [72.163.7.163]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 45H5Dtjn010674 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 17 Jun 2024 05:13:55 GMT
X-CSE-ConnectionGUID: X3HhuBhCQyKkCP1U1qsydQ==
X-CSE-MsgGUID: wguot7YTSW21zRqLgA7vLQ==
Authentication-Results: rcdn-opgw-2.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,244,1712620800"; d="scan'208,217";a="15973064"
Received: from mail-bn7nam10lp2040.outbound.protection.outlook.com (HELO NAM10-BN7-obe.outbound.protection.outlook.com) ([104.47.70.40]) by rcdn-opgw-2.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2024 05:13:54 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WN8peC6OIJK5j3OgzawUDM59QX5zu7PxBgi+4aTYBSTZBk0MjKHqYYE0mQ7YIKq8dNwoIlkYU7W96TxWwYdVJbcK7XzhTz0TexoRrrA/drVXlwYSKAY8so6QRhvJi15/XOV9fkqAcxdHKTLjhpbeLKwgFCCrFGOr+0S+KSYglE9xYCFtZfef+YDIIsS+YXzeCQnIrUzr0zbbWIJu/gzMVvl0sNCbtOhxe0tUis5YZZIR8E6eiLNHt60JXz5F5AGhUKV87M6ZPDliuE1QGI7vm5mxU+Twc8Rrw13VDW9KRymPSw7Z3dhaqoquaJBr7mCS/TR+FaGOXqg+cjo6TCbRqQ==
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=LICu+O8WXBtDHw1VJ3kaUKPjlHw/5QpOlvx/CHd5EPU=; b=oG8K5LRP3mOAnSePMyG/LOOF10KYgyguNwt5EcbYZHEkcqXtH7xS4VAM1jRIaTyi6k59MD6AP66aA6RcVwOIqHveApqyXRYOSF+8N1RkryYLSmKE///uH7o4Z+wrg/dVjYSIhiEY5Epz0dgFUh2LjW/ebMx3MJPCm6VPXmXRcJG/a4U43ezYKPaPk/mnkp8i8/Edntu2xiYKxqzHJm5Dz/GdUqne5kxe4rSmTfHwvOgaFz5RoyA+mkgLlyiiZRprpbDlPTzP+L8r2eSEm3bZWaR+UH9P076/Gw1zWNteZf4FnDul4+T0kvGB4x3dCVqZWWF9uVbIz3j3IlFOY/SLFg==
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=LICu+O8WXBtDHw1VJ3kaUKPjlHw/5QpOlvx/CHd5EPU=; b=oeD6thZfASxb4M0/dK1OguMkm+koUSGVcSbOf/lPY1s028rx7/mDM9DwE+7PguBT8PSbPqX4vGNkWpp2f/XdfiWlx7v0RxCJRJxcTBylVu0lnEAXHX9b85n9e67umU4Ace41wyxum72qS8I0PR+OAA4RxM3s4mjm3w1uRu+0f4k=
Received: from LV3PR11MB8696.namprd11.prod.outlook.com (2603:10b6:408:216::14) by PH7PR11MB6473.namprd11.prod.outlook.com (2603:10b6:510:1f3::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7677.30; Mon, 17 Jun 2024 05:13:52 +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.7677.030; Mon, 17 Jun 2024 05:13:52 +0000
From: "Christian Schmutzer (cschmutz)" <cschmutz@cisco.com>
To: "Andrew G. Malis" <agmalis@gmail.com>
Thread-Topic: RtgDir Last Call review: draft-ietf-pals-ple
Thread-Index: AQHapqDGP6YjkURmXUWCHSj9po4+JrG9u7SAgAxOgwCAAInrAIAAT3gAgAAVyoCAAKOXAA==
Date: Mon, 17 Jun 2024 05:13:52 +0000
Message-ID: <C19B7155-40CF-4654-B65E-5FEDA58174E3@cisco.com>
References: <CABUE3Xn7XyqQAUJpr9qGx-yG3Au=OX00sgX8uZ4vOBHLpLdhrw@mail.gmail.com> <8DB06D5B-E2E5-4BC9-ACA2-EBE552E51266@cisco.com> <CABUE3XkUYP6BE8soG2_i8EB1+CMLr81FWMTfbYbtJ8e8nndDEQ@mail.gmail.com> <CAA=duU2RRYTU4bZMjGKUq06a0RzAtxFzjWO=ZSUVsXWuQkpPoA@mail.gmail.com> <CABUE3XnP3qNnZYd+xFERp0O53=Nn4YPwLoOnk_yUMdpy04wfcw@mail.gmail.com> <CAA=duU2D4=xVz7yTevn5Qff-PuQ3E3NRe0ha8amnUax15CLNdQ@mail.gmail.com>
In-Reply-To: <CAA=duU2D4=xVz7yTevn5Qff-PuQ3E3NRe0ha8amnUax15CLNdQ@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_|PH7PR11MB6473:EE_
x-ms-office365-filtering-correlation-id: 84f3a430-0a34-44da-d375-08dc8e8c47a9
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230037|366013|376011|1800799021|38070700015;
x-microsoft-antispam-message-info: IHALPu9SK82XC568Z4A1RIb3IsbRAKssl4mJ34ETvasF5Q+hP9Av/60YQlNS7aXbc3XUSrzzNIXyxLabR5lmSWy2YMpVWPmCkDItMneYpDZR9nEvFrZXmvZawYfpIOzzqOIjDN7oBB7ZTTOl/6JjLRAVAIJ6Be2C4YO62iOyq0/n/FKbpSzeth/0eYe8yJocbLCOpR/6jGBOZXK9HJA2pDo/VgaS2xzkrZJW2b3yj+e7ZVzCBJeCm+QR6/Sc7tixA7KCPVYKdgb30Abqv2ehcJEVIdpB7RCo87VkKbsGEZhJt4IEQ0cyaqhXTjX2PWoBGpcgNaNFV6tNuaXZFUBdWnpaw8w/bwRmfmFEfn8ILBpGbvqYgkhVBVXv59zeGBsjYP6bBq1cQ+OEWxfoXMdPjiQLGKikU//XKkVAHmkdnfAFBTZoV+GEHO3jmECfC9epMb1UfJUy0HI7zwlXgikmQX7F8RKqirGMjAVTak41w4cSWTHLTWWcXWqX9cVnYpTiNpDHgGVwGoct0FL+FUJ+MO+laZ3q/zS/rqexo/C0lEnVw7jsPQ4HtO2+GvGl+mxrMgVK0hnmX0LqBUPCF/+fvdqgRClREC2QMj8uw1aYnwIhoFYt2/yXZmyPTfijyNhJArMLDwQvfcOheGTFyIXP3AFGbh/d2NFicVp0qE9pwJdJ0iVr+irjPYtypVzJh5wEB7eXtc2U9xaUUoYLAyvmNC8XLlLDPpjZ0RitLB020IZ4/mjpeYPAJFmxdyevqDSOaZcG/D3XaHvLNfcQUKN+kNPC6AC/aNTZWwFAHfZTUA87DIdS8qDoktC25YCucTqGJ13BOOwNFiJbHa8S/ND8Db4ldZhw67p/ye3M3lGTH+LpldkqlahAH7iH/rlpCXpILyuNOtgOfpUovl3VBsbn4qScVR2tqcKiQP3oOGLE3XTDyb21mpYCICRo7frcwL8q/wdnzXO/muhkQ8JWAitzEVDbWcs7f6sYcMpUlGJAxe5SavgnxGxOXCKbXcNGbzkt6fiyrMhKZQ56xDqiz0EZ8PvnHjOv3HP0gvWwTEH6rL8kH7dKPslsckI884HeQwsabIY2xptFtsVjVS5zw5h81M2d3ilsyQHs0pIyZPZF4OCndfCCo+lKCgh9xXfutboFZLSGQaBbGG+jrVCNsAs1b8lbaRyiyQP32sWGx0TEAmRoBzeZjGS0oaTbT0Ul+A/73WJqp/HQNwckAb1VoLEJFgdMC2bZjqTKAM0Sfbbtb7vw+yi7Ce19uo0dvZ0gh5KlWw+4gDjVANWGxrgNp/4Qqj880eyj97wWgpJ5EPabOj0l1/teTxbxZOhErbfShbpU
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:(13230037)(366013)(376011)(1800799021)(38070700015);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: nIUybjfyC3bJPNf3tguLSY/bprzSGXojYHdqVazOPRigh8bj2Ii0sF0DGybcGy0XytEO6Ao+3BFF+u0XRO9EHC39z67f/3sfgBgcDOysFhxn4ok/TRuzO78LGbmI+JiiCeuPLL6DsWABbtpB9x+KTu/hyV0qnOAFXUOJhApb99bF8OHyGJ+r8q7aLBNpohwCSaPMAh+jc5g3IU5SLXglajxnTx8HpKRe8YKpldd1QxwVQv0ycqGqfSba/euy+lL6+oILubl4EPeUJmUq5ifcNKUMvGVjdHkAMcqWPZ2DWtQ/PY1KX/vZc9u9PZZ/g3dH0713QOgRJcjXN+H1/YaMiU9OBs+d2mJz032B04Pq+ksWLRX0aTjf8qYRPSOo+hmjOPojDajfd52/Lb2w0sRI4t5+p0ebw64U/SY6pOXWGdc5DapQzU5GscH/hSFyyjhe/MAaLZyrATh5QqzPvDG0RyRkQlAoRJTX8oyN/RJYdt9eLx92kdMGT7jXbP772BlvczOWB0gqY0VX58fEfO/8hN3Q0P669bq0Tx+mE8xY60XZtSOfrLQeANW5iN0VJY9cJ7l2KNTXWFOTRGV70bW+6uUN6mrUVtBbmsocQeg5dba/jbPJXW8eevY9COelQfI3itkiVdZguMHlOP/9Q9ykST9Mh8qec1l6DVpcA7uB8/xu3jR5KX6ql+X8+KUtltS9Dp0Y8aBoE2tYMvUQtCrYqhhB6mllu1SIm4YYsdOGyR+EyDYHmT6FPxwUR8XtkahRCA5SGlbyr6GEwy25cRfGSphcU6Zlv8NPi6JhUDp98MY3ZX1fZxyxfWYR5F5+aHi2RUG5flqZMCBnSnR7jKlCt6ghyG0HkQmK+JXTBDCi09QQvD5eaEaMKkWg4LG7GN6JHV7Hb8TBGbJcuXWCZCbK3/Y+55VwOLIGQKmDL8eRHJcwe7DTzqKpEdoukSKOb0hs56VOr7bLJgwPCUwaX7eLOAvy1lquRX0CHQXQyss7BOeS2lcjfgt+2/MD3oweLgoyULOsUciglhSEeYsTEeiR253M+foecCJl9URoBH6YKOkIrDrCkv+af7m3F6uOJOnQiQGwepLRDu/S+v4WVp7G/OxYYNSehKese82PHEHgDXo44MC0VZbhK2P0Sx1gJ0ycrGne3eZ1esL1+jfzyJc0+EpsqGDfBb9fb2x2eaSvDhQi10cEsm9Yc27errpP6OIXUKbDbSyTYKmhVU20k3dPxXToC6+HS9R+FDMpdqz89cLzHdewBNrwqHG1zB6+JMivwQE54igDQsiY6MlS+DosUoO7L4xWSZENTVMlmfGB3HSlc+AOMoG38M8I2P6fD8rTWOaS4aNDHefY26Sj4zL/vO52022twy1v86GoItdLyvmVrgaW9VFWdGWd8II2l8veSLnFuDN/AOwt5Yg7Nsk4syPCP4ZrWTOrI1GOnIHYvIGcXghwiEAMj2jLyOh+TXFVuw+YpnXSmQSwYK4S4y0oK+IRgzACnBsfYY83/Axq5C2BqOzitHalWEk+7MggdQSzyRmOEIuZwrAohL0AheSbImZq0MhDNg2YwR3Rf0+uiAYajduKh+ULQS6QXP+FRlV+
Content-Type: multipart/alternative; boundary="_000_C19B715540CF4654B65E5FEDA58174E3ciscocom_"
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: 84f3a430-0a34-44da-d375-08dc8e8c47a9
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2024 05:13:52.8205 (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: e+CC7sI/ifEiK+Nly+U6y5Uxbd6Y9h6bB3VuRInI3TvZvq2EDWD6FwTqbwNgYQd30gEd53/IJYfLnIBzyCcGDQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB6473
X-Outbound-SMTP-Client: 72.163.7.163, rcdn-opgw-2.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Message-ID-Hash: F7PQIVUQEDG5MFQCYM35D727EJAMFKRA
X-Message-ID-Hash: F7PQIVUQEDG5MFQCYM35D727EJAMFKRA
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>, Tal Mizrahi <tal.mizrahi.phd@gmail.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/Ri5qKctFLj9vUZ3A8xSyeyB8vLU>
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 Andy and Tal,

Works for me and agree on RFC8986 being normative. I will first describe the behaviours and only after that insert a note to the two informative references that don’t really define anything with respect to PLE but provide context which I thought may be useful.

Christian

On 16.06.2024, at 21:28, Andrew G. Malis <agmalis@gmail.com> wrote:

Tal,

That sounds good to me, thanks!

Christian, how about you?

Cheers,
Andy


On Sun, Jun 16, 2024 at 2:10 PM Tal Mizrahi <tal.mizrahi.phd@gmail.com<mailto:tal.mizrahi.phd@gmail.com>> wrote:
Hi Andy,

That is an interesting question.
The text that was suggested by Christian seemed to assume that the
reader is familiar with the previous endpoint behaviors (End.DX2,
End.DX2 with NEXT-CSID and End.DX2 with REPLACE-CSID).
Therefore, the text does not explain the meaning of the new endpoint
behaviors, because a reader who is familiar with the DX2 endpoint
behaviors would understand what the new DX1 behaviors do.

A possible way around this is to add more detailed text to the current
document that explains for each of these new behaviors (End.DX1,
End.DX1 with NEXT-CSID and End.DX1 with REPLACE-CSID) what exactly it
means and the corresponding pseudo-code. The similarity to the DX2
behaviors could be mentioned as a side note, and thus the two drafts
(srh-compression and srv6-usid) could be informative references. I
believe RFC 8986 should probably be normative anyway.

Please let me know if that makes sense.
Cheers,
Tal.

On Sun, Jun 16, 2024 at 4:26 PM Andrew G. Malis <agmalis@gmail.com<mailto:agmalis@gmail.com>> wrote:
>
> Tal,
>
> Thanks again for your review and also reviewing Christian's reply.
>
> I'm concerned regarding your suggestion that draft-filsfils-spring-net-pgm-extension-srv6-usid be made a normative reference, as it is only an individual draft right now and there's no guarantee that it'll even become a WG draft, never mind an RFC, and making it a normative reference would hold up publishing this draft for quite a while, unless we get special dispensation from the IESG. Do you see any way we can get around making draft-filsfils normative?
>
> I'm much less concerned regarding draft-ietf-spring-srv6-srh-compression, as that is currently in WG last call.
>
> Thanks again,
> Andy
>
>
> On Sun, Jun 16, 2024 at 1:12 AM Tal Mizrahi <tal.mizrahi.phd@gmail.com<mailto:tal.mizrahi.phd@gmail.com>> wrote:
>>
>> Hi Christian and authors,
>>
>> Thanks for considering my comments.
>> The changes you suggested make sense to me.
>>
>> Regarding the new endpoint behaviors, please note:
>> - The IANA section will need to be updated accordingly.
>> - You may need to move the references to normative: {{?RFC8986}},
>> {{?I-D.draft-ietf-spring-srv6-srh-compression}},
>> {{?I-D.draft-filsfils-spring-net-pgm-extension-srv6-usid}}.
>> Specifically the last two, which may still be subject to changes.
>>
>> Cheers,
>> Tal.
>>
>> On Sat, Jun 8, 2024 at 12:16 PM Christian Schmutzer (cschmutz)
>> <cschmutz@cisco.com<mailto:cschmutz@cisco.com>> wrote:
>> >
>> > 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<mailto: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