From nobody Fri Oct 1 12:11:38 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471F13A02BB for ; Fri, 1 Oct 2021 12:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q-JT0FYlia4 for ; Fri, 1 Oct 2021 12:11:32 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601DC3A012A for ; Fri, 1 Oct 2021 12:11:32 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id 66so9882154pgc.9 for ; Fri, 01 Oct 2021 12:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FN9I+23JAJRcXXv85KzNBOtdfY9ES/Mpt2Xd4cN/gZU=; b=CNdIQAD6yERWXhvF7lU1TM9whfAWQfZFeu70aYddtIcSShDxEV2jBsa4wnbVZhxwyo i1F+EwjZc8ZtPhLvtcxyIYIqQmrAju3PGRhMN9E/rJCZtt7eUpi/5Nc2LMEbtQjzktf6 fDUDV1Am4Uy+nFuhAjbAZpEodbzs97navb/hSj10rAaK6/Z3Tk3EP12Jzbg+8PksgTG6 Lv3zDpMsde2P+Q9g8osAhhu6naZKYs9+MFXOGfDt8DsHms9Nlx+kuTi9lY7xogJKFVYG SJbE/68IjIybEQV+iZRSB+QJSiiVMotw2qOyeTNXv9t1RhyZELyGdbXZlN/kGWvvixU6 NOLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FN9I+23JAJRcXXv85KzNBOtdfY9ES/Mpt2Xd4cN/gZU=; b=udnRKzq1GFmHs68UYhETlnGaxloVGBfq6FBwIQp17PJ1ncLe3gxLFETPf51hnd2iTl rGOGNmN1iwkwmnMU/FgSxx6g3N2loXFFIkXiXxagBcx/ZcTqoJ2uNWK+yvzsL97yLv9j qZuwOxpNJGdR1slm4yyGQis1UGsBrGObNyGrosLHp8Sq6aHTQn7Jebkqt875gJXbdRax 76kibaE6idYjU0Rkk6Bm7hUKfW3vl4/xeATBHeXhSMHakVJdsLphcUSgz0NwcJD9nia4 1TKiG5i3ml6QbjL7D9Kxe0lvsTyKW8BeuBPodzYhGsqfqNVZ++SFTavRmWvLa0g5z6JW LNjw== X-Gm-Message-State: AOAM5324blYl1nWdFjFWpSBCO5NHPmZDV9Bllpo5A/VPAqmqWJAPPfwf SgyWrqVW0V8qy/CiJKF2QbJxCw3iqxzx+Q== X-Google-Smtp-Source: ABdhPJzhkcWpkbODRQcz+ImOhBnOUuFigpUZnAXPTYL5LP0QOXUHPHireSvXMO0qxBHvcGw0Kvv5pg== X-Received: by 2002:a63:f306:: with SMTP id l6mr10823950pgh.72.1633115491353; Fri, 01 Oct 2021 12:11:31 -0700 (PDT) Received: from ?IPv6:2406:e003:11aa:d701:80b2:5c79:2266:e431? ([2406:e003:11aa:d701:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id z65sm7052371pfc.30.2021.10.01.12.11.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Oct 2021 12:11:30 -0700 (PDT) To: Lars Eggert Cc: gendispatch@ietf.org References: <188353ab-9801-1c4f-2c66-4dd6901912c6@gmail.com> From: Brian E Carpenter Message-ID: <7dd209c2-9c6f-8723-76f4-bafedf86a483@gmail.com> Date: Sat, 2 Oct 2021 08:11:27 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Gendispatch] New Version Notification - draft-eggert-bcp45bis-04.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2021 19:11:36 -0000 On 30-Sep-21 21:52, Lars Eggert wrote: > Hi, > > On 2021-9-30, at 0:52, Brian E Carpenter wrote: >> 1) The current BCP45 states "It also hosts discussions of IETF direction, policy, meetings, and procedures." That has been deleted in the draft, which leaves a gap. > > Most of those topics moved to admin-discuss and the meeting attendees lists. Others are in scope for gendispatch (although I am unsure whether a possibly ephemeral WG should be explicitly named in the BCP). > >> I think that the list of appropriate postings should include something like: >> >> * Discussions of IETF direction, policy, and the standards process in general. >> >> (and perhaps mention that drafts in this area go to GENDISPATCH.) > > I think this may be a little too broad. How about: > > * Discussions of IETF direction, policy, and the standards process > in general, when a more suitable list (such as admin-discuss, > architecture-discuss, a meeting attendees list, or a > process-oriented WG list) cannot be identified. Yes, exactly right. > >> 2) I suggest an extra sentence just after this: >> >>> These topics used to be in scope for the IETF discussion list, but have since moved to dedicated lists: >>> >>> * Last Call discussions of proposed protocol actions now take place on the IETF Last Calls mailing list [LAST-CALLS]. >>> >>> * Discussion of IETF administrative policies now take place on the discussion list for IETF LLC administrative issues [ADMIN-DISCUSS]. >> >> Add: >> >> However, if the discussion is broader than the specific protocol concerned, or than administration as such, it may revert to the IETF discussion list, preferably with an appropriate change of the Subject header. >> >> [For example, if the Last Call discussion identifies a completely separate technical requirement, or if the admin discussion identifies a problem with the standards process.] > > I agree that should be possible. Do you think that with the proposed change above, this would still need to be explicitly called out again? This would be on the "for avoidance of doubt" axis. Personally I am very keen that people should change the Subject when changing the subject, in which case this would not need to be stated. Brian > > Thanks, > Lars > From nobody Fri Oct 1 12:19:54 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D723A05A7 for ; Fri, 1 Oct 2021 12:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1H2X-1RsZ-0V for ; Fri, 1 Oct 2021 12:19:48 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4FC3A059F for ; Fri, 1 Oct 2021 12:19:48 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 5EB063201E28 for ; Fri, 1 Oct 2021 15:19:46 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 01 Oct 2021 15:19:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=i0IwnbeqTGhMPyAz3KS7tvy6VcYiUJ5oMhzlFwFMq qg=; b=TvxkqV98zp9HDetnUvbiJZlxOOWyWVNGdRtSMITvOIX5jWhHVp4M/bgQq y7de1gVtwRr9kQMJe/6wkiqf3bPeYSwN538UNGOh9ofxbk1kqYu+G7UKRDmlar13 4T1h2FzhA0+QkXfJpO4AyZ0Bh2JsEO+Mj0mUyeVvywKYThJS+ZPOCgzdIvR3Ma61 b/LfseRY34+d0vbt7dtUyHSF2P1iYTi0Ccza5Y620cm12CudU1lmD7ni8GHMFbF1 HJyt5C1v3Oi2ovzvPr75dxbfgdCBb7G/zg4BkN3fmT918vIOEC0CkT52X7Ly2h3Z 32MNyUqEfPQd08MLaab61sLJSHhPQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudekiedgudefvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesth ekredttdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvght fihorhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepgeffjefhge evteelueekudefvdeivdekuefhtdeikedvkeetjedvtedvhfeifeeknecuffhomhgrihhn pehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 1 Oct 2021 15:19:45 -0400 (EDT) To: gendispatch@ietf.org References: <163307035459.16292.12035199300248451406@ietfa.amsl.com> From: Keith Moore Message-ID: <0ce85c1a-8896-2428-f75f-6646608aafe3@network-heretics.com> Date: Fri, 1 Oct 2021 15:19:45 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <163307035459.16292.12035199300248451406@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] New Version Notification - draft-eggert-bcp45bis-05.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2021 19:19:53 -0000 I definitely do not think that either the IETF Chair or the IESG should be in the appeals process for SAA actions.   This lets the IESG effectively suppress input that it does not like, for arbitrary reasons, and makes any notions of IETF Consensus extremely dubious. Please consider this objection added to my other several objections to this proposal. Keith On 10/1/21 2:39 AM, internet-drafts@ietf.org wrote: > A new version (-05) has been submitted for draft-eggert-bcp45bis: > https://www.ietf.org/archive/id/draft-eggert-bcp45bis-05.txt > https://www.ietf.org/archive/id/draft-eggert-bcp45bis-05.html > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-eggert-bcp45bis/ > > Diff from previous version: > https://www.ietf.org/rfcdiff?url2=draft-eggert-bcp45bis-05 > > IETF Secretariat. > > From nobody Fri Oct 1 12:31:29 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427C33A077E for ; Fri, 1 Oct 2021 12:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Q_970NvCJJA for ; Fri, 1 Oct 2021 12:31:24 -0700 (PDT) Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D32F53A0776 for ; Fri, 1 Oct 2021 12:31:23 -0700 (PDT) Received: by mail-ua1-f53.google.com with SMTP id k32so7437770uae.2 for ; Fri, 01 Oct 2021 12:31:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AjPpknChBEyfGMIMSxWD3JrbIR1Yc09njpNdb83D4EA=; b=CXdFm/84Wdtf3rK3c5GQ35NGfaOZ8aHN9gwTz+BbJCpwiQNrAsE/g/mZ87nPnR6e2E srnETHfECn0GVAPBbH0jYNGoVGXZAkGKvYTbEckNBV1siG2sI2fBHd1gRJq3K5d1bMn3 iyShsK9Qa1OYY6sMrRkohJhTNiVM9Q721m4i6zuCK1KFke7KaptmMPv1f4aXRhQO8gxM Nfji8OKmHkBEkYACPoCWq9PTy5NzyMWgax5QYmULHyLnVKzkNTFNM8oFhMx9n3ITt1qg wdL3+ObJQVWVuntHvKUOZmzKYL1xV2cj88y+kUiN8LMt1ABj2+X95ik9YQCczO2a6aRJ P5/w== X-Gm-Message-State: AOAM5327v92OgT36DfugW71egu3zdHyJz1EzlLpGadpi5ZLj2RvmJlRg XU+tY3y4nvG6NYNodjK7qYY05812jMJ60WAnehW2CLMw X-Google-Smtp-Source: ABdhPJwPiEZ9vf217r7wWqs22KnACWalJdXOfitts2dTQt80iUYJ1RuYGZz5Z/3SNvOW8Lel2fNhmvlvOR/fNvkPRV4= X-Received: by 2002:ab0:7382:: with SMTP id l2mr3393711uap.94.1633116682752; Fri, 01 Oct 2021 12:31:22 -0700 (PDT) MIME-Version: 1.0 References: <163307035459.16292.12035199300248451406@ietfa.amsl.com> <0ce85c1a-8896-2428-f75f-6646608aafe3@network-heretics.com> In-Reply-To: <0ce85c1a-8896-2428-f75f-6646608aafe3@network-heretics.com> From: Barry Leiba Date: Fri, 1 Oct 2021 15:31:11 -0400 Message-ID: To: Keith Moore Cc: GENDISPATCH List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Gendispatch] New Version Notification - draft-eggert-bcp45bis-05.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2021 19:31:28 -0000 As the one who proposed moving to the normal appeals process, let me support that proposal: 1. If one has a problem with what someone does, one should start there. In this case, ask the SAAs (politely and without assuming they're being evil) to reconsider, and give reasons. 2. One should then move up the chain. In this case, the next step is to ask the one who appointed them -- the IETF Chair -- to review the situation and weigh in. Given that the IETF Chair appoints the SAAs and then steps back and lets them do their jobs, it's reasonable that the IETF Chair has not even been following the specific situation. S/he should be given a chance to resolve it. 3. Continue moving up. The next "up" is the IESG, and then the IAB after that. They're all available, and it makes sense to invoke them in turn, just as for any other decision in the IETF. This does not allow the IESG to suppress anything, because an appeal can still always go to the IAB. 4. The original plan, where the IAB is the only entity to appeal to, gives no mechanism for reasonable review and resolution by the chair or relevant ADs. As I said at the time, a multi-level appeal process is always better than having only one step available. Keith, please tell us why you think the IETF Chair and the IESG should not have a chance to review -- and perhaps support -- an appeal before it goes to the IAB. Given that it *can* still go to the IAB, how does letting the IESG try to resolve it first allow them to suppress input that it doesn't like? Barry On Fri, Oct 1, 2021 at 3:20 PM Keith Moore wrote: > > I definitely do not think that either the IETF Chair or the IESG should > be in the appeals process for SAA actions. This lets the IESG > effectively suppress input that it does not like, for arbitrary reasons, > and makes any notions of IETF Consensus extremely dubious. > > Please consider this objection added to my other several objections to > this proposal. > > Keith > > On 10/1/21 2:39 AM, internet-drafts@ietf.org wrote: > > A new version (-05) has been submitted for draft-eggert-bcp45bis: > > https://www.ietf.org/archive/id/draft-eggert-bcp45bis-05.txt > > https://www.ietf.org/archive/id/draft-eggert-bcp45bis-05.html > > > > > > The IETF datatracker page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-eggert-bcp45bis/ > > > > Diff from previous version: > > https://www.ietf.org/rfcdiff?url2=draft-eggert-bcp45bis-05 > > > > IETF Secretariat. > > > > > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch From nobody Fri Oct 1 13:32:18 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0C33A098A for ; Fri, 1 Oct 2021 13:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAVTNLgEDGSp for ; Fri, 1 Oct 2021 13:32:11 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CE903A0984 for ; Fri, 1 Oct 2021 13:32:10 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 020BB3200E88; Fri, 1 Oct 2021 16:32:07 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 01 Oct 2021 16:32:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=vYGcFO J99VECm61SDqcPPEyV7nLsXkt5VHZK+9gzt1k=; b=D58CIcmrvP8tNaqm9/UqdS ksmNvgPByqehGQJmDIwq9zwenvfkjmYTNMuSoiH4b2Faqldxteen3C/HeIkIGpVK +7F8bxu/e1w+g3nwngBh4me0i8KwaCVolF9WaU4R0FRcghhgbdjT3wihaF2yGb6b oLz/TSZ/kaSonRI0rNfSN0pKvOMRZpc+csmC2/xgsh/DmJJ59cLh7rWRn5SlORiq BOOsU5/eSsNmpeWRnO1aT+R1r+MHv3T2lT/3aarQRGci+FseVflLvnEF9x9F31IB yCD0L9He+9lxxfzOJfGnRx2XVPWXCC/Fq5+fI46wdtPWqDERtt1E0Y8wsDvPB1Tg == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudekiedgudegiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefuvfhfhffkffgfgggjtgesrgdtreertdefjeenucfhrhhomhepmfgvihht hhcuofhoohhrvgcuoehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh eqnecuggftrfgrthhtvghrnhepveefteduieegtdelvddvtddufeejjeffvdefteejieeu lefgtdfggedtffektedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 1 Oct 2021 16:32:07 -0400 (EDT) To: Barry Leiba Cc: GENDISPATCH List References: <163307035459.16292.12035199300248451406@ietfa.amsl.com> <0ce85c1a-8896-2428-f75f-6646608aafe3@network-heretics.com> From: Keith Moore Message-ID: <7bd45391-25cc-7eb4-4081-6eeb46bd3b6c@network-heretics.com> Date: Fri, 1 Oct 2021 16:32:06 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4C3B4BFD3F14B6E49CA5B7CB" Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] New Version Notification - draft-eggert-bcp45bis-05.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2021 20:32:17 -0000 This is a multi-part message in MIME format. --------------4C3B4BFD3F14B6E49CA5B7CB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/1/21 3:31 PM, Barry Leiba wrote: > As the one who proposed moving to the normal appeals process, let me > support that proposal: > > 1. If one has a problem with what someone does, one should start > there. In this case, ask the SAAs (politely and without assuming > they're being evil) to reconsider, and give reasons. Sure.  But the SAAs should also have to justify their reasons for taking action, and there should be some transparency about this. (Admittedly, how to do transparency right for cases like this is tricky.) > 2. One should then move up the chain. In this case, the next step is > to ask the one who appointed them -- the IETF Chair -- to review the > situation and weigh in. Given that the IETF Chair appoints the SAAs > and then steps back and lets them do their jobs, it's reasonable that > the IETF Chair has not even been following the specific situation. > S/he should be given a chance to resolve it. Well I also think the IETF Chair should not be appointing SAAs. > 3. Continue moving up. The next "up" is the IESG, and then the IAB > after that. They're all available, and it makes sense to invoke them > in turn, just as for any other decision in the IETF. This does not > allow the IESG to suppress anything, because an appeal can still > always go to the IAB. Well, except that this can cause lengthy delays should the IETF Chair and IESG want to stonewall.    I think that moderation questions should be settled quickly so as to interfere with the ongoing conversation as little as possible.   For other kinds of appeal, there's often more at stake, and multiple layers of appeal seem more appropriate for those situations. > 4. The original plan, where the IAB is the only entity to appeal to, > gives no mechanism for reasonable review and resolution by the chair > or relevant ADs. As I said at the time, a multi-level appeal process > is always better than having only one step available. I don't see what the role of "chair or relevant ADs" is here, since these are not technical questions, but rather questions of what kinds of speech are permissible.  (Or maybe by "chair" you were referring to a working group chair, but BCP45 is specific to the IETF mailing list.)  A SAA is usually separate from the leadership of a deliberative body precisely to keep the roles distinct - so that the same rules for behavior apply to everyone and the SAA's power can't be used by the leadership to favor one side over another. > Keith, please tell us why you think the IETF Chair and the IESG should > not have a chance to review -- and perhaps support -- an appeal before > it goes to the IAB. Given that it *can* still go to the IAB, how does > letting the IESG try to resolve it first allow them to suppress input > that it doesn't like? Most importantly, I believe that a consensus process inherently requires tolerance of a wide range of input.  It must be possible to air unpopular points-of-view and suggestions without reprisal, and members of the community need to see from others' examples that they can also speak freely without reprisal.  Otherwise an appearance of consensus is meaningless. (Note that I'm /not/ arguing for "free speech" as it's often understood; I think the Guidelines for Conduct are mostly well-written (though the word "professional" is problematically vague), and input to the IETF list needs to fall within the scope of IETF.   But we're trying to engineer and maintain what is collectively the most complex distributed system ever devised by humans, and we absolutely need for participants to be able to point out problems with a proposal no matter whose proposal it is.) The specific problem that I've seen was that in the recent past IETF leadership tried to basically impose an agenda on IETF, impose vague and arbitrary rules without getting community consensus on those rules, and actually discourage community discussion of those rules, and use the SAAs and other mechanisms (like GENDISPATCH itself) to suppress input that opposed that agenda.    And in private conversations with various persons it was clear that they were trying to suppress input from specific people, that they believed those specific people needed to be marginalized. In general, if the people who are making up the rules are also the ones who interpret the rules, those people can impose any constraints on the conversation that they wish, and they can probably do that without any scrutiny.   So I think we need clearer rules that are approved by IETF Consensus (just as other process rules have been), and we need for those rules to be adjudicated separately from IETF technical leadership, and we need for there to be transparency in this process to make sure it's not abused. I remember when IETF was a friendly and welcoming place, when there was a widely-shared value of inclusivity and an often-demonstrated desire to accept input even from difficult individuals as long as those individuals (a) were trying at all to contribute constructively to the discussion (note that opposing a proposal can still be constructive), and (b) knew what they were talking about (technically) or were willing to try to learn. Today, by contrast, IETF is actively hostile to "difficult" individuals... even though this is supposedly done in the name of "inclusion". Every community needs behavior standards (which will necessarily vary from one community to another) and some way of enforcing them.   But you can't make a community more inclusive by trying to marginalize people you don't like, or whose ideas you don't like. Keith --------------4C3B4BFD3F14B6E49CA5B7CB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 10/1/21 3:31 PM, Barry Leiba wrote:

As the one who proposed moving to the normal appeals process, let me
support that proposal:

