Return-Path: X-Original-To: mod-discuss@mail2.ietf.org Delivered-To: mod-discuss@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 31BCA5A8B7F9 for ; Fri, 29 Aug 2025 03:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -11.886 X-Spam-Level: X-Spam-Status: No, score=-11.886 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_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=cisco.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 GHWxNRvn0FK1 for ; Fri, 29 Aug 2025 03:54:21 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 250125A8B7E2 for ; Fri, 29 Aug 2025 03:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; i=@cisco.com; l=31956; q=dns/txt; s=iport01; t=1756464861; x=1757674461; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=6EXrw2PwmCwql9kjefe/Y9mJo1KiW3rFE5URZrUYwYI=; b=feog2bKCyFwrpJpsZg6GShbkiYFuNSsu2vWEeg+4fcdG+TOaZBzDvGWE 4Q7E92XfEDjFv9g1CIqGLOY6rTWtO/NUZljiPwin34xM3rUJM29tBh/IZ UjKF55X35l+sO8jpzf8MLNbLbsbfwvGo83nYUPxcn+DuhoR5Trkc78d9j 5HZzfFRz0jm3+sl1UTJyuHsRNLBSRI2r7TUAcap+PaWf9DOCIUuFmPzjp A+1Nrou3f2Dw2VuG1BcdadsBFKyZiRvT3rkQR1g+0B7Z4L171EgaiuQ+Y d8Iw7AwFKuM/eg7BLwoZPtn4o981oS0Rj5LG1FEoDU6WWekm2d9xGWfr+ w==; X-CSE-ConnectionGUID: u8uQnviDSaCk8GNBrVPxwg== X-CSE-MsgGUID: Kl7HeQ/7Q1aciRPOwTDXgg== X-IPAS-Result: =?us-ascii?q?A0AgBgAuhrFo/5MQJK1aHgEBCxIMQCWCazEqKAd6gRxJi?= =?us-ascii?q?CADhSyGFj+CIQOeLoFrDwEBAQ0CRA0EAQGFBwKMJQImOBMBAgQBAQEBAwIDA?= =?us-ascii?q?QEBAQEBAQEBAQELAQEFAQEBAgEHBYEOE4ZPDYZaAQEBAQIBEjwgEAsCAQgRA?= =?us-ascii?q?wECIQENMAEUCQgCBAEHCwgRAgICAgGCYYIdLyYDARCrCQGBQAKKK3iBNIEB4?= =?us-ascii?q?B8GgUmIUAEqgTSEDoR1AicbgUlEgVeBZko4PoEFeWMCgSsBEgEJGh6DdYIvB?= =?us-ascii?q?IIJBBVBGSgKChILD4EpNoEpAgEEHTYFNTcQgSeEGQIsUS4DPW8Eans8BAFeQ?= =?us-ascii?q?gEBBgMWGhgBBAMBdgE+iBtSciIDJjMsAVUTFwsHBYEgEDMDKjQxI0sFLR1zD?= =?us-ascii?q?CgSZ4JqgSqEHitPghtygQF0V0CDUxIMBmsPBoEVGUkCAgIFAkM+gW8kBh8SA?= =?us-ascii?q?gMBAgI6VxCBbUADC209NwYOGwUEgTUFk1sXKRmCMgoQWwYBLQI0BA0BDxQeB?= =?us-ascii?q?BQMAg0rAw4QFjQHARgJFAEvHJMDUgKPE6I4gT4KhByMHohgjQ8XhASNE4cCk?= =?us-ascii?q?WtnmQYijWaVEgFphRICBAIEBQIQAQEGgX8laXBwFTuCMwEBMlIZD1iNVRYcd?= =?us-ascii?q?gEJgkKFE7cIeDwCBwsBAQMJkwdgAQE?= IronPort-PHdr: A9a23:S4UPZRABQyF+qxT3+I7UUyQVXRdPi9zP1kY9454jjfdJaqu8us6kN 03E7vIrh1jMDs3X6PNB3vLfqLuoGXcB7pCIrG0YfdRSWgUEh8Qbk01oAMOMBUDhav+/Ryc7B 89FElRi+hmG IronPort-Data: A9a23:5tN1vKuRf8R+1mZHs0gjAU6BG+fnVBtfMUV32f8akzHdYApBsoF/q tZmKWzQOfjZM2CjeIwkOY2w8U8O7Z/RyddnGgRorSAyEyMSgMeUXt7xwmUckM+xwmwvaGo9s q3yv/GZdJhcokf0/0nrav676yAlj8lkf5KkYMbcICd9WAR4fykojBNnioYRj5Vh6TSDK1vlV eja/YuGaDdJ5xYuajhJs/LZ+Es01BjPkGpwUmIWNKgjUGD2zxH5PLpHTYmtIn3xRJVjH+LSb 47r0LGj82rFyAwmA9Wjn6yTWhVirmn6ZFXmZtJ+AsBOszAazsAA+v9T2Mk0NS+7vw60c+VZk 72hg3AfpTABZcUgkMxFO/VR/roX0aduoNcrKlDn2SCfItGvn3bEm51T4E8K0YIw57ZqOGdQ9 NAjIRsOPj+lrfiI+KKkRbw57igjBJGD0II3s3Vky3TdSP0hW52GGv2M7t5D1zB2jcdLdRrcT 5NGMnw0MlKZPVsWZgh/5JEWxI9EglHlbDxctFWTjaE2+GPUigd21dABNfKJI4LQFJ0OxxfwS mTu3GCmIhwjc4OmkDOO80iUofDzsRP0V9dHfFG/3rsw6LGJ/UQWDxFTWVqgquSikWa/Vs5Rb UsO9UITQbMa/UivSJz5Gha/unPB50ZaUNtLGOp84waIokbJ3zuk6qE/ZmcpQPQttdQ9Qnoh0 Vrhoj8jLWUHXGG9IZ5FyoqpkA== IronPort-HdrOrdr: A9a23:WcBfb6zGVRJ5UYTa7hDZKrPxaugkLtp133Aq2lEZdPULSL36qy n+ppQmPEHP6Qr5AEtQ5uxoWJPtfZquz+8K3WBxB8bvYOCIghrSEGgP1/qH/9SkIVyDygc/79 YuT0EdMqyLMbESt6+Ti2fIcadE/DDEytHUuQ609QYKcegeUdAZ0+4PMHfjLqQZfnggObMJUL Cnyo5soT2mdX4LbsK9KEUkcoH4zeHjpdbNWzJDIwQoxjWvoFqThYISFSL24j4uFxd0hZsy+2 nMlAL0oo+5teug9xPa32jPq7xLhdrI0LJ4dY2xo/lQDg+pphejZYxnVbHHlisyuvuT5FEjl8 SJiws8Pv5092jacgiO0FvQMkjboXUTAk3ZuBqlaEjY0IjErfUBeo18bLdiA1nkAowbzZdBOe xwrjukXtFsfGL9dWzGlqj1vldR5wSJSb5Iq59Js5SZOrFuMIN5vMgR+lhYH4wHGz+/4Ic7EP N2BMWZ//pOd0iGBkqp9VWH7ebcF0jbJC32CnQqq4iQyXxbjXp5x0wXyIgWmWoB7os0T91B6/ 7fOqplmblSRotOBJgNSdspUI+yECjAUBjMOGWdLRDuE7wGIWvEr9ry7K8u7O+ndZQUxN85mY jHUllfqWkuEnieQ/GmzdlO6FTAUW+9VTPixoVX4IV4oKT1QP7xPSiKWDkV4r2dSjUkc7rmst qISeZr6qXYXBnTMJcM2xe7QJVbI2QfVsoO0+xLKG5mivi7X7HXig== X-Talos-CUID: =?us-ascii?q?9a23=3A9YNXkGooSNrdLID+1KJfRZLmUd11b0Tb0nb8GEa?= =?us-ascii?q?TCjZGbpePd2eA56wxxg=3D=3D?= X-Talos-MUID: 9a23:dhA7egUhvaeG89/q/Bzo2xFvDYA32v2nA0E3qbIZh+W0OiMlbg== X-IronPort-Anti-Spam-Filtered: true Received: from alln-l-core-10.cisco.com ([173.36.16.147]) by rcdn-iport-5.cisco.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 29 Aug 2025 10:54:20 +0000 Received: from alln-opgw-2.cisco.com (alln-opgw-2.cisco.com [173.37.147.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by alln-l-core-10.cisco.com (Postfix) with ESMTPS id 1562018000157 for ; Fri, 29 Aug 2025 10:54:20 +0000 (GMT) X-CSE-ConnectionGUID: hy2tZUHiQku264iodDCNcw== X-CSE-MsgGUID: BChecWlbSrKvUiDvOgpWAA== Authentication-Results: alln-opgw-2.cisco.com; dkim=pass (signature verified) header.i=@cisco.com X-IronPort-AV: E=Sophos;i="6.18,221,1751241600"; d="scan'208,217";a="28957264" Received: from mail-bn7nam10lp2043.outbound.protection.outlook.com (HELO NAM10-BN7-obe.outbound.protection.outlook.com) ([104.47.70.43]) by alln-opgw-2.cisco.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 29 Aug 2025 10:54:19 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IIWwJdsrj+egLdYeMJDZMTgj8gPXBTIj9BhdteIBTuGM7Pli7+DnMH2c0Lu4CdDmQzLKxXaG6xRoScyN3myp0bb54UU/QsO/KXrPM57pPBWpmPlb8A6OhFVQGMR9/eT9AoZQ++VcxjGBHbzQuxBkSNr8WdpB/UcEHtZohEXxH0y2c0nae+DAtt/qMb9p/l7emc3tYObgCA1nMSlwgTVvoPFjeEb6UrSHj8nrsZ58CmPK2+25Iw3gXZtVQ3BV4PAakB6H2TDFAsUYMY6MVcUEIbVQ/f+3wPBxBzGjx5uN/6eKOR3s290Zotalivht9bcs3+7BJJGJ1SMN+YwdTq/gFw== 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=6EXrw2PwmCwql9kjefe/Y9mJo1KiW3rFE5URZrUYwYI=; b=Lz72wNgiv5aHhYJIXeEhbuxuhkyBNYpRl56ODgdEnUOWuC100kzimS1EIIak9Ly1uqaRaRvmeUHVTLZEN6nu4SE/0raxzxYxYL6LwiqUFM5Mmdc+lqrt6z51T3VrI6IhihdSBseDNOqVw/2EmSpy8mqA4zH6BuLexzw1J7UKmkYecDx5O+FATN/K4d/Opyn83lDIl5m2whUZwAGNmkWM+TkWhesWQZ+hb0Zz3auxIev7uLaRlk/WkLwiUxGSbHMXYmI/cRZTNCsnX9DDEeuzljfHGN2mQ2oh2MXXMYMftOQGxzz793bo8bIjVx0sZ8hHLbtycHPYlxp8uzild9U98w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none Received: from LV8PR11MB8536.namprd11.prod.outlook.com (2603:10b6:408:1ec::19) by CH3PR11MB8138.namprd11.prod.outlook.com (2603:10b6:610:158::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9073.13; Fri, 29 Aug 2025 10:54:17 +0000 Received: from LV8PR11MB8536.namprd11.prod.outlook.com ([fe80::ff1c:486e:efc9:119e]) by LV8PR11MB8536.namprd11.prod.outlook.com ([fe80::ff1c:486e:efc9:119e%6]) with mapi id 15.20.9073.017; Fri, 29 Aug 2025 10:54:17 +0000 From: "Rob Wilton (rwilton)" To: "D. J. Bernstein" , "mod-discuss@ietf.org" Thread-Topic: [Mod-discuss] Re: WG Last Call: draft-ietf-modpod-group-processes-10 (Ends 2025-09-08) Thread-Index: AQHcF1zvcNV33VL8AEaN8woE2C3AELR2k58AgABxCoCAAO/6AIAAGpIAgAAMMdCAADwkgIAA+o0t Date: Fri, 29 Aug 2025 10:54:16 +0000 Message-ID: References: <20250828174233.142131.qmail@cr.yp.to> In-Reply-To: <20250828174233.142131.qmail@cr.yp.to> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-reactions: allow x-ms-publictraffictype: Email x-ms-traffictypediagnostic: LV8PR11MB8536:EE_|CH3PR11MB8138:EE_ x-ms-office365-filtering-correlation-id: 7ee94880-14e5-4fc8-7269-08dde6ea6653 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|4022899009|10070799003|1800799024|366016|376014|8096899003|7053199007|38070700018|13003099007; x-microsoft-antispam-message-info: =?Windows-1252?Q?XYUXD9RB+r52mY5P2qo1jUQlB92669NulsXQ97s628NxPIZI17kWnGue?= =?Windows-1252?Q?3i9SyFoMc/kcBP78FgowrGfYvCNRJHW30gCBvyHAKZX4VByb5Ge5nqr+?= =?Windows-1252?Q?YdEQTExgBigC5kIE0+KQMUS6RBNXV0rmqjFQDq0N6gy7zemEek9J3Rdo?= =?Windows-1252?Q?vkjFGxEhA6MgCQvz/UuaFDJv94nj3o+gbkhBrwWSe7OOq4462IOSndEe?= =?Windows-1252?Q?1T7WewyiFml2Y4ewJUeAhrDnSS+m6PA5tsCCypH7TiK8x8np2dStUh7a?= =?Windows-1252?Q?JARz2J+wmqaVISGWj07b1J0akRGnS24Y824IrlWB12Z92cUZtFxrTTVu?= =?Windows-1252?Q?uRRd6Dfhn1brwXsuoZW/c5dkpw2oY4snXfNkJM+gM+ku+Ps4rGZIzcRK?= =?Windows-1252?Q?0krLwkHe5Jqux2JRKth9XzOi85SIKiY0klJX8YMk21NJFIAfgpbhvhZH?= =?Windows-1252?Q?YVLp7XM4kgvJyHjnmnFoMy9csrqNKgWLRQNeoe2lKVQUJHNwHE9nU7q2?= =?Windows-1252?Q?LUcvwOfUxE0G8qiDR6tf4jfop6rAoYkB+OrAlkWdN0r3tWN4FT+b/VP8?= =?Windows-1252?Q?XUiQiOz6Qz235w5Tfcb8vPgeNuczTgJ1Q0liRXqfC2wTDYABK2xSgYoB?= =?Windows-1252?Q?XCvx1E2r2vpq3tXTOZTS5Q1HiyNnLVnhC2NHvHnsZ0BhGyhyK8HclAai?= =?Windows-1252?Q?YCnJt28NoyQaJng5KgWqZc0k0wsExWdBCg+zAv9nXWwTzs/i63ReS1YN?= =?Windows-1252?Q?D3aDPM1F03u/dKYDj9zJj6s5iZ+hO3/teFI+ktjygoAjgeOSk7CUkvfV?= =?Windows-1252?Q?YR1rU9TwlO+jgo1JbA0uWpbqGGKTN6X4TCRGnTwdquNwGRrKu54FwFo2?= =?Windows-1252?Q?H7KcOdX1ZXbAwurzb6GwTrn/ZECpp+ag/umZb1j1tnF/g1dqnxbzeUpg?= =?Windows-1252?Q?ahxeQy8HBX3tmoVAQ/FCVkHHT2GcpsaS8xfFjU7QUCezgUibjvcVgPJZ?= =?Windows-1252?Q?PpALnuv6Dag3tEQa1dqCS61668ZfDa5UoXzjVdnr7bfw+7mdyLbL2qBp?= =?Windows-1252?Q?Cv0s6yzu12efhQkG0Kk9o4AuNZMx3tLP6/rOyhEzTgfteB4w0zTkERaQ?= =?Windows-1252?Q?vX/V2M/tf/iPTSN9pC8h+eGSMWgCIXvhaGNJwlAZt/Ta26J+0tigEhav?= =?Windows-1252?Q?007ULH1UEi/FfDPJRnPtprQMkaxBcaeg8NVG/kAdx2INwxJ++FrmsN4M?= =?Windows-1252?Q?S9+J9h+pFh8EM8nGnkfNnHlPEfmTk9wfTn3EVCRz9SCEv0B3mQdJffa1?= =?Windows-1252?Q?H988y5sqbVzJruLDxkQbvEwaj4ZSBZNGqBus91oTx25ePKIk+uBI/Xoe?= =?Windows-1252?Q?3mr/nul+jmLHdiRGmC20tsWzyVuQ9VnKnQO5LBBjoms4rdavxX6UCBUc?= =?Windows-1252?Q?rYflpdDEsGZ7rlZ590ZItboJhvsyHlct0lJtYmiX5Icx6IOvXJc4fk4G?= =?Windows-1252?Q?VFnDhht1dsWdI+Hc4pyH7Mjj1OZd1c+FO//wk6FdbqWcKvGX2VM/pFLQ?= =?Windows-1252?Q?UGWEFQx+oh6Ei9pt7Xsr0+q8I2z9jiAa5nWncjUItl7w/afLhATlPid9?= =?Windows-1252?Q?XRo=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV8PR11MB8536.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(4022899009)(10070799003)(1800799024)(366016)(376014)(8096899003)(7053199007)(38070700018)(13003099007);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?qPwWnZ586mm28jP6tnBMD8schfB0IiYkaAzOQzQFG1YCf/J8zpTRuT1W?= =?Windows-1252?Q?JhCnQ97FrVnbHwt/UC49dJBV+nn7dv/GXi2CqejL9RytC3gBStugv9Lf?= =?Windows-1252?Q?QNRFQrukXPQSEhqxWqqlDvrw9WeCBiDJyD1StJAtjEVC2b0xFpFeAh4T?= =?Windows-1252?Q?L4kCOJ3lZ4jgth13ssRCBpUt/5XpjliIChQzWO+i6SrTVjOPXicPnAcy?= =?Windows-1252?Q?qm70VXLlzpiag046gmdfGPiRX8nhLr03v7SJoEjJN2AsgrEM8p2zM0Wu?= =?Windows-1252?Q?giQrYssrCvc1SCMaUv0wpBjxvprmIpwTnINO3S271J6bO9hMs8Q8ohyz?= =?Windows-1252?Q?EAo2mv0D7WQooiRo8r+uWXSrfLgLYzVWqoYw2NFzqU2uzCwuRjKSp/qH?= =?Windows-1252?Q?/78gLu239Kn8shF53tvw2fo9SQxDKESz5p2sPPlwj4cq3JEXEPR1qync?= =?Windows-1252?Q?K+prpmDg570vg02QNjCNe+i7yj8d8p070H4WtIbqEfCESoNGIVgSZfjc?= =?Windows-1252?Q?nVl3qwp/HNcGu2nG3AAx1pQVQDu3dJ9ajgLHqSMaddx42GRWPt5w5RDW?= =?Windows-1252?Q?cB8ZFLAuU6e/UB1WHh967b6fYhBg9GVkZe3sG+O0bTEvIp+A9AA0B0Bw?= =?Windows-1252?Q?14jIUCe+OZMx/LfSNVXxnj54JR6OJvMm5Gd2kKMOJUmsv5dRB/8I0JHZ?= =?Windows-1252?Q?VKXKi18+KKSMeNifivqKTNcPTZjEZBJCuoN9WeOZ6Yiz1VqvL1Mv/Scm?= =?Windows-1252?Q?uK9Gvgy2KNo3+dwWo6gfA/x5KnHDVuqUuow0lUncjnGJsMbE+VXlMtfU?= =?Windows-1252?Q?LgSdi0CjZWtt7z6xpm7Eedmt8/uIdDfleFZ9SeS0vIX5kpacH2tQYomT?= =?Windows-1252?Q?nOwMrYlrx95JAHIgh0SYFJtRu5yGJuIaKYGi+C+dqHR3s0+tYCCz15vs?= =?Windows-1252?Q?NxDE9kNpE8s5OivA7xv4IVNzUDADp3nucQGMFzvTycovFaO9QHibbs2w?= =?Windows-1252?Q?VxZN+g2iGqfVzMDTVWlhDq6RuZA+GIN5wCmcRhr8C/ZfBRDyjjq46nGK?= =?Windows-1252?Q?foBGAQx1vL/hLEATcwN9D9bhZaUxbgUFKrLd/agIBZPv1x09SwfAPHWZ?= =?Windows-1252?Q?TWiqLb5NpunvHpc/6KvWGVdwgYU/Xwu/M1oB7SCwC9UT/q/tGcokCfA8?= =?Windows-1252?Q?DXMDKUQlOHyvD5bEBWhIvIof7fuG8gJLqUrlchbBEvVy4RHqH9Pjzh5n?= =?Windows-1252?Q?KdWl2/M/gB77bb/vepb7S3X+80lKDda5ck947RYp115cs3hGhkCjUefh?= =?Windows-1252?Q?xN/8E9JBVgb+ZjyGs4gamKzh2EulsBp3ie71cCjtPmRwjIeafdMDm0qc?= =?Windows-1252?Q?PiSGdqrcrQakCBhPS0gQpZv1V/9R9Jv8JY8nWkG+F5BkUqld5KCq3OMZ?= =?Windows-1252?Q?bMGqf50iOgG7BctYXFopLW0WHVKSC7E6OVdoFR1ZcyjmY/4A/z34i18g?= =?Windows-1252?Q?6QCF4s+bNIWkbWSD4FEiuqq7skn64HQ/T7oWO88H2F3rrXXYJMjXOAt8?= =?Windows-1252?Q?2I1fXzsk6Mdcpz4KNGFhEo490nCAUwGjDt3a8HITovANSDvL3BnanOGL?= =?Windows-1252?Q?5LwalWKHoxnixGwFQ+EAgUlgvaeycsIeoGZUmZCuJDuZKgKlYUa4hTTd?= =?Windows-1252?Q?gZIxvqpSu/VS9nNziKGZY+Jo4G/JhGbciJDiNT76H/eHbmEr/Cepy+5Z?= =?Windows-1252?Q?HM+Dzm1087ZsHPGNgOYAu4fXkNy6ntKuKt//hrhbu8STkon2d4aPWimm?= =?Windows-1252?Q?Fwjyyw=3D=3D?= Content-Type: multipart/alternative; boundary="_000_LV8PR11MB8536D89FFA77ED4D4D3BE026B53AALV8PR11MB8536namp_" MIME-Version: 1.0 X-OriginatorOrg: cisco.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LV8PR11MB8536.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7ee94880-14e5-4fc8-7269-08dde6ea6653 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2025 10:54:16.9734 (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: pzUJkJ4TrhyixrPRXJJ05dDzOBPCeuTC9EJkuKuZEjNOfbcgOB9WPwWmYXnKNk3yFTWuKsLD+OQeSM7LkFVypg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR11MB8138 X-Outbound-SMTP-Client: 173.37.147.250, alln-opgw-2.cisco.com X-Outbound-Node: alln-l-core-10.cisco.com Message-ID-Hash: H7YA7JG37E55YCD3DTYC6N4JXFAQB7CS X-Message-ID-Hash: H7YA7JG37E55YCD3DTYC6N4JXFAQB7CS X-MailFrom: rwilton@cisco.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mod-discuss.ietf.org-0; header-match-mod-discuss.ietf.org-1; header-match-mod-discuss.ietf.org-2; header-match-mod-discuss.ietf.org-3; header-match-mod-discuss.ietf.org-4; header-match-mod-discuss.ietf.org-5; header-match-mod-discuss.ietf.org-6; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BMod-discuss=5D_Re=3A_WG_Last_Call=3A_draft-ietf-modpod-group-pr?= =?utf-8?q?ocesses-10_=28Ends_2025-09-08=29?= List-Id: Discussion list for IETF moderation policies and practices Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_LV8PR11MB8536D89FFA77ED4D4D3BE026B53AALV8PR11MB8536namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Dan, Please see inline =85 From: D. J. Bernstein Date: Thursday, 28 August 2025 at 18:42 To: mod-discuss@ietf.org Subject: [Mod-discuss] Re: WG Last Call: draft-ietf-modpod-group-processes-= 10 (Ends 2025-09-08) Rob Wilton (rwilton) writes: > if someone repeated makes the same point that drowns out other useful > discussion Hmmm, really? Can you give a few links to examples of IETF mailing-list threads that were drowned out, so that people can understand concretely what happened and consider potential solutions? No, not publicly. I don=92t think that would be appropriate or necessary si= nce most of the people participating in this working group will be aware of= such instances, and =91relitigating=92 such examples is unlikely to be fru= itful. I would be willing to send you such information privately, but (1) = I get an auto reply from your email address that indicates that you are pro= bably dropping/filtering my emails given that I=92m not willing to enter in= to a contract just to send you emails, and (2) it seems that you would ask = that I share it in public, which as per above, I won=92t do because I don= =92t think that is appropriate. Did the list server run out of disk space? Not that I=92m aware of, but disk space is cheap and isn=92t the problem (e= xcept it is allegedly causing water shortages in the UK ;-). The cost to b= e concerned about is participant time/energy in reading and responding to t= hose messages. By default I would think that any repetition of the same objection reflects a failure by the chairs of whichever WG to maintain a chart of the objections that had been raised already. No, not really. Often in these cases the same issue gets raised repeated, = sometimes in very slightly different guises, and responded to. Eventually,= many of the WG participants get fed up and either stop reading the emails,= or stop replying to them, since the discussion isn=92t progressing, it is = just stuck at a point of disagreement. Often you will see other participan= ts starting to complain on the list about the same point being repeated bro= ught up. IETF consensus is not, and should not be, either last person stan= ding or whoever shouts the loudest wins. Sometimes, a participant=92s opin= ion is in the rough and they have to accept it, even if they think the WG i= s making a technical mistake and move on. In some cases, the WG may subseq= uently realise the mistake and rectify it. Life is imperfect. In addition, for the key issues I believe that the WG chairs already did th= is (e.g., please search the mod-discuss archives for emails that Lisa has s= ent out as chair and you will find various examples where she has summarize= d open issues. I also cite such an email later in my reply). In addition = to this, the authors have also been tracking issues on github (available he= re, https://github.com/larseggert/draft-ietf-modpod-group-processes/issues)= . So, I disagree that there is any failure of the chairs here, or that iss= ues haven=92t been adequately tracked. As a concrete example of such a failure, having this WG proceed to last call suggests to observers that all objections have been addressed---but that's not true: for example, there was no response to Keith Moore's point about Challenger. Observers can't find a chart of the objections; they're forced to dredge through list archives. Here I am suffering through highlighting the Challenger point again, exactly because the point was improperly ignored. The root-cause fix for the repetition is to track objections (as in other standards-development organizations), not to shoot the messenger. And this is perhaps a case where you and I have a difference of opinion on = how the IETF process works. I don=92t agree that all emails must be respond= ed to (e.g., if there are just restating a point that has already been full= y debated), and I don=92t agree that all issues require changes to the unde= rlying text. If all issues have been clearly considered by the WG then in= many cases, the conclusion may be that no further changes to the text are = needed. Further, WG LC (and IETF LC) is another opportunity to ensure that= all remaining issues have been raised. So, for example, if someone was moderated by the WG chairs (e.g., prevented= from posting directly to the mailing list) during WG LC because the chairs= perceived that they were being disruptive then, depending on the nature of= the disruption, I would anticipate that the chairs (or moderation team) mi= ght take 1 of 2 actions: 1. Set the mailer so that the WG chairs can manually read/filter the ema= ils from the moderated participant before deciding whether they can be sent= on to the WG. 2. Allow the moderated person to send a single email to summarize their = objections during WG LC, to ensure that their issues have been heard. The moderation team is expected to come up with guidance for WG chairs, whi= ch may end up being like what I suggest above, or it may be substantially d= ifferent. It doesn=92t really matter because the key point is that, at lea= st for me, there is an expectation that the moderation team acts to minimiz= e the risk of censorship, as is stated in the draft. But I don=92t really see the point that Keith is making about Challenger ha= ving any bearing on a moderation team for the following reasons: * The challenger issue (as summarised by Keith - I=92ve not read any de= tails) seemed to be due to managers ignoring (not censoring) the technical = input of engineers. However, the moderation team is made up of other parti= cipants, not folks involved within the IETF leadership and the moderation p= rocedures document clearly states that moderation is not to be used to supp= ress technical input. In my experience, often contentious decisions in the= IETF can boil down to disagreements as to whether A or B is the better app= roach, or disagreements above whether a particular approach or change will = be harmful to the Internet. Just because someone is in the minority and is= objecting loudly doesn=92t mean that that they are technically right and t= heir technical input is more valid that the others participants in the disc= ussion. * The challenger decision seemed to happen quickly. I haven=92t read t= he details, but I would presume within 24 hours of when the disaster happen= ed. But IETF decisions happen over a period of weeks or months, normally w= ith multiple opportunities to raise the issue, and an appeals process in pl= ace. Often IETF solutions are tested and deployed over a matter of years. = Hence, I=92m struggling to see a case where a moderation action is going t= o cause the Internet to fail in a way that is not spotted and rectified or = mitigated. But I would like to turn this argument around. Can you please cite example= s within the last 5 years (that don=92t directly involve yourself because y= our opinion may not be objective in such cases), where moderation has been = used in the IETF to suppress constructive technical input into the standard= s process. Ideally, I would be looking for cases where the decision has be= en appealed and the appeal succeeded. > However, given that we have a WG with an approved charter I believe > that we are well past the point of debating or deciding whether > anything needs to be done. The charter does _not_ mandate censorship. Neither does the solution, as best explained by Eliot=92s previous reply (h= ttps://mailarchive.ietf.org/arch/msg/mod-discuss/OYrqrTbf0Gubb2twyPOj3nGPyj= I/) Everything the charter asks for can be met by purely advisory actions. I disagree, and this specific issue was one that was tracked by Lisa, discu= ssed, and I believe rough consensus has been reached (https://mailarchive.i= etf.org/arch/msg/mod-discuss/fVxyeW-qN0cDF6OLHgOh7k8DOik/). That isn=92t t= o say that the consensus cannot be changed during WG LC, but I do think tha= t it is incumbent on the individuals who want to change the consensus to ma= ke the argument and persuade the WG that the previously reached consensus s= hould be changed. This would also eliminate the concerns about damaging IETF's openness and silencing minorities. If we are unable to improve the decorum on IETF lists then we just end up s= ilencing a different set of minorities. In particular, younger folk who se= em to be much less willing to put up a bunch of old white guys having very = vocal and forthright debate =96 what was acceptable in the 80=92s and 90=92= s is no longer acceptable today, and the IETF must somewhat move with the t= imes (hopefully in a moderate fashion) to continue to stay relevant. Kind regards, Rob ---D. J. Bernstein _______________________________________________ Mod-discuss mailing list -- mod-discuss@ietf.org To unsubscribe send an email to mod-discuss-leave@ietf.org --_000_LV8PR11MB8536D89FFA77ED4D4D3BE026B53AALV8PR11MB8536namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Dan,

