Return-Path: X-Original-To: core@mail2.ietf.org Delivered-To: core@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 7820998A030; Mon, 10 Mar 2025 04:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.442, 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=ericsson.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNMAM22__m3e; Mon, 10 Mar 2025 04:43:18 -0700 (PDT) Received: from PA4PR04CU001.outbound.protection.outlook.com (mail-francecentralazon11013071.outbound.protection.outlook.com [40.107.162.71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 60DEE98A020; Mon, 10 Mar 2025 04:43:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ln1urk/nw5hbPkro8ZNNULg3ciUmcjMXoYzgxqbDl4YqjMChs5ddUTf0aG4enWP7l2awbWLdi1HviL1d+3EvujpSQHoUPDO3aNQVWMifN8mVc0OTpv5CFKVvzBHmEhgqSR6weadoxFYOQvdbBueilV7BYL7x/nbBoPhDzkHhTccWwpmfvjSd7UVyVGh+glVUcy0Lt3ZFlZzKXMe0h6FpCKtFy7/JiS0k8+bAejioMjQzwegBAFS6qwRHn59jKLKPV1u8DvX0pv00bgVp66uADBGBaa6clJIl6DcYZmUbdVUQELXKL18aotdQCu/AMrZW+uJo9m/W/z6WyBH3qsm90Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=JElhurCvOuHZrOQEt0Jvo3dV0v5Uw86QyFN8Ev3C7F8=; b=ImkXMkVyvN8/pqWRF48cTivTd5z/U5Zi5BL3C4B2wtFfVIG3Cydu4VJq4bzd5neXF5KmXz4TCOclI5xSUDr3Mv5829nBPbyBpu7uaElAXQKSetnOu/xLhnWhiX34V35rk3+p9I0662831tKTuazljYTSMt0hme3yAOwX1nmIogMPIFHPBQnhJamBK2t4hHNrk7p8LEPZDzTuZ05LiwJ/Uhg4WdsQCIRQBmOvKUJzbH/UPuFM8kwmqSQheAOR3jt2DCfeukslpEnSsrEf0a+Ht6OEsh43Dt9PLjjTPPpEa26hfa2T6QQs1xo94fNJGXaDyFt04SffA1/bDdm88iffrg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JElhurCvOuHZrOQEt0Jvo3dV0v5Uw86QyFN8Ev3C7F8=; b=LwCX8XkQ4h8LsePDhyReMXkOV3E6A6meJ4Z9Yfa7pmpwf6lNDLXaBaMBeE01Y4ydOx8M4Gjux7dogE4C9GaaFqvmAWSippPUbJzjxGKULFWUSRjsWt9bbjyD9oyxuTsOo6x6KavAtC3DGHVnWdy+aWkkqVNSpl4WyM9/WlJfyFJkM8muZbGxzVbpsD1fwhX/XPq+662hrXlCbtbhrFgcytYR3viBOM6fp11UKvotHmZJjKsfFlwcN+NpJiZifFJVOta5MVrQWU3AGycF0ndsLQfI38QfVUtNO+We/XZ7FfH0i61VK3LUK3z8f/VY536S+qB694Jq8Kg81Oz7/f/Cbg== Received: from PAXPR07MB7838.eurprd07.prod.outlook.com (2603:10a6:102:15e::16) by AS8PR07MB9066.eurprd07.prod.outlook.com (2603:10a6:20b:56b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8511.27; Mon, 10 Mar 2025 11:43:16 +0000 Received: from PAXPR07MB7838.eurprd07.prod.outlook.com ([fe80::e0a0:dfe2:98bc:7ba4]) by PAXPR07MB7838.eurprd07.prod.outlook.com ([fe80::e0a0:dfe2:98bc:7ba4%4]) with mapi id 15.20.8511.026; Mon, 10 Mar 2025 11:43:15 +0000 From: Francesca Palombini To: Mike Bishop , "draft-ietf-core-groupcomm-bis@ietf.org" Thread-Topic: AD review of draft-ietf-core-groupcomm-bis Thread-Index: AQHbjtdRGYEjaZGi2Uud4HVikGCwlbNsRHoo Date: Mon, 10 Mar 2025 11:43:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-reactions: allow authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PAXPR07MB7838:EE_|AS8PR07MB9066:EE_ x-ms-office365-filtering-correlation-id: 937546b5-1f27-4a1b-897d-08dd5fc8bf06 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|10070799003|366016|1800799024|376014|38070700018|7053199007|8096899003; x-microsoft-antispam-message-info: =?us-ascii?Q?Hfix9GnsWAbjVf0827bcAWdJjDK+V3hRTJ798ZdcyoTp10GLyPFH4PAJ7RLu?= =?us-ascii?Q?N/JZoXCk7agLPB3odeeGPBcV9AwowT8hPTh+M83j40erBZ6EI9uwG/m4vN0y?= =?us-ascii?Q?UOCVqfISzz0/zJ2Maw/oIWTwFj+1ExE4CWEkld0OCNOARlvy647pBBPg73p3?= =?us-ascii?Q?+CC2MYqyOtN/8xLr0IT7APdRGgX0PuA/7r8eizdEGVp3mO7q9CjYmf3/TbaO?= =?us-ascii?Q?EDkspEa2wGWj6j7evCgPKpa6L8MdOBeEZSimBBsDqoHFJGibW458BWvMxF26?= =?us-ascii?Q?TnwexcevW6pgbopyQjaxP/ioZEEQPerDdDdSq6DwZs04P1A9MEoiqxQ2Sukb?= =?us-ascii?Q?wOx0WomOAc4Yw7ZNa1QkTs0oSKNgMk7zOe9wgpXg1kD0bhTHJoWbju/vlPFY?= =?us-ascii?Q?lSxqgUaFNK16s1+uvs/xwiugdA5wRVXYI8cOe8d5T/lT62yHR69277ANEed9?= =?us-ascii?Q?9/Im6JGoVIKMHpZMdEn+k/5DZ3YyfPWrMGScnKyeat8+GrJKZJwse0grzKwI?= =?us-ascii?Q?J1if/Dtd+xASQ1FB8dIcqyD2Ostle24bgdQDXaosBpvEKAcIk29JZaRblEDT?= =?us-ascii?Q?iX+byX/U84z5z2D1XuUIQ7T/cqRsPGyTpoHrqc9BMNh2w5t1vLCVnH1zSio8?= =?us-ascii?Q?wi5B4F6V1WzsXjoFcvB1N/Fu+KJ7lSastqpxSgiWj4qTJjHuEsu7NMzyzhEg?= =?us-ascii?Q?Nl2dKCVh6B/GO/svD7bW3sf4AMafpvkR4qraZTgbAvS8KEIn9CAqWp8PgGVA?= =?us-ascii?Q?naMzsXXjP1zinjYG4/PmhHjpRiOBKpeIp7OF2rAeVzIBHLJD0iHZ2ao6k9H9?= =?us-ascii?Q?hyEv+fpOba4pb0/ULZpPOzPZB7mN95y4bMizXynUknlYeaTtU6zLEBuMH3jc?= =?us-ascii?Q?FuvnSIgUzoQZFmCHVrOInP/JYpjTjJIn9/e0csAFCdrAXVB9zBkpC4yOI4rd?= =?us-ascii?Q?WiYfKNJ5lA3EZw4dbM5T8eXu0C2UO7SRrN0Eu7UJ7b4GSouSWWHSC54vrDDg?= =?us-ascii?Q?sw8rqTNWS68neod0OizNOA15y8B4BSKIoLlSHtdh5xzN9ufaNFR30Qs0Rz7/?= =?us-ascii?Q?bvUDuCMf6dqtfBXlLCBqPhD8vTv6GNcHGyj8GEH8ma7xsfsQCI353Wx2GW+O?= =?us-ascii?Q?LIstIffehwonw++XEM/ivxta+3etgiQCpj5yuhzRy6IxW3Xx7gtYnvXhGhEh?= =?us-ascii?Q?EvJ+C6UAzXpeQaXfDK+ALEGS0KvIMcNrz6+DF7M6iycw8XqYTEEj5ymFjRn0?= =?us-ascii?Q?fLvOc/X7yb63kwxs5nSdxDgkczyim/YvOxCR+mWGLnAIydOBFNKKWznzbE4U?= =?us-ascii?Q?qy0+TmY53RiYIJV4+3uSp/lWBDe8gZPWnz8H1bRDVdPw7/5dw4EZyTD3QyGQ?= =?us-ascii?Q?MFHStpED68EVTa3G2clKHS0ZgI4DLmDw1uecKFIUId1s2hOc3XUopJ28kaTP?= =?us-ascii?Q?d0r/xPuznRSkVF4ZYrvj6yRjSbXxRNf8?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAXPR07MB7838.eurprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(366016)(1800799024)(376014)(38070700018)(7053199007)(8096899003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Sae8kJh/pq28ZlhESb4NGuj+p7vekk0SAYJEEz3rWrwEQ//fXqQdyCiHVPEA?= =?us-ascii?Q?iJrbSTm6ob6X41XRneDs7xpgrzbQhSDIWGWZxoZC4eXNtVvp0lCY/97XFMTV?= =?us-ascii?Q?sfg9tuTml49Z1v4jPJXgM3du6nEL4Yj146TNt3+QPKOjw341WhPgMjW4PAxW?= =?us-ascii?Q?Igo2qBsGJhaO7cqmZXSjUmPPmS2A2i29iCSYlA2S05+oQlRIF1BuI6Oo72VW?= =?us-ascii?Q?GyxXo6esgopQS4EmqWvCnHIi5d1sAq/LahsqzedgVDebPPIPzPgAjeQRmn2+?= =?us-ascii?Q?cAidOXXyesOXArwudU2aEFTsNBIRRZp+lTntTi3xyGmfSqS6hiWQ0fBX8piO?= =?us-ascii?Q?U9dazDsIKEusPdsDpLq50RTL+bSGq+aOUFMGl8s4Nii7gfDm5vLGY+Y5wJT8?= =?us-ascii?Q?8BShSIBDRgwETZAtNWLzZhGGMvAaR5bhLGC9vg0CM30hxCO70/3q7Q0JLG6K?= =?us-ascii?Q?vahgOTaf8Qk4lpAqj+cIb5DfOo/0kK1NXaVlRWlbepcathZ2NvlprYJDctDj?= =?us-ascii?Q?dMB740N2bTb7N4lhubNDmYDl7LwHbT4TWEmaByCh/hZV+7zFkdwzoJr0Dm9H?= =?us-ascii?Q?ObC1wkdsQ36sIC6AINNQp0pvlaUe5o974GQWWv4M1wJqvy4iCO4dTFURmAi4?= =?us-ascii?Q?wjqVeXMyVBnEKJnPIkxJxmKdFv2NH2DukS9xvG6xlrXnLmkkqDQt61MGthuU?= =?us-ascii?Q?eLD4G8DM2eyTeSe+4yVw/ufzC0l2/fEvHwChsmatr90GajjiMl3gnLD9baJ0?= =?us-ascii?Q?wTp3UQZQJzmlVN/+yWcsg29GKwIqh1u+GqA9nURKdl6XLF369AQhAW/plbo6?= =?us-ascii?Q?A5vSx120U7AmyEB3TPKrVu1YxvsRmu2X1HbnrwlSQHaLsTdunX2DOd/IZBGJ?= =?us-ascii?Q?md2KSlFajMA73ms8/PXrwuNaRTi4Fxhf9vG1cyCDDwMm85mZaVwVmWdQ90yo?= =?us-ascii?Q?BHRrF/Bl12tZJZuUUwkkuzjcLzpVFj9CASY0rITj6ZNjKNVAzN46EyvXSHvZ?= =?us-ascii?Q?SaQHVJjMnW0OIxcaW1Y9uX6Ifu362x8qMoxk1SLW4KEjJo9qGjkmAEpM3elv?= =?us-ascii?Q?Su4B9y51Nw4u62NN4A+9yYR5YHyCPRyzH52kStivGyOGAnHkeBemUp7uUK2+?= =?us-ascii?Q?JGvseyPd/vpgnsoHBGDpnvoxGaVAavJKFnoEqUvZL2g7W8HkswwMw5WzsoSC?= =?us-ascii?Q?d6JKv0N298/r9CVLiS4ce94oikhHgUy5FPeYxOi2kS33d5TRJb0QOptyk8GU?= =?us-ascii?Q?PsLpekyvNZOMwDU/nctUTuuDgAdm9fQ/xFpkEk/1Y0l+4VSN85S+4XXu5GYO?= =?us-ascii?Q?XWWnNEQHZJ+f2uVZ+YEDrsnnHFm6w68ChI4O+mFEa3Aw24nr7Zz6nbfhwQyh?= =?us-ascii?Q?yTxOX337SY5U3uDukp0OuvWGeS0G+h37AT4BQ8wdIysJXc1iFD2t8oifsa3/?= =?us-ascii?Q?IJU5vdfIDf3IAqg7mS1rqDHokf4i6Bvy5aHQDG0W5u4dxhnCHqY4kEPeOsft?= =?us-ascii?Q?AexdsEgn0pCRJZBy5npW/8ohUpGiqp5u4g1Io9YlqHqTOXQu11pfKDsvDcHd?= =?us-ascii?Q?/mQLEpjgk8sI5HCNiWdU5UDwquoWLKlskTxU92ZbY5863il92lV0X3HLQTi0?= =?us-ascii?Q?RpcxlXkhcZNaIKKaCyVmJR1SDWSxerYnZe91Z4HuvCxP95PvF4lTbqrPR5H/?= =?us-ascii?Q?nE702HqgFF5OOWvLUxMEArkaVrI=3D?= Content-Type: multipart/alternative; boundary="_000_PAXPR07MB783807BD3815240ACDC1AAD198D62PAXPR07MB7838eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PAXPR07MB7838.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 937546b5-1f27-4a1b-897d-08dd5fc8bf06 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2025 11:43:15.8841 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /62Q89jPhlvLxpHDjpqU7mZQVVXXo2g+jp6fjH6WgHUzhlxlLHnJeI9ekYLTr63b+w8rhNIiTDiIhc8Q7XOVZTjBjmI9oSikwilaFfHvHtihIqVg+fXo9LZ0uANgUXD2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR07MB9066 Message-ID-Hash: 5TN3ED5I2KA3EVC5WGKP7KLRUHU3MOCW X-Message-ID-Hash: 5TN3ED5I2KA3EVC5WGKP7KLRUHU3MOCW X-MailFrom: francesca.palombini@ericsson.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-core.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "core@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bcore=5D_AD_review_of_draft-ietf-core-groupcomm-bis?= List-Id: "Constrained RESTful Environments (CoRE) Working Group list" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_PAXPR07MB783807BD3815240ACDC1AAD198D62PAXPR07MB7838eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi authors, wg, Mike, as incoming AD, has completed a review of the groupcomm-bis document.= Please see his comments below (fw with permission), and consider them as t= he AD review, as he will be taking over soon. Francesca From: Mike Bishop Date: Thursday, 6 March 2025 at 21:49 To: Francesca Palombini Subject: Review of draft-ietf-core-groupcomm-bis Overall, a good document that lays out the protocol clearly. I read through= it a bit per day as other work permitted, and I'm shooting my notes in you= r direction. I'll have to pick up the pace for IESG reviews, obviously! I had a lot of nits, but my biggest high-level critique was that this bis d= ocument eliminates a lot of text from the original that helped set CoAP in = context with HTTP and describing how group communication is expected to be = used in deployment. As someone only lightly familiar with CoAP, I found the= original text useful in understanding the context of the document and was = surprised not to see equivalent text in the introduction of the bis documen= t. Appendix A appears to have a list of scenarios and is forward referenced= in the Introduction, which helps some. In 2.2.1.1, an example from RFC7390 is referenced, but this document replac= es 7390. I would consider importing the examples to this document. It appea= rs that you already have an example grouping in 2.1.4; could this example b= e expanded to cover this case? 5.1 makes it clear that the sender is authenticated in OSCORE, with more di= scussion in 6.2.2. However, this isn't clearly stated in 2.1.3, which initi= ally leaves open the question of impersonation using the shared keying mate= rial, particularly since it talks about handling authorization separately. = Consider moving some of the OSCore intro earlier in the document and/or hav= ing an explicit forward reference for more detail. Nits follow: In 1.3, is "admits" the correct word? Perhaps "allows" or "permits"? Or if = this is usage that was already happening outside the specification, perhaps= "acknowledges"? In 2.2.1.2, consider scoping the "always maps to exactly one application gr= oup" statement. In context, I believe this is only meant to apply when the = URI authority component method is used, but it could be misconstrued as con= tradicting 2.1.4's 1..N:1..N relationship. 2.2.1.3: - "specific of" =3D> "specific to"? - "request for" =3D> "request" In 2.2.2, "used to configure" could be interpreted as either the address th= at has been selected for the group or as being used to perform the configur= ation. I assume not the latter sense as the previous paragraph described th= at no such protocol is deployed, but a different wording might still be cle= arer. Maybe simply s/to configure/for/? 2.2.3.2: - "As exclusively intended to support examples throughout this document" is= a bit obtuse and similar phrasing occurs several times. Should this be "In= examples in this document"? - 2.2.1.2 discussed three means of identifying an application group from a = URI; this assumes only one. Are there examples of the others? Is this one p= referred? More generally, this section states a number of assumptions that the client= must already have made before it can discover the groups. The last paragra= ph of the section addresses this, but after having read the section and bee= n confused by these assumptions. Consider moving this to the start of the s= ection to clarify that this is an illustrative example of a particular depl= oyment, not something specified by the protocol. Given that this section is= intended to be normative (per Section 1), also consider whether more of th= is example should move to the associated (non-normative) Appendix. 3.1.2: "to be appropriate, as useful" seems like an incomplete edit 3.2: Reword the first paragraph? 3.2: CoAP, like HTTP, supports the same endpoint exposing different resourc= es differentiated by the hostname in the URI (using the Uri-Host option). H= ow does the process of "replacing the authority component of the request UR= I with the transport-layer source address" interact with this? Does the cli= ent still send the group hostname in the revalidation request? If so, this = should be stated, since modifying the URI would normally imply modifying/re= moving the Uri-Host option. "Forward proxies" and "reverse proxies" aren't generally hyphenated in HTTP= ; probably they shouldn't be here either. 3.2.1: Is the reference for proxy caching actually non-normative? If this d= ocument didn't attempt to specify proxy behavior and was merely pointing ou= t where the proxy spec was, definitely, but proxy behavior is defined in Se= ction 3.5. 3.5.3: - "each and every of" =3D> "each of" - Does assigning the proxy P and the server S letters actually add anything= here? They don't appear to be referenced. 3.6: - s/respond to/respond/? 3.10.1: MLD (not v2) and IGMP (not v3) are mentioned in the section heading= , but not the text. Should either the versioned or unversioned names be omi= tted from the heading? 3.10.3: "also other ... may" =3D> "other ... may also" 5.3: In an HTTP reverse proxy, the client isn't aware of the servers behind= the reverse proxy. It seems that end-to-end asymmetric encryption should w= ork, since the client encrypts with its private key and all others in the s= ecurity group can read; should there be text about how pairwise keys work i= n this case, if that's supported? 6.1: "Therefore ..., also in order to prevent...." =3D> "For these reasons = and in order to prevent..., ...." 6.2.3: - "be often correctly inferable" =3D> "often be correctly inferred" - "assert" =3D> "confirm" or "verify"? - "prevents that ... can be" =3D> "prevents ... from being" Abbreviation "6LBR" is used multiple times without definition. Based on con= text, I'm assuming "6LoWPAN Border Router"? Expand on first use, possibly w= ith a reference to another document if warranted. 6.8.2: "many multiple" -- choose one B: The IPv6 address ff35:30:2001:db8:f1::8000:1 should be ff35:30:2001:db8:= f1:0:8000:1; see Section 4.2.2 of RFC 5952. E: "capable to forward" =3D> "able to forward" or "capable of forwarding" --_000_PAXPR07MB783807BD3815240ACDC1AAD198D62PAXPR07MB7838eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi authors, wg,

 

Mike, as incoming AD, has completed a review of the = groupcomm-bis document. Please see his comments below (fw with permission),= and consider them as the AD review, as he will be taking over soon.


Francesca

 

From: Mike Bishop <mbishop@evequefou.be= >
Date: Thursday, 6 March 2025 at 21:49
To: Francesca Palombini <francesca.palombini@ericsson.com>
Subject: Review of draft-ietf-core-groupcomm-bis

Overall, a good document= that lays out the protocol clearly. I read through it a bit per day as oth= er work permitted, and I'm shooting my notes in your direction. I'll have t= o pick up the pace for IESG reviews, obviously!

 =

I had a lot of nits, but= my biggest high-level critique was that this bis document eliminates a lot= of text from the original that helped set CoAP in context with HTTP and de= scribing how group communication is expected to be used in deployment. As someone only lightly familiar with C= oAP, I found the original text useful in understanding the context of the d= ocument and was surprised not to see equivalent text in the introduction of= the bis document. Appendix A appears to have a list of scenarios and is forward referenced in the Introduction,= which helps some.

 =

In 2.2.1.1, an example f= rom RFC7390 is referenced, but this document replaces 7390. I would conside= r importing the examples to this document. It appears that you already have= an example grouping in 2.1.4; could this example be expanded to cover this case?

 =

5.1 makes it clear that = the sender is authenticated in OSCORE, with more discussion in 6.2.2. Howev= er, this isn't clearly stated in 2.1.3, which initially leaves open the que= stion of impersonation using the shared keying material, particularly since it talks about handling authorization = separately. Consider moving some of the OSCore intro earlier in the documen= t and/or having an explicit forward reference for more detail.

 =

Nits follow:<= /span>

 =

In 1.3, is "admits&= quot; the correct word? Perhaps "allows" or "permits"? = Or if this is usage that was already happening outside the specification, p= erhaps "acknowledges"?

 =

In 2.2.1.2, consider sco= ping the "always maps to exactly one application group" statement= . In context, I believe this is only meant to apply when the URI authority = component method is used, but it could be misconstrued as contradicting 2.1.4's 1..N:1..N relationship.

 =

2.2.1.3:

- "specific of"= ; =3D> "specific to"?

- "request for"= ; =3D> "request"

 =

In 2.2.2, "used to = configure" could be interpreted as either the address that has been se= lected for the group or as being used to perform the configuration. I assum= e not the latter sense as the previous paragraph described that no such protocol is deployed, but a different wording might= still be clearer. Maybe simply s/to configure/for/?

 =

2.2.3.2:

- "As exclusively i= ntended to support examples throughout this document" is a bit obtuse = and similar phrasing occurs several times. Should this be "In examples= in this document"?

- 2.2.1.2 discussed thre= e means of identifying an application group from a URI; this assumes only o= ne. Are there examples of the others? Is this one preferred?

 =

More generally, this sec= tion states a number of assumptions that the client must already have made = before it can discover the groups. The last paragraph of the section addres= ses this, but after having read the section and been confused by these assumptions. Consider moving this to th= e start of the section to clarify that this is an illustrative example of a= particular deployment, not something specified by the protocol. Given that= this section is intended to be normative (per Section 1), also consider whether more of this example shou= ld move to the associated (non-normative) Appendix.

 =

3.1.2: "to be appro= priate, as useful" seems like an incomplete edit

 =

3.2: Reword the first pa= ragraph?

 =

3.2: CoAP, like HTTP, su= pports the same endpoint exposing different resources differentiated by the= hostname in the URI (using the Uri-Host option). How does the process of &= quot;replacing the authority component of the request URI with the transport-layer source address" interact wit= h this? Does the client still send the group hostname in the revalidation r= equest? If so, this should be stated, since modifying the URI would normall= y imply modifying/removing the Uri-Host option.

 =

"Forward proxies&qu= ot; and "reverse proxies" aren't generally hyphenated in HTTP; pr= obably they shouldn't be here either.

 =

3.2.1: Is the reference = for proxy caching actually non-normative? If this document didn't attempt t= o specify proxy behavior and was merely pointing out where the proxy spec w= as, definitely, but proxy behavior is defined in Section 3.5.

 =

3.5.3:=

- "each and every o= f" =3D> "each of"

- Does assigning the pro= xy P and the server S letters actually add anything here? They don't appear= to be referenced.

 =

3.6:

- s/respond to/respond/?=

 =

3.10.1: MLD (not v2) and= IGMP (not v3) are mentioned in the section heading, but not the text. Shou= ld either the versioned or unversioned names be omitted from the heading?

 =

3.10.3: "also other= ... may" =3D> "other ... may also"

 =

5.3: In an HTTP reverse = proxy, the client isn't aware of the servers behind the reverse proxy. It s= eems that end-to-end asymmetric encryption should work, since the client en= crypts with its private key and all others in the security group can read; should there be text about how pair= wise keys work in this case, if that's supported?

 =

6.1: "Therefore ...= , also in order to prevent...." =3D> "For these reasons and in= order to prevent..., ...."

 =

6.2.3:=

- "be often correct= ly inferable" =3D> "often be correctly inferred"

- "assert" =3D= > "confirm" or "verify"?

- "prevents that ..= . can be" =3D> "prevents ... from being"

 =

Abbreviation "6LBR&= quot; is used multiple times without definition. Based on context, I'm assu= ming "6LoWPAN Border Router"? Expand on first use, possibly with = a reference to another document if warranted.

 =

6.8.2: "many multip= le" -- choose one

 =

B: The IPv6 address ff35= :30:2001:db8:f1::8000:1 should be ff35:30:2001:db8:f1:0:8000:1; see Section= 4.2.2 of RFC 5952.

 =

E: "capable to forw= ard" =3D> "able to forward" or "capable of forwardin= g"

--_000_PAXPR07MB783807BD3815240ACDC1AAD198D62PAXPR07MB7838eurp_--