1. If one has a problem with what someone does, one should start
there.  In this case, ask the SAAs (politely and without assuming
they're being evil) to reconsider, and give reasons.
Sure.  But the SAAs should also have to justify their reasons for taking action, and there should be some transparency about this. 

(Admittedly, how to do transparency right for cases like this is tricky.) 
2. One should then move up the chain.  In this case, the next step is
to ask the one who appointed them -- the IETF Chair -- to review the
situation and weigh in.  Given that the IETF Chair appoints the SAAs
and then steps back and lets them do their jobs, it's reasonable that
the IETF Chair has not even been following the specific situation.
S/he should be given a chance to resolve it.
Well I also think the IETF Chair should not be appointing SAAs. 
3. Continue moving up.  The next "up" is the IESG, and then the IAB
after that.  They're all available, and it makes sense to invoke them
in turn, just as for any other decision in the IETF.  This does not
allow the IESG to suppress anything, because an appeal can still
always go to the IAB.
Well, except that this can cause lengthy delays should the IETF Chair and IESG want to stonewall.    I think that moderation questions should be settled quickly so as to interfere with the ongoing conversation as little as possible.   For other kinds of appeal, there's often more at stake, and multiple layers of appeal seem more appropriate for those situations. 
4. The original plan, where the IAB is the only entity to appeal to,
gives no mechanism for reasonable review and resolution by the chair
or relevant ADs.  As I said at the time, a multi-level appeal process
is always better than having only one step available.
I don't see what the role of "chair or relevant ADs" is here, since these are not technical questions, but rather questions of what kinds of speech are permissible.  (Or maybe by "chair" you were referring to a working group chair, but BCP45 is specific to the IETF mailing list.)  A SAA is usually separate from the leadership of a deliberative body precisely to keep the roles distinct - so that the same rules for behavior apply to everyone and the SAA's power can't be used by the leadership to favor one side over another.
Keith, please tell us why you think the IETF Chair and the IESG should
not have a chance to review -- and perhaps support -- an appeal before
it goes to the IAB.  Given that it *can* still go to the IAB, how does
letting the IESG try to resolve it first allow them to suppress input
that it doesn't like?

Most importantly, I believe that a consensus process inherently requires tolerance of a wide range of input.  It must be possible to air unpopular points-of-view and suggestions without reprisal, and members of the community need to see from others' examples that they can also speak freely without reprisal.  Otherwise an appearance of consensus is meaningless.

(Note that I'm not arguing for "free speech" as it's often understood; I think the Guidelines for Conduct are mostly well-written (though the word "professional" is problematically vague), and input to the IETF list needs to fall within the scope of IETF.   But we're trying to engineer and maintain what is collectively the most complex distributed system ever devised by humans, and we absolutely need for participants to be able to point out problems with a proposal no matter whose proposal it is.)

The specific problem that I've seen was that in the recent past IETF leadership tried to basically impose an agenda on IETF, impose vague and arbitrary rules without getting community consensus on those rules, and actually discourage community discussion of those rules, and use the SAAs and other mechanisms (like GENDISPATCH itself) to suppress input that opposed that agenda.    And in private conversations with various persons it was clear that they were trying to suppress input from specific people, that they believed those specific people needed to be marginalized.

In general, if the people who are making up the rules are also the ones who interpret the rules, those people can impose any constraints on the conversation that they wish, and they can probably do that without any scrutiny.   So I think we need clearer rules that are approved by IETF Consensus (just as other process rules have been), and we need for those rules to be adjudicated separately from IETF technical leadership, and we need for there to be transparency in this process to make sure it's not abused.  

I remember when IETF was a friendly and welcoming place, when there was a widely-shared value of inclusivity and an often-demonstrated desire to accept input even from difficult individuals as long as those individuals (a) were trying at all to contribute constructively to the discussion (note that opposing a proposal can still be constructive), and (b) knew what they were talking about (technically) or were willing to try to learn.   Today, by contrast, IETF is actively hostile to "difficult" individuals... even though this is supposedly done in the name of "inclusion".  

Every community needs behavior standards (which will necessarily vary from one community to another) and some way of enforcing them.   But you can't make a community more inclusive by trying to marginalize people you don't like, or whose ideas you don't like.

Keith


--------------4C3B4BFD3F14B6E49CA5B7CB-- From nobody Mon Oct 4 00:42:10 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6003A121C for ; Mon, 4 Oct 2021 00:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGj2TxkvEtPj for ; Mon, 4 Oct 2021 00:41:51 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D87D3A121A for ; Mon, 4 Oct 2021 00:41:50 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:69b3:c516:5316:3e6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 0765A600354; Mon, 4 Oct 2021 10:41:38 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1633333299; bh=+6P/HtdGAMtR1ucoMQMKKOhFs3od/rB+2ljFvdsplh0=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=BEpS4lc4pQ6maQWBbyaudNPKDc1IYs9mP9i7P6r4V0BnJFfVlpVQ90RRRyh2jyO4T HmpB5c+/qOuJO6Cp68iCw+1IHwwSca29wiT7f6TRS+xmoiwiCpRkEsxqT11BmAirRL qpP2zdwzg9Rv7RkvlWQ0M9W8DW8kS3+GQt+H8iHk= From: Lars Eggert Message-Id: <6188E7DA-B137-4537-B9E9-DFEC1D3EFB9A@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_32DF168E-6DDD-423A-9261-EC09A4869D2C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Mon, 4 Oct 2021 10:41:35 +0300 In-Reply-To: <7dd209c2-9c6f-8723-76f4-bafedf86a483@gmail.com> Cc: gendispatch@ietf.org To: Brian E Carpenter References: <188353ab-9801-1c4f-2c66-4dd6901912c6@gmail.com> <7dd209c2-9c6f-8723-76f4-bafedf86a483@gmail.com> X-MailScanner-ID: 0765A600354.AF1CF X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Gendispatch] New Version Notification - draft-eggert-bcp45bis-04.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2021 07:42:02 -0000 --Apple-Mail=_32DF168E-6DDD-423A-9261-EC09A4869D2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2021-10-1, at 22:11, Brian E Carpenter = wrote: > Yes, exactly right. with some wording tweaks: https://github.com/larseggert/bcp45bis/pull/10 Thanks, Lars --Apple-Mail=_32DF168E-6DDD-423A-9261-EC09A4869D2C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmFasC8ACgkQVLXDCb9w wVdeEBAAmOqimPxZlnGFTtFcvh94fPgCAMHKL5MsLrCn4R1wdmcjTxcYfJwD2+x4 ayMz9k91Ohs8vMOy9BR+SqCiGc+yz4p2/2J1/Cgx4pEHG7dmXa8FW+FvFEY+6xH9 ge/OrNgtTWhdVWhQNN13RlthCh3qg9DWp/DziOoMGLAUUEvAwcrnyDB2IecTQB+D 509dq+j3ScAq/m2Ouh+TrakrVHIS+UNOgMgeYmpmXSqN9b1Tm9efKNbJEY79ep0w WyG6Q6y7rfYi0BncTUfzTTHGZcs3PsjWhFfCfiduKjcpLHe5zVWHda8zm/iQiON3 HKh21UKb1yKn2ivWHC3I4rQ1+DgqRFXNWi2ady2kUTUwpdwCX3F4yseIcbR5OH2p SX2iXaFXyTAEgFr5/qvOlfkxvZdVOpQk0bKqVc3MXLRLq9Sly9+o456iG07ysiq/ tzeB9Se2qN+q+ufgwxF+zyHJH6tvOkpjRcBsLCc/XWaRGcxZuaIKm6v5DX+o85KP nM0pXw/3N3P3b+tVoHu+CtN5PD6Ch/IySidw/fQ7zHw1lsVs46/hQfnpTEBbjxrr NfMokJi20LioKFf55zMb7rtc6Kkt22ptfOOCZjJk5UzNUN8zxV524xLoHz/WjcB3 8AJFpud3uU/z2oocNfQ+54TZ/dprP3fEbMqVs6JKpVRoZSLHhDY= =jxys -----END PGP SIGNATURE----- --Apple-Mail=_32DF168E-6DDD-423A-9261-EC09A4869D2C-- From nobody Mon Oct 11 00:39:33 2021 Return-Path: X-Original-To: gendispatch@ietf.org Delivered-To: gendispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A63DC3A05F0; Mon, 11 Oct 2021 00:39:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163393797066.7298.8506459471346666425@ietfa.amsl.com> Date: Mon, 11 Oct 2021 00:39:30 -0700 Archived-At: Subject: [Gendispatch] New Version Notification - draft-eggert-bcp45bis-06.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2021 07:39:31 -0000 A new version (-06) has been submitted for draft-eggert-bcp45bis: https://www.ietf.org/archive/id/draft-eggert-bcp45bis-06.txt https://www.ietf.org/archive/id/draft-eggert-bcp45bis-06.html The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-eggert-bcp45bis/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-eggert-bcp45bis-06 IETF Secretariat. From nobody Tue Oct 12 01:00:28 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECCC3A0803; Tue, 12 Oct 2021 01:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.612, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Re1kvCdRJTmr; Tue, 12 Oct 2021 01:00:21 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110096.outbound.protection.outlook.com [40.107.11.96]) (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 ECBDF3A0774; Tue, 12 Oct 2021 01:00:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g97vnee8hkaEYV8LLYXnjlQ3yZjoA6zKRTRipTsX5PYmQP9juTRvnE2cL9PiohX5y93EDqJ12Rsa8uAQihdd/WBP/S8ifxdhfj8F2HLyK9R2TwA1TUptBx4WB3ubhQBs2Yq56hasubzka5ItaA6aqbfpebcEJTsvV/M7XoRfifsjPQ/v6ifZlo/zyEweRAz+1qGX/54Z28UVx0JX+Zzg52seF7/f48lW0YIWIqHcyk6zdiC0/JF2tMimy/65jOAtnv+IHhb8PmF4Ijqb2spzBeHJMPumr+ucF6gMJJZwwV035SD++JREhP6mqaUavC/H6FRHl+vE9YiP/9Ri6OG6ag== 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=qDTYHEf3MR4htFS35yGGe/WFKpdOgkczoXtQmv51el4=; b=aoAhJ2o+s/3yGphV7h0nGDmNQwvw2r0GQseK0IS2sRR4EzIJRuvj0vC5HzBldEmDeGTjICLLYtqU5GWlD9srYaHCzTuNFDevuU0+WgkATtjqL7ySqnIfweByDrJnSBD3OGgFGsfZWpFNB0hu/xewd0Xh4gJ/FTr2cv/Z1HWiD0pjij51G7y3SpcWLtwEwLzOGSSOJMJi1snCeB250gFsb5iCP5AGzkemIHHegZQX314+4yafUoql25ULtsEjeawLLEJZMd/EWHy+Wp1KpoRUt1gExvBOiNThZ6LGANzaYVLjWdqmAeA+fb1TEAeJwtgP9Ny2QAfqaQglTjl1JcTaGA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qDTYHEf3MR4htFS35yGGe/WFKpdOgkczoXtQmv51el4=; b=AseFe2uC6QlZLHfrt3B7Rcaz9QVPQGFpxuZzS9F2qXLXWN+2aLlnTyuPMJfZVMhF8e6y0RQExfXjtk3wL5ajN5CNwlP+9iWboZ6lMVWZmbncMPOjcoTze5TkhUfcRmGEdCSOlOoTLOEJwMiYuN861/I4OAzWmRwIMC9xC3UJkWK90CxnIwpBrA/Ugt+IBKJwspV8bTPbcabPryZ9pbQLo76TWbNl4Yvx8P3wxCNv0XLEErxKVSLI4CdVTyG2mQ2k7JMdHCmEpy2DS1YGpD1DaH+ijr1/Z2uxFikijDYmy9kkDUG15oBXk5x/6/ETPDeotn0KTk6yFGOBRmcofdp4kA== Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:12c::10) by LO4P123MB5026.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1f1::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.24; Tue, 12 Oct 2021 08:00:12 +0000 Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::f89f:8437:f410:9be9]) by LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::f89f:8437:f410:9be9%5]) with mapi id 15.20.4587.026; Tue, 12 Oct 2021 08:00:12 +0000 From: Kirsty P To: GENDISPATCH List CC: "gendispatch-chairs@ietf.org" Thread-Topic: GENDISPATCH charter update Thread-Index: AQHXvsTRJxFGMCM9hE+gYFTGYLKo1w== Date: Mon, 11 Oct 2021 17:32:29 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: b19a559f-a3ca-7e6c-4d4e-d26d1981bdc6 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ncsc.gov.uk; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6e6807e6-4808-4764-c940-08d98d5651a3 x-ms-traffictypediagnostic: LO4P123MB5026: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QiZSKP5+S/bNvumPMhPM65qvwFdoHCiBdemdunLcKGhYOVjk08fNBmc1yrGxxN1gAy0yJHy3XjuYhcG4E1uVfQOmzfAifegkDThC8D1pRGuB6Lc5Ot3pfSJJ38unXL/muW4r6P803h3l9qt0NB1uGpY08akz1kGkA6pmV1bbWC4IcnYzopOtWKxzxVzwrQoTU+ABn31QGgoZiFzlQ/X0lt+Am52rfCvSbPD3yfhIuX+9VD4mvyNTGALdgowqCIghuGCRqePsnx3MrrbbV5wJcM9H4IosV67q7t7bOacsPXOGTbmNREtYbLMtfMxly/r5YoOYkU71j1TgMOoR6eGro+ZcvYHCWbQ09wXO60t1xeeBXIPcxS3l7t2il5E3aj0w76AT2SgRT+5LTBmKjotuO0a611WNMlV4Xuxh3YrAKNyZBJYCvyjncecLODQgXDYeW1cejffzMbV0vYIxWvJhvBHUuXH3r+SEnHtD20uJPRmTc3lxn5VRjjs6gMFX6+CcxfQ7ACDX09TfSl6rJXqgX2g5c+KzpqdbdCzqRl78t734AUeK50+3dDCfgiQHjzkeMuYz9AfBGtr8iIiSyYft2BSnWGKkNRrOV8dhxslHEWMCMjH5eYpN2xTpRoJ5b8B62V4oktWTEUiHWumUB4gVskdNqhVkl4Gk2Hx8HAl9zFlamXg++UHETUnKnSikkt/MLv6PL7bkX8AD9WcOKo0d+bIBFmkSf0vj2qfQtfJFfXoyjf6ZSuQD1W9Ao+JALvvBGy9Xdf12D7vHjMvX8WwaeQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(4744005)(19627235002)(33656002)(186003)(8936002)(4326008)(83380400001)(26005)(19627405001)(8676002)(52536014)(7696005)(316002)(450100002)(6506007)(86362001)(3480700007)(7116003)(122000001)(55016002)(6916009)(508600001)(2906002)(966005)(5660300002)(76116006)(66556008)(64756008)(66946007)(9686003)(15650500001)(6666004)(71200400001)(38100700002)(38070700005)(66476007)(66446008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?vHh+USZ6SCk2Ar9lMlw3DEQ+euW8RfQ7u4uCxqeCYcgTmj5fRdqHuqrxWa?= =?iso-8859-1?Q?9wDg5trC49V8MPgq31Odmcp/rGnS63bqa7+HNHdDSTS1YGqC1v5eln5zdP?= =?iso-8859-1?Q?Uw1fK/FKqTsluLH59JRNqulZ6m5TAT0UML6fRxYILL3FO9iZCIL6qD3igs?= =?iso-8859-1?Q?3d6zfSjBiENMxsvC8uu/TDfHSXH7X6awvrWRGdzo//fy1SILykZaFYT7zn?= =?iso-8859-1?Q?mwzNd4WHajGOHGnXx+OVgKf0glm2ujyDbxt+6xs9GAw2hqsoxPb2af3NmB?= =?iso-8859-1?Q?p5V0rWcmYq61To96joCAqx2RTXXoy/yT+nra/qYm/uuFKKz34xTAsFD8T1?= =?iso-8859-1?Q?3M1vFrBlVT84Kj2KCcplURo7r6j/XsBht/m4DE7rue6y006CTNj1a+K06G?= =?iso-8859-1?Q?H7teGSA9uoNrcILDW17JlIIjQQ6RCA45ArI7ln6CXaToYnqlQFX9HyWh1Q?= =?iso-8859-1?Q?FKITGgq6wLVnOUUMBzIk73M+4xYErp5TqtyrUvhgX5r5rcloB4XwGwzg+A?= =?iso-8859-1?Q?gaBsI1XDJLLe5kqIiYxE5C+05OTnKl2gYlTWe0DE8PvCQufkKQnu8ivfmb?= =?iso-8859-1?Q?kCDUsW3gzyoeerOyAXM+si5WZcLJabkbLvChEOC706u1VyTEgn8n9incI4?= =?iso-8859-1?Q?Bkd5bLmX1egW0mll9uto7oOZIFISUBO7EVKcTIHPX9pZiSgUjGPMFSMfbg?= =?iso-8859-1?Q?gD9kWxr4v6/pyYSkOMPqGV9OiKbzy+hkcEE/O22Lrr6/zQw9VXDCMG3xyk?= =?iso-8859-1?Q?8o2/wZH5k282o0purU4RxolTwM0rRp+6mN/O8kYRTvcRuBOGZETulFMtV7?= =?iso-8859-1?Q?YBuc1ei0EstEW9WCdgwXQbAy1oQausCGh2RmxvxvWK8MB1SwqovEtAx9gZ?= =?iso-8859-1?Q?1foUdCk8WLMgQ4zWDRfTQ1AeMG6OYZBE/lTlLVH8+b2+AB/asKiHF6UDae?= =?iso-8859-1?Q?dgiA2aVezFLIlsH8P4aNbmHWLbeWOhE6sL9II+PD/2xP7uV33JXvjH/fil?= =?iso-8859-1?Q?mGiUFxGASbl1gx/qgDJAsS9iwlR2zKz1tA6cixsuv5GUI65DepT1F0h6NQ?= =?iso-8859-1?Q?hhLDD6Nfdi57nQDOHATPVeVbVExMHL0S7oVMcmi0cot5myEHoi6c3ASFPc?= =?iso-8859-1?Q?v9f6EHB6llttZ3Hh6PK0d/98dOYDF11PqTr1TgQ/gbQZz5U69gvkhLu3z8?= =?iso-8859-1?Q?4oU/XR2OL6wW6d9geROUp5oDiIQZVCReaeGIwgMFqM5t++Hh0r6YPBNgZe?= =?iso-8859-1?Q?+EfGcLai3sn5X653MvgUWnJkYe6/AiM4I4TEMkWaqkhSRHLrJ8iaI2tP6q?= =?iso-8859-1?Q?yyzx/8wX7A89y1teOdtdgCS5SU2h47Gc587DNJp1KYHusggeyhJIxwtb7Z?= =?iso-8859-1?Q?VkbsjMq9rC?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P123MB359972A0C20111F8D83D0333D7B59LO2P123MB3599GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 6e6807e6-4808-4764-c940-08d98d5651a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2021 08:00:12.5206 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 56CCEIJpNibky8dNwmPHTrPCxwbLD7yiOSv6C+olPbeGWiQIRfoiUT83uwFB7opR7csHaqSIzrzTFEaIo1QoWQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO4P123MB5026 Archived-At: Subject: [Gendispatch] GENDISPATCH charter update X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2021 08:00:27 -0000 --_000_LO2P123MB359972A0C20111F8D83D0333D7B59LO2P123MB3599GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi GENDISPATCH, We've made minor updates to the GENDISPATCH charter, following the group's = review at IETF 111 in July. You can see the new charter here: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/01-00/ And for comparison, the old charter is here: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/01/ For info, Pete, Lars and I are all happy with the updates - but please do g= et in touch with the chairs if you have feedback (positive, negative or neu= tral) or would like to see other changes. Kirsty (gendispatch co-chair) This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB359972A0C20111F8D83D0333D7B59LO2P123MB3599GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi GENDISPATCH,

We've made minor updates to the GENDISPATCH charter, following the group's = review at IETF 111 in July. You can see the new charter here:
https://datatracker.ietf.org/doc/charter-ietf-gendispatch/01-00/
And for comparison, the old charter is here:
https://datatracker.ietf.org/doc/charter-ietf-gendispatch/01/

For info, Pete, Lars and I are all happy with the updates - but please do g= et in touch with the chairs if you have feedback (positive, negative or neu= tral) or would like to see other changes.

Kirsty (gendispatch co-chair)




This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB359972A0C20111F8D83D0333D7B59LO2P123MB3599GBRP_-- From nobody Tue Oct 12 03:16:34 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8473A0DB2 for ; Tue, 12 Oct 2021 03:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=3rV+5zcY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XOUBrG84 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHC5QC1PS3D6 for ; Tue, 12 Oct 2021 03:16:28 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085FD3A088F for ; Tue, 12 Oct 2021 03:16:27 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 9670F32008FB for ; Tue, 12 Oct 2021 06:16:27 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Tue, 12 Oct 2021 06:16:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=f/N4INs CWCciR9wp1nTwuiaMC8ViMJBJ12z65jxZbRs=; b=3rV+5zcY7V3F162A73p4wyG zZOLYA+GeuaLdr9LBicRrkjHDhOwU3HiekggQksV0AkTkgvXxV7713cPKdKc4XB2 rL1SQtiBFjVOFJanmQVAhumUtio8DGQpHYcPWLWP2LHRsi8odLFc/pSNhE4BOCeZ umOs8HtZ9Jtd9wQjMYciRIOiyOKoHUWhv2tujZfaUEJJUh3Ie6FALWs+TcySM6/7 d1rWK3fKKsIF6UV/gS1SpoWMKL7seOUmX7srAC/+9zfSBM6vBS9KGGlDpPHxHW8U uLZF7/fMXkorMJBzczl5oesxXjTNjVytGgqwYPt7VghpZ2tjnpDabSqm/rCrFww= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=f/N4IN sCWCciR9wp1nTwuiaMC8ViMJBJ12z65jxZbRs=; b=XOUBrG84pA48P1ZRWP41oY VIw+Y69CAxerfJWN/cEofRAVK/2gedmIzS19AylzTdvOiTRXXN1zKP+YPPEGJaWE zy/inldB7OaQgt8yggbzv2UymBDhdxKsRbp4apHv01I/o20/gW2DjjcEw6Rn51Dg mA8Nz89u3eHN2CiedoCrlDkCA/yRnkqbQ6rEI1zW6obk7mHa2IvfOy2Hi1GVb1fU pnPfyInLCvshAbKWBYPiYZUDl+iOEjK9xXKMTAvvMWwdVa5NADbfVP4zRS6f3otS VJeA8NyvugYclva9tKFe2mpkAIQHqyCzeZ5j3iieLiryts1b6+tAUj4iLShHg4+w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddtkedgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeffvdekfeegle eiueettddtffehveevffefkeduvddttdekiefgjeduvdfhvdduleenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 11DC2AC0380; Tue, 12 Oct 2021 06:16:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1345-g8441cd7852-fm-20211006.001-g8441cd78 Mime-Version: 1.0 Message-Id: <894c7b52-79b9-4392-80cc-1061edff4730@dogfood.fastmail.com> In-Reply-To: References: Date: Tue, 12 Oct 2021 21:16:06 +1100 From: "Bron Gondwana" To: gendispatch@ietf.org Content-Type: multipart/alternative; boundary=79e186b5414641fb92aa927921987846 Archived-At: Subject: Re: [Gendispatch] GENDISPATCH charter update X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2021 10:16:33 -0000 --79e186b5414641fb92aa927921987846 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable I've just read through the diff, and it looks good to me - tightening up= the language and allowing for dispatch to additional places appear to b= e the substantive changes. Cheers, Bron. On Tue, Oct 12, 2021, at 04:32, Kirsty P wrote: > Hi GENDISPATCH, >=20 > We've made minor updates to the GENDISPATCH charter, following the gro= up's review at IETF 111 in July. You can see the new charter here: > https://datatracker.ietf.org/doc/charter-ietf-gendispatch/01-00/ >=20 > And for comparison, the old charter is here: > https://datatracker.ietf.org/doc/charter-ietf-gendispatch/01/ >=20 > For info, Pete, Lars and I are all happy with the updates - but please= do get in touch with the chairs if you have feedback (positive, negativ= e or neutral) or would like to see other changes. >=20 >=20 > Kirsty (gendispatch co-chair) >=20 >=20 >=20 >=20 > This information is exempt under the Freedom of Information Act 2000 (= FOIA) and may be exempt under other UK information legislation. Refer an= y FOIA queries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copy= right =C2=A9=20 > --=20 > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch >=20 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --79e186b5414641fb92aa927921987846 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
I've just read through the diff, and it looks good to= me - tightening up the language and allowing for dispatch to additional= places appear to be the substantive changes.

Cheers,
=

Bron.

<= div>On Tue, Oct 12, 2021, at 04:32, Kirsty P wrote:
Hi GENDISPATCH,

We've made minor updates to the GENDISPATCH charter, following t= he group's review at IETF 111 in July. You can see the new charter here:=
https://dat= atracker.ietf.org/doc/charter-ietf-gendispatch/01-00/

= And for comparison, the old charter is here:
https://datatracker.ietf.org/doc/charte= r-ietf-gendispatch/01/

= For info, Pete, Lars and I are all happy with the updates - but please d= o get in touch with the chairs if you have feedback (positive, negative = or neutral) or would like to see other changes.


Kirsty (gendispatch= co-chair)
<= br>



This information is= exempt under the Freedom of Information Act 2000 (FOIA) and may be exem= pt under other UK information legislation. Refer any FOIA queries to ncs= cinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =C2=A9
-- 
Gendispatch mailing list
<= div>https:= //www.ietf.org/mailman/listinfo/gendispatch

=

--
&= nbsp; Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com

--79e186b5414641fb92aa927921987846-- From nobody Fri Oct 15 08:37:12 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F003A07DE for ; Fri, 15 Oct 2021 08:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEfWLFrjNeuY for ; Fri, 15 Oct 2021 08:37:06 -0700 (PDT) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1CC13A07E6 for ; Fri, 15 Oct 2021 08:37:06 -0700 (PDT) Received: by mail-ua1-x92a.google.com with SMTP id i15so18923621uap.0 for ; Fri, 15 Oct 2021 08:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=atFtBuogK2ReTvwbElNezK0b6s0JyustaCcUD+Im9PA=; b=JCK1+rqyFW/murB/EjcNT1VMx4POviXacBZm/OOFeOP9o2LMBfmKHAZyRtQBxoMPNS lhSLFhZr517NPfgNrsGUqxAqApK6dZKCHlxIdjsRuFP4ifHyKRiGWmzemdwgbtw7sSBP 9ghrTr0iEZ+281fVgb+2mNI/xP2PylSkPVMv6dy2Rtgd2dBr7lr+lw7BxFtaPpJ38BdR r5agXdTi66AZB6ixrmgVHkwHjY227zhqibF9+3qv0LhE2MZMVJ9gYJMzeZrPhu0oIyzn WVm/dnL/bd0PHIUIgggdVV72wxQy5ckZJRP+YtcygS0So2AhXYPc1xDtXCIj3oOlE91q vZcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=atFtBuogK2ReTvwbElNezK0b6s0JyustaCcUD+Im9PA=; b=LHiiZtwVmbcpvCX/bNNw4GFOd6BYVbwvu/YaXR+b6luYKZlEU6MOAme7uGwhfNrYpH 40a+Qc9Pfz/RTd/4ndp61LozFz9ZHw1FuXRaEYx55btlaSnvl6XP6TXqUdXqmfkrBU6i 7AzG+ZYIk8cgMUiuob26CF3uu4XxIDxpudiA623TynrlYG3xKHdA96eH79KixyHrrlkb oudry0aXKP09oPsgO9ZH4TPXhubRXZ8IHjZfI+yWsHQEvYUV4hfo+bBLv4GEOqHvjttV ZvZnKz+RI21T+AFXmdl2GvF9Oiy0oTFQO2cpJBaqn7OystC2a+Lg9WOnpPZkMWitwyFE 38ow== X-Gm-Message-State: AOAM532o6rsVgvbYIDBZ1xlPn1CSjGCKQ99ELB5ZSSDOxeYGVVxtqvJl LR7n9pVuSxj+S7/wlfN9suNmIfjDCuPM4e/vr6Szd8Us16LFzQ== X-Google-Smtp-Source: ABdhPJwIF2gmYR6broBEvTf5cYOjaxG8/5k+yvwlqInjVV5rurQW2x8+f3FWSuuKfYcryE/l1XjnzbFg/RvT+CKOtmI= X-Received: by 2002:a67:c088:: with SMTP id x8mr14110932vsi.45.1634312225142; Fri, 15 Oct 2021 08:37:05 -0700 (PDT) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Fri, 15 Oct 2021 08:36:54 -0700 Message-ID: To: gendispatch@ietf.org Cc: Erik Kline Content-Type: multipart/alternative; boundary="000000000000a1b95f05ce65f771" Archived-At: Subject: [Gendispatch] BCP97bis X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 15:37:11 -0000 --000000000000a1b95f05ce65f771 Content-Type: text/plain; charset="UTF-8" Colleagues, I've got a draft that seeks to update BCP 97, which is the guidance around how we handle normative downward references. It's currently made up of three separate RFCs and an erratum, so this will consolidate those into a single document. The main mission here, though, is to update the guidance around normative references to external documents, especially those behind paywalls. The draft is being sponsored by Erik Kline and can be found in the datatracker here: https://datatracker.ietf.org/doc/draft-kucherawy-bcp97bis/ As GENDISPATCH is an important discussion venue for process changes, I wanted to let this audience know of this work in progress and invite feedback, but this isn't the place for discussion since the actual "dispatch" question isn't on the table. So if there is any feedback, please bring it to my attention, or to Erik's, or start a thread on ietf@ietf.org. I imagine if there's no feedback or if people are generally happy with it as-is, we can initiate Last Call before IETF 112 begins next month. Thanks, -MSK, ART AD --000000000000a1b95f05ce65f771 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Colleagues,

I've got a d= raft that seeks to update BCP 97, which is the guidance around how we handl= e normative downward references.=C2=A0 It's currently made up of three = separate RFCs and an erratum, so this will consolidate those into a single = document.=C2=A0 The main mission here, though, is to update the guidance ar= ound normative references to external documents, especially those behind pa= ywalls.

The draft is being sponsored by Erik K= line and can be found in the datatracker here:

As GENDIS= PATCH is an important discussion venue for process changes, I wanted to let= this audience know of this work in progress and invite feedback, but this = isn't the place for discussion since the actual "dispatch" qu= estion isn't on the table.=C2=A0 So if there is any feedback, please br= ing it to my attention, or to Erik's, or start a thread on ietf@ietf.org.=C2=A0 I imagine i= f there's no feedback or if people are generally happy with it as-is, w= e can initiate Last Call before IETF 112 begins next month.

<= /div>
Thanks,

-MSK, ART AD
--000000000000a1b95f05ce65f771-- From nobody Fri Oct 15 15:41:58 2021 Return-Path: X-Original-To: gendispatch@ietf.org Delivered-To: gendispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87CD03A0DDD; Fri, 15 Oct 2021 15:34:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: gendispatch@ietf.org, lars@eggert.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163433724154.17026.14003820384793099154@ietfa.amsl.com> Date: Fri, 15 Oct 2021 15:34:01 -0700 Archived-At: Subject: [Gendispatch] gendispatch - Requested session has been scheduled for IETF 112 X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 22:34:16 -0000 Dear Kirsty Paine, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. gendispatch Session 1 (2:00 requested) Monday, 8 November 2021, Session III 1600-1800 Room Name: Room 2 size: 502 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/112/sessions/gendispatch.ics Request Information: --------------------------------------------------------- Working Group Name: General Area Dispatch Area Name: General Area Session Requester: Kirsty Paine Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 150 Conflicts to Avoid: People who must be present: Kirsty Paine Lars Eggert Pete Resnick Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Oct 19 08:10:49 2021 Return-Path: X-Original-To: gendispatch@ietf.org Delivered-To: gendispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 794253A0A41; Tue, 19 Oct 2021 08:10:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "DraftTracker Mail System" To: Cc: gendispatch@ietf.org, rwilton@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163465624430.17777.13766157144325532494@ietfa.amsl.com> Date: Tue, 19 Oct 2021 08:10:44 -0700 Archived-At: Subject: [Gendispatch] Last Call: X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2021 15:10:45 -0000 Last Call Request has been submitted for https://datatracker.ietf.org/doc/draft-eggert-bcp45bis/ From nobody Tue Oct 19 08:12:42 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5DF3A0A21 for ; Tue, 19 Oct 2021 08:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.9 X-Spam-Level: X-Spam-Status: No, score=-11.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=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=kMgDEMnv; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tdQkKz/K Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGRMhLksStQJ for ; Tue, 19 Oct 2021 08:12:35 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 459843A0A62 for ; Tue, 19 Oct 2021 08:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1181; q=dns/txt; s=iport; t=1634656355; x=1635865955; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=8M5uoWBOik0byqn06yk69ExcEFewbXkPv1IsV6EEOrg=; b=kMgDEMnvVumcgmxt6M5S0Dcc7/+Hv/JPNUiElyXm+MVpBZpT7WYxjFWU taB5Wx6X3GhbUGCwOSew7RxjTyxU5mfO8yO+yzRKXrVS39KXrSw1UKIc7 aVwN3ELVxuhepSAF9WJOa1HGQRSYfo0f1ULTVTIm85XfxDTmB1wjJoCKe M=; IronPort-PHdr: =?us-ascii?q?A9a23=3AM1cuuR+lS+AQWP9uWDnoyV9kXcBvk7T5IgBT7?= =?us-ascii?q?YAo2PpCcaWmqpLlOkGXpfBgl0TAUoiT7fVYw/HXvKbtVS1lg96BvXkOfYYKW?= =?us-ascii?q?0oDjsMbzA0tHMDDDlf0f7bmaiUgF5FEU1lot3iwLUlSHpP4YFvf6n2/5DIfA?= =?us-ascii?q?FPxLw1wc+/0AYXVyc+w0rPaxg=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3ANE/32aMF4QXkl6/vrR2+lcFynXyQoLVcMsEvi?= =?us-ascii?q?/4bfWQNrUoi0jJVmmYWUGiDaffeazD8fYsjOYTgo09X68OExtNnHXM5pCpnJ?= =?us-ascii?q?55oRWUpJjg4wn8dtEp+F+WbJK5cx5hYOoaowPwcFCeG/071a+m58RGQ6InRL?= =?us-ascii?q?lbCIL+cUsxObVcMpBcJ0XqPqsZh6mJaqYHR7zCl4bsel/bi1GqNgFaYBI67B?= =?us-ascii?q?5Wr83uDtNyq0N8RU8dXifpj5DcynFFNZH4TyD3YEpf2fmVUNrbSq+fr1rq1+?= =?us-ascii?q?CbS+A0gT4r81L36aUYNBLXVOGBiiFIPBPPk2UcE93d0i/pkXBYfQR8/ZzGhh?= =?us-ascii?q?c9wzMlKs7S7SBwiOevHn+F1vxxwQn0uY/QbqO+WSZS4mYnJp6HcSFPjzvNiD?= =?us-ascii?q?VouNJET+s52DH1As/sCJ1gwgrqr7w6t6KiwRu8pjcM5IYyyZcUUu2prynfSC?= =?us-ascii?q?vNOfHwKeI2Sjfcw4dv6rpkm8S7iWvck?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A9PM3maG2vxk0bQzcpLqFXZHXdLJyesId70?= =?us-ascii?q?hD6qkvc31om52j+fxGws516fatskdqZJhSo6H8BEDmewKSyXcV2/hcAV7GZm?= =?us-ascii?q?nbUQSTXflfBOfZsljd8k7Fh6BgPMVbAtND4bTLZDAQ56uXkWrIcerIq+P3l5?= =?us-ascii?q?xA8N2utkuFOjsaDZ2IgT0JbjqzIwlTfk1rFJA5HJ2T6o5svDy7Y0kaacy9Gz?= =?us-ascii?q?0sQ/XDj8ejruOmXTc2QzocrCWehzKh77D3VzKC2A0Fbj9JybA+tUDYjg3C4L?= =?us-ascii?q?m5uf3T8G6d64aT1eUUpDLS8KoHOCW+sLlQFtwqsHfuWG1VYczBgNnympDo1L?= =?us-ascii?q?9lqqiUn/5qBbUO15qYRBDLnfKq4Xi57N7rgEWSk2NxRhDY0JfErXsBerR8rJ?= =?us-ascii?q?McfR3D50U6utZglKpNwmKCrpJSSQjNhSLn+rHzJllXf2eP0AwfeNQo/jViuE?= =?us-ascii?q?olGc1shJ1a+FkQHIYLHSr85oxiGO5yDNvE7PITdV+BdXjWsmRm3dTpBx0Ib1?= =?us-ascii?q?27a1lHvtbQ3yldnXh/wUddzMsDnm0Y/JZ4T5Vf/ezLPqlhibkLRM4LaqB2Av?= =?us-ascii?q?sHXKKMeyfwaAOJNHjXLUXsFakBNX6Io5nr4K8t7OXvY5AMxItaouW3bLqZjx?= =?us-ascii?q?9HR6vKM7zC4HRmyGG8fIyNZ0WZ9igF3ekJhlTVfsuZDRG+?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DgBgAS325h/5NdJa1agQmBWYFRKSg?= =?us-ascii?q?HgVE3MYgOA4U5hWidGoEugSUDVAsBAQENAQFBBAEBhQACgk0CJTQJDgECBAE?= =?us-ascii?q?BARIBAQUBAQECAQYEgREThWgNhlsoBgEBLAwRAT5CJgEEGwwOhSUDLwGhFwG?= =?us-ascii?q?BOgKKH3iBM4EBgggBAQYEBIUKGII1CYE6gwaLNxyBSUSBWIdsg02CLo1yBDK?= =?us-ascii?q?BZIElD5IIrBoKgzGfEhSDaqMylguCPp4yhQUCBAIEBQIOAQEGgWE7K4EucBU?= =?us-ascii?q?7gmlRGQ+PRgEJgkKKXnQ4AgYLAQEDCY9+AQE?= X-IronPort-AV: E=Sophos;i="5.87,164,1631577600"; d="scan'208";a="948615889" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Oct 2021 15:12:34 +0000 Received: from mail.cisco.com (xbe-rcd-007.cisco.com [173.37.102.22]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 19JFCXpN004170 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Tue, 19 Oct 2021 15:12:33 GMT Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xbe-rcd-007.cisco.com (173.37.102.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 19 Oct 2021 10:12:33 -0500 Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 19 Oct 2021 11:12:32 -0400 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Tue, 19 Oct 2021 11:12:32 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oJTxjXaeUEZ8AtJZ8/RK0ti1/wANKaARpYpYIZfNke7gHRRiMo7BrpxMrQ0o8qbjbOajGukAiyo+q79HAr60P6xegq525T9Iwg5lcyMupQyAN/USqxher0TltItTxGT6yCKvEi7steOtRZr15mTbTq/2wEbFJp2+2iS4DacO0qlzwcVeS+r1K+jvoxcR+hCzX8RX6invTf462NFr60CMmCHpNMazRxZRSrCaJDmi30byyB5O7lkXp4BpFwIm8x5+T5+kpV6I2Z0a0W1BAJGb0DzuZqu5xoWfZpLkZhKyTt8DJPzZyuFpbaVgl3nOEo3xPGq8JWzZeePeH8RjcybyVQ== 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=LkpBrayjS/5UboDJyb56OuwJvd2WBenDBdwOwqb/a58=; b=Ll+T2ASz4ZQqfzGzSM9ONL2ij8cDYgKP7xyH5eg4wuhU6ra5CSDM+mYdvB749XBCgKYnPxIwXaY8SIQblTPpo2oH+iPgoBNw0qqJVgr0OQ38++AQjPrVMEQ+V79BZzD1eFbbeFCO1roHpKhNilIiew1ZZSFiOaHD5eQOUNlZXD/OuS+ZD+0WR9FEp+tLU4jRs0/F4baBbOZnK7EDJglOrEBdOUH1zHc69UG10ZWsvnzDlH4a3vIy8Dmu9i4F+vUN8QcMZTTsw4ZIc0z1xgxRMyb840C3qZ+T0Eb+Vc/TwvFlMOrTj9K0EhWXN4fX0iXBCMp14/GLXNEqMBhwzOl99g== 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.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LkpBrayjS/5UboDJyb56OuwJvd2WBenDBdwOwqb/a58=; b=tdQkKz/KW0FOISq53mefNv5Irsxid/JhCFI7roydgqBzvVnMhPu0KrqYb6n+BIkHF/yFX1WWHA/tyJ02PC8vL6muB0NzEOMUkEVZx6w2hlMTLM4UcRErYZRzd5Po3y/KsOrXmTtsPlfbXjZRsk/dUpmpjRPylNF9ZJOOhmvatuc= Received: from MN2PR11MB4207.namprd11.prod.outlook.com (2603:10b6:208:18a::33) by MN2PR11MB4382.namprd11.prod.outlook.com (2603:10b6:208:18c::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.18; Tue, 19 Oct 2021 15:12:30 +0000 Received: from MN2PR11MB4207.namprd11.prod.outlook.com ([fe80::1c61:4c9d:192:be80]) by MN2PR11MB4207.namprd11.prod.outlook.com ([fe80::1c61:4c9d:192:be80%5]) with mapi id 15.20.4608.018; Tue, 19 Oct 2021 15:12:30 +0000 From: "Rob Wilton (rwilton)" To: GENDISPATCH List Thread-Topic: draft-eggert-bcp45bis-06 Thread-Index: AdfBsHNCeGi0GDn+RnSd39Sz1BcSaQ== Date: Tue, 19 Oct 2021 15:12:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 501f6b2e-56ab-41eb-70f9-08d99312defd x-ms-traffictypediagnostic: MN2PR11MB4382: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: s0dVPTRFBt8kszRGpfpjVI6dr2pad479/ox47+arKef3iJHg/r/F/2edLi7MmJ86xAjK58+xXWbqK9SkO1ur+kIufQv+CeC9/rJrUqwhv44NuHV5PIiiKvW6NQQK3/Xsl6I7nloxwsNhj1UGDLoppzk7eER/zfMDlgx8I70+V+S+u6e3/kYUJf5jT/G59SUEAlkPJjNeVLiYZ+EVwuITPgKS2GWQtUf3oGo3L7gMwUgYW/TYDwBzw8lwQvokFkslNzoN4kMB4t/5TRELJ7TKIGT8ZuEs++neouxPtumOWK/9C1bTYCmsYo40iqSZQNKGfAaEGiRDCgj3iSLxfGJ5pTXU1rjVTC9Fv8zCh7aR30fVSLLX/v4h+sTMgG4oOEX7q3S3GORYn1lJOoTZuKeH+XbSM50zULN+ijd1nG2YxOpEi8jL51CXrmoO+iwNyjpePObXLtGodWkjv/gl7QoEKmJBGutZdtgIojd08yvvTccYPXf/8ltzub/7ZqEgc/NYtT5ExkNOtTNIRxn2J8ZFuM8d+yOlPTvOa3iopaNrDppLSFFjusfeNMW9t4MJZbMFoMElNcCc116n54bvDYd8/gDR7xhV6+UiEC+IJ1fspg7Tr/uqcjlV37f6WAu28eznn0dYw6aqiCjF5zHHzdRWIrgF7GYeEi2R/jnlYYwhXMnhTplA2pQdbbprtAzMZgs1+g+7nWeemK5bsh6ngt4hJQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4207.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(26005)(76116006)(186003)(33656002)(508600001)(8676002)(9686003)(66556008)(66446008)(6506007)(66946007)(66476007)(64756008)(71200400001)(52536014)(5660300002)(6916009)(86362001)(83380400001)(8936002)(38070700005)(122000001)(55016002)(2906002)(38100700002)(7696005)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?UkhtIHwl/jaiTUxoBRE5WJCBu6o6wZlQqbjVzxLOVBrnIf02OovS3pcLVlbK?= =?us-ascii?Q?9zH1/P5La8ZJIOc28DVs7c1R77m0+ffzX0EBI5qoR48hYuxQF6Gl3O1A7oN2?= =?us-ascii?Q?hzc3sx+YruCUhKLmg+6OwaSa2zCYfZSGRlSJD4fdf3FobqfUMHziV0GWuquG?= =?us-ascii?Q?4sagtr/Df0mFmsQvg3Rvsj7IxH8gXtfXBMsAp2+cIkISecnoL9xJdXEmNV+6?= =?us-ascii?Q?Kblc+WK2FUEeLa3Q+lu/X5WQB8N4368nGLLQRNkU7TwGPRdzCYTh8VJrhaNj?= =?us-ascii?Q?FBTUqPTnoo7IHdoYjtcTj6i/oWvq0tjP24BTjhAcczWEwMYCr8MkEfZ1RKJ9?= =?us-ascii?Q?Fr2kFnuovrQkA24xYX0o6woUhTt6QE2o/lTrorQRjnCtlz9Ed0XhlUftQaUo?= =?us-ascii?Q?rgf4mLOfullxxx/R6hfGsinMm0QL7P56K9lSPADxdb5NMU6YljCx5h9oDgJn?= =?us-ascii?Q?txTpyE8oVGyLE3oGzs93M4OhXWK0LKgSx8N4P9w9+GZG2LURqA6U+dg6EL+W?= =?us-ascii?Q?TvyLZ6KB11JgU87dV5oQnXhmaQ3qAnkaBXxS6lzRPkvnsxDZUxLgRhGMr00n?= =?us-ascii?Q?/b6NfKzMXpOsKsksGOBXlyynkpaSaZ8U8cydiP+u4NGAM0FsWAiKwoSsoLeY?= =?us-ascii?Q?+aDoma/hqgTyRkDRMMGOmf/KgqjZxaoV72N9jUWsp+myouwPoBfhwRsuDcch?= =?us-ascii?Q?z9KWt3lOIxu0U1hmxLF6mUKP3BRccXLPidfn2Ca21r61kAu+/dTmM7SYBpzW?= =?us-ascii?Q?Ret4xZqoSXRw7hsuPWDGzeLrm/cFVTTCEshPx0MWZ+uQcMq5nZukWdB3jaRt?= =?us-ascii?Q?jSQe9s2C+rX0DwBunHw+bwaIUd5ZPUjK1DIRI9jSpU2K855OQzX4dz13tvFn?= =?us-ascii?Q?2Ibkr866Cg8r6rZosLMEkWiNo6BTY9Qvyh7+ZGAPGoyq21IHESpQ7RLgCaJO?= =?us-ascii?Q?M22ImXLvl2qSEHE6h7bsBeDTCpIKJ2dVhBmPKeoCIdL04PTRrOhjT6V3lNT2?= =?us-ascii?Q?U+JfKMduY5PN8R8VD5H+tqM1+R7G6oILIXaVJ06/Z3jSzt7fbhb8/5FM7LgT?= =?us-ascii?Q?H9QMrZl/R2T1J3tackCyphrC/eh/7NfXEpDo6ixFwii35FdriSl9CcCMrLfi?= =?us-ascii?Q?GdGq169yALNLbfF2IA05l1XEGEQFLtrD3BDqGwUs00Pznjp/DUZosx8830zz?= =?us-ascii?Q?18CSRPebph6p9Kw67sG/sN2blvJLXVhZDuMq17A3o3mQe97s2wnFCta8FjXt?= =?us-ascii?Q?nGgfp6hOom+zmUS0zasBsWKKcgzLMQLFWvAte4XPnIUWqVlFgQJ11DWK/e9k?= =?us-ascii?Q?+/+Kx54PynoivTTaXmGxKSoP?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4207.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 501f6b2e-56ab-41eb-70f9-08d99312defd X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2021 15:12:30.8822 (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: EFNES7iR0Go+h14WjOTPrLQI7TRGHusAORBLhxBtlESo1QXyMDAP/u1Tb2P4rtsHCRHFOY3P5JnqnnIUPslvCA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4382 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xbe-rcd-007.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: [Gendispatch] draft-eggert-bcp45bis-06 X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2021 15:12:41 -0000 Hi, FYI, I've submitted draft-eggert-bcp45bis-06 to IETF LC. From the discussi= on in this WG, I believe that there is rough consensus to publish a small d= ocument replacing RFC 3005 to accurately describe how the general IETF mail= ing lists are expected to function today. I would like to thank those who = have provided comments to improve the draft and the chairs for allowing thi= s discussion to conclude on gendispatch. I appreciate that some members of the community wanted this draft to go fur= ther in its effort to more deeply consider how the ietf general mailing lis= t and the SAA, or equivalent function, operates. Whilst I personally belie= ve that is an important topic to work on for the overall health of the IETF= , my view is that there are many different opinions on whether the IETF mai= ling list needs to evolve, and if it does, what form that evolution should = take. In short, I do not believe that we would quickly come to consensus o= n such an evolution, but that does not prevent the community from trying. = In the meantime it is helpful to update the BCP documentation to reflect wh= at we currently do. Regards, Rob From nobody Tue Oct 19 08:52:52 2021 Return-Path: X-Original-To: gendispatch@ietf.org Delivered-To: gendispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B947B3A0C9D; Tue, 19 Oct 2021 08:52:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-eggert-bcp45bis@ietf.org, gendispatch@ietf.org, rwilton@cisco.com Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <163465875866.13316.15860075014903480611@ietfa.amsl.com> Date: Tue, 19 Oct 2021 08:52:38 -0700 Archived-At: Subject: [Gendispatch] Last Call: (IETF Discussion List Charter) to Best Current Practice X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2021 15:52:45 -0000 The IESG has received a request from an individual submitter to consider the following document: - 'IETF Discussion List Charter' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-11-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through the general discussion of topics for which no dedicated mailing lists exists. As this is the most general IETF mailing list, considerable latitude is allowed, but there are posts and topics that are unsuitable for this mailing list. This document obsoletes RFC3005. The file can be obtained via https://datatracker.ietf.org/doc/draft-eggert-bcp45bis/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Oct 20 02:25:50 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111733A0856 for ; Wed, 20 Oct 2021 02:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhmaqqrvhJkF for ; Wed, 20 Oct 2021 02:25:41 -0700 (PDT) Received: from sonic312-25.consmr.mail.ir2.yahoo.com (sonic312-25.consmr.mail.ir2.yahoo.com [77.238.178.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E281A3A08B8 for ; Wed, 20 Oct 2021 02:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1634721937; bh=e8JwYc1aPnatBTdr0H5Tu+oNveCRIyDu222yZJNz5DU=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From:Subject:Reply-To; b=U8enmx5bVJtLEQP2Ux7WpEotfJyM5kxfZyF/HeXXayCGrjif3IewpveuMI09N+3bQu5ET1AorGJkXcZ4IFOciqWiPJN872EYJXTCDfY6KEvz4S1gj4rbz8AoIuXQwMg4ghSTODfSB9usglAZMpthn9eCYZcIF96oJY7pGDcvB1a0Gai5XEhiFG1hoJsfVwl7S62ySclxsISYlmBLltYvF9cHhObD1tmcySEQDBQDF9nAmtH4MU6tOlRUCFgmqgh+JJg+BsSV3GwbtTboL+tisOBqMJMpEDSsZtSdbrUaP9958Pl31YPqRYQ0/MVCVIbr5PEjvcquJNGN/Ktdw82kKw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1634721937; bh=w60E4LpjgUQR4IlMklp1ak9QKp8f2hmbzcYg7jLUwqH=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=nEHva7/VUO5aP66CU0R1p7TydTOl/0zJlBnlXgLQc/942Z5Od58j0A+xmnGpc0wLfHA4kEKqpB/Jh4bswrADhIXT/sKbbiTDBt4XlhL/qUdo2PCbknIkNueLQ5yoYCanLchelobYj9+t9Pg8Clwi/KXxuKQNlfFMjM8UBZnXYyv0L+YobDxz62POcdSwDyB3HZTcLPODvmChdVsbzj6FYNWK4l6R6crk6Yysxevl7VVXW3UNfwY8tr3wgriNmKGVgfQeNhYzws0hYVpiWKFItmyrdRtqYd7RA/kxboZTXCpY9XtLFrjFgJS7VwW6x5Xit0tNlYn6nB966gS9Uv83UQ== X-YMail-OSG: V4RiO84VM1nLR7yrlh3vbXBdCUwmZc3Cn7CgIs__OvgVI2wBGx97YK6F2eCzvYQ S.3NjPeubO39HmD3zaVNhtRJWAvEZKI3sfwCQaGzj4aHfCwBuwk0MFmZus.2_z4dXLWlzwAsind0 MG2MXUK49TVqiRspYryFWRhNDfERhuIOxjVXrvLXR8K053e_uG_ukQSDrP4CGe_lrY3NFLQ0gYuR prs3W6ZFpzZ2U_V9kQdek_1SMdAQP2qZGIdkiCKJhfch0d8nDJJOKrrqH6M8YmmMBDgZq0vAjiNE zkpe0UnepZlnGd02.5ueBoIheodRdLNRaoy4nP4okp9h.2tGZ3VIhzDhdNdLhvpW97IYDvWnRL.M oHFu4wQg6gAlcgA4Zw3F2VYpequ6t4O7BedKdgrHWXwUyuM2PAiOzdBd_PZZ83_Xr4GLaXqLBexg JikptYFQhbkbTn0Kqdc6Nk_q5kogsrFw9XOiSW0CVG5oA1toPJjas9hlgizRlF58JJcx71Wnz3Fg .q4pWHPY2iUbcMruw02Ns1iVAzAmroypjtomWsPFQt38VvHgfN1Ozyn6qn8wNsZGVRzKxdxC4GrF 8b0fZ3YBU_AzXmadwuw46t3aIXWflqe7viQBvJ8GsDsqd6fS38CrOfqUQm3izPoeNJjanJ479DeB xojgjIXpGT7T3.CHHDvUadBLP0laaXxtmtXgROPWocn7KCrDNl.NT33pQB8aiAjz5QTx44Xd6Lrv nVzYePUDe.J_Q5ptYWyJKcjT6VfR1SSdXwn1wlsGs6eCbze4GQ5bfDZdTMrY1821d9OgOVX5cB.a ZTcgIPUYLNMFMUIYErG_8yc64Cv.O2Vduafa6OTPn863H9seYuLsAmMYvFx_HETT62cWg40fG_jN wtNZQM11h3KxwOglF5.qcgIHW2jZNhPQJPU0wBwO649axebQa65mglfe7YqLkvo_LhNAiPzSSin3 12B69FVUkU9hypN3ZFXry4K6m2hH3Ll94IFxH3Re2dzWpUzlwX6hf.ehAmhvKfJa_fX3jP9PvPJU VffvvPg.leVDyVZDTr05kUWtu3dQhxksD8hfHSR1Nu9KxYDv0QlivFhTeJlBpP95O4zFjySEIyIi oxYGRCOOwwFyzvW854_18hMUCjDbpWt41c7zNiJ5RpG4BK.2fOG16oTL2gHK6uSh.tLUL.fYHycu njXdVC4xhzHbu.wQGuNr_R8T7.p1BYe.K2D0q8jNrbbJe8RUCanVv35VycpTzPwCh2Vw1BwZ8l0S ObFDT9AryAcsqnhJGQzJSnDz8H7BvAWyfSCwhLpVKARBkl9TKHdp8UDPZjWacTh5I._q3PldoJU_ XaUzEbJ0WMcNkve96Dc1MNBUCjxY1KzFoc_7mC4gQ3f9LEFlNmHqAR7JeLE52Mo8hbHBF1H6SzxJ 90oeSs.wQcNYie_6oowaaPeqBp.Fi7afa6FO.6xcBtBzJ691qZFQF6X8wNrfaPBd863uckP.j_TS .SQEcbMwR8J0Au2p4mr1_JsFH73w3jPbK0toOMHM9EcVVHhk2inJ77Ot7zGKKT0GfVRHXDyZWqo6 wWTQ3_71EAgQSsBD3_S2nKWpbNfP54agzATOlGIaKbuk_b3mY7QvkgXqGOCA9mcZvAp6aDlYb7ZN 4.vMaeiYGBd8QFdU.whPQZL5xVGewmvstWf6uqJcjhW9MXg4Q6Um4ZUKu2O86BRFLNwotj0G1H0. mZw0bpeazcYCi8MxsK.dKmVAeFpgVq9xPuMALwHFDLaddd8WpxL2sESOSMv4OrNgNvNTO2a5SvTb ccu5lfrEIGqxj5t16HQzY0y3ZwP3XPkDwADcyo8CHMJz2hB4oXH4wLXOQ9_cr_RcQ3trktZ8J94n deh2hZ3ZjgqT97wtLui_isKT33hR5zYmGki5WUqR7pjR2eIMAzrI2AzqdQv0w.HaVkrpyApPSMu_ QXAEaFoDLYwCpx8eCMEK4c.Xb1H32FxLo1SBphYSAYU8guNPREeJ7PmT8ByHK7yW4lJ.wkdXlPPU bSkroZ118Mq8xbWmyRmi.BwirmfJvO5tV88nKkzK_qL.5J9ve51sGRWLQf5XlzMrZlvgNP8LBMxv SktjmrMlluj4jjjK8ZaiJFLB4go5SdvYhCH4sO9sODYxU9_9zdncjlEDRtTystyYoUmvkfms7wpI GDJD4McJfM6yauWAlyhbtIQEHHpBony997UYweNv_eizN92J8315Dx4hI1bUeU93Hd3JdiJhogUQ t1GcbbP0PqXA0MU_Kefhwj4b7TTLHewOrjKysZca7Mh6b85UeluHs43t02CbaZkddBGJ1SkvhGqI 7o_qrvg0tjWvXJiqbp48- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ir2.yahoo.com with HTTP; Wed, 20 Oct 2021 09:25:37 +0000 Received: by kubenode531.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 871ddbf6ba0a97f50c3a394b0af3c24d; Wed, 20 Oct 2021 09:25:31 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-F5F76836-E019-452C-9EAF-7FD5F42C70D3 Content-Transfer-Encoding: 7bit From: Lloyd W Mime-Version: 1.0 (1.0) Date: Wed, 20 Oct 2021 20:25:27 +1100 Message-Id: References: <163465875866.13316.15860075014903480611@ietfa.amsl.com> Cc: gendispatch@ietf.org, draft-eggert-bcp45bis@ietf.org, IETF Discussion , The IESG , last-call@ietf.org In-Reply-To: <163465875866.13316.15860075014903480611@ietfa.amsl.com> To: last-call@ietf.org X-Mailer: iPad Mail (18H17) Archived-At: Subject: Re: [Gendispatch] Last Call: (IETF Discussion List Charter) to Best Current Practice X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 09:25:47 -0000 --Apple-Mail-F5F76836-E019-452C-9EAF-7FD5F42C70D3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable A sergeant-at-arms (SAA) "is an officer appointed by a deliberative body (...) to keep order during its meetings" [SAA-WIKIPEDIA]. SAAs for the IETF discussion list are appointed by the IETF Chair and are empowered to restrict posting by a person, or of a thread, when the content is inappropriate and represents a pattern of abuse there's an inherent contradiction in that little quoted snippet, which remai= ns unexplained in the text of this draft despite being raised previously on g= endispatch. In many bodies, the body itself appoints the SAAs, and that Wikipedia page s= ays as much, at least until someone edits it to say otherwise. Here, in a draft being written by the IETF Chair, the very next sentence say= s that the SAAs are not appointed by the deliberative body itself - which is= to say, the mailing list contributors - but by the Chair. Who, by the way, i= s the person writing this draft describing the Chair's powers. Yes, the Chai= r is the person doing the necessary work of writing this update draft, but, j= ust maybe, hear me out, since it describes powers of the Chair, the Chair re= ally shouldn't have been tasked with doing it in the first place? This cascading cognitive dissonance remains a bad look, and the draft should= at least attempt to explain these points somehow - historical practice, un= der further review, we didn't realise how much the SAAs were at the behest o= f the chairs, the SAAs actually have very little independence, this is just h= ow it is, the SAAs are not appointed by the list, but by the chair who is wr= iting this draft which tightens and tidies and documents previous practice, w= e can't trust the list to even stay on topic and keep to an undefined level o= f 'professionalism', so have it appoint its own SAAs? Ha, you must be joking= , IETF LLC has a reputation to protect. I don't know what the explanation will be, but there needs to be one. Just s= aying 'well, the wikipedia page is not a dictionary and is not normative' wo= uld not be enough - and if referencing wikipedia you'd need to give a date/r= evision, anyway, just as we do for drafts, because wikipedia is eternally dr= afted. (we reject kings etc. and the chair unfortunately looks here very much like a= king issuing executive fiat. but we also reject voting, so we'd have to... h= um between candidates?) The draft can't skip around this, but imo does have to explicitly address an= d explain these points in its text, and thus shed some light on the underlyi= ng philosophy of list governance which must underpin and support the reasoni= ng given. Somehow.=20 How the draft chooses to do this will imo say a lot about the IETF. I encourage IETF mailing list contributors to look closely at this draft. Lloyd Wood lloyd.wood@yahoo.co.uk > On 20 Oct 2021, at 02:53, The IESG wrote: >=20 > =EF=BB=BF > The IESG has received a request from an individual submitter to consider t= he > following document: - 'IETF Discussion List Charter' > as Best Current Practice >=20 > The IESG plans to make a decision in the next few weeks, and solicits fina= l > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2021-11-23. Exceptionally, comments ma= y > be sent to iesg@ietf.org instead. In either case, please retain the beginn= ing > of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > The Internet Engineering Task Force (IETF) discussion mailing list > furthers the development and specification of Internet technology > through the general discussion of topics for which no dedicated > mailing lists exists. As this is the most general IETF mailing list, > considerable latitude is allowed, but there are posts and topics that > are unsuitable for this mailing list. >=20 > This document obsoletes RFC3005. >=20 >=20 >=20 >=20 > The file can be obtained via > https://datatracker.ietf.org/doc/draft-eggert-bcp45bis/ >=20 >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 >=20 >=20 >=20 > --=20 > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch --Apple-Mail-F5F76836-E019-452C-9EAF-7FD5F42C70D3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 
   A sergeant-at-arms (SAA) "=
is an officer appointed by a deliberative
   body (...) to keep order during its meetings" [SAA-WIKIPEDIA].  SAAs
   for the IETF discussion list are appointed by the IETF Chair and are
   empowered to restrict posting by a person, or of a thread, when the
   content is inappropriate and represents a pattern of abuse

=
there's an inherent contradiction in that little quoted snippet, which= remains unexplained in the text of this draft despite being raised previous= ly on gendispatch.

In many bodies, the body itself appoin= ts the SAAs, and that Wikipedia page says as much, at least until someone ed= its it to say otherwise.

Here, in a draft being wri= tten by the IETF Chair, the very next sentence says that the SAAs are not ap= pointed by the deliberative body itself - which is to say, the mailing list c= ontributors - but by the Chair. Who, by the way, is the person writing this d= raft describing the Chair's powers. Yes, the Chair is the person doing the n= ecessary work of writing this update draft, but, just maybe, hear me out, si= nce it describes powers of the Chair, the Chair really shouldn't have been t= asked with doing it in the first place?

This cascad= ing cognitive dissonance remains a bad look, and the draft should at least a= ttempt to explain these points somehow -  historical practice, under fu= rther review, we didn't realise how much the SAAs were at the behest of the c= hairs, the SAAs actually have very little independence, this is just how it i= s, the SAAs are not appointed by the list, but by the chair who is writing t= his draft which tightens and tidies and documents previous practice, we can'= t trust the list to even stay on topic and keep to an undefined level of 'pr= ofessionalism', so have it appoint its own SAAs? Ha, you must be joking, IET= F LLC has a reputation to protect.

I don't know wha= t the explanation will be, but there needs to be one. Just saying 'well, the= wikipedia page is not a dictionary and is not normative' would not be enoug= h - and if referencing wikipedia you'd need to give a date/revision, anyway,= just as we do for drafts, because wikipedia is eternally drafted.

(we reject kings etc. and the chair unfortunately looks here= very much like a king issuing executive fiat. but we also reject voting, so= we'd have to... hum between candidates?)

The draft= can't skip around this, but imo does have to explicitly address and explain= these points in its text, and thus shed some light on the underlying philos= ophy of list governance which must underpin and support the reasoning given.=  Somehow. 

How the draft chooses to do t= his will imo say a lot about the IETF.

I encourage I= ETF mailing list contributors to look closely at this draft.

<= div>
Lloyd Wood
lloyd.wood@yahoo.co.uk

On 20 Oct 2021, at 02:53, The IESG &= lt;iesg-secretary@ietf.org> wrote:

=EF=BB=BF
The IESG has r= eceived a request from an individual submitter to consider the
following document: - 'IETF Discussion List Charter'
&nb= sp;<draft-eggert-bcp45bis-06.txt> as Best Current Practice
<= span>
The IESG plans to make a decision in the next few week= s, and solicits final
comments on this action. Please send s= ubstantive comments to the
last-call@ietf.org mailing lists b= y 2021-11-23. Exceptionally, comments may
be sent to iesg@ie= tf.org instead. In either case, please retain the beginning
= of the Subject line to allow automated sorting.

<= span>Abstract


  = ;The Internet Engineering Task Force (IETF) discussion mailing list   furthers the development and specification of Internet t= echnology
  through the general discussion of top= ics for which no dedicated
  mailing lists exists= .  As this is the most general IETF mailing list,
&nbs= p; considerable latitude is allowed, but there are posts and topics tha= t
  are unsuitable for this mailing list.<= br>
  This document obsoletes RFC3005.




The file can be obtained via
https://datatracker.ietf.or= g/doc/draft-eggert-bcp45bis/



No IPR declarations have been submitted directly on this= I-D.





--
Gendispatch mailing list<= /span>
Gendispatch@ietf.org
https://www.ietf.org/ma= ilman/listinfo/gendispatch
<= /html>= --Apple-Mail-F5F76836-E019-452C-9EAF-7FD5F42C70D3-- From nobody Wed Oct 20 05:38:12 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976F03A0654; Wed, 20 Oct 2021 05:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dy4jfnVD_i3n; Wed, 20 Oct 2021 05:36:49 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5EED3A05E2; Wed, 20 Oct 2021 05:36:48 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:9937:ce73:118c:3221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 6C381600C9C; Wed, 20 Oct 2021 15:36:36 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1634733396; bh=trhUm9vLVobZEFov1aFwNNPc/NARN6vCIdcEHCz5Qz0=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=oT8mR4NQjxX6/l1o7vNDpQI6cqE4YlYGgg3kT68zxsWq31IvBI1OgE8spmNtSmKZr ghy1MvcCi7w/KPgafy1sh2RtbKuUaA+1YMxfxEhssUjYt8833ESDKy0iUjMEbO2rO4 rhunHR5jfrWLWEbWYXTjWvjgyZHEPK2FsFuqkdIs= From: Lars Eggert Message-Id: <068AC0DD-CF59-4A36-B528-C18E34ED4EF7@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_131D3CEE-DDCA-4E17-BE94-77D8BDFDC733"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Wed, 20 Oct 2021 15:36:33 +0300 In-Reply-To: Cc: last-call@ietf.org, The IESG , GENDISPATCH List , draft-eggert-bcp45bis@ietf.org, IETF Discussion To: Lloyd W References: <163465875866.13316.15860075014903480611@ietfa.amsl.com> X-MailScanner-ID: 6C381600C9C.A3E1C X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Gendispatch] Last Call: (IETF Discussion List Charter) to Best Current Practice X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 12:36:57 -0000 --Apple-Mail=_131D3CEE-DDCA-4E17-BE94-77D8BDFDC733 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Lloyd, thank you for your feedback. On 2021-10-20, at 12:25, Lloyd W = wrote: >=20 > A sergeant-at-arms (SAA) "is an officer appointed by a deliberative > body (...) to keep order during its meetings" [SAA-WIKIPEDIA]. = SAAs > for the IETF discussion list are appointed by the IETF Chair and = are > empowered to restrict posting by a person, or of a thread, when the > content is inappropriate and represents a pattern of abuse >=20 > there's an inherent contradiction in that little quoted snippet, which = remains unexplained in the text of this draft despite being raised = previously on gendispatch. >=20 > In many bodies, the body itself appoints the SAAs, and that Wikipedia = page says as much, at least until someone edits it to say otherwise. >=20 > Here, in a draft being written by the IETF Chair, the very next = sentence says that the SAAs are not appointed by the deliberative body = itself - which is to say, the mailing list contributors - but by the = Chair. First, I added the link to that Wikipedia page (which was not in the = original BCP45), because I received feedback from IETF participants = outside of the US/UK geos that the term "sergeant at arms" was = unfamiliar. I'd be happy to point to a better definition. Second, I think we're reading the Wikipedia text differently. I read = "appointed by a deliberative body" pretty broadly, including = appointments by an elected committee or chair of the body in question. > Who, by the way, is the person writing this draft describing the = Chair's powers. Yes, the Chair is the person doing the necessary work of = writing this update draft, but, just maybe, hear me out, since it = describes powers of the Chair, the Chair really shouldn't have been = tasked with doing it in the first place? BCP45bis does not grant the IETF chair any additional powers. In fact, = it removes some. I repeatedly asked if the community felt that someone else should hold = the pen for this, and most feedback I received seemed to indicate that = it was OK for me to do this, given the minor nature of the changes. I'll = leave it up to my sponsoring AD to decide if this is a change we should = (now) do anyhow. > This cascading cognitive dissonance remains a bad look, and the draft = should at least attempt to explain these points somehow - historical = practice, under further review, we didn't realise how much the SAAs were = at the behest of the chairs, the SAAs actually have very little = independence, this is just how it is, the SAAs are not appointed by the = list, but by the chair who is writing this draft which tightens and = tidies and documents previous practice, we can't trust the list to even = stay on topic and keep to an undefined level of 'professionalism', so = have it appoint its own SAAs? Ha, you must be joking, IETF LLC has a = reputation to protect. I'm sorry this minor update is giving you cascading cognitive = dissonance. You raised two points in this email: (1) that in your opinion the = Wikipedia page for SAA is not fully aligned with our SAA selection, and = (2) that the IETF chair is authoring this minor update. I hope I gave = additional context on both points above. > I don't know what the explanation will be, but there needs to be one. = Just saying 'well, the wikipedia page is not a dictionary and is not = normative' would not be enough - and if referencing wikipedia you'd need = to give a date/revision, anyway, just as we do for drafts, because = wikipedia is eternally drafted. The Wikipedia page is an informative reference already. I don't think = it's common practice to call out in the text that a reference is = informative, but I can of course do so if that ends up being the = consensus. I will add a retrieval date to the reference, or = alternatively cite an archive.org snapshot of the page. > (we reject kings etc. and the chair unfortunately looks here very much = like a king issuing executive fiat. but we also reject voting, so we'd = have to... hum between candidates?) >=20 > The draft can't skip around this, but imo does have to explicitly = address and explain these points in its text, and thus shed some light = on the underlying philosophy of list governance which must underpin and = support the reasoning given. Somehow. >=20 > How the draft chooses to do this will imo say a lot about the IETF. Again, I hope I gave you additional context above. I remain unconvinced = that the document itself needs text to capture some of this context, = however. > I encourage IETF mailing list contributors to look closely at this = draft. Seconded. Thanks, Lars --Apple-Mail=_131D3CEE-DDCA-4E17-BE94-77D8BDFDC733 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmFwDVEACgkQVLXDCb9w wVdOwg/5AV7AcXUak9yfaltBSmcNd3Ns+0BcxLCZGSvxlUcvOecEL2TIcVHHw6EL IryHd9hUjBfSB5ov8q9+OEqGv6wAwmJ77qpP+pc0Lovr+WyYLuj9Z9iu9GhbEIIo hy/Nti3kMg9uasZrb9LIeAD/zIwRXcylQQhTqaF6+9zEiQpLzHzGgjJ5kbqZOLde No0VkqplThYmmrMFEL4vmR7VTXZ1DwKe2wOGK8oPTYjb5zWj2jPqV2cvKrRMxh8c fKxwq99ptfwm18wB6EEeL//TMpPHsBqGjMEzmTxOmI1dKsG3ReaJGB1HUmRAoHoJ wHDZj9LvFjj9GUfFxlHeRo/2HBdV94EA/oFnXvp/mwGTsvcSyLAMruYOqtkVyv8k cm3qvzmnHT9UGhHj83bWNgcbuuIpLx0FO2v7j7NkP2YhYpxLNO7pbvYAmPLXl6KE SiJlnZyhQWBEy5Rhs8li601WDjonLy7gTdjZ2V9W2CC0nXdz4hFOw5uTvyPDheVp qFsgGTi9q/NLqnDcc2lsbmHlpqL2XxcmtJw/BiCwwiiEmr2OBksmS5hW/t9FYyuP vVgf5CdWwArmgHKsQudnQiwswlWA4vfRjorieHMWZ3rze9TdwgpMT53Sn8r20wCl nHkDlyuDmP2n68XISUduLG5hQ8ZRrGWfsCgxLWMUmT95H2GrGOQ= =acvr -----END PGP SIGNATURE----- --Apple-Mail=_131D3CEE-DDCA-4E17-BE94-77D8BDFDC733-- From nobody Wed Oct 20 06:14:34 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EA43A0865; Wed, 20 Oct 2021 06:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi2cNJY_SQQh; Wed, 20 Oct 2021 06:13:53 -0700 (PDT) Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D393A0857; Wed, 20 Oct 2021 06:13:53 -0700 (PDT) Received: by mail-vk1-f175.google.com with SMTP id o42so12031235vkf.9; Wed, 20 Oct 2021 06:13:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IRAJc7BwF2bvKYcDifaFbrMNxBcizC8ZuwNQCD50quA=; b=D1aO6x5+EFgJXlw/HTUOLK8KPEnFLUSFag0ACTPeeQxXdooUZrMI75Kyf/hpybuXLw UgSYT5xyGy+Nh0399Ol8c+jcn06+sbuFnJyFW7c1j0MKXbwqJg0Jav2BS7RfxKBWAt98 ZRJcyGaX5TQNhqKw5G62RM8EAuHFm1MggsSzhfSAwHMiKHNClSyq+e6en5yPnG3jathc 6AfwDOssM7K21OGCZWKBKFomWLi5IGTXpX/YsV8Mk4/UNeuGlAJPdLFFYx4Ulf9Llmkr VPXvtfCIYroPBFLxqRqBDdR2WeUnCaJ8uLVHS2+fTxu1Frclc6xrMXLFxV80VKMKHuY+ XrSA== X-Gm-Message-State: AOAM530Hc86MxY53t7osjcf/RwdV6hEsM8j4D6idj2g/y8udh6nvHt22 xYJzeX9mGOc05y3yIQaU+IrqE0afZlYfog+TrOxVkKr6g9wpxA== X-Google-Smtp-Source: ABdhPJxkU3+WA1vmGf+vxuiO3kNmBMBo/VeBuqHRlLdRxluBvNUnHy+ri7CYWAhBEVZ9s8mcY95JM7iyLUYkF7ZHuSY= X-Received: by 2002:a1f:324d:: with SMTP id y74mr38719549vky.20.1634735630811; Wed, 20 Oct 2021 06:13:50 -0700 (PDT) MIME-Version: 1.0 References: <163465875866.13316.15860075014903480611@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Wed, 20 Oct 2021 09:13:39 -0400 Message-ID: To: last-call@ietf.org Cc: The IESG , GENDISPATCH List , draft-eggert-bcp45bis@ietf.org, IETF Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Gendispatch] Last Call: (IETF Discussion List Charter) to Best Current Practice X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 13:13:58 -0000 > I encourage IETF mailing list contributors to look closely at this draft. I have looked at it closely, and I do NOT share the concerns raised here. I think the draft is a reasonable update to BCP 45, that it clarifies the charter for the IETF list and the SAA team's role, and that anything more than this would need a fresh effort by the community to make a more significant update -- which I don't think is needed. I think there is no contradiction between the use of Wikipedia to explain the general role of Sergeants at Arms and the role the SAAs have with respect to the IETF list. Wikipedia discusses some mechanisms for appointment and use of SAAs, but those are not the only mechanisms. It's not wrong, and neither is it exhaustive. The only way we have, at this point, to make community appointments is through the NomCom, and I think it would be a bad approach to add SAA positions to the NomCom's slate. The draft makes it clear that the purpose of the SAA team is to allow the IETF Chair to appoint people to handle this role, and then to step back and *not* be a king, to *not* have a day-to-day role in monitoring and managing the IETF list. That is as it should be. I find nothing at all wrong with the IETF Chair being the editor of this draft: Lars has fairly edited it based on input, and its contents reflect not Lars's thoughts, but rough consensus of the community so far. That not everyone is happy with everything it says shows that we have *rough consensus*, not unanimity... it does not say that the IETF Chair has done anything inappropriate here. This is ready to be published and to update BCP 45. Barry On Wed, Oct 20, 2021 at 5:26 AM Lloyd W wrote: > > A sergeant-at-arms (SAA) "is an officer appointed by a deliberative > body (...) to keep order during its meetings" [SAA-WIKIPEDIA]. SAAs > for the IETF discussion list are appointed by the IETF Chair and are > empowered to restrict posting by a person, or of a thread, when the > content is inappropriate and represents a pattern of abuse > > > there's an inherent contradiction in that little quoted snippet, which re= mains unexplained in the text of this draft despite being raised previously= on gendispatch. > > In many bodies, the body itself appoints the SAAs, and that Wikipedia pag= e says as much, at least until someone edits it to say otherwise. > > Here, in a draft being written by the IETF Chair, the very next sentence = says that the SAAs are not appointed by the deliberative body itself - whic= h is to say, the mailing list contributors - but by the Chair. Who, by the = way, is the person writing this draft describing the Chair's powers. Yes, t= he Chair is the person doing the necessary work of writing this update draf= t, but, just maybe, hear me out, since it describes powers of the Chair, th= e Chair really shouldn't have been tasked with doing it in the first place? > > This cascading cognitive dissonance remains a bad look, and the draft sho= uld at least attempt to explain these points somehow - historical practice= , under further review, we didn't realise how much the SAAs were at the beh= est of the chairs, the SAAs actually have very little independence, this is= just how it is, the SAAs are not appointed by the list, but by the chair w= ho is writing this draft which tightens and tidies and documents previous p= ractice, we can't trust the list to even stay on topic and keep to an undef= ined level of 'professionalism', so have it appoint its own SAAs? Ha, you m= ust be joking, IETF LLC has a reputation to protect. > > I don't know what the explanation will be, but there needs to be one. Jus= t saying 'well, the wikipedia page is not a dictionary and is not normative= ' would not be enough - and if referencing wikipedia you'd need to give a d= ate/revision, anyway, just as we do for drafts, because wikipedia is eterna= lly drafted. > > (we reject kings etc. and the chair unfortunately looks here very much li= ke a king issuing executive fiat. but we also reject voting, so we'd have t= o... hum between candidates?) > > The draft can't skip around this, but imo does have to explicitly address= and explain these points in its text, and thus shed some light on the unde= rlying philosophy of list governance which must underpin and support the re= asoning given. Somehow. > > How the draft chooses to do this will imo say a lot about the IETF. > > I encourage IETF mailing list contributors to look closely at this draft. > > Lloyd Wood > lloyd.wood@yahoo.co.uk > > On 20 Oct 2021, at 02:53, The IESG wrote: > > =EF=BB=BF > The IESG has received a request from an individual submitter to consider = the > following document: - 'IETF Discussion List Charter' > as Best Current Practice > > The IESG plans to make a decision in the next few weeks, and solicits fin= al > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2021-11-23. Exceptionally, comments m= ay > be sent to iesg@ietf.org instead. In either case, please retain the begin= ning > of the Subject line to allow automated sorting. > > Abstract > > > The Internet Engineering Task Force (IETF) discussion mailing list > furthers the development and specification of Internet technology > through the general discussion of topics for which no dedicated > mailing lists exists. As this is the most general IETF mailing list, > considerable latitude is allowed, but there are posts and topics that > are unsuitable for this mailing list. > > This document obsoletes RFC3005. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-eggert-bcp45bis/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch From nobody Wed Oct 20 06:52:07 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA41D3A08F8 for ; Wed, 20 Oct 2021 06:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20210112.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siadH8XfhBoJ for ; Wed, 20 Oct 2021 06:52:00 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25D63A0743 for ; Wed, 20 Oct 2021 06:51:59 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id m20so24606858iol.4 for ; Wed, 20 Oct 2021 06:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20210112.gappssmtp.com; s=20210112; h=from:mime-version:subject:message-id:references:to:date; bh=mLXSwmn3d+9IiEYqoK0/VjZLOEbXciJ5k2q1pI60DOk=; b=sT4orywtC85wKRZ4xf8Jhj0d29xTdIvJ7BzqrlTIWreJwAK30nT3QzY6elRWoPpdP+ CTclEmqhTOWKsIiuQ8SBioJsAcXUD5Osy0aGx9iwY15eJI0iFpB0wanFtRtM+DL3MapW /gC1MyVUf/hzUufOsgYgnuw8Hh98DTzGgFnjFXQCH8wwmvrSkJFRd2nV/V+bZ61F3jt7 VONpVIFHh+doC/t6RHBtjrLQlA6rAhjhHpmSpPCkNiQS4ZKQIVo/fIPwR1u4OysJl6OL RYbaXeaV7Q/wwRaAV5avKGXQZQMialqx/F4l4UNAhScjAV03gkWgGY8n+AdpB0QiAz/b nqFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=mLXSwmn3d+9IiEYqoK0/VjZLOEbXciJ5k2q1pI60DOk=; b=6lNeJYpy0jB0QBUNIMKCretFRPFmShEEO6YLJ2JGy3dmes0r2yreT6JWxqzqgVH6lA DIypvq2mSDnfvn9TM3eAfgV30BYgUxtFfqnqryuMcqGj4NbuDb1OPmn8k4vcK6f2JafG 2JzVZo4ZJFY/aHQ9WaIrlOqvo/FDf4w+3HMFNt+DBms5BYushgYQmF7O0zwvD2QrjMZL TuMue7PyIsvaTtLV4JBxyEd170rS0Ms+Z6cRG6NlMDonN/9zZBiVdx1+/649CJGkAMkZ 15QigbIjUGJXxJC6ibZt63tEYZaNSefVcSvwfLZQvZble+AZrA7u39ge9QoW1EuNTtr8 aJUw== X-Gm-Message-State: AOAM532YpoNkt63mVaR2s/2Y9RWmV8pJ6gahNpUbx04lsjF9SELO8z5a AWtaEO9WNpCu2gQkzm6hk7A/ObY2YoshtdMd X-Google-Smtp-Source: ABdhPJzfktoH1X21U5PBvTnaQDSEl4mVxl72DMxykgyDBUtHF8jMjuSscqMQ22p66MnI5XfR4fEELw== X-Received: by 2002:a05:6638:2690:: with SMTP id o16mr101769jat.96.1634737917341; Wed, 20 Oct 2021 06:51:57 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id l4sm1061937ilg.44.2021.10.20.06.51.56 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Oct 2021 06:51:57 -0700 (PDT) From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_E659578B-C604-4B47-B55E-385610677906" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Message-Id: <7B0E3BB5-CC18-49D1-91C0-5AFF1B7E1023@brianrosen.net> References: <163473747926.26402.9452978909596932509@ietfa.amsl.com> To: Gendispatch@ietf.org Date: Wed, 20 Oct 2021 09:51:54 -0400 X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: [Gendispatch] Fwd: New Version Notification for draft-rosen-rfcefdp-update-2026-01.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 13:52:05 -0000 --Apple-Mail=_E659578B-C604-4B47-B55E-385610677906 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This draft has been created as part of the RFC Editor Future Development = program. =20 It is very short: all it does is delete a line in RFC2026 that says: =E2=80=9CRFC publication is the direct responsibility of the RFC Editor, = under the general direction of the IAB"=20 Can I request dispatching it please? Brian > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-rosen-rfcefdp-update-2026-01.txt > Date: October 20, 2021 at 9:44:39 AM EDT > To: "Brian Rosen" >=20 >=20 > A new version of I-D, draft-rosen-rfcefdp-update-2026-01.txt > has been successfully submitted by Brian Rosen and posted to the > IETF repository. >=20 > Name: draft-rosen-rfcefdp-update-2026 > Revision: 01 > Title: RFC Series Responsibility Change > Document date: 2021-10-20 > Group: Individual Submission > Pages: 3 > URL: = https://www.ietf.org/archive/id/draft-rosen-rfcefdp-update-2026-01.txt > Status: = https://datatracker.ietf.org/doc/draft-rosen-rfcefdp-update-2026/ > Html: = https://www.ietf.org/archive/id/draft-rosen-rfcefdp-update-2026-01.html > Htmlized: = https://datatracker.ietf.org/doc/html/draft-rosen-rfcefdp-update-2026 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-rosen-rfcefdp-update-2026-01 >=20 > Abstract: > In RFCXXXX [RFC Editor, please replace with the RFC resulting from > draft-iab-rfcefdp-rfced-model], responsibility for the RFC series > moved to the RFC Series Working Group and the RFC Series Approval > Board. This document updates RFC2026 to recognize this change. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 --Apple-Mail=_E659578B-C604-4B47-B55E-385610677906 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = draft has been created as part of the RFC Editor Future Development = program.  
It is very short: all it does is delete a = line in RFC2026 that says:
=E2=80=9CRFC publication is the direct responsibility of the = RFC Editor, under the general direction of the = IAB" 


Can I request = dispatching it please?

Brian


Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-rosen-rfcefdp-update-2026-01.txt
Date: = October 20, 2021 at 9:44:39 AM = EDT
To: = "Brian Rosen" <br@brianrosen.net>

A new version of I-D, = draft-rosen-rfcefdp-update-2026-01.txt
has been = successfully submitted by Brian Rosen and posted to the
IETF= repository.

Name: = draft-rosen-rfcefdp-update-2026
Revision: 01
Title:= = RFC Series Responsibility Change
Document = date: = 2021-10-20
Group: Individual Submission
Pages:= = 3
URL: =            https://www.ietf.org/archive/id/draft-rosen-rfcefdp-update-2026= -01.txt
Status: =         https://datatracker.ietf.org/doc/draft-rosen-rfcefdp-update-202= 6/
Html: =           https://www.ietf.org/archive/id/draft-rosen-rfcefdp-update-2026= -01.html
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-rosen-rfcefdp-updat= e-2026
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-rosen-rfcefdp-update-= 2026-01

Abstract:
=   In RFCXXXX [RFC Editor, please replace with the RFC = resulting from
=   draft-iab-rfcefdp-rfced-model], responsibility for the RFC = series
  moved to the RFC Series Working Group = and the RFC Series Approval
  Board.  This = document updates RFC2026 to recognize this change.




The IETF = Secretariat



= --Apple-Mail=_E659578B-C604-4B47-B55E-385610677906-- From nobody Wed Oct 20 07:37:26 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDDF3A0063; Wed, 20 Oct 2021 07:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id od9mxL96fEJv; Wed, 20 Oct 2021 07:37:15 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 F355F3A0062; Wed, 20 Oct 2021 07:37:14 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19KBmxuV011463; Wed, 20 Oct 2021 15:37:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=cqVcFGWaCI5c1myvf8XKVapAMjTcXWqzHj9vecjgbic=; b=jxMwNJDpcTtefi1pDPcgztGRd2JAa8dNYTHD7LvvUxFv79pSp1XpQVftJUE1qyAnMczo idy5nGJfQUANH9lCcB91ZhaHgZ1/9fNfytCoL/C9Z1yzvQSI8SRdMm2hQdJ5rcKGWWRZ rPSS1lWfoUe2nwo87idlJyDDLvI/LmyY67xfZPyJRjPcGsA9bImJRhLFkUhunbDRkOZ7 akE9sQQiTUmSoUaMJ4vk3qabPFSOS7SUtpW5LZ3BIP/ju5JGlszyYOl09rm1wyW/7EpR fC6T3SUYnF4+51eamil/OQTigQpM6ckEefH2XWp2PAG3ad4GH0pxltSzMaUPfELhmkni qQ== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 3btjjqkh0p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Oct 2021 15:37:12 +0100 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 19KEa3jI000999; Wed, 20 Oct 2021 10:37:11 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint6.akamai.com with ESMTP id 3bt07yhstu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 20 Oct 2021 10:37:11 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Wed, 20 Oct 2021 10:37:10 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.023; Wed, 20 Oct 2021 10:37:10 -0400 From: "Salz, Rich" To: "gendispatch@ietf.org" CC: "ietf@ietf.org" Thread-Topic: Agenda item request Thread-Index: AQHXxb/2ccy36ftOwkmr+E7GztLpBg== Date: Wed, 20 Oct 2021 14:37:09 +0000 Message-ID: <4BDF1DD9-9D30-499F-8C26-1E7790F2A729@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.54.21101001 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: <645EB6F921A6F24684DC67C599A964AB@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-20_05:2021-10-20, 2021-10-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 mlxscore=0 malwarescore=0 adultscore=0 spamscore=0 mlxlogscore=753 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110200085 X-Proofpoint-GUID: VsaI4GtNHqChKjxMiz5xgFvQJrb1VO6Z X-Proofpoint-ORIG-GUID: VsaI4GtNHqChKjxMiz5xgFvQJrb1VO6Z X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-20_05,2021-10-20_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 impostorscore=0 adultscore=0 clxscore=1011 priorityscore=1501 mlxlogscore=704 spamscore=0 malwarescore=0 mlxscore=0 phishscore=0 lowpriorityscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110200085 Archived-At: Subject: [Gendispatch] Agenda item request X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 14:37:20 -0000 SSB3b3VsZCBsaWtlIHRvIGhhdmUgdGhpcyBvbiB0aGUgbmV4dCBHRU5ESVNQQVRDSCBhZ2VuZGEu DQoNCiAgICBOYW1lOgkJZHJhZnQtcnNhbHotdGVybWxpbWl0cw0KICAgIFJldmlzaW9uOgkwMA0K ICAgIFRpdGxlOgkJVGVybSBsaW1pdHMgZm9yIElFVEYgTGVhZGVyc2hpcCBQb3NpdGlvbnMNCiAg ICBEb2N1bWVudCBkYXRlOgkyMDIxLTEwLTIwDQogICAgR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1p c3Npb24NCiAgICBQYWdlczoJCTMNCiAgICBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1yc2Fsei10ZXJtbGltaXRzLTAwLnR4dCANCiAgICBTdGF0 dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcnNhbHot dGVybWxpbWl0cy8gDQogICAgSHRtbDogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2Fy Y2hpdmUvaWQvZHJhZnQtcnNhbHotdGVybWxpbWl0cy0wMC5odG1sIA0KICAgIEh0bWxpemVkOiAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXJzYWx6LXRlcm1s aW1pdHMgDQoNCg0KICAgIEFic3RyYWN0Og0KICAgICAgIFRoaXMgZG9jdW1lbnQgc2F5cyB0aGF0 IG5vYm9keSBjYW4gYmUgcGlja2VkIGJ5IE5vbUNvbSBmb3IgYSBwb3NpdGlvbg0KICAgICAgIG1v cmUgdGhhbiB0d28gY29uc2VjdXRpdmUgdGVybXMuDQoNCiAgICAgICBJdCBvYnNvbGV0ZXMgc29t ZSBvdGhlciBkb2N1bWVudHMsIHdoaWNoIG9uZXMgYXJlIFRCRC4NCg0KICAgIERpc2N1c3Npb24g VmVudWVzDQoNCiAgICAgICBUaGlzIG5vdGUgaXMgdG8gYmUgcmVtb3ZlZCBiZWZvcmUgcHVibGlz aGluZyBhcyBhbiBSRkMuDQoNCiAgICAgICBTb3VyY2UgZm9yIHRoaXMgZHJhZnQgYW5kIGFuIGlz c3VlIHRyYWNrZXIgY2FuIGJlIGZvdW5kIGF0DQogICAgICAgaHR0cHM6Ly9naXRodWIuY29tL3Jp Y2hzYWx6L2RyYWZ0LXJzYWx6LXRlcm1saW1pdHMNCg0KDQoNCiAgICBUaGUgSUVURiBTZWNyZXRh cmlhdA0KDQoNCg0K From nobody Wed Oct 20 08:18:33 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16773A0835; Wed, 20 Oct 2021 08:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evkOwWr0zqHX; Wed, 20 Oct 2021 08:17:45 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 0168F3A081D; Wed, 20 Oct 2021 08:17:44 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.1.2/8.16.1.2) with SMTP id 19KF2mCL029695; Wed, 20 Oct 2021 11:17:42 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 3btndkrjm7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Oct 2021 11:17:42 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 19KFHeUa007775; Wed, 20 Oct 2021 11:17:41 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 19KFHavU007559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Oct 2021 11:17:36 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 2768740145A4; Wed, 20 Oct 2021 15:17:36 +0000 (GMT) Received: from GAALPA1MSGEX1AD.ITServices.sbc.com (unknown [135.50.89.99]) by zlp30483.vci.att.com (Service) with ESMTP id BEF8340145A5; Wed, 20 Oct 2021 15:17:35 +0000 (GMT) Received: from GAALPA1MSGED2AC.ITServices.sbc.com (135.50.89.122) by GAALPA1MSGEX1AD.ITServices.sbc.com (135.50.89.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14; Wed, 20 Oct 2021 11:17:35 -0400 Received: from GAALPA1MSGETA02.tmg.ad.att.com (144.160.249.124) by GAALPA1MSGED2AC.ITServices.sbc.com (135.50.89.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14 via Frontend Transport; Wed, 20 Oct 2021 11:17:35 -0400 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.168) by edgeal2.exch.att.com (144.160.249.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.14; Wed, 20 Oct 2021 11:17:07 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gPg2V+AlaziQBjR4zSaTBJzj2LGhZuNmisBfhsbqPTcjc2QeleKi39g/+K4A7wD2uFg/v2oOKeHv7873O9GlbhhgJEpObk6U0LB1oTTJ8eRJ8Ue/bh8yMmYifekattQ/xkXx2lMerYpFXevIrVcEANpLadXpQ3jWu4jxZYG7dIJ7IyCmI4Q5Wqj2ZbaYYRyBzNFUHX3qxj8xIDMGiP7i8cA3boWljd+8CNbKuV5yTUIPpo3UGrAkxfc0P1cTE39PsOuL77sjPAINKGFhDJY90joarRym4E7fJ8cH9aL6IhEc2d8j9jM57etPODbORkt+EGYjVe568M5Fa6HUNe5ttw== 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=fyVkGLUeXyoIdPby+zj+gpDy5nid+jnKbPv0ghJJFfw=; b=bqIA+al54cC4vfnwP+lGVJ4jHn+Hxf6LyvRyQmhWGCXiRhvYkwt+tqen9ksF5y47h9kYHsqQv4t3dY8KUP4tQZdVD0d6zzeZuePrFX7AIoPFMeQerDwEs/GhdxGfJmfn9faqskgsIJns+nJe7Z013r/Y2+ttA2+yLZ2BKNNlk5eyAy/ma+oH0rTCdZ60XvhaUk4HU9pVPLeZxhYfqkoORkKqa+J5HWBqU/odYoir3wORZwJDLbOye0r4sC28EVo9YMtAnVkx7LYOFpP/9AP/nKThuGMBCbPbWrEs0tlWKRAptBjyujDt1aLO5Rkrq097apdzx2yuETI+w4Hmvwww6w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fyVkGLUeXyoIdPby+zj+gpDy5nid+jnKbPv0ghJJFfw=; b=lSXtKU7SYMgftyM2dCXTMaXUQbsp5FX7gCtC43CV5Uxla8X6QhtdoyRtEY3g5Wfjp74KhGWy/4VXM3zT9EODws/hQG97hODKXRce0LdqN6vGoVoFci82ARFUzeHNzpf889PC3nBB7w2fRy65X3SgJUTksBdtAsBsR7SB5QUjXJI= Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM6PR02MB5099.namprd02.prod.outlook.com (2603:10b6:5:51::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.18; Wed, 20 Oct 2021 15:17:06 +0000 Received: from DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::ddec:9436:4971:5d1e]) by DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::ddec:9436:4971:5d1e%4]) with mapi id 15.20.4608.018; Wed, 20 Oct 2021 15:17:06 +0000 From: "STARK, BARBARA H" To: "'Barry Leiba'" , "'last-call@ietf.org'" CC: "'IETF Discussion'" , "'GENDISPATCH List'" , "'The IESG'" , "'draft-eggert-bcp45bis@ietf.org'" Thread-Topic: [Gendispatch] Last Call: (IETF Discussion List Charter) to Best Current Practice Thread-Index: AQHXxQGiT9hAjDW+k0WXqI51EGxDyKvbntKAgAA/woCAABqi8A== Date: Wed, 20 Oct 2021 15:17:06 +0000 Message-ID: References: <163465875866.13316.15860075014903480611@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=att.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 42f6356d-94cd-4e40-5648-08d993dcada5 x-ms-traffictypediagnostic: DM6PR02MB5099: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2733; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5mpdHYt5OD2vDL9GNEzAVRBBgFplHeugYFT3fbEruW+MpNx0vhiGEN5di5/HXJzyhzNaMOalw7zJ4Zif3Ran9AlmDORP6YZ1p3kFxbvt/eoIfFA0SkWTr5f83jUunUZJDoED20X6wMDlXoB2NKVkwTyESF/NRqyvzKgWcaAVP5uqOBURs9/2I02oz+LsKxVmN6CPnRucxmivNygyWRpUZBGYwDsu1G1XZS8oPSJrw78kpYCDLoKLtbNblI+t5ZXeuyRjFE8n1tugIStgcg9/L4PTyW2H9mwHtapEInb+BAdCXWPCOWRfMiMfp4gpdeZpBa/ITNbMFHWBA7yzP7zQFTpuGpl7lBoqjSHM4JMm7WiRSL/VEYF1af0/NC5+MxwCkSgmSeuanU9TCfWlhezzb+IRGBmmgdfB6KZzizo1HwTiZwpy0oatbgkSU2BSJhV2Z9ibAkRl5i76GLALcHXgQqxowLJpboDG6cWh0cv295CWIX3YQyi/CU+HC2H+E7KBsqvTncuCc0kSZrXa6Ik5O2nXyHEjdf4ILp5S2201dFVVvp3K89SuWlxU/F3sDSOfyhU/vNQxrUG6cQeZyxutprZ0zURpDq1xS1Mpt1RyN13P7mn/ifYNYIZPXU3FvT3qOXJBNvDBBahhKg/JjRnunDE7lnZbJEuAhDoN3JjuaOgyBJ44gWcnVazd+413AawC0nPmCMmTT6fzujigTL1I3k9VgzGqRGqaDdgQK3QI7szKYlC71W5SsSBoPNInODFpRKLhultHO9HZ1I0Eghat2vZXbQ+691nBusYNEAAq6G2Uoc4OauB7my3FThnwTtDZYBUgSWhAkFTCF3ddkFqDNsh30QpLcvHMfnrwhd9phjU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR02MB6924.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(966005)(64756008)(38100700002)(76116006)(122000001)(66946007)(82960400001)(2906002)(7696005)(71200400001)(66476007)(66556008)(6506007)(38070700005)(54906003)(8676002)(4001150100001)(8936002)(9686003)(316002)(186003)(52536014)(55016002)(82202003)(26005)(508600001)(83380400001)(110136005)(5660300002)(66574015)(86362001)(53546011)(4326008)(33656002)(66446008)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SE0zUC9UTE5WdTdhNkp3ZWo2ejZXREwwbTk2eHEyVmhLWllLdGhaalp1Y0dZ?= =?utf-8?B?QUpsajJoNDVGU040cXl1bjk3UXFRdjNINGZuMUp4ZGs2SGVIeGJvRWU5NnBq?= =?utf-8?B?WHNiQ2VlNGpRVk4vVHArVnNUUWZmVmNLVnR0VzY5VkpEUWd5dzFOczV1djgr?= =?utf-8?B?ZW05bmM0M1VqU2RXNjJ5QUpyWjdNM0lHRG1Zei8rSklWeGxWSlVZMEpacUJI?= =?utf-8?B?ajRsUFgwSklhT0dCeWtHNVEzOXhLOEZ6bFhaeFkvTHpzelowNkQ1V3I0cEk4?= =?utf-8?B?Rno0MTJ2SUt1b1AwY2d3bWJRVXArdUpMZWVzQTdlVUNEVVRDcHk5VFJqb1Rh?= =?utf-8?B?UHNMK0JmY1Y0OTcyMW1NUmxzRTE3bG1RSjlhak9MS3J3ajRjL2l6K1NoQ3JM?= =?utf-8?B?QTB3OVZMYnZsbGhYOHBQcmoyNWJpS0RXMTc1cmdGVkEzdit0Njk2Z2FycWl0?= =?utf-8?B?K3RZOEUxeXkvQzRlVXlQVDRyaWx0QTVUKzZaVkpkR2RTZ1VxWG1jcTZRcGc4?= =?utf-8?B?dCtQb05ZWjRKUnJ5b3JMc0Y4L2hnY051QVB6R2JHUTZPSEpZZ2xVR1d3Y1hr?= =?utf-8?B?bUhvRzJwM01pV29ITUtmYTlJdkp1Q0NJOG5LNWo2eDZvWEtGVjRuWGYydmxv?= =?utf-8?B?LzlNd0dQa3JMbEptWDBCdHMwcHJ5TlY3WFFIdjl5TEM4cGptZjBvRlRJOW9q?= =?utf-8?B?ekZhZHpWUWU3cjBCYWU0b3VjRUxudkhOOFVtcjZUTElxN3d6Z1JxdTdOeDB0?= =?utf-8?B?TEw5ZW9XY083RlY0QlJRbERZajZEZEluS2s0NCtZcHhyeXJidjNXZ3FkdWR3?= =?utf-8?B?UEhNaTFqalo4QkJiZThOdEcvTFZRalp4ZWpveDdJN2ZIVHhXY0NyNlpnYzYv?= =?utf-8?B?M3Y2TVZWL3JLUERBMXd6dlVreTNvSVhuZnBMOGhSLzJOQk50dGYyOHYwYmJv?= =?utf-8?B?anF2TnZoRXVNeWZFR3hqRnhISTVjN3g5czNjRFl4clAxdFFjaWh0bjgwZVA0?= =?utf-8?B?YkkyM21zTHEvT052V0tBTXVvV2FacmFTUElCM2djM2VrMWlwSnNSL1RmdGhn?= =?utf-8?B?N2x6L3hEVStudFpvV3lpWWh1Zlk1N0JPMDc0NHRVM1pOV1loTXJHWmc5UzZ3?= =?utf-8?B?K2RqdnNjaVRvaWJLalFwTXI3ME0zMlZOQlpzY0txZWZtREZpM0VuL3B4UG5R?= =?utf-8?B?UzlaK0d3d2JORXZjT21RakpMbndBNk1OdEtUSU1FN0JpNlRmT2FPTjg4ZDBt?= =?utf-8?B?bzRndUYxUGFrR0dRcnArZExUeVZ1MWl0dEVXbS8zUWZZYzVPeS83Y1NVU2p0?= =?utf-8?B?S0VFaU1VdWNPZFZMV1RwNW9lbjBJOFBRbkY4a2ZMMG93cUlDanpVTitHclEv?= =?utf-8?B?anhFUHVoMnY2aHJidng5L05UMTRULzU1OHB1UkJtQkZLTHN0clR4cVphNEEv?= =?utf-8?B?U0hBMFliZW1ETUhUWWo3SG5tQWExeHd0UU5Wa1NlV2xGcGZxb1BzeVRiSGdt?= =?utf-8?B?YzVNQlJDVEtRR2NGcUd5ODVxNjMwWCtwcVhoOHBGUWY3SldDY01Ga2ltaC91?= =?utf-8?B?SkZlL1VBTjE4WlB4TzVMcHgyS1VSTmdjVEV2L1FRZkhBTkZVU0lvTTQ3U3Zn?= =?utf-8?B?d0RvSS9kakVaTlZ0L0d5aGJURWtJMVFEWHhRVGNGMXZJay8yYjhGbytjekRu?= =?utf-8?B?dzJ1dEJ1NUFra2duUkw5TWdGcDN0NXgxaWVZU2U5SjVwazlCaXVoZk10MU0y?= =?utf-8?Q?qrdpCE2dkpGvoZ2OfE=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR02MB6924.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 42f6356d-94cd-4e40-5648-08d993dcada5 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2021 15:17:06.4131 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: trImIS8YfdxjyAwD7i/RQf4UMwejcEAP1qSsl9tILIe+V0O0dVd+24otpKkeh2L2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB5099 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: B21EF7B08002815A18ED304C066C1EA8C4DC75B9B1B47B1F8C74661BC34435B72 X-Proofpoint-ORIG-GUID: _wH45qgOs42B60_RN92orJpeAZRN1STj X-Proofpoint-GUID: _wH45qgOs42B60_RN92orJpeAZRN1STj X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-20_05,2021-10-20_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 impostorscore=0 mlxscore=0 suspectscore=0 adultscore=0 mlxlogscore=999 clxscore=1011 malwarescore=0 lowpriorityscore=0 spamscore=0 priorityscore=1501 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110200088 Archived-At: Subject: Re: [Gendispatch] Last Call: (IETF Discussion List Charter) to Best Current Practice X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 15:17:54 -0000 PiA+IEkgZW5jb3VyYWdlIElFVEYgbWFpbGluZyBsaXN0IGNvbnRyaWJ1dG9ycyB0byBsb29rIGNs b3NlbHkgYXQgdGhpcyBkcmFmdC4NCj4gDQo+IEkgaGF2ZSBsb29rZWQgYXQgaXQgY2xvc2VseSwg YW5kIEkgZG8gTk9UIHNoYXJlIHRoZSBjb25jZXJucyByYWlzZWQNCj4gaGVyZS4gIEkgdGhpbmsg dGhlIGRyYWZ0IGlzIGEgcmVhc29uYWJsZSB1cGRhdGUgdG8gQkNQIDQ1LCB0aGF0IGl0DQo+IGNs YXJpZmllcyB0aGUgY2hhcnRlciBmb3IgdGhlIElFVEYgbGlzdCBhbmQgdGhlIFNBQSB0ZWFtJ3Mg cm9sZSwgYW5kDQo+IHRoYXQgYW55dGhpbmcgbW9yZSB0aGFuIHRoaXMgd291bGQgbmVlZCBhIGZy ZXNoIGVmZm9ydCBieSB0aGUNCj4gY29tbXVuaXR5IHRvIG1ha2UgYSBtb3JlIHNpZ25pZmljYW50 IHVwZGF0ZSAtLSB3aGljaCBJIGRvbid0IHRoaW5rIGlzDQo+IG5lZWRlZC4NCj4gDQo+IEkgdGhp bmsgdGhlcmUgaXMgbm8gY29udHJhZGljdGlvbiBiZXR3ZWVuIHRoZSB1c2Ugb2YgV2lraXBlZGlh IHRvDQo+IGV4cGxhaW4gdGhlIGdlbmVyYWwgcm9sZSBvZiBTZXJnZWFudHMgYXQgQXJtcyBhbmQg dGhlIHJvbGUgdGhlIFNBQXMNCj4gaGF2ZSB3aXRoIHJlc3BlY3QgdG8gdGhlIElFVEYgbGlzdC4g IFdpa2lwZWRpYSBkaXNjdXNzZXMgc29tZQ0KPiBtZWNoYW5pc21zIGZvciBhcHBvaW50bWVudCBh bmQgdXNlIG9mIFNBQXMsIGJ1dCB0aG9zZSBhcmUgbm90IHRoZSBvbmx5DQo+IG1lY2hhbmlzbXMu ICBJdCdzIG5vdCB3cm9uZywgYW5kIG5laXRoZXIgaXMgaXQgZXhoYXVzdGl2ZS4NCj4gDQo+IFRo ZSBvbmx5IHdheSB3ZSBoYXZlLCBhdCB0aGlzIHBvaW50LCB0byBtYWtlIGNvbW11bml0eSBhcHBv aW50bWVudHMgaXMNCj4gdGhyb3VnaCB0aGUgTm9tQ29tLCBhbmQgSSB0aGluayBpdCB3b3VsZCBi ZSBhIGJhZCBhcHByb2FjaCB0byBhZGQgU0FBDQo+IHBvc2l0aW9ucyB0byB0aGUgTm9tQ29tJ3Mg c2xhdGUuDQo+IA0KPiBUaGUgZHJhZnQgbWFrZXMgaXQgY2xlYXIgdGhhdCB0aGUgcHVycG9zZSBv ZiB0aGUgU0FBIHRlYW0gaXMgdG8gYWxsb3cNCj4gdGhlIElFVEYgQ2hhaXIgdG8gYXBwb2ludCBw ZW9wbGUgdG8gaGFuZGxlIHRoaXMgcm9sZSwgYW5kIHRoZW4gdG8gc3RlcA0KPiBiYWNrIGFuZCAq bm90KiBiZSBhIGtpbmcsIHRvICpub3QqIGhhdmUgYSBkYXktdG8tZGF5IHJvbGUgaW4NCj4gbW9u aXRvcmluZyBhbmQgbWFuYWdpbmcgdGhlIElFVEYgbGlzdC4gIFRoYXQgaXMgYXMgaXQgc2hvdWxk IGJlLg0KPiANCj4gSSBmaW5kIG5vdGhpbmcgYXQgYWxsIHdyb25nIHdpdGggdGhlIElFVEYgQ2hh aXIgYmVpbmcgdGhlIGVkaXRvciBvZg0KPiB0aGlzIGRyYWZ0OiBMYXJzIGhhcyBmYWlybHkgZWRp dGVkIGl0IGJhc2VkIG9uIGlucHV0LCBhbmQgaXRzIGNvbnRlbnRzDQo+IHJlZmxlY3Qgbm90IExh cnMncyB0aG91Z2h0cywgYnV0IHJvdWdoIGNvbnNlbnN1cyBvZiB0aGUgY29tbXVuaXR5IHNvDQo+ IGZhci4gIFRoYXQgbm90IGV2ZXJ5b25lIGlzIGhhcHB5IHdpdGggZXZlcnl0aGluZyBpdCBzYXlz IHNob3dzIHRoYXQgd2UNCj4gaGF2ZSAqcm91Z2ggY29uc2Vuc3VzKiwgbm90IHVuYW5pbWl0eS4u LiBpdCBkb2VzIG5vdCBzYXkgdGhhdCB0aGUgSUVURg0KPiBDaGFpciBoYXMgZG9uZSBhbnl0aGlu ZyBpbmFwcHJvcHJpYXRlIGhlcmUuDQo+IA0KPiBUaGlzIGlzIHJlYWR5IHRvIGJlIHB1Ymxpc2hl ZCBhbmQgdG8gdXBkYXRlIEJDUCA0NS4NCg0KKzENCkkgZmluZCB0aGUgZGVmaW5pdGlvbiBvZiBT QUEgYXQgImh0dHBzOi8vd3d3LndvcmRuaWsuY29tL3dvcmRzL3NlcmdlYW50JTIwYXQlMjBhcm1z Ig0KdG8gYmUgbW9yZSBjb25zaXN0ZW50IHdpdGggSUVURiB1c2FnZSBidXQgZG9uJ3Qgb2JqZWN0 IHRvIHRoZSBXaWtpcGVkaWEgcGFnZSBiZWluZyB1c2VkDQp0byBoZWxwIHBlb3BsZSB1bmRlcnN0 YW5kIHRoZSBvcmlnaW5zIG9mIHRoZSB0ZXJtLiBVbmRlcnN0YW5kaW5nIHRoZSBvcmlnaW5zIG9m IHRoZSB0ZXJtIGlzDQphIHJlYXNvbmFibGUgdXNlIG9mIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5j ZS4gSSBkbyBub3QgYWdyZWUgd2l0aCBzdWdnZXN0aW9ucyB0aGF0ICJpZiBJRVRGDQp3YW50cyB0 byB1c2UgdGhpcyB0ZXJtIGFuZCBwb2ludCB0byB0aGUgV2lraXBlZGlhIHBhZ2UgdG8gaGVscCBw ZW9wbGUgdW5kZXJzdGFuZCB0aGUNCnRlcm0ncyBvcmlnaW5zLCB0aGVuIElFVEYgbXVzdCBkZWZp bmUgdGhlIHJvbGUgZXhhY3RseSBhcyBkZXNjcmliZWQgb24gdGhlIFdpa2lwZWRpYSBwYWdlIi4N CkkgYWxzbyB3b3VsZCBub3QgYWdyZWUgd2l0aCBhIHN1Z2dlc3Rpb24gdGhhdCAiYmVjYXVzZSBJ RVRGJ3MgZGVmaW5pdGlvbiBvZiB0aGUgU0FBIHJvbGUNCmRvZXMgbm90IHByZWNpc2VseSBtYXRj aCB0aGUgV2lraXBlZGlhIGRlc2NyaXB0aW9uIG9mIHRoZSB0ZXJtJ3Mgb3JpZ2lucywgSUVURiBt dXN0IHVzZQ0KYSBkaWZmZXJlbnQgbmFtZSBmb3IgdGhlIHJvbGUiLg0KTmVpdGhlciBzdWdnZXN0 aW9uIG1ha2VzIHNlbnNlIHRvIG1lLg0KSSBhbHNvIHRoaW5rIHRoZSBwcm9wb3NlZCB1cGRhdGVz IGFyZSBmaW5lIGFuZCBkb24ndCB0aGluayBpdCdzIGEgcHJvYmxlbSBmb3IgTGFycyB0byBoYXZl DQp3cml0dGVuIHRoZW0uDQpCYXJiYXJhDQoNCj4gQmFycnkNCj4gDQo+IE9uIFdlZCwgT2N0IDIw LCAyMDIxIGF0IDU6MjYgQU0gTGxveWQgVw0KPiA8bGxveWQud29vZD00MHlhaG9vLmNvLnVrQGRt YXJjLmlldGYub3JnPiB3cm90ZToNCj4gPg0KPiA+ICAgIEEgc2VyZ2VhbnQtYXQtYXJtcyAoU0FB KSAiaXMgYW4gb2ZmaWNlciBhcHBvaW50ZWQgYnkgYSBkZWxpYmVyYXRpdmUNCj4gPiAgICBib2R5 ICguLi4pIHRvIGtlZXAgb3JkZXIgZHVyaW5nIGl0cyBtZWV0aW5ncyIgW1NBQS1XSUtJUEVESUFd LiAgU0FBcw0KPiA+ICAgIGZvciB0aGUgSUVURiBkaXNjdXNzaW9uIGxpc3QgYXJlIGFwcG9pbnRl ZCBieSB0aGUgSUVURiBDaGFpciBhbmQgYXJlDQo+ID4gICAgZW1wb3dlcmVkIHRvIHJlc3RyaWN0 IHBvc3RpbmcgYnkgYSBwZXJzb24sIG9yIG9mIGEgdGhyZWFkLCB3aGVuIHRoZQ0KPiA+ICAgIGNv bnRlbnQgaXMgaW5hcHByb3ByaWF0ZSBhbmQgcmVwcmVzZW50cyBhIHBhdHRlcm4gb2YgYWJ1c2UN Cj4gPg0KPiA+DQo+ID4gdGhlcmUncyBhbiBpbmhlcmVudCBjb250cmFkaWN0aW9uIGluIHRoYXQg bGl0dGxlIHF1b3RlZCBzbmlwcGV0LCB3aGljaCByZW1haW5zDQo+IHVuZXhwbGFpbmVkIGluIHRo ZSB0ZXh0IG9mIHRoaXMgZHJhZnQgZGVzcGl0ZSBiZWluZyByYWlzZWQgcHJldmlvdXNseSBvbg0K PiBnZW5kaXNwYXRjaC4NCj4gPg0KPiA+IEluIG1hbnkgYm9kaWVzLCB0aGUgYm9keSBpdHNlbGYg YXBwb2ludHMgdGhlIFNBQXMsIGFuZCB0aGF0IFdpa2lwZWRpYSBwYWdlDQo+IHNheXMgYXMgbXVj aCwgYXQgbGVhc3QgdW50aWwgc29tZW9uZSBlZGl0cyBpdCB0byBzYXkgb3RoZXJ3aXNlLg0KPiA+ DQo+ID4gSGVyZSwgaW4gYSBkcmFmdCBiZWluZyB3cml0dGVuIGJ5IHRoZSBJRVRGIENoYWlyLCB0 aGUgdmVyeSBuZXh0IHNlbnRlbmNlIHNheXMNCj4gdGhhdCB0aGUgU0FBcyBhcmUgbm90IGFwcG9p bnRlZCBieSB0aGUgZGVsaWJlcmF0aXZlIGJvZHkgaXRzZWxmIC0gd2hpY2ggaXMgdG8gc2F5LA0K PiB0aGUgbWFpbGluZyBsaXN0IGNvbnRyaWJ1dG9ycyAtIGJ1dCBieSB0aGUgQ2hhaXIuIFdobywg YnkgdGhlIHdheSwgaXMgdGhlIHBlcnNvbg0KPiB3cml0aW5nIHRoaXMgZHJhZnQgZGVzY3JpYmlu ZyB0aGUgQ2hhaXIncyBwb3dlcnMuIFllcywgdGhlIENoYWlyIGlzIHRoZSBwZXJzb24NCj4gZG9p bmcgdGhlIG5lY2Vzc2FyeSB3b3JrIG9mIHdyaXRpbmcgdGhpcyB1cGRhdGUgZHJhZnQsIGJ1dCwg anVzdCBtYXliZSwgaGVhciBtZQ0KPiBvdXQsIHNpbmNlIGl0IGRlc2NyaWJlcyBwb3dlcnMgb2Yg dGhlIENoYWlyLCB0aGUgQ2hhaXIgcmVhbGx5IHNob3VsZG4ndCBoYXZlIGJlZW4NCj4gdGFza2Vk IHdpdGggZG9pbmcgaXQgaW4gdGhlIGZpcnN0IHBsYWNlPw0KPiA+DQo+ID4gVGhpcyBjYXNjYWRp bmcgY29nbml0aXZlIGRpc3NvbmFuY2UgcmVtYWlucyBhIGJhZCBsb29rLCBhbmQgdGhlIGRyYWZ0 IHNob3VsZA0KPiBhdCBsZWFzdCBhdHRlbXB0IHRvIGV4cGxhaW4gdGhlc2UgcG9pbnRzIHNvbWVo b3cgLSAgaGlzdG9yaWNhbCBwcmFjdGljZSwgdW5kZXINCj4gZnVydGhlciByZXZpZXcsIHdlIGRp ZG4ndCByZWFsaXNlIGhvdyBtdWNoIHRoZSBTQUFzIHdlcmUgYXQgdGhlIGJlaGVzdCBvZiB0aGUN Cj4gY2hhaXJzLCB0aGUgU0FBcyBhY3R1YWxseSBoYXZlIHZlcnkgbGl0dGxlIGluZGVwZW5kZW5j ZSwgdGhpcyBpcyBqdXN0IGhvdyBpdCBpcywgdGhlDQo+IFNBQXMgYXJlIG5vdCBhcHBvaW50ZWQg YnkgdGhlIGxpc3QsIGJ1dCBieSB0aGUgY2hhaXIgd2hvIGlzIHdyaXRpbmcgdGhpcyBkcmFmdA0K PiB3aGljaCB0aWdodGVucyBhbmQgdGlkaWVzIGFuZCBkb2N1bWVudHMgcHJldmlvdXMgcHJhY3Rp Y2UsIHdlIGNhbid0IHRydXN0IHRoZSBsaXN0DQo+IHRvIGV2ZW4gc3RheSBvbiB0b3BpYyBhbmQg a2VlcCB0byBhbiB1bmRlZmluZWQgbGV2ZWwgb2YgJ3Byb2Zlc3Npb25hbGlzbScsIHNvDQo+IGhh dmUgaXQgYXBwb2ludCBpdHMgb3duIFNBQXM/IEhhLCB5b3UgbXVzdCBiZSBqb2tpbmcsIElFVEYg TExDIGhhcyBhIHJlcHV0YXRpb24NCj4gdG8gcHJvdGVjdC4NCj4gPg0KPiA+IEkgZG9uJ3Qga25v dyB3aGF0IHRoZSBleHBsYW5hdGlvbiB3aWxsIGJlLCBidXQgdGhlcmUgbmVlZHMgdG8gYmUgb25l LiBKdXN0DQo+IHNheWluZyAnd2VsbCwgdGhlIHdpa2lwZWRpYSBwYWdlIGlzIG5vdCBhIGRpY3Rp b25hcnkgYW5kIGlzIG5vdCBub3JtYXRpdmUnIHdvdWxkDQo+IG5vdCBiZSBlbm91Z2ggLSBhbmQg aWYgcmVmZXJlbmNpbmcgd2lraXBlZGlhIHlvdSdkIG5lZWQgdG8gZ2l2ZSBhIGRhdGUvcmV2aXNp b24sDQo+IGFueXdheSwganVzdCBhcyB3ZSBkbyBmb3IgZHJhZnRzLCBiZWNhdXNlIHdpa2lwZWRp YSBpcyBldGVybmFsbHkgZHJhZnRlZC4NCj4gPg0KPiA+ICh3ZSByZWplY3Qga2luZ3MgZXRjLiBh bmQgdGhlIGNoYWlyIHVuZm9ydHVuYXRlbHkgbG9va3MgaGVyZSB2ZXJ5IG11Y2ggbGlrZSBhDQo+ IGtpbmcgaXNzdWluZyBleGVjdXRpdmUgZmlhdC4gYnV0IHdlIGFsc28gcmVqZWN0IHZvdGluZywg c28gd2UnZCBoYXZlIHRvLi4uIGh1bQ0KPiBiZXR3ZWVuIGNhbmRpZGF0ZXM/KQ0KPiA+DQo+ID4g VGhlIGRyYWZ0IGNhbid0IHNraXAgYXJvdW5kIHRoaXMsIGJ1dCBpbW8gZG9lcyBoYXZlIHRvIGV4 cGxpY2l0bHkgYWRkcmVzcyBhbmQNCj4gZXhwbGFpbiB0aGVzZSBwb2ludHMgaW4gaXRzIHRleHQs IGFuZCB0aHVzIHNoZWQgc29tZSBsaWdodCBvbiB0aGUgdW5kZXJseWluZw0KPiBwaGlsb3NvcGh5 IG9mIGxpc3QgZ292ZXJuYW5jZSB3aGljaCBtdXN0IHVuZGVycGluIGFuZCBzdXBwb3J0IHRoZSBy ZWFzb25pbmcNCj4gZ2l2ZW4uICBTb21laG93Lg0KPiA+DQo+ID4gSG93IHRoZSBkcmFmdCBjaG9v c2VzIHRvIGRvIHRoaXMgd2lsbCBpbW8gc2F5IGEgbG90IGFib3V0IHRoZSBJRVRGLg0KPiA+DQo+ ID4gSSBlbmNvdXJhZ2UgSUVURiBtYWlsaW5nIGxpc3QgY29udHJpYnV0b3JzIHRvIGxvb2sgY2xv c2VseSBhdCB0aGlzIGRyYWZ0Lg0KPiA+DQo+ID4gTGxveWQgV29vZA0KPiA+IGxsb3lkLndvb2RA eWFob28uY28udWsNCj4gPg0KPiA+IE9uIDIwIE9jdCAyMDIxLCBhdCAwMjo1MywgVGhlIElFU0cg PGllc2ctc2VjcmV0YXJ5QGlldGYub3JnPiB3cm90ZToNCj4gPg0KPiA+IA0KPiA+IFRoZSBJRVNH IGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSBhbiBpbmRpdmlkdWFsIHN1Ym1pdHRlciB0byBj b25zaWRlciB0aGUNCj4gPiBmb2xsb3dpbmcgZG9jdW1lbnQ6IC0gJ0lFVEYgRGlzY3Vzc2lvbiBM aXN0IENoYXJ0ZXInDQo+ID4gIDxkcmFmdC1lZ2dlcnQtYmNwNDViaXMtMDYudHh0PiBhcyBCZXN0 IEN1cnJlbnQgUHJhY3RpY2UNCj4gPg0KPiA+IFRoZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNp c2lvbiBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0cyBmaW5hbA0KPiA+IGNvbW1l bnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBjb21tZW50cyB0byB0 aGUNCj4gPiBsYXN0LWNhbGxAaWV0Zi5vcmcgbWFpbGluZyBsaXN0cyBieSAyMDIxLTExLTIzLiBF eGNlcHRpb25hbGx5LCBjb21tZW50cyBtYXkNCj4gPiBiZSBzZW50IHRvIGllc2dAaWV0Zi5vcmcg aW5zdGVhZC4gSW4gZWl0aGVyIGNhc2UsIHBsZWFzZSByZXRhaW4gdGhlIGJlZ2lubmluZw0KPiA+ IG9mIHRoZSBTdWJqZWN0IGxpbmUgdG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcuDQo+ID4NCj4g PiBBYnN0cmFjdA0KPiA+DQo+ID4NCj4gPiAgIFRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNr IEZvcmNlIChJRVRGKSBkaXNjdXNzaW9uIG1haWxpbmcgbGlzdA0KPiA+ICAgZnVydGhlcnMgdGhl IGRldmVsb3BtZW50IGFuZCBzcGVjaWZpY2F0aW9uIG9mIEludGVybmV0IHRlY2hub2xvZ3kNCj4g PiAgIHRocm91Z2ggdGhlIGdlbmVyYWwgZGlzY3Vzc2lvbiBvZiB0b3BpY3MgZm9yIHdoaWNoIG5v IGRlZGljYXRlZA0KPiA+ICAgbWFpbGluZyBsaXN0cyBleGlzdHMuICBBcyB0aGlzIGlzIHRoZSBt b3N0IGdlbmVyYWwgSUVURiBtYWlsaW5nIGxpc3QsDQo+ID4gICBjb25zaWRlcmFibGUgbGF0aXR1 ZGUgaXMgYWxsb3dlZCwgYnV0IHRoZXJlIGFyZSBwb3N0cyBhbmQgdG9waWNzIHRoYXQNCj4gPiAg IGFyZSB1bnN1aXRhYmxlIGZvciB0aGlzIG1haWxpbmcgbGlzdC4NCj4gPg0KPiA+ICAgVGhpcyBk b2N1bWVudCBvYnNvbGV0ZXMgUkZDMzAwNS4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IFRoZSBm aWxlIGNhbiBiZSBvYnRhaW5lZCB2aWENCj4gPiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19f aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZWdnZXJ0LQ0KPiBiY3A0NWJp cy9fXzshIUJoZFQhMHFoSExrUkxCQ3pmejJfQjB6WUtjVC0NCj4gODdseG5FczdwNVhFblc0Ymht VEhwX1I4dmRjNmZjaEVoR3JOVFJ3JA0KPiA+DQo+ID4NCj4gPg0KPiA+IE5vIElQUiBkZWNsYXJh dGlvbnMgaGF2ZSBiZWVuIHN1Ym1pdHRlZCBkaXJlY3RseSBvbiB0aGlzIEktRC4NCj4gPg0KPiA+ DQo+ID4NCj4gPg0KPiA+DQo+ID4gLS0NCj4gPiBHZW5kaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4g PiBHZW5kaXNwYXRjaEBpZXRmLm9yZw0KPiA+DQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMv X19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dlbmRpc3BhdGMNCj4gaF9f OyEhQmhkVCEwcWhITGtSTEJDemZ6Ml9CMHpZS2NULQ0KPiA4N2x4bkVzN3A1WEVuVzRiaG1USHBf Ujh2ZGM2ZmNoR2ZpZHhmSkEkDQo+ID4NCj4gPiAtLQ0KPiA+IEdlbmRpc3BhdGNoIG1haWxpbmcg bGlzdA0KPiA+IEdlbmRpc3BhdGNoQGlldGYub3JnDQo+ID4NCj4gaHR0cHM6Ly91cmxkZWZlbnNl LmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VuZGlzcGF0 Yw0KPiBoX187ISFCaGRUITBxaEhMa1JMQkN6ZnoyX0IwellLY1QtDQo+IDg3bHhuRXM3cDVYRW5X NGJobVRIcF9SOHZkYzZmY2hHZmlkeGZKQSQNCg0K From nobody Wed Oct 20 09:54:19 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAEB3A087C; Wed, 20 Oct 2021 09:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rBwsXZMW1Oc; Wed, 20 Oct 2021 09:54:12 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7193A0819; Wed, 20 Oct 2021 09:54:11 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mdEqv-0004iq-Nh; Wed, 20 Oct 2021 12:54:09 -0400 Date: Wed, 20 Oct 2021 12:54:03 -0400 From: John C Klensin To: "Salz, Rich" , gendispatch@ietf.org cc: ietf@ietf.org, Spencer Dawkins Message-ID: In-Reply-To: <4BDF1DD9-9D30-499F-8C26-1E7790F2A729@akamai.com> References: <4BDF1DD9-9D30-499F-8C26-1E7790F2A729@akamai.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Gendispatch] Agenda item request X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 16:54:17 -0000 I concur with Rich's request and favor a discussion but, if we are going to do that, I request that draft-klensin-nomcom-term (yes, from 2005-2006) be added as well. Unless Spencer has vigorous objections, I'll try to find the original and get a version with current dates, affiliations, etc., posted within the next several days. The abstract of that I-D read: A consensus is emerging in the IETF that very long tenure in leadership roles is not in the best interests of the community. While, in theory, that advice could simply be given to the NomCom, there is reason to believe that a different model for consideration of renewal or replacement for members of the leadership would be more efficient for the NomCom and would impose less hardship on incumbents and the community. This document outlines that alternate method. In addition to proposing an approach that would limit most Nomcom appointees to two terms and change the way Nomcoms review appointees, Section 3 (of -01) reviews the discussions at the time about other alternatives including hard term limits. john --On Wednesday, October 20, 2021 14:37 +0000 "Salz, Rich" wrote: > I would like to have this on the next GENDISPATCH agenda. > > Name: draft-rsalz-termlimits > Revision: 00 > Title: Term limits for IETF Leadership Positions > Document date: 2021-10-20 > Group: Individual Submission From nobody Wed Oct 20 10:23:49 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706073A0A83 for ; Wed, 20 Oct 2021 10:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ealFQ74nXsfn for ; Wed, 20 Oct 2021 10:23:45 -0700 (PDT) Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40BA03A0A7D for ; Wed, 20 Oct 2021 10:23:45 -0700 (PDT) Received: by mail-ua1-f44.google.com with SMTP id a17so7987197uax.12 for ; Wed, 20 Oct 2021 10:23:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oq4qb24Uakksjt4nnnOKU97IAGQz9Z0vd8cbRuDfiiU=; b=MEp/rsQFzEn3GsRKd95P9vu06vEte2Fwiw2WfSi0blwtU4bsYjRAlD24jqf8Kwj906 8O1+JPkYU+XVh425BtBq1N15ixwkxn+QuwiYH7mhZAc8ZgEWfMpZ8myxDdFuA+5uYgpV v5Fako9w/eqksO14JpLkrA6S1EpuhTgFjQu4kYpe5nprivW3GShgMawF8ifOnPH2OGwl maIyzbSX5HfXi24ZNLTGhJ3eB9PZ0KgPXCvd8aGzQF4DjoCJh1scp2+mBB14sCUGOomE b19mDNnZZBLBi4aSSCkMUr/Chv5fZ6Omi1Y7Ifm6TSWU3X8jBsHwHHrTo9PqTwNHl/3Z cf7Q== X-Gm-Message-State: AOAM530GsLKYWWfQE/LCpuBtBocs9ZqjdyyKIN9/qIuIIeMaXLjoE5hy 3k7MSxzx4yvkMi00sW9BkEfzm7InsxQxV6MiQMnazEQwM1U= X-Google-Smtp-Source: ABdhPJwf0pZdq8wm4lUBAn6mHiPAOXysSniPj4C48u/Snfe0ar+t/ix19ww5HeVhIopxWKs8OZXzyqHt8RVj6Eka/Lc= X-Received: by 2002:a9f:36f0:: with SMTP id p103mr704404uap.42.1634750624202; Wed, 20 Oct 2021 10:23:44 -0700 (PDT) MIME-Version: 1.0 References: <4BDF1DD9-9D30-499F-8C26-1E7790F2A729@akamai.com> In-Reply-To: <4BDF1DD9-9D30-499F-8C26-1E7790F2A729@akamai.com> From: Barry Leiba Date: Wed, 20 Oct 2021 13:23:32 -0400 Message-ID: To: "Salz, Rich" Cc: "gendispatch@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Gendispatch] draft-rsalz-termlimits X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 17:23:48 -0000 Rich, thanks for bringing this to discussion. First: I am very strongly *against* hard term limits, as it places unreasonable limitations on the appointment process. In a public voting system, it's antidemocratic, artificially eliminating the ability to vote for whom one thinks is best. In our NomCom system, it restricts the NomCom from considering excellent candidates who have been doing well and can be expected to continue that way. And it would make it impossible for a NomCom to re-appoint an excellent AD (say), when there are no good alternatives, ending us up with a bad choice because it's the best the NomCom had to work with. Second, I am very strongly *for* soft term limit guidance. Specifically saying that NomComs MUST consider more than two terms to be atypical and more than three to be truly exceptional, and [etc, etc, wording like that with further explanation] would absolutely get my support. But NomComs *have* to have options to deal with situations where re-appointing someone for a third (or fourth) term really *is* the right thing *in this case*. Third, while I appreciate the desire not to have ADs move straight to the IAB or vice-versa, and while a one-year gap before making the move is not unreasonable, the issue is more of a challenge for someone moving into the IETF Chair role. Here are two reasons why: - It's critical for an IETF Chair to have experience as an AD. And, while Lars's experience is older and he is doing and will do fine, we've generally had more recent ADs step into the IETF Chair position. I would not want to limit the NomCom by saying that they can't appoint a sitting AD as the next IETF Chair. - The IETF Chair is only appointed every two years. An AD who wants the IETF Chair position would have to step down at least a year ahead, and an AD whose term is in sync with the IETF Chair appointment would have to step down at least two years ahead. Given that a one-term IETF Chair is likely to get a second term, that could move to four years ahead. Now we have an AD who might have been a great choice for IETF Chair, but has to wait four years -- and be four years away from the AD experience -- before she will really be considered by the NomCom (especially if we should also move in the direction of JCK's proposal). So *if* we should go in the direction Rich proposes, I would want to see an exception for IETF Chair appointments. But, really, I'd much rather see us move toward giving NomComs very clear and strong guidance on what the community expects, but leave them the option to do what needs to be done as the situation might require. Barry From nobody Wed Oct 20 11:16:51 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4E33A0BBC; Wed, 20 Oct 2021 11:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yjhutapbTiI; Wed, 20 Oct 2021 11:16:44 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 2C5643A0BC8; Wed, 20 Oct 2021 11:16:43 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.1.2/8.16.1.2) with SMTP id 19KFUnB5008184; Wed, 20 Oct 2021 19:16:42 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=9G2EqnarND2moCyx/J70LdkPf2vJPJfhhFCvbacJEJs=; b=RDSR+Cum9ztWXMG1NWK/HTkLOUW5UqrZlcuGxD+MVvhfBLKD//ff3j2B15EY/g9BnxF+ Tyu1jAxwumF+GfFcP1JXdcT7zaAxjGMLbhXnOAyoTb4KckA97wtrJLwtTgS0yHy+Kqj2 OASQhAAqvykPC6LLzQrSz2COdv20cMmZH2/MH8Of34F/+aA3P8trbkK+TKvcOhZHtlrd m2sFMeqwMKr1vxsMAnuECDCMTr73QGU+aiZgorAvjdcGxqWw87vL9JZMPL1iKUW/5pBS 1ToUHgBq1k5xRhtJIbi9Ge1++s1CUzkzkdqezM9fMvuTW2fn4gS5vn2m9jj/PoWcpniY yQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 3btntnatck-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Oct 2021 19:16:42 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 19KI6gag032666; Wed, 20 Oct 2021 14:16:41 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 3bt085t25s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 20 Oct 2021 14:16:41 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Wed, 20 Oct 2021 14:16:40 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Wed, 20 Oct 2021 14:16:40 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.023; Wed, 20 Oct 2021 14:16:40 -0400 From: "Salz, Rich" To: Barry Leiba CC: "gendispatch@ietf.org" Thread-Topic: draft-rsalz-termlimits Thread-Index: AQHXxddAKjIdH+LOF0mnbpXJbOhEqavcMZAA Date: Wed, 20 Oct 2021 18:16:39 +0000 Message-ID: <631045B5-9249-41C1-AC0B-C4D33AE254EE@akamai.com> References: <4BDF1DD9-9D30-499F-8C26-1E7790F2A729@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.54.21101001 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: <7AC309AD200E8341BBE6A08ABC24D48A@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-20_06:2021-10-20, 2021-10-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=726 spamscore=0 malwarescore=0 adultscore=0 phishscore=0 bulkscore=0 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110200102 X-Proofpoint-ORIG-GUID: nppe56Gf9btNwmJixyPh2scAEFUCUBSK X-Proofpoint-GUID: nppe56Gf9btNwmJixyPh2scAEFUCUBSK X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-20_06,2021-10-20_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=673 priorityscore=1501 malwarescore=0 phishscore=0 spamscore=0 clxscore=1011 bulkscore=0 lowpriorityscore=0 impostorscore=0 mlxscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110200104 Archived-At: Subject: Re: [Gendispatch] draft-rsalz-termlimits X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 18:16:50 -0000 Tm90ZSB0aGF0IHRlcm0gbGltaXRzIGlzIG5vdCBxdWl0ZSB0aGUgY29ycmVjdCB0ZXJtLCBidXQg aXQncyBjbG9zZSBlbm91Z2ggdG8gZm9zdGVyIGRpc2N1c3Npb24uDQoNClRoZSBsaW1pdCBpcyBu byBtb3JlIHRoYW4gdHdvIGNvbnNlY3V0aXZlIHRlcm1zLiAgSXMgdGhlcmUgYSBvbmUtd29yZCBk ZXNjcmlwdGlvbiBmb3IgdGhhdD8NCg0KPiAgICBUaGlyZCwgd2hpbGUgSSBhcHByZWNpYXRlIHRo ZSBkZXNpcmUgbm90IHRvIGhhdmUgQURzIG1vdmUgc3RyYWlnaHQgdG8NCiAgICB0aGUgSUFCIG9y IHZpY2UtdmVyc2EsIGFuZCB3aGlsZSBhIG9uZS15ZWFyIGdhcCBiZWZvcmUgbWFraW5nIHRoZSBt b3ZlDQogICAgaXMgbm90IHVucmVhc29uYWJsZSwgdGhlIGlzc3VlIGlzIG1vcmUgb2YgYSBjaGFs bGVuZ2UgZm9yIHNvbWVvbmUNCiAgICBtb3ZpbmcgaW50byB0aGUgSUVURiBDaGFpciByb2xlLiAg SGVyZSBhcmUgdHdvIHJlYXNvbnMgd2h5Og0KDQpJIGFncmVlIGl0J3MgYW4gaXNzdWUuIEkgdGhp bmsgdGhlIG1vcmUgaW1wb3J0YW50IGlzc3VlLCBub3csIGlzIHRvIGdldCAibmV3IGJsb29kIiBp bnRvIGxlYWRlcnNoaXAgcG9zaXRpb25zLiBPdGhlcnMgb2YgY291cnNlIG1heSBkaXNhZ3JlZS4N Cg0KICAgID4gTm93IHdlIGhhdmUgYW4gQUQgd2hvIG1pZ2h0IGhhdmUgYmVlbiBhIGdyZWF0IGNo b2ljZSBmb3INCiAgICBJRVRGIENoYWlyLCBidXQgaGFzIHRvIHdhaXQgZm91ciB5ZWFycyAtLSBh bmQgYmUgZm91ciB5ZWFycyBhd2F5IGZyb20NCiAgICB0aGUgQUQgZXhwZXJpZW5jZSAtLSBiZWZv cmUgc2hlIHdpbGwgcmVhbGx5IGJlIGNvbnNpZGVyZWQgYnkgdGhlDQogICAgTm9tQ29tIChlc3Bl Y2lhbGx5IGlmIHdlIHNob3VsZCBhbHNvIG1vdmUgaW4gdGhlIGRpcmVjdGlvbiBvZiBKQ0sncw0K ICAgIHByb3Bvc2FsKS4NCg0KVGhlIGRvd25zaWRlIG9mIHRoaXMgaXMgd2UgZG9uJ3Qga25vdyB3 aG8gd291bGQgbWFrZSBhIGdyZWF0IElFVEYgQ2hhaXIgYmVjYXVzZSBpZiB0aGUgQUQtPkNoYWly IGJpYXMgdGhhdCBwcmVzZW50bHkgZXhpc3RzLg0KDQoNCg== From nobody Wed Oct 20 11:34:32 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9293A0C92 for ; Wed, 20 Oct 2021 11:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6DEdlgthNjl for ; Wed, 20 Oct 2021 11:34:24 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC6B3A0C7C for ; Wed, 20 Oct 2021 11:34:22 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id k7so291968wrd.13 for ; Wed, 20 Oct 2021 11:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wIsbup+7fHcFAXTMIcRZXBYQI6Cr9QiaSm8MqTzWclc=; b=UTlszrmQQMp30WnKyUQf6/D3JA1iW7GREj6XF4H69JjHOp7S/pqIf/Y6W1baizLTZt 3FPjw82KxxJt9J2c24SvGn0Pf2A7wceDobjaSlS89afPe3S2vC34SqPtV0pnR/nBBf7m vny+UhBXGFxBY1X2LQYVxHHQJppo6DhI3M/5M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wIsbup+7fHcFAXTMIcRZXBYQI6Cr9QiaSm8MqTzWclc=; b=v7jk9rEGFkDkjnkrOoBpipwIFXEkp3k10+TZxBVdEcjNnq0Vcpb6Psqp6aAoFQ/39/ dTELXCI/30PKFeey4zC9lVjiMy37bUQaL7qt/g47M7CaN2ZGMStmys1sMV2wlkM/MpeW XTOou3zJ+m8OW6llFMeUwi62fZ0yWBkzZxmy994j3u4kGWKUSEwVFidfwhtrJ1dxZlCZ HQdiKYvw8GQIPkZ5qlYzbDfnyaGbN5f3pTMn6XKWPjm50yGXrP4SGwsL7tNFcQO3vlib ViHgseFoJhr5324RKdz7ug4opnb23bHScabWU1MpdUX5X9MzkQzhBWTHNqfdP3jUW5VN QiHA== X-Gm-Message-State: AOAM531nOSi299gNsI8HFYAMtH2k64UUGPGhVSKkV3iCshsYlF9rlTpY ChqsKlJNr/tS3gHfUkV1o9lcXivn3ZnmABRLZwPC/pk1 X-Google-Smtp-Source: ABdhPJycMwy7Vj3C30NO/7bq0cmm0O70cGGECVfWchzYTYwat6qvjmpHRIAY4lh48G1OPfjrybPBP9jW30iV/iK9xCE= X-Received: by 2002:a05:6000:18a3:: with SMTP id b3mr1135191wri.178.1634754858201; Wed, 20 Oct 2021 11:34:18 -0700 (PDT) MIME-Version: 1.0 References: <4BDF1DD9-9D30-499F-8C26-1E7790F2A729@akamai.com> <631045B5-9249-41C1-AC0B-C4D33AE254EE@akamai.com> In-Reply-To: <631045B5-9249-41C1-AC0B-C4D33AE254EE@akamai.com> From: Kyle Rose Date: Wed, 20 Oct 2021 14:34:07 -0400 Message-ID: To: "Salz, Rich" Cc: Barry Leiba , "gendispatch@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009e489205cecd0699" Archived-At: Subject: Re: [Gendispatch] draft-rsalz-termlimits X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 18:34:30 -0000 --0000000000009e489205cecd0699 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 20, 2021 at 2:16 PM Salz, Rich wrote: > > Third, while I appreciate the desire not to have ADs move straight to > the IAB or vice-versa, and while a one-year gap before making the move > is not unreasonable, the issue is more of a challenge for someone > moving into the IETF Chair role. Here are two reasons why: > > I agree it's an issue. I think the more important issue, now, is to get > "new blood" into leadership positions. Others of course may disagree. > I think part of Barry's point is that we have a supply problem: not enough good candidates. Further constraining supply at a time like that is probably unwise. If you want new blood and not end up with incompetent leadership, you have to somehow solve that issue. I might be more inclined to agree on the desirability of term limits if there were lots of deserving candidates being passed over, but that is simply not the case today. Kyle --0000000000009e489205cecd0699 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 20, 2021 at 2:16 PM Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org= > wrote:
>=C2=A0 =C2=A0 Third, while I appreciate the desire not= to have ADs move straight to
=C2=A0 =C2=A0 the IAB or vice-versa, and while a one-year gap before making= the move
=C2=A0 =C2=A0 is not unreasonable, the issue is more of a challenge for som= eone
=C2=A0 =C2=A0 moving into the IETF Chair role.=C2=A0 Here are two reasons w= hy:

I agree it's an issue. I think the more important issue, now, is to get= "new blood" into leadership positions. Others of course may disa= gree.

I think part of Barry's point is that we have a s= upply problem: not enough good candidates. Further constraining supply at a= time like that is probably unwise. If you want new blood and not end up wi= th incompetent leadership, you have to somehow solve that issue. I might be= more inclined to agree on the desirability of term limits if there were lo= ts of deserving candidates being passed over, but that is simply not the ca= se today.

Kyle

--0000000000009e489205cecd0699-- From nobody Wed Oct 20 11:49:27 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6163E3A0CDB for ; Wed, 20 Oct 2021 11:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDzBUIkc60wl for ; Wed, 20 Oct 2021 11:49:20 -0700 (PDT) Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72CF3A0CDD for ; Wed, 20 Oct 2021 11:49:20 -0700 (PDT) Received: by mail-vk1-f170.google.com with SMTP id u130so772612vku.2 for ; Wed, 20 Oct 2021 11:49:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jrXBTqG50VK61n4oSTaLs8DoYa+3UOfU6L5yI8Vg4dk=; b=ER+3Y1rvTkZdc0nJgxG4SzrMXDne5i/zxWxp/Ug25MNRmWU+UuEjPbtvnNe552s4fh XluwR8LNfTfomc6vk/YXFZ2DSsyR1f818nR5sqoUVoFtVGPVMp6BLdBnkxZ66Ch33uzN l2zhM9ry8BMBFNzYi67CijoPjPUeQKbNPuYd2nHBq1jeg9lXjzZX9AQ/xFK9nVEUJ8ua 9cJGgMXoLYhFo99JNKByBYII5uYCEZTm9cnrUdBXbRt26V04x3Q2IWqWyYUWvtbC/nlI f9Kv/l6/1kApeH2BUNwsc+poKtGdWM2iuEkIb/G75qlevnlA/e1qaqghKiuefyNz4/uh dovA== X-Gm-Message-State: AOAM533eIM3VCHCg58HJGsDjeOFHkDUEcrdFjtwYYN6yP8S2rNhoflf0 wAXabaLpCESXBgUMneZriVG1TL13O2CiNqlvmMOaWPlHoIo= X-Google-Smtp-Source: ABdhPJwltVzZKNKmAeftFVbSfKokp8dXlOwre5FR/WlDQp5N2DKJhEXzun0xYPwvyHCzuOxgtC46iK781o6usTQSvDw= X-Received: by 2002:a05:6122:da0:: with SMTP id bc32mr1434164vkb.4.1634755759759; Wed, 20 Oct 2021 11:49:19 -0700 (PDT) MIME-Version: 1.0 References: <4BDF1DD9-9D30-499F-8C26-1E7790F2A729@akamai.com> <631045B5-9249-41C1-AC0B-C4D33AE254EE@akamai.com> In-Reply-To: From: Barry Leiba Date: Wed, 20 Oct 2021 14:49:08 -0400 Message-ID: To: Kyle Rose Cc: "Salz, Rich" , "gendispatch@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Gendispatch] draft-rsalz-termlimits X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 18:49:26 -0000 Exactly, Kyle; thanks for rephrasing more clearly. Barry On Wed, Oct 20, 2021 at 2:34 PM Kyle Rose wrote: > > On Wed, Oct 20, 2021 at 2:16 PM Salz, Rich wrote: >> >> > Third, while I appreciate the desire not to have ADs move straight = to >> the IAB or vice-versa, and while a one-year gap before making the mo= ve >> is not unreasonable, the issue is more of a challenge for someone >> moving into the IETF Chair role. Here are two reasons why: >> >> I agree it's an issue. I think the more important issue, now, is to get = "new blood" into leadership positions. Others of course may disagree. > > > I think part of Barry's point is that we have a supply problem: not enoug= h good candidates. Further constraining supply at a time like that is proba= bly unwise. If you want new blood and not end up with incompetent leadershi= p, you have to somehow solve that issue. I might be more inclined to agree = on the desirability of term limits if there were lots of deserving candidat= es being passed over, but that is simply not the case today. > > Kyle > From nobody Wed Oct 20 12:14:54 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D31C3A0DB2 for ; Wed, 20 Oct 2021 12:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JkxlQie8nqx for ; Wed, 20 Oct 2021 12:14:46 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 DA77F3A0DB9 for ; Wed, 20 Oct 2021 12:14:46 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19KIgCBe000995; Wed, 20 Oct 2021 20:14:44 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=B0UEXngIz4YzA1AN8c4xY5bRUTCyHiBffruX/7Tq7cg=; b=YNTBHizu5iSSn5HPJTvJx/3n7IWY7DanF/3rCwKbTEHKuDkqs/4mO6ZjLJyrdZ5kthHW fzad/sj3Tov3CxzRj2IFnXm/ZnD0GqPHXiME/vDyaH9kA+O2WH6Q8VJHK6XJLoM0urqu P95xcUsngNIiG/Z9Ji0hvpuhRNDu1CGbSV9K7liVi84IB1Ma6wNZotI333COBdHwmmby kRnM+DTQ06EDNLr4RbDFNZrt0Tqtu5Ofml+Tsqfp2yMB0f5fNDHXZc+aGx6keeBm7WHO m01TQxhYmc2HN2ac14/eJJWKWZ2bXqv+8ndQs0OJyAzBawOXypQbUylJu7pQf5QXJ2e8 lQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 3btjjkrk7s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Oct 2021 20:14:43 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 19KJ5M8K019118; Wed, 20 Oct 2021 15:14:42 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 3bsxhrac7f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 20 Oct 2021 15:14:42 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Wed, 20 Oct 2021 15:14:41 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.023; Wed, 20 Oct 2021 15:14:41 -0400 From: "Salz, Rich" To: Kyle Rose CC: Barry Leiba , "gendispatch@ietf.org" Thread-Topic: [Gendispatch] draft-rsalz-termlimits Thread-Index: AQHXxddAKjIdH+LOF0mnbpXJbOhEqavcMZAAgABH8YD//8hGAA== Date: Wed, 20 Oct 2021 19:14:41 +0000 Message-ID: <99143DD1-6AF2-4D50-9467-B2E6FF83B7C0@akamai.com> References: <4BDF1DD9-9D30-499F-8C26-1E7790F2A729@akamai.com> <631045B5-9249-41C1-AC0B-C4D33AE254EE@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.54.21101001 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_99143DD16AF24D509467B2E6FF83B7C0akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-20_06:2021-10-20, 2021-10-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 bulkscore=0 mlxlogscore=693 mlxscore=0 suspectscore=0 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110200109 X-Proofpoint-GUID: Yxgo0vxsEgoj07zsPBZve4m-z2xQpS31 X-Proofpoint-ORIG-GUID: Yxgo0vxsEgoj07zsPBZve4m-z2xQpS31 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-20_06,2021-10-20_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=627 adultscore=0 suspectscore=0 clxscore=1011 impostorscore=0 bulkscore=0 malwarescore=0 lowpriorityscore=0 mlxscore=0 phishscore=0 priorityscore=1501 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110200110 Archived-At: Subject: Re: [Gendispatch] draft-rsalz-termlimits X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 19:14:52 -0000 --_000_99143DD16AF24D509467B2E6FF83B7C0akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgdGhpbmsgcGFydCBvZiBCYXJyeSdzIHBvaW50IGlzIHRoYXQgd2UgaGF2ZSBhIHN1cHBs eSBwcm9ibGVtOiBub3QgZW5vdWdoIGdvb2QgY2FuZGlkYXRlcy4NCg0KSSBkb27igJl0IHRoYXQg cG9pbnQgaXMgcHJvdmVuLiAgSSBjb3VsZCBhZ3JlZSB0aGF0IHdlIGRvbuKAmXQgaGF2ZSBlbm91 Z2ggY2FuZGlkYXRlcywgYnV0IHdoZXRoZXIgdGhleSBhcmUgZ29vZCBvciBub3QgaXMgdW5rbm93 bi4NCg0KDQogICogICBJZiB5b3Ugd2FudCBuZXcgYmxvb2QgYW5kIG5vdCBlbmQgdXAgd2l0aCBp bmNvbXBldGVudCBsZWFkZXJzaGlwLCB5b3UgaGF2ZSB0byBzb21laG93IHNvbHZlIHRoYXQgaXNz dWUNCg0KSXTigJlzIG5vdCBjbGVhciB0aGF0IHdlIHdpbGwgZW5kIHVwIHdpdGgg4oCcaW5jb21w ZXRlbnTigJ0gbGVhZGVyc2hpcC4gSXTigJlzIG5vdCBldmVuIGNsZWFyIHdoYXQgdGhhdCBtZWFu cywgYmV5b25kIOKAnEkga25vdyBpdCB3aGVuIEkgc2VlIGl0LuKAnSBJdCBpcyBhbHNvIG5vdCBj bGVhciBpZiBoYXZpbmcg4oCcbmV3IGJsb29k4oCdIGlzIHdvcnNlIHRoYW4gdGhlIGN1cnJlbnQg cGF0aC4NCg0KSSBhbSBvcHBvc2VkIHRvIG1ha2luZyBpdCDigJxzdHJvbmcgZ3VpZGFuY2XigJ0g dG8gTm9tQ29tIGJlY2F1c2Ugbm9ib2R5IGlzIGluY2VudGl2aXplZCB0byBmaW5kIGFkZGl0aW9u YWwgY2FuZGlkYXRlcy4NCg0K --_000_99143DD16AF24D509467B2E6FF83B7C0akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjExMzA3ODQ3MTE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi05NTYzOTk4MDQgLTkyMzI0ODI4NCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjU5MDY7DQoJbXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1hbnNp LWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8dWwgc3R5bGU9Im1hcmdp bi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPnRoaW5rIHBhcnQgb2YgQmFycnkncyBwb2ludCBpcyB0aGF0IHdl IGhhdmUgYSBzdXBwbHkgcHJvYmxlbTogbm90IGVub3VnaCBnb29kIGNhbmRpZGF0ZXMuPG86cD48 L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JIGRvbuKAmXQgdGhh dCBwb2ludCBpcyBwcm92ZW4uJm5ic3A7IEkgY291bGQgYWdyZWUgdGhhdCB3ZSBkb27igJl0IGhh dmUgZW5vdWdoIGNhbmRpZGF0ZXMsIGJ1dCB3aGV0aGVyIHRoZXkgYXJlIGdvb2Qgb3Igbm90IGlz IHVua25vd24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N Cjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SWYgeW91IHdhbnQgbmV3IGJsb29k IGFuZCBub3QgZW5kIHVwIHdpdGggaW5jb21wZXRlbnQgbGVhZGVyc2hpcCwgeW91IGhhdmUgdG8g c29tZWhvdyBzb2x2ZSB0aGF0IGlzc3VlPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JdOKAmXMgbm90IGNsZWFyIHRoYXQgd2Ugd2lsbCBlbmQgdXAgd2l0aCDigJxpbmNvbXBl dGVudOKAnSBsZWFkZXJzaGlwLiBJdOKAmXMgbm90IGV2ZW4gY2xlYXIgd2hhdCB0aGF0IG1lYW5z LCBiZXlvbmQg4oCcSSBrbm93IGl0IHdoZW4gSSBzZWUgaXQu4oCdIEl0IGlzIGFsc28gbm90IGNs ZWFyIGlmIGhhdmluZyDigJxuZXcgYmxvb2TigJ0gaXMgd29yc2UgdGhhbiB0aGUgY3VycmVudCBw YXRoLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG9wcG9zZWQgdG8gbWFraW5nIGl0IOKA nHN0cm9uZyBndWlkYW5jZeKAnSB0byBOb21Db20gYmVjYXVzZSBub2JvZHkgaXMgaW5jZW50aXZp emVkIHRvIGZpbmQgYWRkaXRpb25hbCBjYW5kaWRhdGVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_99143DD16AF24D509467B2E6FF83B7C0akamaicom_-- From nobody Wed Oct 20 12:26:52 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4113B3A0DCA for ; Wed, 20 Oct 2021 12:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5E0F1sjvoVUL for ; Wed, 20 Oct 2021 12:26:44 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8603A0DE4 for ; Wed, 20 Oct 2021 12:26:33 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id d125so26046063iof.5 for ; Wed, 20 Oct 2021 12:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cziEWb8G7XOscmA9hDp/P5wNU8QVVcYFaHU7nxcv678=; b=wPj9xuVlojnKFCJDDEFjQyuUwfAfMNAJpkVNwbfdoJ6EB2IXKXgaUYO6Cq6sXC5b93 jP0d/SdT7zri44cMnx4jq+6CdEZgURytU1BU4RoINFVg5jUrL6414tdrKWVw06CMlZ5P kpnmhMQj3StBkzp5wFMN3Bjq0+P6mW+8jJpuFiplbxNl8XmWwQxVeiI1f1xtGQhwDw1y xn/ei6vHqfgG4i+jUz3ZOUH4e/5czDqgeXCpFSavWl3BSTGdrvc02/L/JvsvWIzIfXyP zcbnjW8bDVU28B4B0whr1trRqsWNUs0pZE5rIF/UbU0nyeiXB/uhM9xkxV8epYg92mr9 iAIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cziEWb8G7XOscmA9hDp/P5wNU8QVVcYFaHU7nxcv678=; b=ns+O04HzF7DNB1tBz8isUhJW6Mpq6BEG/8hpyXFWusI1biQyY17hXbbfZOi8FwYNFw Nl5QXyX3+lSEg4tzbpzM5F7R93NcVJQ6ImUhb0jY/MkK2xrEtWZ/dgr5Ot3XN89NPB6w Dgbm8iYW3nVYZtHwVbw1zv8ryj8we0juJYMYEZgZHBfE009TbnOCHU8b3QyCbsIbJZCD USzeYT9EHu3xYoo3V/NC3M7Z3dS1zIZ8dRUwfTSzPt34UCH21idOPFiu7w39/WlEro4Q do65cwCsyeU/iQTwo6IHX15/TAp21uLL1HY8fd2JbgUsPuLLfWMFfgS4KB5gmlZBMo0w 3iRA== X-Gm-Message-State: AOAM530boRVIXxdkfc/jXjxdTXK+LDcHPWOZFZEQNreO4h7go00pAYrk OUBZJqHT7Q3GqVV9UIE6FTZBxruW9O1VtC04mfg2fA== X-Google-Smtp-Source: ABdhPJwXlA20qo5p/w97K959LQsT5HfkuHqOeT2JXh/c2rSbbT7//m1BkuU5TLmQHravQXJbrxXtd8fPa5Y4oDbKvY4= X-Received: by 2002:a6b:c309:: with SMTP id t9mr814278iof.50.1634757990677; Wed, 20 Oct 2021 12:26:30 -0700 (PDT) MIME-Version: 1.0 References: <4BDF1DD9-9D30-499F-8C26-1E7790F2A729@akamai.com> In-Reply-To: From: Eric Rescorla Date: Wed, 20 Oct 2021 12:25:54 -0700 Message-ID: To: Barry Leiba Cc: "Salz, Rich" , "gendispatch@ietf.org" Content-Type: multipart/alternative; boundary="00000000000054198e05cecdc11c" Archived-At: Subject: Re: [Gendispatch] draft-rsalz-termlimits X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 19:26:51 -0000 --00000000000054198e05cecdc11c Content-Type: text/plain; charset="UTF-8" I mostly agree with Barry. Specifically, Barry raises two points: 1. In exceptional cases a candidate needs to be appointed for a third term. I've seen this as well though I think it wouldn't be fatal if we limited to two terms. 2. That often you want to pick an active AD or an IAB member as IETF Chair. I think this is the strongest point and it would be quite bad to make this more difficult. I am more sympathetic to the IAB case: there are always a lot of IAB candidates and I don't think that having it be common practice for ADs to go right to the IAB is that great. -Ekr I On Wed, Oct 20, 2021 at 10:23 AM Barry Leiba wrote: > Rich, thanks for bringing this to discussion. > > First: I am very strongly *against* hard term limits, as it places > unreasonable limitations on the appointment process. In a public > voting system, it's antidemocratic, artificially eliminating the > ability to vote for whom one thinks is best. In our NomCom system, it > restricts the NomCom from considering excellent candidates who have > been doing well and can be expected to continue that way. And it > would make it impossible for a NomCom to re-appoint an excellent AD > (say), when there are no good alternatives, ending us up with a bad > choice because it's the best the NomCom had to work with. > > Second, I am very strongly *for* soft term limit guidance. > Specifically saying that NomComs MUST consider more than two terms to > be atypical and more than three to be truly exceptional, and [etc, > etc, wording like that with further explanation] would absolutely get > my support. But NomComs *have* to have options to deal with > situations where re-appointing someone for a third (or fourth) term > really *is* the right thing *in this case*. > > Third, while I appreciate the desire not to have ADs move straight to > the IAB or vice-versa, and while a one-year gap before making the move > is not unreasonable, the issue is more of a challenge for someone > moving into the IETF Chair role. Here are two reasons why: > > - It's critical for an IETF Chair to have experience as an AD. And, > while Lars's experience is older and he is doing and will do fine, > we've generally had more recent ADs step into the IETF Chair position. > I would not want to limit the NomCom by saying that they can't appoint > a sitting AD as the next IETF Chair. > > - The IETF Chair is only appointed every two years. An AD who wants > the IETF Chair position would have to step down at least a year ahead, > and an AD whose term is in sync with the IETF Chair appointment would > have to step down at least two years ahead. Given that a one-term > IETF Chair is likely to get a second term, that could move to four > years ahead. Now we have an AD who might have been a great choice for > IETF Chair, but has to wait four years -- and be four years away from > the AD experience -- before she will really be considered by the > NomCom (especially if we should also move in the direction of JCK's > proposal). > > So *if* we should go in the direction Rich proposes, I would want to > see an exception for IETF Chair appointments. > > But, really, I'd much rather see us move toward giving NomComs very > clear and strong guidance on what the community expects, but leave > them the option to do what needs to be done as the situation might > require. > > Barry > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > --00000000000054198e05cecdc11c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I mostly agree with Barry. Specifically, Barry raises= two points:

1. In exceptional cases a candidate n= eeds to be appointed for a third term. I've seen this as well though I = think it wouldn't be fatal if we limited to two terms.
2. Tha= t often you want to pick an active AD or an IAB member as IETF Chair. I thi= nk this is the strongest point and it would be quite bad to make this more = difficult.

I am more sympathetic to the IAB case: = there are always a lot of IAB candidates and I don't think that having = it be common practice for ADs to go right to the IAB is that great.

-Ekr



I

On Wed, Oct 20, 2021 at 10:23 AM Barry Leiba <barrylei= ba=3D40computer.org@dmarc.= ietf.org> wrote:
Rich, thanks for bringing this to discussion.

First: I am very strongly *against* hard term limits, as it places
unreasonable limitations on the appointment process.=C2=A0 In a public
voting system, it's antidemocratic, artificially eliminating the
ability to vote for whom one thinks is best.=C2=A0 In our NomCom system, it=
restricts the NomCom from considering excellent candidates who have
been doing well and can be expected to continue that way.=C2=A0 And it
would make it impossible for a NomCom to re-appoint an excellent AD
(say), when there are no good alternatives, ending us up with a bad
choice because it's the best the NomCom had to work with.

Second, I am very strongly *for* soft term limit guidance.
Specifically saying that NomComs MUST consider more than two terms to
be atypical and more than three to be truly exceptional, and [etc,
etc, wording like that with further explanation] would absolutely get
my support.=C2=A0 But NomComs *have* to have options to deal with
situations where re-appointing someone for a third (or fourth) term
really *is* the right thing *in this case*.

