Re: Question about pre-meeting document posting deadlines for the IESG and the community

"Rob Wilton (rwilton)" <rwilton@cisco.com> Mon, 25 March 2024 10:17 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E78C14CF1C for <ietf@ietfa.amsl.com>; Mon, 25 Mar 2024 03:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.594
X-Spam-Level:
X-Spam-Status: No, score=-14.594 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_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="LGZ09hwr"; dkim=pass (1024-bit key) header.d=cisco.com header.b="FjWlXOm1"
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 fiToQr0Y2_2c for <ietf@ietfa.amsl.com>; Mon, 25 Mar 2024 03:17:35 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (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 C2A49C14F739 for <ietf@ietf.org>; Mon, 25 Mar 2024 03:17:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; i=@cisco.com; l=25503; q=dns/txt; s=iport; t=1711361854; x=1712571454; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=xpslKCY9VN6KG+I5mca0pdsancx5zepc6P57ZatbaDE=; b=LGZ09hwrtbGvEi5udQtT31TgWfePvleuNhrz7SaooLfvE8y9IlQ47k74 Nam1PNQkjzbytxGJyEMZYHw06MrkCDIH5Ba7MbHmpfqkDOcBNQESqStrC 5f2aL4/4TV9IvHeB97cES1DUsdMAiIh6fNwfP56RhpngxuG790agNKy1U I=;
X-CSE-ConnectionGUID: OjWLVzpzSauZpLQOxUhkfg==
X-CSE-MsgGUID: dIkEVl4MQnCxV9blGaMIbw==
X-IPAS-Result: A0BPAAA8TgFmmIMNJK1aHAEBAQEBAQcBARIBAQQEAQFAJYEZBAEBCwGBNTFSegKBBRJIiCEDhS2GSYIiA5FCjWoDVg8BAQENAQE5CwQBAYUGAogEAiY3Bg4BAgICAQEBAQMCAwEBAQEBAQEBBgEBBQEBAQIBBwUUAQEBAQEBAQEeGQUQDieFbA2GWQEBAQECARIuAQEjCQwECwIBCBEDAQIvMR0IAgQBEggMAQYHgl4BghclIwMBEKVKAYFAAoooeIE0gQGCCgEBBgQFsngDBoFIAYglAYFShiyCMycbgUlEgRVCgWZRMT6CYQIDgScNKx4Ng2eCDSKBGH+DN4FgRFRrgVuET4dGPwougm0nQYFaAodwVHkiA30IBFwNGxAeNxEQEw0DCG4dAjE6AwUDBDIKEgwLHwUSQgNABkgLAwIaBQMDBIEtBQsaAhAaBgwoAwMSSQIQFAM4AwMGAwoxLk9BDFADZx8xCTwLBAwaAhsUDSQjAiw+AwkKEAIWAx0WBDARCQsmAyoGNgISDAYGBlwgFgkEIwMIBANQAyBwEQMEGgQLB3aCAIE9BBNHEIEyBooQDIMJAgUjgXkpgREYgxMLLwNEHUADC209NQYOGwUEHwGBGQWiRnsBgXERAVoVCBEGECYRRhQMAi0XBBsLAQcYBA8CBgIRNQwTGAQaD5JCjyajTAqEE4wMjh+HNBeEUaVemGIgjVOVQgISChmEbQIEAgQFAg8BAQaBeiSBW3AVO4JnUhkPiEqFVgwNCRaDQoUUimV4OwIHCwEBAwmIboEdXQEB
IronPort-PHdr: A9a23:VMFdrRMpnr2v+kF1WL8l6nfMWUAX0o4cdiYP4ZYhzrVWfbvmpdLpP VfU4rNmi1qaFYnY6vcRk+PNqOigQm0P55+drWoPOIJBTR4LiMga3kQgDceJBFe9LavCZC0hF 8MEX1hgrDmgKUYAIM/lfBXJp2GqqzsbGxHxLw1wc/7qG4rOiMKf3OGp8JqVaAJN13KxZLpoJ 0CupB7K/okO1JFvKKs61lPFo2AdfeNQyCIgKQeYng334YG7+5sLzg==
IronPort-Data: A9a23:1edQj6Dq5TXyRhVW/1vjw5YqxClBgxIJ4kV8jS/XYbTApDMg1jBVx mcYXjiCPKqJNmP3c4wgPdvnoR9TvZ7VyNAxOVdlrnsFo1CmBibm6XV1Cm+qYkt+++WaFBoPA /02M4SGdIZsCCaE+n9BC5C5xVFkz6aEW7HgP+DNPyF1VGdMRTwo4f5Zs7ZRbrVA357hXGthh fuo+5eDYAT/h2YuWo4pw/vrRC1H7ayaVAww5jTSVdgT1HfCmn8cCo4oJK3ZBxMUlaENQ4ZW7 86apF2I1juxEyUFU7tJoZ6nGqE+eYM+CCDV4pZgtwdOtTAZzsA6+v5T2PPx8i67gR3R9zx64 I0lWZBd1W7FM4WU8NnxXSW0HAlZP5Jixq3fM0O2rP6L63ThY0bswPthWRRe0Y0woo6bAElH8 fgebTsKdB3G3qS9wamwTa9ngcFLwMvDZdxE/Co+i2iCS699GPgvQI2SjTNc9C0vh8RSGvD2b MsCYj0pZxPFC/FKEg1LUsxux7jw2hETdRVUiVG4m65rxlHV5xxPgbLpH9PwW9aVEJA9ckGw/ T+eoD+jXXn2Lue3yDeZ/Fqti/PB2yThV+ov+KaQ//puhhiYwXYeTURQXlqgqv7/gUm7Mz5CF 6AK0g0skowM5lS5ddDgbQWcmVmUgx4fVdUFRoXW9zqx4qbT5g+YAE0NQThAdMEquacKqdoCi AThczTBW2YHjVGFdU9x4It4ut9bBMT4BWYGYSlBRgwf7py65ooylRnICN1kFcZZb+EZ+xmuk 1hmTwBn293/aPLnMY3npTgrZBr3+PD0ovYdvFm/Y45cxloRiHSZT4Kp80PHyv1LMZyUSFKM1 FBdxJHHt7hTVc/cyHHVKAnoIF1Pz6jfWNE7qQM+d6TNCxzyk5JeVdkJv2EgfhsB3jgsIGe3M Sc/Rj+9FLcIYSP1NvUoC25AI88r1qPnXc/0TezZa8EGY556Mme6ENJGOyatM5TWuBF0y8kXY M7DGe71VCZyIfo8llKeGbxCuYLHMwhjnws/s7ihkUT+uVdfDVbIIYo43KymNL5gsvzV/FSEm zudXuPToyhivCTFSnC/2aYYLEsBKj4wApWeliCdXrTrztZOcI35N8Ls/A==
IronPort-HdrOrdr: A9a23:ZtWoya4uPTTc8auNhQPXwYCCI+orL9Y04lQ7vn2ZFiYlEfBwxv rPoB1E737JYW4qKQ8dcLC7VJVoMkmshKKdgLNhcYtKOTOW2ldAQ7sSl7cKrweQfBEWs9Qtqp uIEJIOR+EYb2IK8PoSiTPQe71Psbz3lJxAx92us0uFJjsaEp2Imj0JcTpzZXcGPDWua6BJcq a0145snRblU3IRaciwG3kCWMb+h/CjrvjbSC9DLSQKrC2Vgx2VyJOSKXWlNxElPA9n8PMHyy zoggb57qKsv7WQ0RnHzVLe6JxQhZ/I1sZDLNbksLlVFhzcziKTIKhxUbyLuz445Mu17kwxrd XKqxA8e+xu9nLqeH2vqxeF4Xih7N9u0Q6g9baruwqnnSXLfkN/NyOHv/MfTvLt0TtjgDi76t MM44vWjesPMfqKplWM2zGBbWAYqqPzmwttrQbW5EYvCrf3r9Rq3NQi1VIQH5EaEC3g7oc7VO FoEcHH/f5TNUiXdnbDowBUsZeRt1kIb167q3I5y4So+ikTmGo8w1oTxcQZkHtF/JUhS4Nc7+ CBNqhzjrlBQsIfcKo4XY46MIaKI32IRQiJPHOZIFzhGq1CM3XRq4Tv6LFw4O2xYpQHwJY7hZ yEWlJFsmw5fV7oFKS1rdd22wGIRH/4USXmy8lY6ZQ8srrgRKDzOSnGU1wqm9vImYRoPiQaYY fFBHt7OY6WEYK1I/c64+TXYegmFUUj
X-Talos-CUID: 9a23:7ydVWmMIBqypkO5DfytY0HAGAtIee2Dv1FPpBF+FCWVnR+jA
X-Talos-MUID: 9a23:EGG6UA+bYN5VtaxYXoj5lo2Qf8tJ4ImQDBwoqJMtq/fVPyhfMhK8hiviFw==
X-IronPort-Anti-Spam-Filtered: true
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-1.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2024 10:17:33 +0000
Received: from rcdn-opgw-2.cisco.com (rcdn-opgw-2.cisco.com [72.163.7.163]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 42PAHX3d012435 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <ietf@ietf.org>; Mon, 25 Mar 2024 10:17:33 GMT
X-CSE-ConnectionGUID: dCSKYU3WQs6zf+i250JydQ==
X-CSE-MsgGUID: JPvp1ErJQM+aEmbQyr/Eyw==
Authentication-Results: rcdn-opgw-2.cisco.com; dkim=pass (signature verified) header.i=@cisco.com; spf=Pass smtp.mailfrom=rwilton@cisco.com; dmarc=pass (p=reject dis=none) d=cisco.com
X-IronPort-AV: E=Sophos;i="6.07,152,1708387200"; d="scan'208,217";a="11352282"
Received: from mail-dm6nam11lp2168.outbound.protection.outlook.com (HELO NAM11-DM6-obe.outbound.protection.outlook.com) ([104.47.57.168]) by rcdn-opgw-2.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2024 10:17:33 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VTbF0FtPSrw4DyII+GJWuxWQROoPgSn5WxD6N1IyRbQG0ROK+fUFfQoW8BSlGZsYmozjDtqTKiXuccV+zGcBIMdjctw4sYCJZ2dwUiaqYujGe+6SCVRRLi/rVIxQM1zAERPuG3IhYTVqo9bQhbx4FCJiVuIeV0fvsLnGSMunbBYvq512e9f/3ajnpl/4vmlqTplmNmXYEfLLsC95V3wkuorF3tIuf6IYHB2hmpmzeY6AH2nqCEsmiVASlEZNCHd5f/Wx3ftdFdiF2vmAs4Thxab2xFCS7jOoEwW8E+Yu8aqAMd0TYXlzoeuCA8mlggXwcvRgO5DId6TaG32e9ZGvPQ==
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=xpslKCY9VN6KG+I5mca0pdsancx5zepc6P57ZatbaDE=; b=UF7vsQnV/NBC4MbaB6HOsI/Ig5+qMySeBdWkSZmRq0C2Rv0KVX6OafgozKrRpLU45kO+b4IFc9ERn8Q1f1CuCkBWIRAimkzEIKaTn9Kj4WlobWKzhB7snaV8jW+TqVC9BITBlVJhKCjIwBuZ3WEVq7RdHbwRaCz5LyrmHoqrpzn/t5vbTjDtxXnYyBUXjNLzpQd3X0Q0fRo905weEToZ5QV9LYpYu6+66gKK/rokfYIZrt10Ib0dH6lgxrxIUqTlYk5SkVIdDs/On/xxMSr0t2l/XViPzSUqKetAiNeEgjTxZRMNszMZfIJlSwQYdvqUYqiBLGwh7ZqRM53hsBrFXQ==
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=xpslKCY9VN6KG+I5mca0pdsancx5zepc6P57ZatbaDE=; b=FjWlXOm1HcmxI6vVtv4f5W089v3jRicQkYp5C6wMDlrvkORz3wD6zjhNPogdscqp1YBazP1dufUVjWK0BduwR5C/PQrNMxiIS/Rqbqj8vlkMTZ795NWFqnlRfoRLbPuVfG6A8AN0o1KqENU1z7jBzsAiGa2VIMVbYajxcn9NDzI=
Received: from LV8PR11MB8536.namprd11.prod.outlook.com (2603:10b6:408:1ec::19) by MW4PR11MB5911.namprd11.prod.outlook.com (2603:10b6:303:16b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.31; Mon, 25 Mar 2024 10:17:31 +0000
Received: from LV8PR11MB8536.namprd11.prod.outlook.com ([fe80::dae8:c4e2:9d09:1d9]) by LV8PR11MB8536.namprd11.prod.outlook.com ([fe80::dae8:c4e2:9d09:1d9%7]) with mapi id 15.20.7409.010; Mon, 25 Mar 2024 10:17:30 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: John C Klensin <john-ietf@jck.com>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: Question about pre-meeting document posting deadlines for the IESG and the community
Thread-Topic: Question about pre-meeting document posting deadlines for the IESG and the community
Thread-Index: AQHadw7AJB7j6AiV2EqSUhgUyjRJNLE5PEQAgAAG5YCAAI3dAIABEFaAgAAgsQCAACgyAIAADIGAgAkkY4CAAE/3gIAAGhiAgABJ7oCAAHXkAIAAhkAAgACsVQCAACmNgIAARnyAgAAm0ACAAPJ0Hw==
Date: Mon, 25 Mar 2024 10:17:30 +0000
Message-ID: <LV8PR11MB8536C2440ECEA0CA6ABF5463B5362@LV8PR11MB8536.namprd11.prod.outlook.com>
References: <7826C4F13FA874CD79459A4B@PSB> <65A7921B-2A05-439A-976C-226560C5E7F4@strayalpha.com> <e0702d8a-cea5-4928-b571-98442ccd4f29@petit-huguenin.org> <6d0c6b07-2fc3-496c-ba66-dc40cbf46df8@dfn.de> <69EE71C9-C42B-49A6-BC0D-508F799DB68E@tzi.org> <1d301b86-c994-4a9c-810c-9a42e12a0ad8@network-heretics.com> <53C617FA98D84931861C1F59@PSB> <85D994BF-5E89-437B-821C-12DE93C403B3@episteme.net> <6.2.5.6.2.20240322143647.10ef96f8@elandnews.com> <569FBECE-E637-4B2A-86C5-4F7B7AEC333E@episteme.net> <7F1502637EB78EE7032F4384@PSB> <6.2.5.6.2.20240323004217.115aeb28@elandnews.com> <240d0bf6-36e8-410d-8f86-2069dfc16f52@network-heretics.com> <6.2.5.6.2.20240323154539.127fbdb8@elandnews.com> <897e2bce-2187-433c-af26-c8c8f3b37c1b@network-heretics.com> <6.2.5.6.2.20240324031614.13b523c8@elandnews.com> <5af5aabd-7201-485e-b828-752951b1a852@network-heretics.com> <B8DA7CC4E91DEC51A30B00D4@PSB>
In-Reply-To: <B8DA7CC4E91DEC51A30B00D4@PSB>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: LV8PR11MB8536:EE_|MW4PR11MB5911:EE_
x-ms-office365-filtering-correlation-id: 7f4a7785-7a41-45d4-39ba-08dc4cb4c78d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: cMyzVuO3781MGMl1gCg8XNXU6d4wYYsMOk7FSwDeqAqWYpt83Bmquew/kaw3BRmUQJhdd9T2dZCk+Yu2FrzraabUaLpkaX8ggFmAwHXgQ3Vfav2vDWj2EccN5kPOJPrf8YX188UjDycgszDL3ifu2GKcDh3i4EeF+uz8zLwlrhRdRnaXr7Q4BHaz8ptiuK4vy/XYCBjzftsRMK0TxUl29hg+81SyIS3bXr2+hsk1FdiplEhVCqvvDHHsRpKltMxB1P5dD6+93mhf/X1ngOA9rLd35ztK2gF6g/hw0xXvo0RcQUkP2NtsFB5JuTW2aVfbZ/KQbUToZXeZ7aJuiA2ikDmrrKGjcktA7YRfbJ1FrP3ytcpr4Wppj3gBsl9hQIQAINUyjsFIMghkINIwbZmuQ8ocA0GegyJFNNllzbaSxb41q9yo2oofhfuF/VuueKncIl2iiCppXbMiD1VRmrM5n7A9PRtUCLYX7EtMKWhX4pjWeqp4aB9Ls9BpN0EPvUrTGRQ9/6aZa8msTJZd1zYqe7HWwt4WUGlr5enoa1RAmmUxUSaPQbJDiUCfeuCUzixWbjbuREx+dL/nyTtvl1YoXznldxQB+eaZpxV6yBvbm5roPl+az5U7Tq857x3Cd8kEhu9mLLd29K/FCKMN5220Kg9GSsy+9nO0m4WHIrWcKwo=
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:(13230031)(1800799015)(366007)(376005)(38070700009); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 6qIqzojlkE9Bxf09AH+AheBsg8IRY6TFbjY+s3BIsBpodDUO24TRBKhbhF3Kp0Pz5YKSk42KYho3ar//WJxaQX4fMH6zkpIhu+1J3wGkQzvTshOSO3B+euuyc9dAS5UBMtuql7ASyViFP77o2Oxq0nwLMXsdH4ynvpX9WlCmmKx85mQiLi3r5FgmEJDzjnXfM9sB7KEcCN5T8yRthzmuP8xigSUl0qDcSsd0Um3xf2VdQw2p4rBALvC6/XpbbyVmt8UqpY19sB47cJl/S6qPpr++4ipKrlxlBkOk4JSHlOO2eexAcoOCxmDRgutdkQQbV/5ch5xPexSg7FgBeaktayHANCh9UwYUsWfrAraCv/k8ceMwA5NnDsjHgkXQ0u1+aJ/LvFSixyPB/lV0eITU66xPoP41Juh6znsR1/rcQsQvTUSGp4hd5rL8uoYWfy4+rLGBnaUqKf98ql84wCR2zh5kmYupHDgXzqVJp8XrMEi7izO6kc/5uG/Z3w1PFzcxZKGKuypiBQsYYFHwvHf6a00V6BsYslVe6at5Wd0YCvXab9bD2xyD8Q1qBKYd+vzFAgCBLl1kI7n45NRqjNjb9jxfnw5dQP0OkxOYnBWzfeGba/HozohM6x7gVvQlvLbAjVOkgggyLiAc7BZXQZ0I32TObESJ9mD+iryAhMZX/DN/oiabawEzScaOT79AYP7Bwv2yndO1m/TPKO5KGqVZgJMdOqn1n1dABH+l0zTYeelmHsHKMnK3Gt6wEOkbehLVVxwognH1/eoJBu1L8AP2yvcB6vUTCn58ggGkBXyBQv0liiuPX1Fj/+42DTiDHRMfSB230A/vHZzvxC9E9ku1RT2jh8iauN9udt1HNUlZzrF3DdyqILS3vlrs39P3pQKQ0+I09rKPevH4cqTHOuMkkk3I7Lpim6PFL7VJnPTrn+Ef8xWH31RX+6xb7Ce7r3HbHA+gW5Xfd6cG5yEiR4p9KhMCeiKrfo/4XHY/R0i+9/plNok6fLkwsqDJoq6njUVWAxiH4xUtKn1yCbZC3vnMIBve/CwcV8TWnn8IuwYUnEhWkdZchBslOT6IZqw9K21YXud2VpZQNilBnCVI3P6j0n909EfT8qkr48J7bL5M/VtA55Mgi5ehTIRJPIvVsAFUf5py7/9EUmh7QtbPFkHmp6c/qh/whoirF6gc6zYM3LxwEBn2vRyi1vESevvQAGgaSl70Itn1SVltT8E0XmuDU3NswInVrSDw2PXQyxGA4H88UO8HUoP8vj0uIg4GvE9sJglrpLJWlqqkEaVMwy9h3jw5QZBmKdV6hNTfd5FdcQgptG4Cv2pA1k2/ivfuLM0kf4HywjZqvMXtcWyfoT335IRms2w00ppZVHwq+5Tz5iRoneMwWzGN/GJJRqswDvl+7LC5lwcqCO0DAjA33XLy64FzAszzoxBWYOP9bExxfYrOZkKU6esPVoykBTtsDYbxflYjqw5aSN6RQFKQ7D2i1YeLflozTt9moXURVPQL8raQm0YlWXNk0JFMlzibFusVCzxTZviY8hSwwOxp66NZmhfirHRPehcLFEvJ9qvi/M2UwKEcmgrk0wqBQ7agW8IKhitLqRY2ps5/Ha0dfIxQeOv6PlAuwS7FSCsGKb0aclebO0k0sLrajJUnr2AqlyywpsFrFjnBPZJ0ntRR7/yWdw==
Content-Type: multipart/alternative; boundary="_000_LV8PR11MB8536C2440ECEA0CA6ABF5463B5362LV8PR11MB8536namp_"
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: 7f4a7785-7a41-45d4-39ba-08dc4cb4c78d
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2024 10:17:30.5184 (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: RBEgKk7iCUPfYMxEdUnrXE9OujGHaxfj3L85/HgNdG3oYdMpphFFwR/Th9VVdIWAH6VfGId+0GCH4OPYnw9WYw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR11MB5911
X-Outbound-SMTP-Client: 72.163.7.163, rcdn-opgw-2.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/KilcXfb4EV5dtatRNpTgzb8x6SM>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Mar 2024 10:17:40 -0000

Hi John,

In my recent experience, the IESG didn’t regard appeals as big issues or attacks, and they welcomed appeals as an important and necessary safeguard to ensure checks and balances and that everyone is following the process.  However, handling appeals properly is time consuming, and like all things, if it is possible to deal with issues without the overhead of dealing with a formal appeal then arguably that is a more efficient use of time, and of course, you acknowledge that ADs are time poor anyway.

In terms of the plenary, I think that it is useful for the IESG/IAB to report on the number of appeals that they have received and processed.  It would be surprising, at least to me, if the IETF chair had said “Unfortunately there have been no appeals in the last cycle” … so, being pleased that there were no appeals since IETF 118 seems unsurprising, and I don’t think that this messaging is intended to indicate the appeals are bad and should be avoided.

It also does not surprise me when appeals fail, particularly if it relates to an issue that the IESG/IAB are already familiar with and hence will have already considered the options carefully before reaching their initial decision.  Of course, it can always be the case that there are some factors that they didn’t sufficiently consider or give a different weight to, or the outcome of the original decision will have a wider impact beyond what they may have initially considered, and here I think that the appeals process is particularly useful.

In short, I don’t see that anything is broken with the appeal process, and I encourage participants to make use of this mechanism if they believe that they have valid concerns about decisions taken by either the IESG or IAB.

Regards,
Rob


From: ietf <ietf-bounces@ietf.org> on behalf of John C Klensin <john-ietf@jck.com>
Date: Sunday, 24 March 2024 at 19:06
To: Keith Moore <moore@network-heretics.com>, S Moonesamy <sm+ietf@elandsys.com>, ietf@ietf.org <ietf@ietf.org>
Subject: Re: Question about pre-meeting document posting deadlines for the IESG and the community
Keith, SM,

--On Sunday, March 24, 2024 12:46 -0400 Keith Moore
<moore@network-heretics.com> wrote:

>...
>> As a comment on interim meetings, there is a decision by the
>> IAB at:
>> https://datatracker.ietf.org/group/iab/appeals/artifact/39

A decision I deliberated at length about whether I should take
to the ISOC BoT and, when I decided against it, whether I should
post a note to this list about why not and what I saw as the
broader principles.  If I did neither of those things whether I
should send a note to the IESG on that subject.   I concluded
that neither of the first two would be in the best interests of
the community and that the latter would probably be a waste of
their time and mine.  As a personal request, let's not reopen
that discussion: the appeal was ultimately about a detail and
potential small/isolated fix to it.  It the IESG and IAB did not
focus on the principle, that was probably at least partially my
fault as author of the appeal.  I continue to agree with Pete
that we should try to focus on broader principles and not spend
more time on those details.

I could have filed a second appeal that focused more clearly on
the principle, but I did consult with a few people before making
my decisions and came away with the sense that the IESG would
reject such an appeal either on the grounds that there were no
concrete examples they had not decided on already or that the
procedures allow for appeals against actions but not against
necessarily vague principles.   And I probably would have agreed
with them on both of those likely conclusions.    More on
appeals in general below.

> I have pretty strong opinions about interim meetings based on
> my own experience while on IESG, in which one WG in particular
> was holding interim meetings without broad public notice and
> only to the WG mailing list.   I found that this WG was
> hostile to outside input and that this was detrimental to the
> quality of their output.   I still find that WG's output to
> be of very low quality and to impair interoperability to this
> very day.   And I believe that the complexity of the spec
> that they produced discourages additional implementation which
> might improve reliability for users.

And here the obvious question --for you and others who knew
about that case but also not one that I think would be
productive to visit on this list after so much time had passed--
is why that WG was not told to choose between stopping that
behavior or being shut down.  There was precedent even then for
shutting down WGs that were not doing their work in a way that
was open and productive for the Internet.  That precedent was
not limited to the one instance that had become public and
notorious.

> But on rereading IESG's current guidance, the only thing that
> really bugs me is that they permit frequent online interim
> meetings and that they only consider the current set of WG
> participants' interests, and not so much the interests of
> potential participants from outside the current WG.

Again, that is what that appeal was intended to be about.
Whether the IESG, and, even more the IAB, correctly interpreted
and responded to it that way is a separate question and one very
much tied to my comments and request above.  If that appeal and
response are really tied up with a principle that used to be
important but from which we have drifted away, then back to
Pete's comments.

However, I believe (and it is tied to another one of those
principles) that the appeals process has become deeply flawed
over the years and is tending toward being ineffective.  In
retrospect, our first big mistake was calling them "appeals"
rather than something more like "requests for reconsideration"
or "requests for additional review".   The second may have been
that, perhaps because things were running smoothly and the
community was somewhat exhausted after POISED, there were two
few of them early on and too few since.  The result of
infrequency and some of them being perceived as just annoyances
was that they started being perceived as A Big Deal and at least
some ADs (possibly more as time went on) began to view them as
an attack to be defended against (maybe even for the IAB to
defend the IESG against) rather than a request to think again
about issues, especially issues that had not obviously been
considered the first time.  If we are at a point that leadership
bodies can proudly announce at plenaries that there have been no
appeals as if that were a major accomplishment (the one last
week is certainly not the first time), then we may be passing
the point that appeals are a useful tool for encouraging
reconsideration as surely as recalls (at least beyond the threat
of one) are no longer useful tools to deal with bad behavior by
people the leadership.  Again, referring to Pete's comments,
those are cultural shifts, not things we can (or should try to)
patch by small procedural adjustments and, yes, I personally and
with no disrespect to any individual, especially those who have
been swept along by the tide, I think the shift stinks.

>  I
> continue to believe that IETF needs to facilitate broad
> participation and needs to discourage working groups operating
> as effectively closed clubs, by whatever mechanisms they use
> (including making disparaging remarks about non-regular
> participants who show up at meetings, as I've seen done).
> I don't think that the current set of WG participants are the
> only set of potential participants whose interests need to be
> considered in making scheduling decisions for a WG.  I also
> don't think that mere "discussion" of proposed meetings with
> the responsible AD is adequate, but I expect that in practice
> a WG is unlikely to meet over the AD's objection.

Again, strongly agreed and close to why I started this thread.
As a matter of principle, I don't care whether such discussions
are initiated by the WG Chair or the AD as long as the AD has
ample warning that there might be an issue worth discussing and
that, if they initiate the discussion and/or then either they or
the WG leadership decide to make the discussion and its
conclusions public, that is not considered bad behavior.

Put differently and again drawing closer to the discussion I've
been having with Pete and SM (and them with each other), I think
we used to have broad principles that openness and transparency
about WG actions, discussions, and decisions were in the best
interests of the IETF and a better Internet.  If I'm consistent
with that principle, I have no objections to a WG that consists
only of membership hand-picked by the chairs and meeting in
complete secret... as long as the community is aware that is
going on, and that, if the responsible AD is allowing that
(whether through agreement, indifference, or ignorance), we have
an appeals procedure that works without being seen as an attack
on the IESG. Fortunately, I don't think we have ever had a WG
that extreme (a few design teams notwithstanding) but I'd like
to continue to believe that the principle is well enough
established and agreed that WGs who went even a little bit down
that path could be held accountable to the community.

Finally as the sort of specific example I've been asked to give,
I have seen cases in the last few years in which a document has
gone into IETF LC after the WG reached internal consensus
(occasionally very rough in both senses of that term) but the
shepherd's report has gone to the IESG claiming no significant
dissent or controversy.  If Last Calls or IESG review are to be
meaningful, at least the IESG and preferably the community are
entitled to know what the controversies were and whether those
who dissented or supported an alternate position within the WG
agreed with the solution in the spec (rather than, e.g., being
overwhelmed or dropping out of the WG instead).    Again, the
principle about full and accurate disclosure in those reports
(and a culture that supports it) are important, especially if
the IESG is going to rely on them, but I cannot imagine any
procedure or rule that we could plausibly adopt that would
prevent the problem.

best,
    john