Please see inline =85

 

From: D. J. Bernstein <djb@cr.yp.to>
Date: Thursday, 28 August 2025 at 18:42
To: mod-discuss@ietf.org <mod-discuss@ietf.org>
Subject: [Mod-discuss] Re: WG Last Call: draft-ietf-modpod-group-pro= cesses-10 (Ends 2025-09-08)

Rob Wilton (rwilton) writes:
> if someone repeated makes the same point that drowns out other useful<= br> > discussion

Hmmm, really? Can you give a few links to examples of IETF mailing-list
threads that were drowned out, so that people can understand concretely
what happened and consider potential solutions?

 

No, not publicly. I= don=92t think that would be appropriate or necessary since most of the peo= ple participating in this working group will be aware of such instances, an= d =91relitigating=92 such examples is unlikely to be fruitful.  I would be willing to send you such information priv= ately, but (1) I get an auto reply from your email address that indicates t= hat you are probably dropping/filtering my emails given that I=92m not will= ing to enter into a contract just to send you emails, and (2) it seems that you would ask that I share it in public,= which as per above, I won=92t do because I don=92t think that is appropria= te.

 

 

Did the list server run
out of disk space?

 

Not that I=92m awar= e of, but disk space is cheap and isn=92t the problem (except it is alleged= ly causing water shortages in the UK ;-).  The cost to be concerned ab= out is participant time/energy in reading and responding to those messages.