Third, while I appreciate the desire not to have ADs move straight to
the IAB or vice-versa, and while a one-year gap before making the move
is not unreasonable, the issue is more of a challenge for someone
moving into the IETF Chair role.=C2=A0 Here are two reasons why:

- It's critical for an IETF Chair to have experience as an AD.=C2=A0 An= d,
while Lars's experience is older and he is doing and will do fine,
we've generally had more recent ADs step into the IETF Chair position.<= br> I would not want to limit the NomCom by saying that they can't appoint<= br> a sitting AD as the next IETF Chair.

- The IETF Chair is only appointed every two years.=C2=A0 An AD who wants the IETF Chair position would have to step down at least a year ahead,
and an AD whose term is in sync with the IETF Chair appointment would
have to step down at least two years ahead.=C2=A0 Given that a one-term
IETF Chair is likely to get a second term, that could move to four
years ahead.=C2=A0 Now we have an AD who might have been a great choice for=
IETF Chair, but has to wait four years -- and be four years away from
the AD experience -- before she will really be considered by the
NomCom (especially if we should also move in the direction of JCK's
proposal).

So *if* we should go in the direction Rich proposes, I would want to
see an exception for IETF Chair appointments.

But, really, I'd much rather see us move toward giving NomComs very
clear and strong guidance on what the community expects, but leave
them the option to do what needs to be done as the situation might
require.

Barry

--
Gendispatch mailing list
Gendispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/gendispatch
--00000000000054198e05cecdc11c-- From nobody Wed Oct 20 12:40:35 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02DB3A0DE5 for ; Wed, 20 Oct 2021 12:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJTJRaznZhcX for ; Wed, 20 Oct 2021 12:40:30 -0700 (PDT) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE173A0CAC for ; Wed, 20 Oct 2021 12:40:30 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id a15-20020a17090a688f00b001a132a1679bso1346109pjd.0 for ; Wed, 20 Oct 2021 12:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Ph8aQrvSl2AUSUVpl5zE2D9fCQnNLkZzf/PU04YwC4A=; b=lZPUD1ajGM/uAvf0ZWgdBBwGn4VHsm1ZXwldhaD889zGAEqhgMzIepvMBakloPa485 tJ2/f2WNDuecxovhD6kFw3X3alNBZQUy3oQn80Dbk9BrIQjL2UZGZkiJs9UYnWXRriKU CrD9ZulZ3R6e8vRsP87hRC2EU6En+tCVE0/6nuYAwYuCdFEWy/0HlLlFUooxjVpPGA6a EcmpFOm20JWstQC3LgVunUfLjCNuV2DYIJ7mXM2iamFGqfGxF7YXIb28L44dojxswKl+ FCs4zVImF+AvvLuYcY9k2aKSnKOdEqOn59Pn39QPRx9OBcrz4HEzo07NRllKhJ9wjiAg bQaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ph8aQrvSl2AUSUVpl5zE2D9fCQnNLkZzf/PU04YwC4A=; b=7nhCncF/vNenuU7znPZsYSAnXwxjvtizQvOBYBMrQgQzf5Bds7M1ft4ge8FiUjCma2 53PmisVWWZ0ao1ZRmaofvO1OdyGvWEpmPUkROkq8NWHQDqeDFKFVwErn11YH482OaMv4 6qj9/C2eO9LGFxfjz0rvpX0tA4LVD3Hox9HzpqM1hCyPPi0ime28yc8lwTWPvVAu2DkP 77B2NypLhCwt2vbFATT94vxuIMdvKaKN5hwBeo2bLEUS9jJ2+4bBZebT2fK883CjytUS XvdN/ZCMMWHuHsREuddF+2IHgBzb99zl53JoMpdTEM3ftnNfLpHi/fQhmfcXeUZrfi/c /h3Q== X-Gm-Message-State: AOAM530NTNPU+gOPPUXx+zX5HFdNTi/Ev5AwqzE4a3jgEnifdexrz+Gv hNT5Klv1fqgelRhotsOU12UG0I4fSBGwUw== X-Google-Smtp-Source: ABdhPJwE1x4l3k7yYZzljZzajaihxgIZgR5ikgDbcecwuVQTkHlkYEf6qLcl6mb2KLKPrxTLXlUHEg== X-Received: by 2002:a17:90b:120c:: with SMTP id gl12mr1030152pjb.50.1634758829175; Wed, 20 Oct 2021 12:40:29 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id m7sm2916542pgn.32.2021.10.20.12.40.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Oct 2021 12:40:28 -0700 (PDT) References: <2a65cc6e-3a39-d209-491f-f4ad67cca151@gmail.com> To: gendispatch@ietf.org From: Brian E Carpenter X-Forwarded-Message-Id: <2a65cc6e-3a39-d209-491f-f4ad67cca151@gmail.com> Message-ID: Date: Thu, 21 Oct 2021 08:40:23 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <2a65cc6e-3a39-d209-491f-f4ad67cca151@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Gendispatch] Fwd: I-D Action: draft-rsalz-termlimits-00.txt X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 19:40:33 -0000 Since I see this is being discussed here: -------- Forwarded Message -------- Subject: Re: I-D Action: draft-rsalz-termlimits-00.txt Date: Thu, 21 Oct 2021 08:32:58 +1300 From: Brian E Carpenter To: IETF discussion list Well, this is a bad idea that was repeatedly rejected in the past. Why? Because it's always hard to fill all the positions, and this would make it harder. If someone is incompetent, NomCom will not reappoint them even once, let alone twice. We all agree that ossification is unwelcome, but artificial turnover is not the way to avoid that. Regards Brian Carpenter On 21-Oct-21 03:34, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Term limits for IETF Leadership Positions > Author : Rich Salz > Filename : draft-rsalz-termlimits-00.txt > Pages : 3 > Date : 2021-10-20 > > Abstract: > This document says that nobody can be picked by NomCom for a position > more than two consecutive terms. > > It obsoletes some other documents, which ones are TBD. > > Discussion Venues > > This note is to be removed before publishing as an RFC. > > Source for this draft and an issue tracker can be found at > https://github.com/richsalz/draft-rsalz-termlimits. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-rsalz-termlimits/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-rsalz-termlimits-00.html > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Wed Oct 20 12:43:30 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623DD3A0DE8 for ; Wed, 20 Oct 2021 12:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eUz2RHYghh4 for ; Wed, 20 Oct 2021 12:43:23 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3993A0CAC for ; Wed, 20 Oct 2021 12:43:22 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id t4so10973623oie.5 for ; Wed, 20 Oct 2021 12:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=IDOpqT8H6hT4EzRM1wvA9PBhcJ/sl6mlOrOgMKjiSt4=; b=KuB5ARp2x4lP5pjqs2c+Z2zlv/IiW56FcVj6ooT+vd3yrsIzI3A7dDKdOzQFCukrVi tO7pp9VD+BpbCnlqvATJ9YnRyDjO4uWBpKL4yzdaoLd0octLIHoz3JpF6NNEKlSrSrnI Xs6IY779yXLoMCINf4Gu3mzLpCWoyHf3rN6DLcC0qyhEqeIGWikFGF3QWc6f/K4cWqDl 9ksX6Xv8wwnbg5cEUAF26Ph+Pr0YOOwcWnuNuAMQHiTB+yAzvZkSZsQPk1vEhGY5R5js fsg59CW3tuDFco2gPbk5UuPVG81G1V3lBh5sIdTIAJBUdeH51irTUa+Pa/aVGylwhtgo yilQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=IDOpqT8H6hT4EzRM1wvA9PBhcJ/sl6mlOrOgMKjiSt4=; b=X79BSjxow8onFWpfR62PQ5EYvDqocXy3iLV5z5KlzlduLPqcw14Agc+m+BJNnfi2Uk QS+RDuSgJkrSfxwjUgUFv1bN964C7woZv7L7vQyeeLsIYP5nLAwejOFjzvZUADO1Kv2+ ahvmOKQIhF4NCVkhngNokZ8roV3tzZLD5XJJgxLt1qGUa+ioFkef9R36SCioiZ50Suyd l/djx3lV6KjVbbmjrtHzwQHXRwRRDjL5q8Z+AuYHJnDptD4iW9eMaPcsnFnYhAKq5S5F 8uwEVShTmeic56KhJFNAyKR/3IRMtoY4TPxATFvIxurrZichq0qjAsclXfw+uFWQWXO5 1BZg== X-Gm-Message-State: AOAM530fmBB/DeqlTIZqUFw8w5Shf1qb0yNbmaIKDu4PrejmtlVrjweX c/gHJiYdHungDFwWF3DDh3E= X-Google-Smtp-Source: ABdhPJyS71IZJIGHfxos2rdR9HmLONd7uTGJigBspQOL0K/FIEyA4MTlyXOLVi4u2FpnAoYrncWqfg== X-Received: by 2002:aca:d68d:: with SMTP id n135mr778179oig.144.1634759000244; Wed, 20 Oct 2021 12:43:20 -0700 (PDT) Received: from ?IPv6:2601:647:5a00:659:b59a:3cb2:d105:2bb6? ([2601:647:5a00:659:b59a:3cb2:d105:2bb6]) by smtp.gmail.com with ESMTPSA id s206sm619169oia.33.2021.10.20.12.43.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Oct 2021 12:43:19 -0700 (PDT) From: Bob Hinden Message-Id: <53A1649E-0E10-449D-9EC0-87A6FDCD07B2@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_2D4A3543-49E6-4D00-85A5-6DEBFAF55D41"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Wed, 20 Oct 2021 12:43:16 -0700 In-Reply-To: Cc: Bob Hinden , "gendispatch@ietf.org" To: Barry Leiba References: <4BDF1DD9-9D30-499F-8C26-1E7790F2A729@akamai.com> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Gendispatch] draft-rsalz-termlimits X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 19:43:28 -0000 --Apple-Mail=_2D4A3543-49E6-4D00-85A5-6DEBFAF55D41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree about hard term limits, but think the selection bar should go = way up for more than two terms. Related, I think doing a second term as = an AD (and other positions too) should be encouraged. I think people should not move directly from one leadership group (IESG, = IAB, LLC, Trust) to another. At least one year being a regular IETF = participant provides a lot of perspective. Otherwise we get an inbred = (so to speak) leadership who may loose site of what it is like to be a = regular IETF participant. Note, I purposely didn=E2=80=99t include = w.g. chair in my list. The IETF Chair is different, I agree it=E2=80=99s good to have a person = who has served recently as an AD. I think that should be the exception = to moving between leadership positions. However, I don=E2=80=99t think = an IETF chair should be appointed to the IAB, LLC, or Trust directly = when their term ends. Bob > On Oct 20, 2021, at 10:23 AM, Barry Leiba = wrote: >=20 > Rich, thanks for bringing this to discussion. >=20 > First: I am very strongly *against* hard term limits, as it places > unreasonable limitations on the appointment process. In a public > voting system, it's antidemocratic, artificially eliminating the > ability to vote for whom one thinks is best. In our NomCom system, it > restricts the NomCom from considering excellent candidates who have > been doing well and can be expected to continue that way. And it > would make it impossible for a NomCom to re-appoint an excellent AD > (say), when there are no good alternatives, ending us up with a bad > choice because it's the best the NomCom had to work with. >=20 > Second, I am very strongly *for* soft term limit guidance. > Specifically saying that NomComs MUST consider more than two terms to > be atypical and more than three to be truly exceptional, and [etc, > etc, wording like that with further explanation] would absolutely get > my support. But NomComs *have* to have options to deal with > situations where re-appointing someone for a third (or fourth) term > really *is* the right thing *in this case*. >=20 > Third, while I appreciate the desire not to have ADs move straight to > the IAB or vice-versa, and while a one-year gap before making the move > is not unreasonable, the issue is more of a challenge for someone > moving into the IETF Chair role. Here are two reasons why: >=20 > - It's critical for an IETF Chair to have experience as an AD. And, > while Lars's experience is older and he is doing and will do fine, > we've generally had more recent ADs step into the IETF Chair position. > I would not want to limit the NomCom by saying that they can't appoint > a sitting AD as the next IETF Chair. >=20 > - The IETF Chair is only appointed every two years. An AD who wants > the IETF Chair position would have to step down at least a year ahead, > and an AD whose term is in sync with the IETF Chair appointment would > have to step down at least two years ahead. Given that a one-term > IETF Chair is likely to get a second term, that could move to four > years ahead. Now we have an AD who might have been a great choice for > IETF Chair, but has to wait four years -- and be four years away from > the AD experience -- before she will really be considered by the > NomCom (especially if we should also move in the direction of JCK's > proposal). >=20 > So *if* we should go in the direction Rich proposes, I would want to > see an exception for IETF Chair appointments. >=20 > But, really, I'd much rather see us move toward giving NomComs very > clear and strong guidance on what the community expects, but leave > them the option to do what needs to be done as the situation might > require. >=20 > Barry >=20 > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch --Apple-Mail=_2D4A3543-49E6-4D00-85A5-6DEBFAF55D41 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAmFwcVQACgkQrut0EXfn u6i0lwf/f7IKM2IPdHd74cbOIgySo7WA56YdlgoXB0WsXWNjg/lZlWfB7PCt/WG6 Joouy878T4i/o4fZjPvo6LjF0A2d2hrd9agdOwb/RBj314+OyfUtlfnrY7E7mTHa A1uB4Yo+xy8hwQrzTWVyEt7tfMCwW+EeOCaRT4JOE5X3kK8xm37cJdKxzq9RHC5V zbhyYTA/R9OzdBaR4ZOMknL28dfwADC1KORNWsBdoQnNPNLK7RbKnr4NRa8KTUDz pzW1qqhttnMUuxevm8b+/bPN7phlypRE+OQxD/C0JP+RjIlt+OvPNkO+XpxL+VAg KAWnGfQJYTLrcMRrpU9wkgxtdvxoJQ== =sXnc -----END PGP SIGNATURE----- --Apple-Mail=_2D4A3543-49E6-4D00-85A5-6DEBFAF55D41-- From nobody Wed Oct 20 12:55:04 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570273A0E4A; Wed, 20 Oct 2021 12:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7w2aLe4kZ5P; Wed, 20 Oct 2021 12:54:29 -0700 (PDT) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31ECE3A0E61; Wed, 20 Oct 2021 12:54:28 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id om14so3225559pjb.5; Wed, 20 Oct 2021 12:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Gfl+zGe8dc03SvAAlqYAmyyc1cH3qWRxYYDt14glp6U=; b=Ve03iiT/ipUhv/hbFqXR59AX4mVtHiB83P0UYc+jX7tZYbW2VnHAZCI+FWMIkeuLR7 dTmo/aDFdJKs9uewh6vuHIb5yuCLzVzpU2D/spjxqGJKee/bHtnj5LHf4QURSJSxAMrH JlRXZui3FHQJ+jpBCBsx2CLCTuGBmJoFNlysbWB4Mew3qE0gVcc/wT6WK0s4FsjrLD4Y YrFPuRwuZ48Py/OXxb15Az44u+eapzM9y0UqOHE5njdLdR1V8FkWO+1GSm79wvr+M8S9 88AWhCYqg/93M14zHxeV9MsMaZtvsYvCyIUA+I89ehRWMW+iReQtSJ5eg+lAcENHUfdW OYVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Gfl+zGe8dc03SvAAlqYAmyyc1cH3qWRxYYDt14glp6U=; b=HHZQnexzFjnFrVLIT+9i96A1SX5C0Jju8SJloQlreee7XBRk+kAdZQFfW11XPsW3xW zmAiH/ylarWdE2fyRQbiS6m0ntnOVsk3CfLw/oXh8hCUu2DLLGjjg7UiRjVnFeJ2/Tdi PBe9CyblZFAXqrxRlnIy7V77bXoMjH21X96VxQXu54DRXO94HZOgh3SimV2iYmezLd/n ydOBNJwhPty+2TwuFFSjQk28kmIYUZExQGMk/LHr2fOYgi+jlkIpXPazeNZCrF9Yq2gh vjZiBbgGM7BxDeBgNzfpz6tzBIebaxo2RelftOSvM6+kqXEqJMshASwK9IpwPn6eW2+Q KaAA== X-Gm-Message-State: AOAM532glRvFCKyBhZldvomIVMHwdJrhzAWFXV3ImKe5e3OnsnTihOLb qq/2/mhw6VbXlU2yi0hsmJ8Q46DQI1Ot9g== X-Google-Smtp-Source: ABdhPJwzdtzD/EvI0eoc7gjQ4PYRvSBe1DHq6nCXu9hE+nkkYxrpAMuNXcBJOVgt257sEE7f6S+O6A== X-Received: by 2002:a17:90b:782:: with SMTP id l2mr1067714pjz.190.1634759666005; Wed, 20 Oct 2021 12:54:26 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id b8sm3624902pfv.56.2021.10.20.12.54.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Oct 2021 12:54:25 -0700 (PDT) To: last-call@ietf.org, IETF-Announce Cc: rwilton@cisco.com, gendispatch@ietf.org, draft-eggert-bcp45bis@ietf.org References: <163465875866.13316.15860075014903480611@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <8941ad71-b424-3cf2-5af1-ca74443941ff@gmail.com> Date: Thu, 21 Oct 2021 08:54:20 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <163465875866.13316.15860075014903480611@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Gendispatch] Last Call: (IETF Discussion List Charter) to Best Current Practice X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 19:54:42 -0000 For the record, I've tracked this draft all along and I think it is ready. Regards Brian Carpenter On 20-Oct-21 04:52, The IESG wrote: > > The IESG has received a request from an individual submitter to consider the > following document: - 'IETF Discussion List Charter' > as Best Current Practice > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2021-11-23. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > The Internet Engineering Task Force (IETF) discussion mailing list > furthers the development and specification of Internet technology > through the general discussion of topics for which no dedicated > mailing lists exists. As this is the most general IETF mailing list, > considerable latitude is allowed, but there are posts and topics that > are unsuitable for this mailing list. > > This document obsoletes RFC3005. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-eggert-bcp45bis/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > From nobody Wed Oct 20 13:02:23 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A665B3A0C1A for ; Wed, 20 Oct 2021 13:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rjnhgjiwr8qh for ; Wed, 20 Oct 2021 13:02:14 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53013A0E22 for ; Wed, 20 Oct 2021 13:02:13 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id s3so23508276ild.0 for ; Wed, 20 Oct 2021 13:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NtGS7GiR7nsXG7F6QFss+w8HFFryYvtHCVz27nBiPjQ=; b=ehmsVeVJIouVGkPFpKjdx1eiO/qAwps63S9JFhBukIg+nz2tf2DEOK6MXUI9WG4G0c Juxm27PzZrm1r5ylvxEFQrqSB5kl/bkGh3uIlnOtMUtCTeqf6NAq0Qtvh6tA4MvtPiFv MmfrlbjAfxxgpo8a62/g/G2VpZbYYEBfzBlY5T1aTXqzth3CXv7zTHYWOKMM881KYgPO fM6NoMJImRpZPGKpzI6YBsPQEU7ZEGufebR95QLYEYA6FQV/2iOLL4CQn3sTPSkno46/ y01CcD8JZV1NFm6E7dRM0/VpHNRNUkuTY3Y6aiTsUhJBEnLZdS+37sh5nAcTL9NF2pc1 cElg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NtGS7GiR7nsXG7F6QFss+w8HFFryYvtHCVz27nBiPjQ=; b=HxMr1qDWxsMWknUOL0vkVEljIgZozoSHOX8QWTIbOPhkSzuXINpd3xSxODBw3f+iz6 Tn6hid4mXD7vjYRYefaUgHU4OQFFKp6D8PDKIfntNSPeZEYpkKosbkwoUUnXBD7lkCuY klcFjy5SwGoSdk5teDsEli5WM6TCBCZ2aRBlg2gJtGNqJfnRNUmLWeVV7l/c/gSbLcCP nLoQZ7bxHCMPqSc8eNSW3d99gIGJGfaTzVrPYg8mruS3gFvPQw/7t8f7t8uJBbpS75/g PkunOqkw8hUh5wbk8+xqKBLgXsCVWUQ7seF8HzjZpBVCyW7QERpssPJcdsWw0vJBGjuy Yuag== X-Gm-Message-State: AOAM531WfH8RsocYbzM3Y/ihc4g6fXur1/8QOR6uQB1gwzJNAkyyr04z xg1QyIAbSBpVnqfxOpl5E6Tb/qO7kISbcvrpuCw= X-Google-Smtp-Source: ABdhPJwYHzSAkP7oXOMk/CuNjqr/Af61Y1Q72l2ZzeDmwdTYHy3weQtX8w/cV/QX6333Cv/dfk/pD/JTv3NUcqc+2aQ= X-Received: by 2002:a05:6e02:216f:: with SMTP id s15mr738647ilv.259.1634760132629; Wed, 20 Oct 2021 13:02:12 -0700 (PDT) MIME-Version: 1.0 References: <4BDF1DD9-9D30-499F-8C26-1E7790F2A729@akamai.com> In-Reply-To: From: Rob Sayre Date: Wed, 20 Oct 2021 13:02:01 -0700 Message-ID: To: Eric Rescorla Cc: Barry Leiba , "gendispatch@ietf.org" , "Salz, Rich" Content-Type: multipart/alternative; boundary="000000000000ffa53105cece40d4" Archived-At: Subject: Re: [Gendispatch] draft-rsalz-termlimits X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 20:02:19 -0000 --000000000000ffa53105cece40d4 Content-Type: text/plain; charset="UTF-8" I mostly agree with Barry as well. I also find that the people who get reappointed or agree to serve again tend to be pretty cool folks, so I'm not sure term limits solve a problem. However, I'm not against it either, really. thanks, Rob On Wed, Oct 20, 2021 at 12:26 PM Eric Rescorla wrote: > I mostly agree with Barry. Specifically, Barry raises two points: > > 1. In exceptional cases a candidate needs to be appointed for a third > term. I've seen this as well though I think it wouldn't be fatal if we > limited to two terms. > 2. That often you want to pick an active AD or an IAB member as IETF > Chair. I think this is the strongest point and it would be quite bad to > make this more difficult. > > I am more sympathetic to the IAB case: there are always a lot of IAB > candidates and I don't think that having it be common practice for ADs to > go right to the IAB is that great. > > -Ekr > > > > I > > On Wed, Oct 20, 2021 at 10:23 AM Barry Leiba 40computer.org@dmarc.ietf.org> wrote: > >> Rich, thanks for bringing this to discussion. >> >> First: I am very strongly *against* hard term limits, as it places >> unreasonable limitations on the appointment process. In a public >> voting system, it's antidemocratic, artificially eliminating the >> ability to vote for whom one thinks is best. In our NomCom system, it >> restricts the NomCom from considering excellent candidates who have >> been doing well and can be expected to continue that way. And it >> would make it impossible for a NomCom to re-appoint an excellent AD >> (say), when there are no good alternatives, ending us up with a bad >> choice because it's the best the NomCom had to work with. >> >> Second, I am very strongly *for* soft term limit guidance. >> Specifically saying that NomComs MUST consider more than two terms to >> be atypical and more than three to be truly exceptional, and [etc, >> etc, wording like that with further explanation] would absolutely get >> my support. But NomComs *have* to have options to deal with >> situations where re-appointing someone for a third (or fourth) term >> really *is* the right thing *in this case*. >> >> Third, while I appreciate the desire not to have ADs move straight to >> the IAB or vice-versa, and while a one-year gap before making the move >> is not unreasonable, the issue is more of a challenge for someone >> moving into the IETF Chair role. Here are two reasons why: >> >> - It's critical for an IETF Chair to have experience as an AD. And, >> while Lars's experience is older and he is doing and will do fine, >> we've generally had more recent ADs step into the IETF Chair position. >> I would not want to limit the NomCom by saying that they can't appoint >> a sitting AD as the next IETF Chair. >> >> - The IETF Chair is only appointed every two years. An AD who wants >> the IETF Chair position would have to step down at least a year ahead, >> and an AD whose term is in sync with the IETF Chair appointment would >> have to step down at least two years ahead. Given that a one-term >> IETF Chair is likely to get a second term, that could move to four >> years ahead. Now we have an AD who might have been a great choice for >> IETF Chair, but has to wait four years -- and be four years away from >> the AD experience -- before she will really be considered by the >> NomCom (especially if we should also move in the direction of JCK's >> proposal). >> >> So *if* we should go in the direction Rich proposes, I would want to >> see an exception for IETF Chair appointments. >> >> But, really, I'd much rather see us move toward giving NomComs very >> clear and strong guidance on what the community expects, but leave >> them the option to do what needs to be done as the situation might >> require. >> >> Barry >> >> -- >> Gendispatch mailing list >> Gendispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/gendispatch >> > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > --000000000000ffa53105cece40d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I mostly agree with Barry as well. I also find that the pe= ople who get reappointed or agree to serve again tend to be pretty cool fol= ks, so I'm not sure term limits solve a problem. However, I'm not a= gainst it either, really.