By default I would think that any repetition of the same objection
reflects a failure by the chairs of whichever WG to maintain a chart of
the objections that had been raised already.

 

 

 

No, not really.&nbs= p; Often in these cases the same issue gets raised repeated, sometimes in v= ery slightly different guises, and responded to.  Eventually, many of = the WG participants get fed up and either stop reading the emails, or stop replying to them, since the discussion isn=92t= progressing, it is just stuck at a point of disagreement.  Often you = will see other participants starting to complain on the list about the same= point being repeated brought up.  IETF consensus is not, and should not be, either last person standing or whoeve= r shouts the loudest wins.  Sometimes, a participant=92s opinion is in= the rough and they have to accept it, even if they think the WG is making = a technical mistake and move on.  In some cases, the WG may subsequently realise the mistake and rectify it.  L= ife is imperfect.

In addition, for the key issues I believe that the WG chairs already did th= is (e.g., please search the mod-discuss archives for emails that Lisa has s= ent out as chair and you will find various examples where she has summarize= d open issues.  I also cite such an email later in my reply).  In addition to this, the authors have a= lso been tracking issues on github (available here, https://github.com/larsegge= rt/draft-ietf-modpod-group-processes/issues).  So, I disagree that there is any failure of the chairs here, or that issues haven=92t been adequatel= y tracked.


As a concrete example of such a failure, having this WG proceed to last
call suggests to observers that all objections have been addressed---but that's not true: for example, there was no response to Keith Moore's
point about Challenger. Observers can't find a chart of the objections;
they're forced to dredge through list archives. Here I am suffering
through highlighting the Challenger point again, exactly because the
point was improperly ignored. The root-cause fix for the repetition is
to track objections (as in other standards-development organizations),
not to shoot the messenger.

 

And this is perhaps= a case where you and I have a difference of opinion on how the IETF proces= s works. I don=92t agree that all emails must be responded to (e.g., if the= re are just restating a point that has already been fully debated), and I don=92t agree that all issues require c= hanges to the underlying text.   If all issues have been clearly = considered by the WG then in many cases, the conclusion may be that no furt= her changes to the text are needed.  Further, WG LC (and IETF LC) is another opportunity to ensure that all remaining is= sues have been raised.

 

So, for example, if= someone was moderated by the WG chairs (e.g., prevented from posting direc= tly to the mailing list) during WG LC because the chairs perceived that the= y were being disruptive then, depending on the nature of the disruption, I would anticipate that the chairs (or mo= deration team) might take 1 of 2 actions:

  1. Set the mailer so that the WG cha= irs can manually read/filter the emails from the moderated participant befo= re deciding whether they can be sent on to the WG.
  2. Allow the moderated person to send a single email to summarize their objec= tions during WG LC, to ensure that their  issues have been heard.

The moderation team= is expected to come up with guidance for WG chairs, which may end up being= like what I suggest above, or it may be substantially different.  It = doesn=92t really matter because the key point is that, at least for me, there is an expectation that the moderation team= acts to minimize the risk of censorship, as is stated in the draft.

 


But I don=92t really see the point that Keith is making about Challenger ha= ving any bearing on a moderation team for the following reasons:=

  • The challenger issue (as summarised = by Keith - I=92ve not read any details) seemed to be due to managers ignori= ng (not censoring) the technical input of engineers.  However, the moderation team is made up of other particip= ants, not folks involved within the IETF leadership and the moderation proc= edures document clearly states that moderation is not to be used to suppres= s technical input.  In my experience, often contentious decisions in the IETF can boil down to disagreements as = to whether A or B is the better approach, or disagreements above whether a = particular approach or change will be harmful to the Internet.  Just b= ecause someone is in the minority and is objecting loudly doesn=92t mean that that they are technically right an= d their technical input is more valid that the others participants in the d= iscussion.
  • The= challenger decision seemed to happen quickly.  I haven=92t read the d= etails, but I would presume within 24 hours of when the disaster happened.&= nbsp; But IETF decisions happen over a period of weeks or months, normally with mult= iple opportunities to raise the issue, and an appeals process in place.&nbs= p; Often IETF solutions are tested and deployed over a matter of years.&nbs= p; Hence, I=92m struggling to see a case where a moderation action is going to cause the Internet to fail in a way that i= s not spotted and rectified or mitigated.

 

But I would like to= turn this argument around.  Can you please cite examples within the l= ast 5 years (that don=92t directly involve yourself because your opinion ma= y not be objective in such cases), where moderation has been used in the IETF to suppress constructive technical input into th= e standards process.  Ideally, I would be looking for cases where the = decision has been appealed and the appeal succeeded.



> However, given that we have a WG with an approved charter I believe > that we are well past the point of debating or deciding whether
> anything needs to be done.

The charter does _not_ mandate censorship.

 

Neither does the so= lution, as best explained by Eliot=92s previous reply (https://mailarchive.ietf.org/arch/msg/m= od-discuss/OYrqrTbf0Gubb2twyPOj3nGPyjI/)

 

 

Everything the charter asks
for can be met by purely advisory actions.

 

I disagree, and thi= s specific issue was one that was tracked by Lisa, discussed, and I believe= rough consensus has been reached (https://mailarchive.ietf.org/arch/msg/mod-discuss/fVxyeW-qN= 0cDF6OLHgOh7k8DOik/).  That isn=92t to say that the consensus cannot be changed during WG LC, but= I do think that it is incumbent on the individuals who want to change the = consensus to make the argument and persuade the WG that the previously reac= hed consensus should be changed.

 

 

This would also eliminate the
concerns about damaging IETF's openness and silencing minorities.

 

If we are unable to= improve the decorum on IETF lists then we just end up silencing a differen= t set of minorities.  In particular, younger folk who seem to be much = less willing to put up a bunch of old white guys having very vocal and forthright debate =96 what was acceptable in th= e 80=92s and 90=92s is no longer acceptable today, and the IETF must somewh= at move with the times (hopefully in a moderate fashion) to continue to sta= y relevant.

 

Kind regards,
Rob

 



---D. J. Bernstein

_______________________________________________
Mod-discuss mailing list -- mod-discuss@ietf.org
To unsubscribe send an email to mod-discuss-leave@ietf.org

--_000_LV8PR11MB8536D89FFA77ED4D4D3BE026B53AALV8PR11MB8536namp_--