thanks,
Rob


On Wed, Oct 20, 2021 at 12:26 PM Eric Rescorla <ekr@rtfm.com> wrote:
I mostly agree with = Barry. Specifically, Barry raises two points:

1. I= n exceptional cases a candidate needs to be appointed for a third term. I&#= 39;ve seen this as well though I think it wouldn't be fatal if we limit= ed to two terms.
2. That often you want to pick an active AD or a= n IAB member as IETF Chair. I think this is the strongest point and it woul= d be quite bad to make this more difficult.

I am m= ore sympathetic to the IAB case: there are always a lot of IAB candidates a= nd I don't think that having it be common practice for ADs to go right = to the IAB is that great.

-Ekr

<= /div>


I

On Wed, Oct 20, 2021 at = 10:23 AM Barry Leiba <barryleiba=3D40computer.org@dmarc.ietf.org> wrote:<= br>
Rich, thanks for= bringing this to discussion.

First: I am very strongly *against* hard term limits, as it places
unreasonable limitations on the appointment process.=C2=A0 In a public
voting system, it's antidemocratic, artificially eliminating the
ability to vote for whom one thinks is best.=C2=A0 In our NomCom system, it=
restricts the NomCom from considering excellent candidates who have
been doing well and can be expected to continue that way.=C2=A0 And it
would make it impossible for a NomCom to re-appoint an excellent AD
(say), when there are no good alternatives, ending us up with a bad
choice because it's the best the NomCom had to work with.

Second, I am very strongly *for* soft term limit guidance.
Specifically saying that NomComs MUST consider more than two terms to
be atypical and more than three to be truly exceptional, and [etc,
etc, wording like that with further explanation] would absolutely get
my support.=C2=A0 But NomComs *have* to have options to deal with
situations where re-appointing someone for a third (or fourth) term
really *is* the right thing *in this case*.

Third, while I appreciate the desire not to have ADs move straight to
the IAB or vice-versa, and while a one-year gap before making the move
is not unreasonable, the issue is more of a challenge for someone
moving into the IETF Chair role.=C2=A0 Here are two reasons why:

- It's critical for an IETF Chair to have experience as an AD.=C2=A0 An= d,
while Lars's experience is older and he is doing and will do fine,
we've generally had more recent ADs step into the IETF Chair position.<= br> I would not want to limit the NomCom by saying that they can't appoint<= br> a sitting AD as the next IETF Chair.

- The IETF Chair is only appointed every two years.=C2=A0 An AD who wants the IETF Chair position would have to step down at least a year ahead,
and an AD whose term is in sync with the IETF Chair appointment would
have to step down at least two years ahead.=C2=A0 Given that a one-term
IETF Chair is likely to get a second term, that could move to four
years ahead.=C2=A0 Now we have an AD who might have been a great choice for=
IETF Chair, but has to wait four years -- and be four years away from
the AD experience -- before she will really be considered by the
NomCom (especially if we should also move in the direction of JCK's
proposal).

So *if* we should go in the direction Rich proposes, I would want to
see an exception for IETF Chair appointments.

But, really, I'd much rather see us move toward giving NomComs very
clear and strong guidance on what the community expects, but leave
them the option to do what needs to be done as the situation might
require.

Barry

--
Gendispatch mailing list
Gendispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/gendispatch
--
Gendispatch mailing list
Gendispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/gendispatch
--000000000000ffa53105cece40d4-- From nobody Wed Oct 20 13:05:29 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081593A0E79; Wed, 20 Oct 2021 13:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSrQldcEKlqN; Wed, 20 Oct 2021 13:05:18 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB9E3A0E78; Wed, 20 Oct 2021 13:05:18 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id h196so26208716iof.2; Wed, 20 Oct 2021 13:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3aoJBJ2EDTq5HcOLkqYZ6ImysB+vADF1FDvY3bMv5XU=; b=QmSRWB9CQBVGmDtO0lDrDK9Q5c197cZWF0Ci3PS8dcgtTKxSixL3XLhS/IvQhrXkb5 tXuoFu4fWAnuAgzAbmgDHwDCISvTV7+lrqmJ4RdsFzGdhWsp4G4M9X9oMYR/RqkgIyXK Yg90qri68ceO2mFhDPw2CYb363msyTq1WtWtDhCFT3WMmqMWWET88X1KJeAZr2Gz/pj0 3fIHORNQZUmNG7cK/gSL3eSAayAkUPGWPgcLSiGzzrF4WY4bYXR0Xf6reYPlxhbKJ9GF ktDidfsBvZuDtCGTtxBNadw38DxN1TFZnUy5GWLKSPMudr5Be8K40NwDviJeJd5UML7P tHGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3aoJBJ2EDTq5HcOLkqYZ6ImysB+vADF1FDvY3bMv5XU=; b=6dy4ya2WRMqO8b4E/e2GKaMNXeO20u6Jv4JGdbI0n2SJiHXjCeh1+fJ+rp9MbSmEX2 YZt9CeFkKun91EZA3vKaugCB/5KvlFVrqsTJ2MxSjZt6l+DqtOX6id1lPzV+uQOp9uJl cw2spllVKZz1kwBqQJmELJLTsIe8jwbUFVUWw0dRxxLZrt4n8XBFkByZcfrF/JoQ085w 9L2ZfiwlmyvF4+UvhzFU6QllLb7iAp+tqusbJ8w9Ikl6lybUVxbHv62nHUgzxLQs9yn9 BBXg9SE1iA+4SnJfq9GPfJ2dzkZalUnalmVlCUJUJOyC8sG5NcoXiMbQPBwGtHQIcpCr SMOA== X-Gm-Message-State: AOAM533DZjEdenXUTZ36zQM1LlPSqNG4tZEGqZG7UvXbBOFlXnGO0v4u Rf4miuF5+icB/L9uQf+h44Jqzbx8VGeeh9SrmCo= X-Google-Smtp-Source: ABdhPJy/PfGgclFz2nrGWNPjh3l/6GYRDqLhhevk4vg+l3s90E5m1MPSQbXNXkcgTwlbNn7a/YvnfrdB71abzf0ZKAY= X-Received: by 2002:a6b:6118:: with SMTP id v24mr894817iob.154.1634760316750; Wed, 20 Oct 2021 13:05:16 -0700 (PDT) MIME-Version: 1.0 References: <163465875866.13316.15860075014903480611@ietfa.amsl.com> <8941ad71-b424-3cf2-5af1-ca74443941ff@gmail.com> In-Reply-To: <8941ad71-b424-3cf2-5af1-ca74443941ff@gmail.com> From: Rob Sayre Date: Wed, 20 Oct 2021 13:05:06 -0700 Message-ID: To: Brian E Carpenter Cc: last-call@ietf.org, IETF-Announce , "Rob Wilton (rwilton)" , GENDISPATCH List , draft-eggert-bcp45bis@ietf.org Content-Type: multipart/alternative; boundary="000000000000f9124d05cece4bb6" Archived-At: Subject: Re: [Gendispatch] Last Call: (IETF Discussion List Charter) to Best Current Practice X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 20:05:23 -0000 --000000000000f9124d05cece4bb6 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 20, 2021 at 12:55 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > For the record, I've tracked this draft all along and I think it is ready. > Agree that it is ready. Many more substantial (and controversial) changes have been discussed, but this draft is better documentation. thanks, Rob --000000000000f9124d05cece4bb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For the record, I've tracked th= is draft all along and I think it is ready.

=
Agree that it is ready. Many more substantial (and controversial) chan= ges have been discussed, but this draft is better documentation.
=
thanks,
Rob
=C2=A0
--000000000000f9124d05cece4bb6-- From nobody Wed Oct 20 14:55:48 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD1B3A12C6 for ; Wed, 20 Oct 2021 14:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abjh1FFx7GXb for ; Wed, 20 Oct 2021 14:25:52 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 436373A12C0 for ; Wed, 20 Oct 2021 14:25:52 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.1.2/8.16.1.2) with SMTP id 19KJVasA023094 for ; Wed, 20 Oct 2021 22:25:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=vALqd0g2lCof7X/nhkclNRZwAUVNycaGiP0q9oQTXuM=; b=XTUlD25NLUcii+rtcXYjp2gbbho2MdmE2ZDKs7xQ9XMKuWBRDkTVDbIRNqao4gNwX7Eo HmC7ffUSuXdWYpnOGK7+XKT3yByFb7NVKSe3dg6NzfkKZIRR7PzNfK0GgcxQLZOtFVsX N3rA+/zmwk5I5+M+UvmzZxRPWpPzhprFBik/qoZQ4XKnR1/KRoAgcrz/XraaDxvzLVpZ js52HcroI5TABtma/kbD7LEM6PTg+CLJX0ie+PJTA/4H0UnaGMEyeKpoChds6zY0OVwj oD1EUdZOzAdQC5EKA5cmX1mdXsA0uoTvdY7G5PChCbxcR24Y41sAJU+GpA7YsSSzJScd 8g== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 3btc59bg8r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 20 Oct 2021 22:25:47 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 19KLJpfj016535 for ; Wed, 20 Oct 2021 17:25:46 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint2.akamai.com with ESMTP id 3bsxhrahrj-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 20 Oct 2021 17:25:46 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Wed, 20 Oct 2021 17:25:45 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.023; Wed, 20 Oct 2021 17:25:45 -0400 From: "Salz, Rich" To: Bob Hinden , Barry Leiba CC: "ietf@ietf.org" Thread-Topic: [Gendispatch] draft-rsalz-termlimits Thread-Index: AQHXxddAKjIdH+LOF0mnbpXJbOhEqavcjNMA///ZkgA= Date: Wed, 20 Oct 2021 21:25:44 +0000 Message-ID: <11EDEA4E-4301-4CB3-9529-6E4DF368789C@akamai.com> References: <4BDF1DD9-9D30-499F-8C26-1E7790F2A729@akamai.com> <53A1649E-0E10-449D-9EC0-87A6FDCD07B2@gmail.com> In-Reply-To: <53A1649E-0E10-449D-9EC0-87A6FDCD07B2@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.54.21101001 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: <94FD3E476AFE704EACB1AE5763452933@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-20_06:2021-10-20, 2021-10-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 bulkscore=0 mlxlogscore=790 mlxscore=0 suspectscore=0 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110200122 X-Proofpoint-GUID: 1NhDaNjb2eEWoEC5dP9bC_mOJCI9yrlh X-Proofpoint-ORIG-GUID: 1NhDaNjb2eEWoEC5dP9bC_mOJCI9yrlh X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-20_06,2021-10-20_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 priorityscore=1501 impostorscore=0 mlxscore=0 bulkscore=0 mlxlogscore=793 clxscore=1015 spamscore=0 malwarescore=0 suspectscore=0 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110200122 Archived-At: X-Mailman-Approved-At: Wed, 20 Oct 2021 14:55:46 -0700 Subject: Re: [Gendispatch] draft-rsalz-termlimits X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 21:25:58 -0000 R2VuZGlzcGF0Y2ggdG8gQkNDOyB1c2luZyB0aGUgZ2VuZXJhbCBJRVRGQCBsaXN0IGZvciB0aGlz IGRpc2N1c3Npb24uDQoNCj4gICAgVGhlIElFVEYgQ2hhaXIgaXMgZGlmZmVyZW50LCBJIGFncmVl IGl04oCZcyBnb29kIHRvIGhhdmUgYSBwZXJzb24gd2hvIGhhcyBzZXJ2ZWQgcmVjZW50bHkgYXMg YW4gQUQuDQoNCkxldCdzIHNlZS4gIExvb2tpbmcgYXQgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYWJv dXQvZ3JvdXBzL2llc2cvcGFzdC1tZW1iZXJzLw0KDQpMYXJzIHdhcyBUcmFuc3BvcnQgQUQgdW50 aWwgMjAxMTsgMTAgeWVhcnMuDQpBbGlpc2Egd2FzIEdlbmVyYWwgQUQgdW50aWwgMjAyMCwgbm8g Z2FwLg0KSmFyaSB3YXMgSW50ZXJuZXQgQUQgdW50aWwgMjAxMjsgb25lIHllYXIuDQpSdXNzIHdh cyBTZWN1cml0eSBBRCB1bnRpbCAyMDA3OyBubyBnYXANCkJyaWFuIENhcnBlbnRlciB3YXNuJ3Qg YW4gQUQgdW5sZXNzIGl0IHdhcyBiZWZvcmUgMTk4OSBzbyBhdCBsZWFzdCBhIDE1IHllYXIgZ2Fw Lg0KSGFyYWxkIHdhcyBPcHMgQUQgdW50aWwgMTk5OCBzbyB0aHJlZSB5ZWFyIGdhcC4NCkZyZWQg QmFrZXIgd2Fzbid0IGFuIEFEIGJlZm9yZSAxOTg5IHNvIGF0IGxlYXN0IGEgc2l4IHllYXIgZ2Fw Lg0KUGF1bCBNb2NrYXBldHJpcyB3YXNuJ3QgYW4gQUQgYmVmb3JlIDE5ODkgc28gYXQgbGVhc3Qg YSBzaXggeWVhciBnYXAuDQpQaGlsbGlwIEdyb3NzIHdhc24ndCBhbiBBRCB1bmxlc3MgYmVmb3Jl IDE5ODkNCk1pY2hhZWwgQ29ycmlnYW4gd2FzIGFuIEFEIHVubGVzcyBiZWZvcmUgMTk4OQ0KDQpE aWQgSSBtYWtlIGFueSBtaXN0YWtlcyAocXVpdGUgbGlrZWx5ISkgaW4gdGhlIGFib3ZlPw0KDQpO b3QgdGhhdCBteSBwcm9wb3NhbCBkb2Vzbid0IHNheSAiY2FuJ3QgYmUgYW4gQUQiICBJdCBqdXN0 IHNheXMgdGhhdCBpZiB5b3Ugc2VydmUgdGhlIGNvbW1vbnBsYWNlIHR3byB0ZXJtcywgdGhlbiB0 aGVyZSBtdXN0IGJlIGdhcCB5ZWFyLg0KDQo= From nobody Wed Oct 20 15:53:45 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D353A0AB0 for ; Wed, 20 Oct 2021 15:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEZDpbnPxyp1 for ; Wed, 20 Oct 2021 15:53:37 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC253A0AAA for ; Wed, 20 Oct 2021 15:53:35 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CB8EF5C0181 for ; Wed, 20 Oct 2021 18:53:34 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 20 Oct 2021 18:53:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=rCt8C+ NwKl1TiLb9sDRDbrYawl/gT28YWtaKbsL8kMY=; b=jaip+t/NcFJGnbcAF8pvwY UO+FliHtUkIpnzjlTuvARtn3WbFRb/EGbGIHBmTwzdvqSAucxk4Gc+YREvwtxggx jXoe1+1Ggdrw9xV6oPGmq4P2beJGs7tt39w9f/oP6UUVzn7IBM2dVFD0FcjqtIPL thvSgFNK2NaQdsDNlHg9F89Rnw45mp7he8Z8tL2ThZTU7dfZBI1HaStFaIvvF5hH kZHHPPCXoBJu7TFrENie/1vXAnl4Gz1zzc9qb8lwtRUsVIlNTaQN7gy8AIBqMYoD +kKdNMgeKGEsrlKhDqptR3jY0tImZOKS4c2mqY6X1exzvAc11NKdRSgdlyNdxHvw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddvhedguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepudetfeekveevfe eltdekffeigeelkefgudevgedtvdehjefggffglefhvdeuudeinecuffhomhgrihhnpehi vghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 20 Oct 2021 18:53:34 -0400 (EDT) To: gendispatch@ietf.org References: <163465875866.13316.15860075014903480611@ietfa.amsl.com> From: Keith Moore Message-ID: <34ec2302-edc3-e180-be00-4d7200372d5f@network-heretics.com> Date: Wed, 20 Oct 2021 18:53:33 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C15B7D3ADA7A7B92D8C8B255" Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] Last Call: (IETF Discussion List Charter) to Best Current Practice X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 22:53:43 -0000 This is a multi-part message in MIME format. --------------C15B7D3ADA7A7B92D8C8B255 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Let me first address some of Barry's points with which I agree: * IETF doesn't need to use "sergeant at arms" in exactly the same way that the term is used elsewhere; IETF is free to define that role however the community consensus sees fit. While there are good reasons for SAAs being independent of the leadership, there are other ways to prevent the SAAs from being used inappropriately by the IETF Chair than by having them be appointed by someone else.   Because of past abuse of this very kind, I would vastly prefer that the SAAs *not* be appointed by the IETF Chair.   But I do accept that nomcom already has plenty of work to do.  And given that this draft does provide for an appeals process, I think that's almost sufficient to address this concern.    Unfortunately, the criteria cited in this draft for acceptable posting to the IETF list are still hopelessly vague, and the IETF Chair is still allowed to disambiguate those criteria without reference to any community consensus. * I don't have an inherent problem with the IETF Chair being author of this draft.   Politically speaking and in hindsight, I think it would have been better if someone else had authored the draft.  But having IETF community leaders write drafts for how to improve IETF processes is longstanding practice, and the people who deal with IETF processes on a day-to-day basis are well-qualified to identify some of the shortcomings of those processes.  (What they're perhaps less qualified to do is to see how those processes marginalize those considered to be "outsiders") I do think that recent behavior of the current IETF leadership, particularly in regard to certain April 1 Internet-Drafts, raises legitimate questions about their objectivity, and whether they've assumed broader roles than intended for their positions.   But we have to follow the process we have, and that means that IESG is tasked with evaluating community consensus on censorship rules for the ietf@ list, even though they have themselves censored input for arbitrary and dubious reasons which were not supported by any IETF Consensus criteria.   I say this in full realization that my pointing this out makes me more of a target, but I believe that it's necessary to recognize the truth even when - perhaps especially when - it's uncomfortable. Now some points on which I disagree: > The draft makes it clear that the purpose of the SAA team is to allow > the IETF Chair to appoint people to handle this role, and then to step > back and*not* be a king, to*not* have a day-to-day role in > monitoring and managing the IETF list. That is as it should be. I agree that the IETF Chair should not be a king and not have a day-to-day role in monitoring and managing the IETF list. I disagree that the draft makes this clear.   While the draft does state: the IETF Chair should stay away from the day-to-day operation and management of the SAA team. It also states: This has been in practice for a while, and the SAA team has independently maintained definitions of abuse patterns [SAA-UPC ] and operating procedures [SAA-SOP ] for them. The SAA team should reach out to the IETF Chair for any conflict resolution in a timely manner. So it doesn't define objective criteria for the SAAs to independently follow (nor for the IAB to use in evaluating appeals).  Instead, it expects the SAAs to make up their own criteria without getting community support for their positions, and to follow the direction of the IETF Chair for "conflict resolution" (which is itself vague - does it refer to conflict between SAA opinions, conflict between SAA opinion and IETF consensus document, or conflicts between individual IETF participants?).    This seems like a significant expansion of the roles described in RFC 3005, that we're being asked to approve as if these changes were nothing. I can understand, however, if for the sake of expedience the SAAs need to make up new temporary rules, to be later vetted (or not) by an IETF Consensus process. I DO NOT think the IETF Chair should be doing so.  The IETF Chair needs to stay out of it. Part of the problem is that in recent history an IETF Chair *has* acted like a king; *has* used the SAAs to suppress dissenting views; *has* apparently dictated to SAAs and others vague, arbitrary, and prejudiced criteria that were never supported by community consensus.  I believe that this has had a chilling effect on IETF discussions, and that this draft really does nothing to address those concerns. ---- The very term "Best Current Practice" acknowledges that a best practice may be dependent on current conditions.   What the community approved as "Best Current Practice" 20+ years ago should not be axiomatically presumed to be even good practice now. Which is why arguments that this new document should be approved, because it's only a minor change from RFC 3005, are unpersuasive. Conditions in the Internet, and in IETF, have changed drastically since 2000.   The Internet serves a much more diverse population now, with more diverse needs, and people everywhere are constantly facing new threats presented to them by the Internet.   In addition, censorship and suppression of dissenting views is now (sadly) much more in fashion than it was in 2000.   (To be fair, disinformation is also (sadly) much more in fashion.) While IETF has traditionally been quite tolerant of diverse views, today the ability of participants with diverse points-of-view to provide input into IETF's deliberations is needed more than ever before.  And yet, the SAAs have been used in the recent past to promote intolerance of diverse views, apparently on the dubious theory that the way to make IETF more inclusive is to suppress views or expressions of views that some people find unsettling. The aggregate effect of such efforts is to make IETF more like an echo chamber, in which everyone is expected to "know their place" - i.e. know to not express views that might conflict with the views of those in power, or otherwise know the unwritten "rules".   This is, after all, often what is expected of "professionals" in their workplaces, which is yet another reason why "professional" is a poor criterion for describing which behavior is appropriate or not in IETF discussions. In effect, what the community is now being asked to do is to retroactively approve a power grab that's been made by a previous IETF chair.   I argue that this power grab is not in the interests of the community, not consistent with IETF's purpose, and not supportive of consensus-based decision making. Furthermore the author of this document has seemed unwilling to date to try to address these concerns in any significant way. He has seemed unwilling to even acknowledge those concerns as even potentially legitimate. Barry also writes: That not everyone is happy with everything it says shows that we have*rough consensus*, not unanimity Well, of course it doesn't show that at all!   No, we don't need unanimity to declare rough consensus.   But rough consensus has not yet been established, and there's generally an expectation that consensus-building requires a good faith effort to acknowledge various parties' concerns and to try to see how they are legitimate.   I don't think that's happened here. So no, we do not have even rough consensus on this issue. Keith --------------C15B7D3ADA7A7B92D8C8B255 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Let me first address some of Barry's points with which I agree:

  • IETF doesn't need to use "sergeant at arms" in exactly the same way that the term is used elsewhere; IETF is free to define that role however the community consensus sees fit.  

    While there are good reasons for SAAs being independent of the leadership, there are other ways to prevent the SAAs from being used inappropriately by the IETF Chair than by having them be appointed by someone else.   Because of past abuse of this very kind, I would vastly prefer that the SAAs not be appointed by the IETF Chair.   But I do accept that nomcom already has plenty of work to do.  And given that this draft does provide for an appeals process, I think that's almost sufficient to address this concern.    Unfortunately, the criteria cited in this draft for acceptable posting to the IETF list are still hopelessly vague, and the IETF Chair is still allowed to disambiguate those criteria without reference to any community consensus.

  • I don't have an inherent problem with the IETF Chair being author of this draft.   Politically speaking and in hindsight, I think it would have been better if someone else had authored the draft.  But having IETF community leaders write drafts for how to improve IETF processes is longstanding practice, and the people who deal with IETF processes on a day-to-day basis are well-qualified to identify some of the shortcomings of those processes.  (What they're perhaps less qualified to do is to see how those processes marginalize those considered to be "outsiders")

    I do think that recent behavior of the current IETF leadership, particularly in regard to certain April 1 Internet-Drafts, raises legitimate questions about their objectivity, and whether they've assumed broader roles than intended for their positions.   But we have to follow the process we have, and that means that IESG is tasked with evaluating community consensus on censorship rules for the ietf@ list, even though they have themselves censored input for arbitrary and dubious reasons which were not supported by any IETF Consensus criteria.   I say this in full realization that my pointing this out makes me more of a target, but I believe that it's necessary to recognize the truth even when - perhaps especially when - it's uncomfortable.

Now some points on which I disagree:

The draft makes it clear that the purpose of the SAA team is to allow
the IETF Chair to appoint people to handle this role, and then to step
back and *not* be a king, to *not* have a day-to-day role in
monitoring and managing the IETF list.  That is as it should be.

I agree that the IETF Chair should not be a king and not have a day-to-day role in monitoring and managing the IETF list.

I disagree that the draft makes this clear.   While the draft does state:

   the IETF Chair should stay away from the
   day-to-day operation and management of the SAA team.

It also states:

   This has been
   in practice for a while, and the SAA team has independently
   maintained definitions of abuse patterns [SAA-UPC] and operating
   procedures [SAA-SOP] for them.  The SAA team should reach out to the
   IETF Chair for any conflict resolution in a timely manner.

So it doesn't define objective criteria for the SAAs to independently follow (nor for the IAB to use in evaluating appeals).  Instead, it expects the SAAs to make up their own criteria without getting community support for their positions, and to follow the direction of the IETF Chair for "conflict resolution" (which is itself vague - does it refer to conflict between SAA opinions, conflict between SAA opinion and IETF consensus document, or conflicts between individual IETF participants?).    This seems like a significant expansion of the roles described in RFC 3005, that we're being asked to approve as if these changes were nothing.  

I can understand, however, if for the sake of expedience the SAAs need to make up new temporary rules, to be later vetted (or not) by an IETF Consensus process.  

I DO NOT think the IETF Chair should be doing so.  The IETF Chair needs to stay out of it.

Part of the problem is that in recent history an IETF Chair *has* acted like a king; *has* used the SAAs to suppress dissenting views; *has* apparently dictated to SAAs and others vague, arbitrary, and prejudiced criteria that were never supported by community consensus.  I believe that this has had a chilling effect on IETF discussions, and that this draft really does nothing to address those concerns.

----

The very term "Best Current Practice" acknowledges that a best practice may be dependent on current conditions.   What the community approved as "Best Current Practice" 20+ years ago should not be axiomatically presumed to be even good practice now.   Which is why arguments that this new document should be approved, because it's only a minor change from RFC 3005, are unpersuasive.   

Conditions in the Internet, and in IETF, have changed drastically since 2000.   The Internet serves a much more diverse population now, with more diverse needs, and people everywhere are constantly facing new threats presented to them by the Internet.   In addition, censorship and suppression of dissenting views is now (sadly) much more in fashion than it was in 2000.   (To be fair, disinformation is also (sadly) much more in fashion.)

While IETF has traditionally been quite tolerant of diverse views, today the ability of participants with diverse points-of-view to provide input into IETF's deliberations is needed more than ever before.  And yet, the SAAs have been used in the recent past to promote intolerance of diverse views, apparently on the dubious theory that the way to make IETF more inclusive is to suppress views or expressions of views that some people find unsettling.  

The aggregate effect of such efforts is to make IETF more like an echo chamber, in which everyone is expected to "know their place" - i.e. know to not express views that might conflict with the views of those in power, or otherwise know the unwritten "rules".   This is, after all, often what is expected of "professionals" in their workplaces, which is yet another reason why "professional" is a poor criterion for describing which behavior is appropriate or not in IETF discussions.

In effect, what the community is now being asked to do is to retroactively approve a power grab that's been made by a previous IETF chair.   I argue that this power grab is not in the interests of the community, not consistent with IETF's purpose, and not supportive of consensus-based decision making. 

Furthermore the author of this document has seemed unwilling to date to try to address these concerns in any significant way. He has seemed unwilling to even acknowledge those concerns as even potentially legitimate.


Barry also writes:

That not everyone is happy with everything it says shows that we have *rough consensus*, not unanimity

Well, of course it doesn't show that at all!   No, we don't need unanimity to declare rough consensus.   But rough consensus has not yet been established, and there's generally an expectation that consensus-building requires a good faith effort to acknowledge various parties' concerns and to try to see how they are legitimate.   I don't think that's happened here.

So no, we do not have even rough consensus on this issue.

Keith


--------------C15B7D3ADA7A7B92D8C8B255-- From nobody Wed Oct 20 16:07:29 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE20F3A0C2F for ; Wed, 20 Oct 2021 16:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gckEXP0eCaNq for ; Wed, 20 Oct 2021 16:07:20 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34743A0BEB for ; Wed, 20 Oct 2021 16:07:20 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id h2so3213153ili.11 for ; Wed, 20 Oct 2021 16:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p0jijMICbb+y5SqdFDFQEy4sqiCkGvzSkHhSQjBPIaQ=; b=x51iZz+ijrDVJrjAHFSyKBTXNNLsSFqRt3VaPcIh4OeK14Ga2z5pBC8CJ8l/ljVhc6 5ZLqrPgSfm7qRmxB1dACz9SdHxoCVvlRjlelFahoJjPiJWFrZ9zgWHuIMOIx7TG5hKDd kkdRxFsI9HGjkFrdiTT8u+bGNOAqsUNcjLiKIi74xTc8MyVlh6jXtH4pWIsqrhp2/ZnS U+IJ9vEtarVRrrt3nBlg7I8GEHin809ywWR8hJhNVMbUS9XSU3+zB//7H9/1mNWdal7n oUVEWH9VgtKiRL5B0Ho9ggBD3ulx0uILKqtdu8G84nhogjAVcMRP6JZB5xeEh/x03eXu GgDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p0jijMICbb+y5SqdFDFQEy4sqiCkGvzSkHhSQjBPIaQ=; b=0cesHI8OJmNqa9ylZu6gXd3daFeLAj0xvXOuO6cGe9O4qbazObeQ3V/tKSebMh+FJy AdAMTtsKej96e+9GvC619cPI8yxZdkvbDtoLbjPVgzt7FCrt19r+KlPe8wq9EmlpvlXL a3Aa2tuStxchr/4zl/v/p1OlrhZnfXAsZnpSQqHQL1wGf9rHZ9hw4Gsky9lC5pOxskjG YLXifWv4aQ2sRB9PxLDLq4AEdzpnbTSRoEVZKf9WYBqtbIxOFigxp+Q3NSnkmS/L4GY0 XHe+/Nnzz/yLxZz9hNikGvGEI9T8Db1IYrmY5OR/xuNVCRwkG5dVsL9uR9ZkBf4sFHHH cp5Q== X-Gm-Message-State: AOAM533lz2h78umaHDd5eACBz92HgUc7DgLI2mYLSr0SkvxO1dBWmzqM /Yg14qTuEdcdIRn0gAQOJhOwhCw4k57sYRgNuanaSg== X-Google-Smtp-Source: ABdhPJzE2fwda2P/9Hqvt6ckBpI4JplgrvRoIQksBCdC3PUh60J9DBRFaSvuJEJi8Af60ETl+rdVJ1lbs4jJWLSexbg= X-Received: by 2002:a05:6e02:1a85:: with SMTP id k5mr1256744ilv.39.1634771239100; Wed, 20 Oct 2021 16:07:19 -0700 (PDT) MIME-Version: 1.0 References: <163465875866.13316.15860075014903480611@ietfa.amsl.com> <8941ad71-b424-3cf2-5af1-ca74443941ff@gmail.com> In-Reply-To: From: Eric Rescorla Date: Wed, 20 Oct 2021 16:06:42 -0700 Message-ID: To: Rob Sayre Cc: Brian E Carpenter , "Rob Wilton (rwilton)" , last-call@ietf.org, GENDISPATCH List , draft-eggert-bcp45bis@ietf.org, IETF-Announce Content-Type: multipart/alternative; boundary="000000000000feff7205ced0d601" Archived-At: Subject: Re: [Gendispatch] Last Call: (IETF Discussion List Charter) to Best Current Practice X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 23:07:26 -0000 --000000000000feff7205ced0d601 Content-Type: text/plain; charset="UTF-8" Agreed. I think this is ready. I also think proposals for more significant changes would be in order (though I doubt they will achieve consensus), but I don't think that needs to delay this draft. -Ekr On Wed, Oct 20, 2021 at 1:05 PM Rob Sayre wrote: > On Wed, Oct 20, 2021 at 12:55 PM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> For the record, I've tracked this draft all along and I think it is ready. >> > > Agree that it is ready. Many more substantial (and controversial) changes > have been discussed, but this draft is better documentation. > > thanks, > Rob > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > --000000000000feff7205ced0d601 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreed. I think this is ready. I also think proposals= for more significant changes would be in order (though I doubt they will a= chieve consensus), but I don't think that needs to delay this draft.

-Ekr


On Wed, Oct 20, 2021 at= 1:05 PM Rob Sayre <sayrer@gmail.com= > wrote:
=
On Wed, Oct 20, 2021 at 12:55 PM Brian E = Carpenter <brian.e.carpenter@gmail.com> wrote:
For the record, I= 've tracked this draft all along and I think it is ready.

Agree that it is ready. Many more substantial (and c= ontroversial) changes have been discussed, but this draft is better documen= tation.

thanks,
Rob
=C2=A0
--
Gendispatch mailing list
Gendispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/gendispatch
--000000000000feff7205ced0d601-- From nobody Wed Oct 20 16:08:42 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF3E3A0C1A for ; Wed, 20 Oct 2021 16:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=RBPtcTk6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=USGX2SLE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcNWk6lR_0BC for ; Wed, 20 Oct 2021 16:08:31 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9199C3A0BB6 for ; Wed, 20 Oct 2021 16:08:31 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 790963200C20; Wed, 20 Oct 2021 19:08:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 20 Oct 2021 19:08:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=3 K0NxoloW3Mo+ZXLFfD++BvwXAxJN8ivS5+3VxYnKfM=; b=RBPtcTk6Bs8+xJIm2 whfn5Dr2ICD1wHBp/zpPuDNUiM9CYPyJS1gLWYmQradWj0R5/ZDdnJqR775Xzm13 YH8Rzz3wtgcj0hX252cCAsO4YvwNTI3ReAJJtCUrOouwK21bFqrDHezrEKl6xRJh ZmV+N4HK4JFS3d6P58ncgZsUFrf0NsGQBx1U19eT0cBw283Buf/WxTQr9axe9bIj WUy+7Rm/rTLreTv+AR48PZrvSxMWAuX/BMi8SGooi33j4CeJHUz15kV2TS1n9p+g TpfZwvhIV5dwT6uNnZTLwaj2FShczMTvq9iO/ifqy/jQlpz4M0EiPibxmHTZQrYT NO07g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=3K0NxoloW3Mo+ZXLFfD++BvwXAxJN8ivS5+3VxYnK fM=; b=USGX2SLE7yysqnIcp6c5wi9OA2EFKQC9bApQIGjAHolnvb7OjA0mEZfrp rGk0MhQmkoYxnwaEOiovGxxSmjpO1ZkXiFlDrya9bUlnvtZUl4mgCjWHo8fRRxt+ uBmq6f916n7ICx8uzlvLopOm/BooJ7B+ueGigmm1J5135Xy+QZr5qlPWtYLXJ/Wf 1NO/os71x1WGkB/y1mmjJ+v6QDhAfSVwyuf0+VvEViNkRpKVIEHWBNXoQKKlRMEz nJ/1P8nqsU/vk4kksNFFtFXALp+twbTxFvHMQPkV7RHPAbdBQ9EtRamM+oxaLaH/ zaZ2XPz19AADrXLtleeOGwBvjkFJw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddvhedgudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehm nhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeduvdeljeegtefhveekhfdtveekle evkeefgeeludeihfdugedvieeuffdttdfhnecuffhomhgrihhnpehivghtfhdrohhrghdp mhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 20 Oct 2021 19:08:26 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mark Nottingham In-Reply-To: Date: Thu, 21 Oct 2021 10:08:24 +1100 Cc: Barry Leiba , "gendispatch@ietf.org" , "Salz, Rich" Content-Transfer-Encoding: quoted-printable Message-Id: <8F3221D2-0FE4-4135-B874-3CB77B44B7D6@mnot.net> References: <4BDF1DD9-9D30-499F-8C26-1E7790F2A729@akamai.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Gendispatch] draft-rsalz-termlimits X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 23:08:37 -0000 +1. Our bench is sometimes *very* thin for ADs. Regarding the IAB - rather than tweak the rules it might be good for the = community to have a re-think about the function that it serves (or = thinks it does). Once we have clarity on that we can figure out what the = best policies are. Cheers, > On 21 Oct 2021, at 6:25 am, Eric Rescorla wrote: >=20 > I mostly agree with Barry. Specifically, Barry raises two points: >=20 > 1. In exceptional cases a candidate needs to be appointed for a third = term. I've seen this as well though I think it wouldn't be fatal if we = limited to two terms. > 2. That often you want to pick an active AD or an IAB member as IETF = Chair. I think this is the strongest point and it would be quite bad to = make this more difficult. >=20 > I am more sympathetic to the IAB case: there are always a lot of IAB = candidates and I don't think that having it be common practice for ADs = to go right to the IAB is that great. >=20 > -Ekr >=20 >=20 >=20 > I >=20 > On Wed, Oct 20, 2021 at 10:23 AM Barry Leiba = wrote: > Rich, thanks for bringing this to discussion. >=20 > First: I am very strongly *against* hard term limits, as it places > unreasonable limitations on the appointment process. In a public > voting system, it's antidemocratic, artificially eliminating the > ability to vote for whom one thinks is best. In our NomCom system, it > restricts the NomCom from considering excellent candidates who have > been doing well and can be expected to continue that way. And it > would make it impossible for a NomCom to re-appoint an excellent AD > (say), when there are no good alternatives, ending us up with a bad > choice because it's the best the NomCom had to work with. >=20 > Second, I am very strongly *for* soft term limit guidance. > Specifically saying that NomComs MUST consider more than two terms to > be atypical and more than three to be truly exceptional, and [etc, > etc, wording like that with further explanation] would absolutely get > my support. But NomComs *have* to have options to deal with > situations where re-appointing someone for a third (or fourth) term > really *is* the right thing *in this case*. >=20 > Third, while I appreciate the desire not to have ADs move straight to > the IAB or vice-versa, and while a one-year gap before making the move > is not unreasonable, the issue is more of a challenge for someone > moving into the IETF Chair role. Here are two reasons why: >=20 > - It's critical for an IETF Chair to have experience as an AD. And, > while Lars's experience is older and he is doing and will do fine, > we've generally had more recent ADs step into the IETF Chair position. > I would not want to limit the NomCom by saying that they can't appoint > a sitting AD as the next IETF Chair. >=20 > - The IETF Chair is only appointed every two years. An AD who wants > the IETF Chair position would have to step down at least a year ahead, > and an AD whose term is in sync with the IETF Chair appointment would > have to step down at least two years ahead. Given that a one-term > IETF Chair is likely to get a second term, that could move to four > years ahead. Now we have an AD who might have been a great choice for > IETF Chair, but has to wait four years -- and be four years away from > the AD experience -- before she will really be considered by the > NomCom (especially if we should also move in the direction of JCK's > proposal). >=20 > So *if* we should go in the direction Rich proposes, I would want to > see an exception for IETF Chair appointments. >=20 > But, really, I'd much rather see us move toward giving NomComs very > clear and strong guidance on what the community expects, but leave > them the option to do what needs to be done as the situation might > require. >=20 > Barry >=20 > --=20 > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > --=20 > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch -- Mark Nottingham https://www.mnot.net/ From nobody Fri Oct 22 09:55:02 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5DD3A1172; Fri, 22 Oct 2021 09:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0Tk4o3N-i98; Fri, 22 Oct 2021 09:54:37 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320CF3A1179; Fri, 22 Oct 2021 09:54:36 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mdxoQ-000CUU-M3; Fri, 22 Oct 2021 12:54:34 -0400 Date: Fri, 22 Oct 2021 12:54:28 -0400 From: John C Klensin To: ietf@ietf.org, gendispatch@ietf.org cc: Spencer Dawkins Message-ID: <4B6D22A2C61695F81D4DDB37@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Gendispatch] draft-klensin-nomcom-term-02 (was: [was: draft-rsalz-termlimits] and draft-leiba-term-limit-guidance-00 X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2021 16:54:45 -0000 Hi. I mentioned this ancient proposal in the context of Rich's request for a GENDISPATCH slot. In the interest of having a contemporary document out there, I just posted a semi-current version. Having not been able to reach/ get a response from Spencer, I'm posting it as sole author but I hope that is temporary. I find much to like in Rich's draft but, like Barry (and what feels to me like the general discussion) dislike rigid limits. This draft does not impose those limits but takes a slightly different view of them than Barry's draft, making an explicit change to how the Nomcom process handles incumbents. That change would probably reduce load on the Nomcom somewhat. It would largely eliminate the possibility of someone running against an incumbent who is seen as having done well simply for practice (I don't know how many people think that is important). In retrospect, I don't really know whether that procedure should be applied to all incumbents or only ones seeking a second term or a second or third one. If the community is not interested an making that sort of change, Barry's draft is probably the foundation on which to build. Please note that this I-D is a slightly rewarmed version of a 2005-2006 proposal that was written partially as a think piece rather than a complete and formal proposal. That shows and I have deliberately not invested much time in fixing/ modernizing it. If the community is interested in the change to the procedures it implies, an update including something of a merge among it and some of the idea and text in Barry's and Rich's drafts would be helpful. If not, it isn't worth much (or any) more effort. best, john From nobody Wed Oct 27 05:13:11 2021 Return-Path: X-Original-To: gendispatch@ietfa.amsl.com Delivered-To: gendispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4602A3A110F; Wed, 27 Oct 2021 05:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KWMANoPQwXc; Wed, 27 Oct 2021 05:12:56 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 EE0833A110A; Wed, 27 Oct 2021 05:12:51 -0700 (PDT) Received: from [IPV6:2a02:aa15:4101:2a80:9916:9b8c:d136:30ae] ([IPv6:2a02:aa15:4101:2a80:9916:9b8c:d136:30ae]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 19RCCmDN1187221 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 27 Oct 2021 14:12:48 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1635336769; bh=KrQkn2JLd+HtJY/NWV7OEE4Wd9Wm2XCAiyYldowfatU=; h=Date:To:Cc:Reply-To:From:Subject:From; b=B/og3ZYCky2WK0rZ/6gfd1ckFqbeGG/2CLgA8+wxMCNPgv7cReEsBAn98AC2/al6z 6bxaOQMjrhXA2CzvI461xXw0a1vrDURlRtg5BwenocBKmpCwXhqSqSN2KL0ZKK3wI6 PPFlrDKb5gU5lHqGFDbn3PLeh/g+MZMBP/J4+EVI= Message-ID: <0e0db0df-6e23-ed9a-2c6e-1d7dc57fac1b@lear.ch> Date: Wed, 27 Oct 2021 14:12:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 Content-Language: en-US To: "irtf-discuss@irtf.org" , gendispatch@ietf.org, The IETF List , rfc-interest@ietf.org Cc: "rfced-future@iab.org" , Brian Rosen Reply-To: "rfced-future@iab.org" From: Eliot Lear Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------jlh709raj4unRJuVAzy9bNuY" Archived-At: Subject: [Gendispatch] Upcoming Community Consultations on Next Generation RFC Model X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 12:13:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------jlh709raj4unRJuVAzy9bNuY Content-Type: multipart/mixed; boundary="------------9SwCufWD1UboIrBgi0JZZ6VC"; protected-headers="v1" From: Eliot Lear Reply-To: "rfced-future@iab.org" To: "irtf-discuss@irtf.org" , gendispatch@ietf.org, The IETF List , rfc-interest@ietf.org Cc: "rfced-future@iab.org" , Brian Rosen Message-ID: <0e0db0df-6e23-ed9a-2c6e-1d7dc57fac1b@lear.ch> Subject: Upcoming Community Consultations on Next Generation RFC Model --------------9SwCufWD1UboIrBgi0JZZ6VC Content-Type: multipart/alternative; boundary="------------VbAGZ5nczXPcH5GlkSjHrRi1" --------------VbAGZ5nczXPcH5GlkSjHrRi1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 RGVhciBjb2xsZWFndWVzLA0KDQpJbiBNYXJjaCBvZiAyMDIwIHRoZSBJQUIga2lja2VkIG9m ZiB0aGUgUkZDIFNlcmllcyBFZGl0b3JpYWwgRnV0dXJlIA0KRGV2ZWxvcG1lbnQgUHJvZ3Jh bSwgYSBwcm9ncmFtIG9wZW5lZCB0byB0aGUgZW50aXJlIGNvbW11bml0eSwgd2l0aCBhbiAN CmV5ZSB0b3dhcmQgcmV2aWV3aW5nIHRoZSBSRkMgRWRpdG9yIG1vZGVsIGZvdW5kIGluIA0K ZHJhZnQtaWFiLXJmY2VmZHAtcmZjZWQtbW9kZWwtMDVbMV0uIFdlIGFyZSBub3cgY29taW5n IHRvIHRoZSBjb25jbHVzaW9uIA0Kb2Ygb3VyIHdvcmssIGFuZCB0aGUgSUFCIHdpbGwgc29v biBiZWdpbiBpdHMgZm9ybWFsIGNvbnNpZGVyYXRpb24sIHdoaWNoIA0KaXMgZ292ZXJuZWQg YnkgUkZDIDQ4NDVbMl0uIFBhcnQgb2YgdGhhdCBwcm9jZXNzIGluY2x1ZGVzIHNvbGljaXRh dGlvbiANCm9mIGNvbW11bml0eSBpbnB1dC4NCg0KVGhlIHByb2dyYW0gaGFzIGRldmVsb3Bl ZCBhbiBldm9sdXRpb24gb2YgdGhlIFJGQyBFZGl0b3IgTW9kZWwgYW5kIGEgDQpzbWFsbCBj aGFuZ2UgdG8gdGhlIGNoYXJ0ZXIgb2YgdGhlIElBQi4gWW91IGNhbiBmaW5kIHRoaXMgZXZv bHV0aW9uIGluIA0KZHJhZnQtaWFiLXJmY2VmZHAtcmZjZWQtbW9kZWwtMDUgYXMgd2VsbCBh cyB0d28gY29tcGFuaW9uIGRyYWZ0c1szLDQsNV0uIA0KVGhpcyBkcmFmdCBicmluZ3MgdG9n ZXRoZXIgbWFueSBkaWZmZXJlbnQgcG9pbnRzIG9mIHZpZXcsIGFzIHlvdSBjYW4gc2VlIA0K ZnJvbSB0aGUgbWFpbGluZyBsaXN0IGFyY2hpdmVbNl0uDQoNCkhlcmUgYXJlIHNvbWUgb2Yg dGhlIHByb3Bvc2VkIGNoYW5nZXMgdGhhdCB5b3UgbWF5IHdpc2ggdG8ga25vdzoNCg0KIDEu DQoNCiAgICBUaGUgY29tbXVuaXR5IG92ZXJzZWVzIHRoZSBldm9sdXRpb24gb2YgdGhlIHNl cmllcyBieSBtZWFucyBvZiBhbg0KICAgIG9wZW4gd29ya2luZyBncm91cC4gUHJvcG9zZWQg Y2hhbmdlcyB0aGF0IHJlYWNoIHJvdWdoIGNvbnNlbnN1cyB3aWxsDQogICAgYmUgcmV2aWV3 ZWQgYnkgYW4gUkZDIFNlcmllcyBBcHByb3ZhbCBCb2FyZCAoUlNBQikgdGhhdCBjb25zaXN0 cyBvZg0KICAgIHRoZSBSU0NFIGFuZCBwZW9wbGUgcmVwcmVzZW50aW5nIHRoZSB2YXJpb3Vz IHN0cmVhbXMuDQoNCiAyLg0KDQogICAgVGhlIFJGQyBFZGl0b3Igcm9sZSBpcyBjaGFuZ2lu ZyB0byB0aGF0IG9mIGEgY29uc3VsdGluZyBlZGl0b3IgKFJGQw0KICAgIFNlcmllcyBDb25z dWx0aW5nIEVkaXRvciBvciBSU0NFKS4gSW4gdGhpcyBtb2RlbCwgYW4gZXhwZXJ0IHdpbGwN CiAgICBwcm92aWRlIGd1aWRhbmNlIHRvIHRoZSBjb21tdW5pdHksIHRoZSBzdHJlYW1zLCBh bmQgdG8gdGhlIFJQQyB0bw0KICAgIGV2b2x2ZSB0aGUgc2VyaWVzLg0KDQogMy4NCg0KICAg IFRoZSBJQUIgd2lsbCBubyBsb25nZXIgbWFuYWdlIG9yIG92ZXJzZWUgdGhlIFJGQyBzZXJp ZXMuIFRoZQ0KICAgIGNvbW11bml0eSBhbmQgdGhlIHN0cmVhbXMgd2lsbCBkbyB0aGF0LiBU aGUgSUFCIHdpbGwgY29udGludWUgdG8gYmUNCiAgICBpbiB0aGUgYXBwZWFsIHBhdGggaWYg dGhlcmUgYXJlIGRpc3B1dGVzLg0KDQpUaGVyZSBhcmUgYSBsb3Qgb2YgdGhpbmdzIHRoYXQg d29uJ3QgY2hhbmdlLiBUaGUgUlBDIHdvdWxkIGNvbnRpbnVlIHRvIA0KaGFuZGxlIGRheS10 by1kYXkgZnVuY3Rpb25zIG9mIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uLCBhbmQgYXV0aG9y cyANCnNob3VsZCBub3Qgc2VlIGFueSBpbW1lZGlhdGUgY2hhbmdlIGluIHRlcm1zIG9mIGhv dyBSRkNzIGFyZSBwdWJsaXNoZWQuIA0KVGhleSBjb250aW51ZSB0byBiZSBtYW5hZ2VkIHRo cm91Z2ggdGhlIExMQy4gV2Ugd2lsbCBjb250aW51ZSB0byBiZW5lZml0IA0KZnJvbSB0aGUg ZXhwZXJ0aXNlIG9mIGEgcHJvZmVzc2lvbmFsIGV4cGVydCwgbm93IHRoZSBSU0NFLg0KDQpP ZiBjb3Vyc2UsIHRoZXJlJ3MgYSBsb3QgbW9yZSBkZXRhaWwgdGhhdCBpcyBzcGVjaWZpZWQg aW4gdGhlIGRyYWZ0cy4NCg0KVGhpcyBpcyB3aGF0IHdpbGwgc29vbiBiZSBwdXQgZm9ydGgg Zm9yIHlvdXIgY29tbWVudHMuIEluIHRoZSBtZWFudGltZSwgDQpldmVuIHRob3VnaCB0aGUg Zm9ybWFsIGNvbW1lbnQgcGVyaW9kIGlzIG5vdCB5ZXQgb3Blbiwgd2UgaW52aXRlIHlvdSB0 byANCnJldmlldyB0aGUgbW9kZWwgbm93IGFuZCBicmluZyB3aGF0ZXZlciBxdWVzdGlvbnMg eW91IG1pZ2h0IGhhdmUgdG8gdGhlIA0KcHJvZ3JhbSB3aGVuIHdlIG1lZXQgb24gV2VkbmVz ZGF5LCBOb3ZlbWJlciAxMHRoLCBhdCAxNC4zMCBHTVQgYXQgdGhlIA0KSUVURiBtZWV0aW5n LiBPZiBjb3Vyc2UgeW91IGNhbiBhbHNvIGpvaW4gdGhlIG1haWxpbmcgbGlzdFs3XSBhbmQg DQpjb250cmlidXRlIHlvdXIgcXVlc3Rpb25zIGFuZCBjb21tZW50cyB0aGVyZS4NCg0KT24g YmVoYWxmIG9mIHRoZSBwcm9ncmFtLA0KDQpCcmlhbiBhbmQgRWxpb3QNCg0KWzFdIA0KaHR0 cHM6Ly93d3cuaWFiLm9yZy9hY3Rpdml0aWVzL3Byb2dyYW1zL3JmYy1lZGl0b3ItZnV0dXJl LWRldmVsb3BtZW50LXByb2dyYW0vDQpbMl0gaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcv cmZjL3JmYzQ4NDUuaHRtbA0KWzNdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtaWFiLXJmY2VmZHAtcmZjZWQtbW9kZWwtMDUNCls0XSANCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtY2FycGVudGVyLXJmY2VkLWlh Yi1jaGFydGVyLTAzDQpbNV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1yb3Nlbi1yZmNlZmRwLXVwZGF0ZS0yMDI2LTAxDQpbNl0gaHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9yZmNlZC1mdXR1cmUvDQpbN10gaHR0cHM6 Ly93d3cuaWFiLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JmY2VkLWZ1dHVyZQ0KDQo= --------------VbAGZ5nczXPcH5GlkSjHrRi1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear colleagues,

In March of 2020 the IAB kicked off the RFC Series Editorial Future Development Program, a program opened to the entire community, with an eye toward reviewing the RFC Editor model found in draft-iab-rfcefdp-rfced-model-05[1]. We are now coming to the conclusion of our work, and the IAB will soon begin its formal consideration, which is governed by RFC 4845[2]. Part of that process includes solicitation of community input.

The program has developed an evolution of the RFC Editor Model and a small change to the charter of the IAB. You can find this evolution in draft-iab-rfcefdp-rfced-model-05 as well as two companion drafts[3,4,5]. This draft brings together many different points of view, as you can see from the mailing list archive[6].

Here are some of the proposed changes that you may wish to know:

  1. The community oversees the evolution of the series by means of an open working group. Proposed changes that reach rough consensus will be reviewed by an RFC Series Approval Board (RSAB) that consists of the RSCE and people representing the various streams.

  2. The RFC Editor role is changing to that of a consulting editor (RFC Series Consulting Editor or RSCE). In this model, an expert will provide guidance to the community, the streams, and to the RPC to evolve the series.

  3. The IAB will no longer manage or oversee the RFC series. The community and the streams will do that. The IAB will continue to be in the appeal path if there are disputes.

There are a lot of things that won't change. The RPC would continue to handle day-to-day functions of the RFC Editor function, and authors should not see any immediate change in terms of how RFCs are published. They continue to be managed through the LLC. We will continue to benefit from the expertise of a professional expert, now the RSCE.

Of course, there's a lot more detail that is specified in the drafts.

This is what will soon be put forth for your comments. In the meantime, even though the formal comment period is not yet open, we invite you to review the model now and bring whatever questions you might have to the program when we meet on Wednesday, November 10th, at 14.30 GMT at the IETF meeting. Of course you can also join the mailing list[7] and contribute your questions and comments there.

On behalf of the program,

Brian and Eliot

[1] https://www.iab.= org/activities/programs/rfc-editor-future-development-program/
[2] https://www.rfc-= editor.org/rfc/rfc4845.html
[3] https://datatrac= ker.ietf.org/doc/html/draft-iab-rfcefdp-rfced-model-05
[4] https://datatrac= ker.ietf.org/doc/html/draft-carpenter-rfced-iab-charter-03
[5] https://datatrac= ker.ietf.org/doc/html/draft-rosen-rfcefdp-update-2026-01
[6] https://mailarch= ive.ietf.org/arch/browse/rfced-future/
[7] https://www.iab.= org/mailman/listinfo/rfced-future

--------------VbAGZ5nczXPcH5GlkSjHrRi1-- --------------9SwCufWD1UboIrBgi0JZZ6VC-- --------------jlh709raj4unRJuVAzy9bNuY Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmF5Qj8FAwAAAAAACgkQh7ZrRtnSejM2 iwgAi6HcFxgP7A5VN4w7DsVmkSL9aiu7ZTARsLSaLnJWwiDhdlrbe6dBX3iRj3ci4yCTJPG5LjtL GFHg/DvrQLkoTakLQJiJNkwLHzMRqEkqIBReCokhp22jGiESEkfqZb5M/UgsyqR/mjf5YZcEDcpG eOi7P78Ldy4EWvaV0YgspfIxWVuS1kSK2BmYbN2A+5ZstVgYPkzJtlkNEQf/HJiKE7xzAN/BIAr2 LnwkJFrF5KTspUiJo9vTk/fZTtzxrWAALZmNGGXa49vrQYCvw2A/UP5suzd4Yy8ekoLQboIb4qx7 gibTuU0Vq0rpGqSvuGfs9mIDNdWE0XtIFpbGecHt7A== =ID7W -----END PGP SIGNATURE----- --------------jlh709raj4unRJuVAzy9bNuY-- From nobody Sun Oct 31 14:58:52 2021 Return-Path: X-Original-To: expand-draft-eggert-bcp45bis.all@virtual.ietf.org Delivered-To: gendispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 060F73A0A83; Sun, 31 Oct 2021 14:58:43 -0700 (PDT) X-Original-To: draft-eggert-bcp45bis.all@ietf.org Delivered-To: xfilter-draft-eggert-bcp45bis.all@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA983A0967; Sun, 31 Oct 2021 14:58:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Elwyn Davies via Datatracker To: Cc: draft-eggert-bcp45bis.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163571752223.22416.4536300554332587854@ietfa.amsl.com> Reply-To: Elwyn Davies Date: Sun, 31 Oct 2021 14:58:42 -0700 Resent-From: Resent-To: gendispatch@ietf.org, lars@eggert.org, rwilton@cisco.com Resent-Message-Id: <20211031215843.060F73A0A83@ietfa.amsl.com> Resent-Date: Sun, 31 Oct 2021 14:58:43 -0700 (PDT) Archived-At: Subject: [Gendispatch] Genart last call review of draft-eggert-bcp45bis-06 X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2021 21:58:43 -0000 Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-eggert-bcp45bis-06 Reviewer: Elwyn Davies Review Date: 2021-10-31 IETF LC End Date: 2021-11-23 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits. The body of the document appears fine, but the Abstract doesn't provide much insight into the content of the document. Major issues: None Minor issues: None Nits/editorial comments: Abstract:, para 1:  Suggest adding a sentence or two to explain what the document actually does., e.g.: s/... mailing list./...mailing list; this document provides guidance on the intended scope of discussions appropriate for the mailing list as currently envisaged while indicating certain types of postings that would be inappropriate. In neither case are the lists considered exhaustive.   The mailing list is intended to operate with self-moderation overseen by member(s) of the Sergeants-at-Arms (SAA) team.  This document sets out the processes by which SAAs monitoring this mailing list are appointed and removed together with their powers as regards control of posting to the list../