From nobody Tue Jun 1 06:57:21 2021 Return-Path: X-Original-To: rfced-future@iab.org Delivered-To: rfced-future@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 619323A17F7; Tue, 1 Jun 2021 06:57:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IAB Executive Administrative Manager To: "IETF-Announce" Cc: rfced-future@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162255583627.26536.11212349305688602887@ietfa.amsl.com> Date: Tue, 01 Jun 2021 06:57:16 -0700 Archived-At: Subject: [Rfced-future] RFC Editor Future Development (rfcefdp) PROGRAM Virtual Meeting: 2021-06-21 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2021 13:57:17 -0000 The RFC Editor Future Development (rfcefdp) Program will hold a virtual interim meeting on 2021-06-21 from 20:00 to 22:00 GMT (20:00 to 22:00 UTC). Agenda: Continue going through our issues. Information about remote participation: https://cisco.webex.com/cisco/j.php?MTID=mc92c349c6fc0514e41265b3041bcc92b https://cisco.webex.com/cisco/j.php?MTID=mc92c349c6fc0514e41265b3041bcc92b From nobody Mon Jun 7 23:11:15 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CFC3A2395 for ; Mon, 7 Jun 2021 23:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=jxnphpLL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Iz+75HxU 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 qom1feXFZ7XF for ; Mon, 7 Jun 2021 23:11:07 -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 AEEE43A2394 for ; Mon, 7 Jun 2021 23:11:07 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 3C74D1528 for ; Tue, 8 Jun 2021 02:11:06 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 08 Jun 2021 02:11:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:to; s=fm2; bh=SXNn0SuK+7gzio1VkGZLwBR3WW7nL8fQc rrRrnM3jlA=; b=jxnphpLLddD5rU0lXI/jVITNPGcFWIPHHKii1UMVMsKfPuUCD IE9yfRTqTW9gnzs3P6CZwpSiNrl6yfq9G+Qvq/3IyDUfK8EDQWeAP8VtYr8xJSrd 7+eevbELHn3/eVRZBlq1pxHMyLzRE+OuNcLcvIrwl9pWPE+NAnwz6HvFIIqGmpjX qzgaqkNUoZ8x3gbtuBwL5t2gxH5RZdPAToxn33Xpy84zLBeKQzWiIsC3FEiXgtY/ Hbc35VH+E7LLNC1b8mtIpBe/Co12hXzykuXbDG99VtxNtR4JVNMSJf0z/+K1H2nu iAF+iI54/RH94ChgZGYr4Polp9GfVBtFz0IuA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=SXNn0S uK+7gzio1VkGZLwBR3WW7nL8fQcrrRrnM3jlA=; b=Iz+75HxU6akSi9QmW2lcbG YZiWlQrWBcbFEOJvGOVFpnbaYv646AuOfIjVCyr+RVOFHJPhBgMD7bEDfTHgqYUM xKVErbCxx3qXNklAt9M1NHUGmIKsT2RpAaTD1Z9i7CrLgIeEzq1kckxrZAZyb3Ps u072/lB+bctYuidT4uCHJP0g6zl86pkEKRmJKTzneyzLaYbzM/ypcLUil0L9FzY/ aqHciX8ltfdXdezrL5xM5nJkabjs2zkYZPHLIUWVazetCSPef1fcX/oh2hLue/7m WUWtGTzXSYNqP5vbNX/qlMSpBgGfxPQoPVScgwSWiV2t2MgNCU9ZUSybYnB9I9Mw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtkedgleeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtgfgggfukfffvffosehtqhhmtd hhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhho thdrnhgvtheqnecuggftrfgrthhtvghrnhepuddujefhiefgkeeltdeluefhgeehhfduhe ethfevgefgveekleevgfejgeeileegnecuffhomhgrihhnpehrfhgtqdgvughithhorhdr ohhrghdpmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 8 Jun 2021 02:11:03 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Message-Id: Date: Tue, 8 Jun 2021 16:11:00 +1000 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: [Rfced-future] Proposal: Community calls for comment (transparency) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 06:11:14 -0000 At the interim, I took a action item to propose text about community = review and transparency. Looking at the current draft, I see that there = is already an open issue to 'specify what counts as a "community call = for [comment]".'=20 My proposal is to insert the following into a new section for reference = from 5.2.2 (Specifics); exact placement I leave to the editor. ~~~ X.X Community Call for Comment When a community call for comment is made, the RSAB sends a notice to at = least the rfc-interest mailing list with a Subject line beginning with = "Call for Comment:". When either the RSAB or the RSWG considers the = proposal warrant it, the notice is also be sent to the ietf-announce and = irtf-announce mailing lists. Notices are also to be made available and = archived on the rfc-editor.org web site. A notice contains: * A clear, concise summary of the proposal * A URL for the proposal document=20 * Any commentary or questions for the community that the RSAB deems = necessary (using their usual decision-making procedures) * Clear instructions on how to provide public comments * A deadline for comments A comment period will not be less than two weeks, unless both the RSAB = and RSWG have consensus that adopting the proposal is urgent and = uncontroversial, in which case the minimum comment period is one week. = If a proposal requires more than one comment period, those after the = first can be shortened to one week at the discretion of the RSAB. Comments will be publicly archived on the rfc-editor.org web site. ~~~ Thoughts? Since we're talking about transparency, I'm also inclined to think we = need to have announcement and records about the decisions taken (in = addition to the comment periods). E.g., any CONCERN positions and the = actual voting of the RSAB needs to be made public, and archived. Does = that make sense? Also, I haven't addressed transparency in the RSWG, under the = presumption that since it operates like a normal WG, it should follow = that it operates in the open. If folks think that needs to be clarified = or strengthened, we should do so. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Jun 7 23:37:18 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250F03A2453 for ; Mon, 7 Jun 2021 23:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=joelhalpern.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 FWyMxwxGx156 for ; Mon, 7 Jun 2021 23:37:12 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 556C03A2451 for ; Mon, 7 Jun 2021 23:37:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4FzgWq6zkzz1nvxk; Mon, 7 Jun 2021 23:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1623134231; bh=l4N8fm07/CpnDfg6xjtLBsR9OiHNt9XZRKwgLsuYnWk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Qr5C8rj4qS6FaT646/AbXWfTEGcMR0JAV1gTdoHlS/COdrAK09Tzo2kYSLWwiEHmM H8fHQ+QsLKVsYcDJl1eFWRu9veK7qMN/KxcB6Lp+METMx9K5ZHGpmrxh7c5OEvU/44 2i9LLl/TNZt3PSMxUkuXbW68jIdiNLx7MfD+gedo= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4FzgWq3CJMz1nv5N; Mon, 7 Jun 2021 23:37:11 -0700 (PDT) To: Mark Nottingham , rfced-future@iab.org References: From: "Joel M. Halpern" Message-ID: <784aaa4c-d40b-939a-15da-8a6684b89b55@joelhalpern.com> Date: Tue, 8 Jun 2021 02:37:09 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Proposal: Community calls for comment (transparency) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 06:37:17 -0000 Mark, I think I am missing two aspects in your proposed text. First, it seems to me that any action that has reached final enough form for community comment should go to ietf-announce (or the ietf last-call list maybe?) Saying that only special decisions need to go to the full IETF seems odd. Separately, there was also extensive discussion on this list of the need to include the larger community in the feedback loop. Your proposed text does nto seem to do so. Yours, Joel On 6/8/2021 2:11 AM, Mark Nottingham wrote: > At the interim, I took a action item to propose text about community review and transparency. Looking at the current draft, I see that there is already an open issue to 'specify what counts as a "community call for [comment]".' > > My proposal is to insert the following into a new section for reference from 5.2.2 (Specifics); exact placement I leave to the editor. > > ~~~ > X.X Community Call for Comment > > When a community call for comment is made, the RSAB sends a notice to at least the rfc-interest mailing list with a Subject line beginning with "Call for Comment:". When either the RSAB or the RSWG considers the proposal warrant it, the notice is also be sent to the ietf-announce and irtf-announce mailing lists. Notices are also to be made available and archived on the rfc-editor.org web site. > > A notice contains: > > * A clear, concise summary of the proposal > * A URL for the proposal document > * Any commentary or questions for the community that the RSAB deems necessary (using their usual decision-making procedures) > * Clear instructions on how to provide public comments > * A deadline for comments > > A comment period will not be less than two weeks, unless both the RSAB and RSWG have consensus that adopting the proposal is urgent and uncontroversial, in which case the minimum comment period is one week. If a proposal requires more than one comment period, those after the first can be shortened to one week at the discretion of the RSAB. > > Comments will be publicly archived on the rfc-editor.org web site. > ~~~ > > Thoughts? > > Since we're talking about transparency, I'm also inclined to think we need to have announcement and records about the decisions taken (in addition to the comment periods). E.g., any CONCERN positions and the actual voting of the RSAB needs to be made public, and archived. Does that make sense? > > Also, I haven't addressed transparency in the RSWG, under the presumption that since it operates like a normal WG, it should follow that it operates in the open. If folks think that needs to be clarified or strengthened, we should do so. > > Cheers, > > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Mon Jun 7 23:47:35 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE8C3A24A7 for ; Mon, 7 Jun 2021 23:47:34 -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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=sdPVv9gQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Fmi0sLoR 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 d91uBaI36Q80 for ; Mon, 7 Jun 2021 23:47:29 -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 101FC3A24A4 for ; Mon, 7 Jun 2021 23:47:28 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 3008C1717; Tue, 8 Jun 2021 02:47:28 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 08 Jun 2021 02:47: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=fm2; bh=Q VblTs2uSLfiHfbG/o34nunv6raH3PSwW8QYCsCcvBA=; b=sdPVv9gQ2/Ueh4q3E 7w5NJQnhwceFlxQHJ1FHIESrZIcpRT+BWmwkvhNUGvVIS0TDqzj0Re30R03+MOkq BLGIu4D5kjGXvH3xYbmBIv+JIts8rUnVDtaTtQ4MLNHz3WK7aiRYNrhtIGIfbUJa o7FrqYmd3SHcLKDZxI7xIo2dG+25ZhUDoEB9vm/03Y9qpjhSHLSNjuafdNvnEa/G /0/xx1MtKZarNUmrIjaSD+9U0HIdo5FW6fgxhyxKRcz56hk3LkJBaoccYnyia5Dx jwIioXJboUPwsAAMpaK5Z4cUbKe2PpMtnanmghhF2GPrxxlP73d+ERFlG+fWFZbV Ve9Rw== 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=fm3; bh=QVblTs2uSLfiHfbG/o34nunv6raH3PSwW8QYCsCcv BA=; b=Fmi0sLoRsd3N2npXCea3sjcV/n3zBQuVoD3zTnsfGowjHdPFslcVcKjTO sBZKnBCCflC9IE2psq5j68bY6BUm1/oG5CFTbAYUKf9PKFd8kZAPYk+1VsI2ds2w 4eJYEm9aNUY7Ye8W/27hvUEh99wiX2HrRmqEQzgO1igX5z09x4PNSMBnMfBanE2x 0+hA/UFuNEfKBYVhNfvQ9P+1NfHCbvg2spMwIAlMryJWWQ+UHfUZGF0Z6RKDMaFm Ls72Y6exsVaPube1XLab8xyq8Jbgzh5Fz8l6IG5EoFZX+dp1zyds6ShfcSHnsKi3 VmKez2gtq1iVBTZ5+EQsM5ryryT+Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtkedguddtfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesth hqmhdthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothes mhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekudekgfegiedvfeetgfejkeettd eghedtveeijeettdelvdfhueegudetudegudenucffohhmrghinheprhhftgdqvgguihht ohhrrdhorhhgpdhmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 8 Jun 2021 02:47:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Mark Nottingham In-Reply-To: <784aaa4c-d40b-939a-15da-8a6684b89b55@joelhalpern.com> Date: Tue, 8 Jun 2021 16:47:22 +1000 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <148204F1-F9A9-4777-BD8F-31297F10C4C3@mnot.net> References: <784aaa4c-d40b-939a-15da-8a6684b89b55@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] Proposal: Community calls for comment (transparency) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 06:47:34 -0000 Hi Joel, Thanks for the prompt feedback. Responses below. > On 8 Jun 2021, at 4:37 pm, Joel M. Halpern = wrote: >=20 > Mark, I think I am missing two aspects in your proposed text. >=20 > First, it seems to me that any action that has reached final enough = form for community comment should go to ietf-announce (or the ietf = last-call list maybe?) Saying that only special decisions need to go to = the full IETF seems odd. I'm not against it, but am a bit wary of flooding ietf-announce with = small changes. I suppose it might come down to the anticipated rate and = granularity of the decisions flowing through this new group -- do we = have a shared sense of that yet? > Separately, there was also extensive discussion on this list of the = need to include the larger community in the feedback loop. Your = proposed text does nto seem to do so. rfc-interest would capture anyone who's interested enough in RFCs to be = subscribed, regardless of IETF affiliation (as ephemeral a concept as = that is). Putting it on the RFC Editor Web site makes it discoverable to a broader = audience as well. In previous drafts I specified that there should be an = Atom/RSS feed of the notices; happy to add that again. What else can we do? I suppose we could have a dedicated list just for = the notices. We could more forcefully try to get it in front of people = who a decision might affect -- but I suspect that's going to be an = uphill battle, competing with much more enticing things for their = interest. We could require circulating in relevant communities -- e.g., = XML, publishing standards, etc. -- but that's largely a judgement call, = and sometimes it's going to be difficult to identify the right place to = engage a particular community; at best I think we could add some = advisory text guiding the RSAB to consider broader audiences that are = appropriate. Is that enough? Suggestions very welcome here. Cheers, >=20 > Yours, > Joel >=20 > On 6/8/2021 2:11 AM, Mark Nottingham wrote: >> At the interim, I took a action item to propose text about community = review and transparency. Looking at the current draft, I see that there = is already an open issue to 'specify what counts as a "community call = for [comment]".' >> My proposal is to insert the following into a new section for = reference from 5.2.2 (Specifics); exact placement I leave to the editor. >> ~~~ >> X.X Community Call for Comment >> When a community call for comment is made, the RSAB sends a notice to = at least the rfc-interest mailing list with a Subject line beginning = with "Call for Comment:". When either the RSAB or the RSWG considers the = proposal warrant it, the notice is also be sent to the ietf-announce and = irtf-announce mailing lists. Notices are also to be made available and = archived on the rfc-editor.org web site. >> A notice contains: >> * A clear, concise summary of the proposal >> * A URL for the proposal document >> * Any commentary or questions for the community that the RSAB deems = necessary (using their usual decision-making procedures) >> * Clear instructions on how to provide public comments >> * A deadline for comments >> A comment period will not be less than two weeks, unless both the = RSAB and RSWG have consensus that adopting the proposal is urgent and = uncontroversial, in which case the minimum comment period is one week. = If a proposal requires more than one comment period, those after the = first can be shortened to one week at the discretion of the RSAB. >> Comments will be publicly archived on the rfc-editor.org web site. >> ~~~ >> Thoughts? >> Since we're talking about transparency, I'm also inclined to think we = need to have announcement and records about the decisions taken (in = addition to the comment periods). E.g., any CONCERN positions and the = actual voting of the RSAB needs to be made public, and archived. Does = that make sense? >> Also, I haven't addressed transparency in the RSWG, under the = presumption that since it operates like a normal WG, it should follow = that it operates in the open. If folks think that needs to be clarified = or strengthened, we should do so. >> Cheers, >> -- >> Mark Nottingham https://www.mnot.net/ -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jun 8 00:22:27 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83533A25B0 for ; Tue, 8 Jun 2021 00:22:25 -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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=K6tqKuyd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Iw5uGmEx 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 d5dqX5O3yooQ for ; Tue, 8 Jun 2021 00:22:20 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37FB73A236A for ; Tue, 8 Jun 2021 00:22:20 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 322655C00AC for ; Tue, 8 Jun 2021 03:22:17 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute4.internal (MEProxy); Tue, 08 Jun 2021 03:22:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=jMCUKh2w4RDPzY2a5OdR0JIcZIjghyP CBtyqdo++4SE=; b=K6tqKuydYWai4fRi+DNGw7uNIRkjWhlocrw/69Vx9WCgEq+ 8ylOgPHHLZqCHnipeiW2d4voR/WVK8/PsGdR2xKHzF5pK1OQzCo7izNscL63/y84 kCZ5jFX8YV9ipqw+8troLxjCcnmoHmDc8r0TWfSF+YiGv1TeOHTqgrG9hWn0eP9Y nY2MCDlCdpXVVnvhos/23z51pnBtVqwGIi/hBx0rKoruTLETGFK1tWV5cdEHbfyY msGpSfRr0nl7PYjFpjczxuZYasN4FFHBJ67CJBRygZcQtxMYKwquHpVzHSHEAkxF RNElN5GEKfEO/INIgob8AHJSHyYWa92b/RnRWNw== 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=fm3; bh=jMCUKh 2w4RDPzY2a5OdR0JIcZIjghyPCBtyqdo++4SE=; b=Iw5uGmExofz+iIfbLYAq8F LURBXZ8z576LfN1wFXTlqv/fjExJFKZCbxiWtvzbU+PipCjC7/Xi/N3h4P8VgEDp D8NQudVL+ZJbMXZIG5IcJTaIcQeEr9Qvyf3Zr82Wt7KbW0OJkOHyrr8gVUiLOq+r frUyQQXIcfovp40pdS9s+CbQFPO+5XMSRfZboRY/tPXJLsDR6jCzB2fVPh3AKseu Lh8ETWg4qjErZyiIQjft8GDnjTcKQRKvUzY5xMBGx8LNZ8+Wpqd5woJAATbPB6Bg XMrSHD4THBgrZDKDBAjficzJFsPcpXN5PvqlVJLH0OFrY1gBTDRccar+itBeMp6Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtkedguddutdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnheplefgtdefhfduveffvd elkeevffeuffegieejleeitdegkeeifedvhfefhedtvdeinecuffhomhgrihhnpehrfhgt qdgvughithhorhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E44B74E0091; Tue, 8 Jun 2021 03:22:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-519-g27a961944e-fm-20210531.001-g27a96194 Mime-Version: 1.0 Message-Id: <2667def3-af0a-42ed-8777-c2caecd939e7@www.fastmail.com> In-Reply-To: <148204F1-F9A9-4777-BD8F-31297F10C4C3@mnot.net> References: <784aaa4c-d40b-939a-15da-8a6684b89b55@joelhalpern.com> <148204F1-F9A9-4777-BD8F-31297F10C4C3@mnot.net> Date: Tue, 08 Jun 2021 17:21:57 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Proposal=3A_Community_calls_for_comment?= =?utf-8?q?_=28transparency=29?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 07:22:26 -0000 On Tue, Jun 8, 2021, at 16:47, Mark Nottingham wrote: > What else can we do? I think that rfc-interest@ and rfc-editor.org are probably adequate as a baseline. Rather than attempting to enumerate the options, why not allow the RSAB to maintain a list of places that it might send notices to and allow them to exercise judgment in whether they do that. I'd say that they can keep a list of "groups that might be interested" in a wiki or similar and just check to see if they want to share specially with those groups if something relevant to them comes up. That's pretty much what you have, except that you are attempting to specify the list now. I agree with Joel that maybe sometimes ietf-announce@ might be appropriate. But I wouldn't mandate it. What I think is needed is a system that would catch accidents where it would have been good for notice to be provided, but the RSAB just forgot. From nobody Tue Jun 8 01:13:23 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942C53A2795 for ; Tue, 8 Jun 2021 01:13:13 -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 4RTm97ux4Bjc for ; Tue, 8 Jun 2021 01:13:08 -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 ADAA13A2785 for ; Tue, 8 Jun 2021 01:13:08 -0700 (PDT) Received: from smtpclient.apple (unknown [212.68.24.84]) (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 4DC3260032B; Tue, 8 Jun 2021 11:13:01 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1623139981; bh=FllwVVbOzxJYOOp52aCOBJQd56dVc26YVMFDIqEtSVg=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=XoXhs/6tSnC4b+4L+6R0BrGtOjxn7uLvyJNz/2uEsxtbEJih55ostW6+OMdddlHtt Rzz6/5KlIdBc34EB2wXQZuMJkQS3UJxOgnGLcUEiyr/sgjT09AN6yhLnSzjDKrwjtz yTbC8XNA5HQPrbSuPrS7uGkdsnpA5BUnNsDiFYi8= From: Lars Eggert Message-Id: <53EA92F3-DB77-4451-9823-2900717E4248@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_F6D872C3-34CB-426C-BA44-427B80B3CB49"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Tue, 8 Jun 2021 11:13:00 +0300 In-Reply-To: <148204F1-F9A9-4777-BD8F-31297F10C4C3@mnot.net> Cc: "Joel M. Halpern" , rfced-future@iab.org To: Mark Nottingham References: <784aaa4c-d40b-939a-15da-8a6684b89b55@joelhalpern.com> <148204F1-F9A9-4777-BD8F-31297F10C4C3@mnot.net> X-MailScanner-ID: 4DC3260032B.A06AB X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Rfced-future] Proposal: Community calls for comment (transparency) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 08:13:22 -0000 --Apple-Mail=_F6D872C3-34CB-426C-BA44-427B80B3CB49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2021-6-8, at 9:47, Mark Nottingham wrote: >> On 8 Jun 2021, at 4:37 pm, Joel M. Halpern = wrote: >> First, it seems to me that any action that has reached final enough = form for community comment should go to ietf-announce (or the ietf = last-call list maybe?) Saying that only special decisions need to go to = the full IETF seems odd. >=20 > I'm not against it, but am a bit wary of flooding ietf-announce with = small changes. I suppose it might come down to the anticipated rate and = granularity of the decisions flowing through this new group -- do we = have a shared sense of that yet? +1 on not flooding ietf-announce. We've already been getting feedback = that it's too noisy (mostly due to some automatic datatracker-generated = emails of maybe limited general interest.) > rfc-interest would capture anyone who's interested enough in RFCs to = be subscribed, regardless of IETF affiliation (as ephemeral a concept as = that is). Since ietf-announce is of course an IETF-specific list, again +1 for = rfc-interest. Thanks, Lars --Apple-Mail=_F6D872C3-34CB-426C-BA44-427B80B3CB49 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmC/JowACgkQVLXDCb9w wVedjw/8C18TDG7+yht+JjtOdK0L4Yt5joPWErIpj1FJFWFGUDyaixSORkOPRQdm UopJuQQt3FkBOIWZ+8F2T23ppqrkF1uVr88TotrL+raPKv/oXoPJAcB9nlUMgonx sPrm2+W1j0I6hkKghB8gb/TzlYH6VEyts/5sCVz52x3mep7auLa2EIdv08r+RbbO sbN8ZtmThN4XzuDjEI0HGFMZ/z32csGIxd+JEgTPAaZXI4l5EXZ1UdzTdadHx2cj dL9u5PIjhaK60yeKsgZ8PpnGuiMzlUIzaacckQu4AhQrZuPxFrWyFD64qUFMVbnB XkTQZAA9t98c3GHFgFwfySyt2EjVTyfZZ2zhW411ymb+o0UveH9LD+FYod0ZMJoA 6iUk6I9ZzWwFN0m+kKVFLKz0/wzlCLfOinBDQmx7KeJ9axyeWMi9AWTYufqwTTYk 5Qx+Ela4iOttZm7H+MoaeM1XGqP6ctnNrWO6/yiBHUF/x1KnuWPeIhbwOuRq0cs9 t+PUEUdTWZUmTpG8KbCtwVpTBIir9CjTVGC+02fag4w0hI/dBPIaWWjBW1+V4DrH 9NLFZMJA+pEtr0s7xtG8p6fc93XCBhbOq46yQuV813Ywtm7SPcabkfkV3DqBzv63 lrJKN/K+tOXA0QuxmXcvvSsP/Uzv0EkfIZ737Fm3ixnSY3c4xn4= =iZq1 -----END PGP SIGNATURE----- --Apple-Mail=_F6D872C3-34CB-426C-BA44-427B80B3CB49-- From nobody Tue Jun 8 21:36:34 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418F13A0874 for ; Tue, 8 Jun 2021 21:36: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, NICE_REPLY_A=-0.001, 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 vP3T15HC9bn7 for ; Tue, 8 Jun 2021 21:36:27 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 BBCE73A0860 for ; Tue, 8 Jun 2021 21:36:27 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id x10so11885749plg.3 for ; Tue, 08 Jun 2021 21:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=daiTcyYHHQ9y784i2Yk5Jt7a9RT68rS3CcTlN+wzyRg=; b=LbH9GSzgPyk03uOj02eFqjN0uFXAwuptS2YvxsTeFcPngpNMWOz9uJuTpvIQfn5m8g Q2g2jteiDPYkIFi76IfzkP2G/vIhxGUJ3u0HTzmhacnwkt6W4+QTjMC9tXgttEYWRxfR +DP9o7Svc1o30sqBZd85U25gYBC44LsjKIF5+ObkycsjLyiZ+7104z/0HCq/Wa/0H4EW O9MHsWHoTcqxMprOU9vvVRUxz05XYCSrsrKAmo07gyjZp2BvtyaQW6x2k7NU5Y7L5NZ1 ozM8qn9598GcL4fwm4ZOwlvvpAiaCZ0sKMzDOg/I+BGYNe+ejwng1vejToyZYPWCamUN Vgig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=daiTcyYHHQ9y784i2Yk5Jt7a9RT68rS3CcTlN+wzyRg=; b=E0GbwMuP5x4or9mwdfELCl6bU/AONq3nKPHJrHckDtSGtmoRvmJayMKIiAMIgIHOWK cUw8ATZIk29XQtEXjcd3SN9iMLUXBFwIoaqWHhztiewzhysB/5k//kTXIv0x2voUAsB6 Ye/CuhQeYorl6ptwdnnZqHNXNkklWSUenDdzs80dMv2Wgqrekc1KMTVpeeJuoCNeAbbw Ozg460+VW5OCvWorIOy4Kq1RGQn+gchG01Z9WiiU9NL7tJNTRDcMAth0bo1At7AMkZBf sLEMljnMVO6J/LoD1xsG1hWLDJwkJVz2LjC6sX3KmINNsWXIAV/+367+92WdYQxPlFDQ 54RA== X-Gm-Message-State: AOAM530d0+1tZmic9/MUA3alBwSXiCeMjhcXkHfeGWV2J9Njx+xFX8Es JaDs2hefrQcGT90r7yu1D9asxL5La6ISQw== X-Google-Smtp-Source: ABdhPJzsA/4T705sYuuVtzt/acknvZWOOJ0qKrvTyWlRw/cXh8FR4MNuzXMfbYdIrk4P9vUc6EsyuQ== X-Received: by 2002:a17:902:d512:b029:104:ea04:4897 with SMTP id b18-20020a170902d512b0290104ea044897mr3235360plg.66.1623213385902; Tue, 08 Jun 2021 21:36:25 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id e17sm11971845pfi.131.2021.06.08.21.36.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Jun 2021 21:36:25 -0700 (PDT) To: Mark Nottingham , rfced-future@iab.org References: From: Brian E Carpenter Message-ID: <76cdfc9e-3bc4-4811-d763-a404959ac612@gmail.com> Date: Wed, 9 Jun 2021 16:36:19 +1200 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: [Rfced-future] Proposal: Community calls for comment (transparency) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 04:36:32 -0000 Could you add some words to make it clear that this defines *minimum* targets for distribution, and that wider distribution is welcome and encouraged? Regards Brian On 08-Jun-21 18:11, Mark Nottingham wrote: > At the interim, I took a action item to propose text about community review and transparency. Looking at the current draft, I see that there is already an open issue to 'specify what counts as a "community call for [comment]".' > > My proposal is to insert the following into a new section for reference from 5.2.2 (Specifics); exact placement I leave to the editor. > > ~~~ > X.X Community Call for Comment > > When a community call for comment is made, the RSAB sends a notice to at least the rfc-interest mailing list with a Subject line beginning with "Call for Comment:". When either the RSAB or the RSWG considers the proposal warrant it, the notice is also be sent to the ietf-announce and irtf-announce mailing lists. Notices are also to be made available and archived on the rfc-editor.org web site. > > A notice contains: > > * A clear, concise summary of the proposal > * A URL for the proposal document > * Any commentary or questions for the community that the RSAB deems necessary (using their usual decision-making procedures) > * Clear instructions on how to provide public comments > * A deadline for comments > > A comment period will not be less than two weeks, unless both the RSAB and RSWG have consensus that adopting the proposal is urgent and uncontroversial, in which case the minimum comment period is one week. If a proposal requires more than one comment period, those after the first can be shortened to one week at the discretion of the RSAB. > > Comments will be publicly archived on the rfc-editor.org web site. > ~~~ > > Thoughts? > > Since we're talking about transparency, I'm also inclined to think we need to have announcement and records about the decisions taken (in addition to the comment periods). E.g., any CONCERN positions and the actual voting of the RSAB needs to be made public, and archived. Does that make sense? > > Also, I haven't addressed transparency in the RSWG, under the presumption that since it operates like a normal WG, it should follow that it operates in the open. If folks think that needs to be clarified or strengthened, we should do so. > > Cheers, > > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Tue Jun 8 22:40:31 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6F53A0E4C for ; Tue, 8 Jun 2021 22:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=O1DLUIQC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Z9GEie7T 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 pTqqdmkH0e02 for ; Tue, 8 Jun 2021 22:40:25 -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 0244B3A0E4F for ; Tue, 8 Jun 2021 22:40:24 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id D4E5023DB; Wed, 9 Jun 2021 01:40:19 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 09 Jun 2021 01:40:20 -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=fm2; bh=U Ga5vLzMvAoD93qKbwPB9p+uakNoa1Ih4sQ9maRwgX8=; b=O1DLUIQCh2fzviWpp +SwW/hErubcEeQPNgvuXMkAsno8bu/08sBa3jtWLqRYP18eyIJKdhWMp0aBBq+P+ n0s6ZjXurOA8/VA1RI3a6bKBR4JZQvKUg8ZptMTXPI2UzfHvIUqiQQdA39dOmbQC l9nH3ZLWmBfZP72uCqhh++2bLX7xaLhfnWRJepJ1hFaoD/6tfyvroqMx6OGV8P/P +0QwvbLRdF6IwkueB4RV2pFxkhvdWhuc1EdVqrwbduLplVRtZkAMCt0Q79YCERH3 2NeTBSk6E9UbLrBoHPbReg49DiANATDeZvZD/jqAA0t2kc/u1O8wOlM4XHLJEpZ+ siBgQ== 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=fm3; bh=UGa5vLzMvAoD93qKbwPB9p+uakNoa1Ih4sQ9maRwg X8=; b=Z9GEie7TzP7r/vy9lFRoIgKlp8jO19UBP79y+VJP8F8lQTVSzPJTYPAQC 7rKcGvsUBYx+AJ1EFHJ1Yomc3oovd9aAd6RvZcWsqRI0VNpnXAyXJOfnjr2rF7HK +4DfJNJ06c7TzxJUGVGuP27FD1Ecz5uXIWvripBsjd9LJYNxvyrJ3Pwux6B/+s+F 7q4WK0hEFefoGWuf3jO5Yr4T8njyG141JzC7LSHITv1aTXbsFA5XpdAwDGYA1jct 8/xRyQdoidCMCAIeFRvGKuh8TjnLzTHcKxaz+2QYAHef/0YoM+bgub8aUraeRDNE Wl7Ex3fQAp1FuldyFdBwpZ2XjyfqA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedutddgledtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekudekgfegiedvfeetgfejkeettdeghedtveeijeettdelvdfhueegudetudeg udenucffohhmrghinheprhhftgdqvgguihhtohhrrdhorhhgpdhmnhhothdrnhgvthenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothes mhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 9 Jun 2021 01:40:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Mark Nottingham In-Reply-To: <76cdfc9e-3bc4-4811-d763-a404959ac612@gmail.com> Date: Wed, 9 Jun 2021 15:40:14 +1000 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <43D23ECC-4370-4647-8A13-2EF1D7642EAC@mnot.net> References: <76cdfc9e-3bc4-4811-d763-a404959ac612@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] Proposal: Community calls for comment (transparency) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 05:40:30 -0000 > On 9 Jun 2021, at 2:36 pm, Brian E Carpenter = wrote: >=20 > Could you add some words to make it clear that this defines *minimum* = targets for distribution, and that wider distribution is welcome and = encouraged?=20 Modified proposal: ~~~ X.X Community Call for Comment When a community call for comment is made, the RSAB sends a notice = containing: * A Subject: line beginning with 'Call for Comment:' * A clear, concise summary of the proposal * A URL for the proposal document=20 * Any commentary or questions for the community that the RSAB deems = necessary (using their usual decision-making procedures) * Clear instructions on how to provide public comments * A deadline for comments Notices will always be sent to the rfc-interest mailing list. When = either the RSAB or the RSWG considers it necessary, a notice will also = be sent to the ietf-announce and irtf-announce mailing lists. The RSAB = is encouraged to send notices to other parties and communities that may = be interested or impacted by a proposal as they see fit. Notices are = also to be made available and archived on the rfc-editor.org web site. A comment period will not be less than two weeks, unless both the RSAB = and RSWG have consensus that adopting the proposal is urgent and = uncontroversial, in which case the minimum comment period is one week. = If a proposal requires more than one comment period, those after the = first can be shortened to one week at the discretion of the RSAB. Comments will be publicly archived on the rfc-editor.org web site. ~~~ -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jun 8 22:58:41 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405593A0FE7 for ; Tue, 8 Jun 2021 22:58:40 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=joelhalpern.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 1MXncRRFHqk1 for ; Tue, 8 Jun 2021 22:58:35 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 1F3AD3A0FEA for ; Tue, 8 Jun 2021 22:58:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4G0Gcp4yRsz1nw58; Tue, 8 Jun 2021 22:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1623218314; bh=x0uS5wwodDreOExeZoAMe6S1u9LKu1Dg8aS84offFE0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=gc+/2PlLrU8Eni25JKkOPlct7KVz2S1MljVNJeQPBlAF3jo9rvm0NKRqspjbRP+wV 4h7thKTTmOCIAd22XibW5mQnwaFvOv++ljj6ieVKkAxoJFbQqca5kuovmB+6IuxWj+ 7ypgg/+d/iBmAkzKqVuUXn6lHsTZ+LY4IJWTL8fg= X-Quarantine-ID: <7_xlsb6GOv6b> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4G0Gcp0XLcz1nv2m; Tue, 8 Jun 2021 22:58:33 -0700 (PDT) To: Mark Nottingham , Brian E Carpenter Cc: rfced-future@iab.org References: <76cdfc9e-3bc4-4811-d763-a404959ac612@gmail.com> <43D23ECC-4370-4647-8A13-2EF1D7642EAC@mnot.net> From: "Joel M. Halpern" Message-ID: Date: Wed, 9 Jun 2021 01:58:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <43D23ECC-4370-4647-8A13-2EF1D7642EAC@mnot.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Proposal: Community calls for comment (transparency) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 05:58:40 -0000 Can you provide an example of something that is simultaneously urgent, uncontroversial, and strategic (since if it is not strategic it is not in the remit of the RSWG / RSAB)? I don't object in principle to the permission for a short call, but I am trying to understand why we might want to allow it? (I tend to think of this as being similar to an IETF last call, and while the IETF has provisions for things needing longer calls, it has no provisions for things getting shorter calls.) Yours, Joel On 6/9/2021 1:40 AM, Mark Nottingham wrote: > >> On 9 Jun 2021, at 2:36 pm, Brian E Carpenter wrote: >> >> Could you add some words to make it clear that this defines *minimum* targets for distribution, and that wider distribution is welcome and encouraged? > > Modified proposal: > > ~~~ > X.X Community Call for Comment > > When a community call for comment is made, the RSAB sends a notice containing: > > * A Subject: line beginning with 'Call for Comment:' > * A clear, concise summary of the proposal > * A URL for the proposal document > * Any commentary or questions for the community that the RSAB deems necessary (using their usual decision-making procedures) > * Clear instructions on how to provide public comments > * A deadline for comments > > Notices will always be sent to the rfc-interest mailing list. When either the RSAB or the RSWG considers it necessary, a notice will also be sent to the ietf-announce and irtf-announce mailing lists. The RSAB is encouraged to send notices to other parties and communities that may be interested or impacted by a proposal as they see fit. Notices are also to be made available and archived on the rfc-editor.org web site. > > A comment period will not be less than two weeks, unless both the RSAB and RSWG have consensus that adopting the proposal is urgent and uncontroversial, in which case the minimum comment period is one week. If a proposal requires more than one comment period, those after the first can be shortened to one week at the discretion of the RSAB. > > Comments will be publicly archived on the rfc-editor.org web site. > ~~~ > > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Tue Jun 8 23:01:55 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A523A1010 for ; Tue, 8 Jun 2021 23:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=fwj5Z3cY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=j+dnEIIn 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 Ks9Twojwhnkf for ; Tue, 8 Jun 2021 23:01:48 -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 971773A100D for ; Tue, 8 Jun 2021 23:01:48 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 1942C2236; Wed, 9 Jun 2021 02:01:46 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 09 Jun 2021 02:01:46 -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=fm2; bh=y DusZJBm02LbKeFRk/rooEwnmCxzfvapM3oCh9S90V8=; b=fwj5Z3cYIOgGGoxpB WtCHVui69iDL+k8uWITCsMsquyViqG4whajd8z8Peuk+aIIH3xTptwzQaL9RopCu pRQchMJWBgHUSCb9mbue4hUubBcxG63myHoJpe+Kj5EI6FXxXDSw7gREFQxi3kOr ERQc+DWAOs7zyJWC7JQN/JE7JyKvtLX18FGeLwhq113LiU0LS+7bPdXtD15GT3c4 3mkwN+xGWBNByeE0LMPK8GnYq/FkhPpsnIKzAKurtd+Bie5xeg58VJMz53r1JqCu 2joAwbc5btr0s0J55Ji1IQMtLKFXfqhvP68Yba2dpQOFYdjWGz4Spitfr32QRMz0 W7Atg== 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=fm3; bh=yDusZJBm02LbKeFRk/rooEwnmCxzfvapM3oCh9S90 V8=; b=j+dnEIInfKH/Mz8jxtb3YpOYJaYODUN6Obp0ncnnPJ0tuIIbOzBazH7Uf 7qWEWbqKhdU0aWFFSylyn46lirFLKbTtufDQ5wn0Uz0BNGNe/DXG0PJddlXm2R6T 3FGqPFQ1jZj3WcrpzYIOz+16gwHzNQz2YsavFkVZ7xDC/HgYbMkz1HEzpKxCpf7D WO1q2ZWg6mvrV+7Jyb1lvjMzwYyC550hhgmz6zoLtoMhXyeERcbEuPMeqHrsNCDb ybulNpLukJRHtDfLBtNwjT2F/arjgQOSjHmsVJuGDBGVsQysyTkHv7vYEHmYAILc N3K+BZL5NyKm4adJ3GsoqDSF3ZMdg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedutddgleegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekudekgfegiedvfeetgfejkeettdeghedtveeijeettdelvdfhueegudetudeg udenucffohhmrghinheprhhftgdqvgguihhtohhrrdhorhhgpdhmnhhothdrnhgvthenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothes mhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 9 Jun 2021 02:01:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Mark Nottingham In-Reply-To: Date: Wed, 9 Jun 2021 16:01:39 +1000 Cc: Brian E Carpenter , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <76cdfc9e-3bc4-4811-d763-a404959ac612@gmail.com> <43D23ECC-4370-4647-8A13-2EF1D7642EAC@mnot.net> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] Proposal: Community calls for comment (transparency) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 06:01:54 -0000 Good Q. I put that in mostly because I didn't want the group backed into = a corner if there was something actually urgent; I have no idea what = that might be. Perhaps that part can be dropped, if we all agree that = it's implied that the rules can be broken by broad consent in such = circumstances. Cheers, > On 9 Jun 2021, at 3:58 pm, Joel M. Halpern = wrote: >=20 > Can you provide an example of something that is simultaneously urgent, = uncontroversial, and strategic (since if it is not strategic it is not = in the remit of the RSWG / RSAB)? I don't object in principle to the = permission for a short call, but I am trying to understand why we might = want to allow it? (I tend to think of this as being similar to an IETF = last call, and while the IETF has provisions for things needing longer = calls, it has no provisions for things getting shorter calls.) >=20 > Yours, > Joel >=20 > On 6/9/2021 1:40 AM, Mark Nottingham wrote: >>> On 9 Jun 2021, at 2:36 pm, Brian E Carpenter = wrote: >>>=20 >>> Could you add some words to make it clear that this defines = *minimum* targets for distribution, and that wider distribution is = welcome and encouraged? >> Modified proposal: >> ~~~ >> X.X Community Call for Comment >> When a community call for comment is made, the RSAB sends a notice = containing: >> * A Subject: line beginning with 'Call for Comment:' >> * A clear, concise summary of the proposal >> * A URL for the proposal document >> * Any commentary or questions for the community that the RSAB deems = necessary (using their usual decision-making procedures) >> * Clear instructions on how to provide public comments >> * A deadline for comments >> Notices will always be sent to the rfc-interest mailing list. When = either the RSAB or the RSWG considers it necessary, a notice will also = be sent to the ietf-announce and irtf-announce mailing lists. The RSAB = is encouraged to send notices to other parties and communities that may = be interested or impacted by a proposal as they see fit. Notices are = also to be made available and archived on the rfc-editor.org web site. >> A comment period will not be less than two weeks, unless both the = RSAB and RSWG have consensus that adopting the proposal is urgent and = uncontroversial, in which case the minimum comment period is one week. = If a proposal requires more than one comment period, those after the = first can be shortened to one week at the discretion of the RSAB. >> Comments will be publicly archived on the rfc-editor.org web site. >> ~~~ >> -- >> Mark Nottingham https://www.mnot.net/ -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jun 8 23:25:50 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E353A11D8 for ; Tue, 8 Jun 2021 23:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=3MIvpXfc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=m/ml2V9P 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 2NdbhcpcRrnf for ; Tue, 8 Jun 2021 23:25:42 -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 D18B23A11DF for ; Tue, 8 Jun 2021 23:25:42 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 973C123F1 for ; Wed, 9 Jun 2021 02:25:41 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute4.internal (MEProxy); Wed, 09 Jun 2021 02:25:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=mw2cthosw2e3jVmf4LBjHTNDrQ6k0wh R/4HLWNd2SWE=; b=3MIvpXfcva9wbPfezczFZzADhhG3dDDSCkXWozo3+TrmDpj KFkZAM+ipgMP9qoZeXPtNYHhTlwn71XJQicVmpNTkEs6jSljp4VLljaONct9f8l0 u3e8Eablfy6/IwL4WhTTU9GZgArtY7GLG4fvg/Th9CAEFCh6JphjqahtvA5HIeg3 kuNFoYJnOc364Rj2mybzrAVHhUr/NOnmuLJL9ZbdQzrepmRCtQaCN6UHPTHXKuxC mt5p9aEB5TiezKXACb2fU1VXCSVdmm2PZqsNFW9Xq1udujKlCBLtCWUoNRQti+NP xnjqsYVQkj7o+0flKol+Uws6wBAGUHIIavS3RUg== 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=fm3; bh=mw2cth osw2e3jVmf4LBjHTNDrQ6k0whR/4HLWNd2SWE=; b=m/ml2V9PJu7hLT+nU8UAe+ uVk/XxrMOwgx37Qs4HXYWBPU7gKFNCVajtJSL1J5M9DLOtvL3ateXaN5ae+cF3ll iSewY1CQQWtkyXJ0mPxD9LUsx5LpneEnrm8LUgcziB2wgZHSuMq7NWHUXuXlBojU t39yQ4sL/7FLuXYRosfjbx3XUu/9Xw60mVRG0CIMfxcRhVsCBlPGPz8CRY7OXVf2 aPHgjhTxjwchHpfwSe60POFBea8qk2cEfljuvcTkv6p8xIADwneMm99FpLtjzw9g H2xNAy/gKAoJtZDxB+yBOfs4UtSTEYdYlk8MKfDHKCN79fGl4wo6ssxr6R94kJfA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedutddgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpedvgeetuefgjefhuddvtd ejheehiefgudevvdejgeeliedviefhuddtfeetjeekfeenucffohhmrghinheprhhftgdq vgguihhtohhrrdhorhhgpdhmnhhothdrnhgvthdpihgrsgdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhho phihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A09DC4E00D3; Wed, 9 Jun 2021 02:25:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-519-g27a961944e-fm-20210531.001-g27a96194 Mime-Version: 1.0 Message-Id: <8ce88a6a-2457-42ea-9db4-ce01000337ba@www.fastmail.com> In-Reply-To: References: <76cdfc9e-3bc4-4811-d763-a404959ac612@gmail.com> <43D23ECC-4370-4647-8A13-2EF1D7642EAC@mnot.net> Date: Wed, 09 Jun 2021 16:25:18 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Proposal=3A_Community_calls_for_comment?= =?utf-8?q?_=28transparency=29?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 06:25:49 -0000 I was going to comment that we had previously agreed that 2 weeks was fine (and up to 4 weeks was OK if people thought that longer was needed). No reason not to apply that here. After all, this is about document approvals, which presumably had discussion in the WG that ended in consensus. And we are looking for people outside of that group to notice, read, think, and respond. In that context, 1 week is short, precipitous even. More urgent answers might be needed for less strategic occurrences, but that would fall into the previously discussed procedures. In that case, let the RSAB make a singular ruling for the circumstances and then refer the matter to the WG. On Wed, Jun 9, 2021, at 16:01, Mark Nottingham wrote: > Good Q. I put that in mostly because I didn't want the group backed > into a corner if there was something actually urgent; I have no idea > what that might be. Perhaps that part can be dropped, if we all agree > that it's implied that the rules can be broken by broad consent in such > circumstances. > > Cheers, > > > > On 9 Jun 2021, at 3:58 pm, Joel M. Halpern wrote: > > > > Can you provide an example of something that is simultaneously urgent, uncontroversial, and strategic (since if it is not strategic it is not in the remit of the RSWG / RSAB)? I don't object in principle to the permission for a short call, but I am trying to understand why we might want to allow it? (I tend to think of this as being similar to an IETF last call, and while the IETF has provisions for things needing longer calls, it has no provisions for things getting shorter calls.) > > > > Yours, > > Joel > > > > On 6/9/2021 1:40 AM, Mark Nottingham wrote: > >>> On 9 Jun 2021, at 2:36 pm, Brian E Carpenter wrote: > >>> > >>> Could you add some words to make it clear that this defines *minimum* targets for distribution, and that wider distribution is welcome and encouraged? > >> Modified proposal: > >> ~~~ > >> X.X Community Call for Comment > >> When a community call for comment is made, the RSAB sends a notice containing: > >> * A Subject: line beginning with 'Call for Comment:' > >> * A clear, concise summary of the proposal > >> * A URL for the proposal document > >> * Any commentary or questions for the community that the RSAB deems necessary (using their usual decision-making procedures) > >> * Clear instructions on how to provide public comments > >> * A deadline for comments > >> Notices will always be sent to the rfc-interest mailing list. When either the RSAB or the RSWG considers it necessary, a notice will also be sent to the ietf-announce and irtf-announce mailing lists. The RSAB is encouraged to send notices to other parties and communities that may be interested or impacted by a proposal as they see fit. Notices are also to be made available and archived on the rfc-editor.org web site. > >> A comment period will not be less than two weeks, unless both the RSAB and RSWG have consensus that adopting the proposal is urgent and uncontroversial, in which case the minimum comment period is one week. If a proposal requires more than one comment period, those after the first can be shortened to one week at the discretion of the RSAB. > >> Comments will be publicly archived on the rfc-editor.org web site. > >> ~~~ > >> -- > >> Mark Nottingham https://www.mnot.net/ > > -- > Mark Nottingham https://www.mnot.net/ > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > From nobody Wed Jun 9 02:49:45 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064973A192A for ; Wed, 9 Jun 2021 02:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 QcMsrvsxkd2L for ; Wed, 9 Jun 2021 02:49:39 -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 114F63A1927 for ; Wed, 9 Jun 2021 02:49:37 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::a] ([IPv6:2001:420:c0c0:1011:0:0:0:a]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1599nRvm165086 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 9 Jun 2021 11:49:33 +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=1623232174; bh=MJYvCcJ/7kkpyX6si9jei8bLbUNyo6xuxm1Cs66E3RQ=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=KCU32t5CNjQV61vo7UE6ZOA4Xow+UoJH32zUd7AC0fRaQCz8ahqOTW9SBV2n1yTUZ BA7b8LwIcx4mQxbk20VkPeBEYJ7WwsICdryQMM4Da3YgTJcu6QdtGdEvMFHgV+2Z6/ t+wy7E55beX06IHG6q4gJQ7pQFvu3GN4peSSfCY4= To: Mark Nottingham , Brian E Carpenter Cc: rfced-future@iab.org References: <76cdfc9e-3bc4-4811-d763-a404959ac612@gmail.com> <43D23ECC-4370-4647-8A13-2EF1D7642EAC@mnot.net> From: Eliot Lear Message-ID: <49764e8e-e490-d1c2-83c4-fd5d2f8270c8@lear.ch> Date: Wed, 9 Jun 2021 11:49:24 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <43D23ECC-4370-4647-8A13-2EF1D7642EAC@mnot.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lEC2RAfg9xFSGx0yyn198QqinfJunHQ9d" Archived-At: Subject: Re: [Rfced-future] Proposal: Community calls for comment (transparency) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 09:49:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lEC2RAfg9xFSGx0yyn198QqinfJunHQ9d Content-Type: multipart/mixed; boundary="hmKfTRlKdLzC9YSRiRu98wY9B6Phbj2Qr"; protected-headers="v1" From: Eliot Lear To: Mark Nottingham , Brian E Carpenter Cc: rfced-future@iab.org Message-ID: <49764e8e-e490-d1c2-83c4-fd5d2f8270c8@lear.ch> Subject: Re: [Rfced-future] Proposal: Community calls for comment (transparency) References: <76cdfc9e-3bc4-4811-d763-a404959ac612@gmail.com> <43D23ECC-4370-4647-8A13-2EF1D7642EAC@mnot.net> In-Reply-To: <43D23ECC-4370-4647-8A13-2EF1D7642EAC@mnot.net> --hmKfTRlKdLzC9YSRiRu98wY9B6Phbj2Qr Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi mark, Thanks for this. Just one comment: On 09.06.21 07:40, Mark Nottingham wrote: > When either the RSAB or the RSWG considers it necessary, a notice wil= l also be sent to the ietf-announce and irtf-announce mailing lists. We did discuss this at some point.=C2=A0 My read of the group was that th= e=20 RSAB and RSWG should maintain living lists based on running code.=C2=A0 S= o...=20 no need to specifically mention either of those lists. However, one=20 thing we didn't discuss is=C2=A0 permission to post to different fora.=C2= =A0 We=20 don't want to appear to be spammers. Also, do we want to leave open the possibility that the groups might=20 want to publicize announcements through other vehicles=20 (MyFaceTweetTockTwitch)? Eliot --hmKfTRlKdLzC9YSRiRu98wY9B6Phbj2Qr-- --lEC2RAfg9xFSGx0yyn198QqinfJunHQ9d Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDAjqQFAwAAAAAACgkQh7ZrRtnSejM2 6Qf/VWlH6ONtqxB90kxLRjWuJKDBmV5azyhcf0/xGgV9dpFMR1qIzA2/Q9sTCAXNIQNsahf33w+6 p9YBmvAuAmMxohhbjtffOXRRviMmQDVJ3VLp3jwjStBcWB1AlB342zTv1gbNsVmhpuTZXObCTOpB DiWQ53d4l0B5zhw+1Opb8Ivwu3LFVbds1y6qTKLdJNfbe3wqaeGNkq/gaqoCKOSls49d4J15qfTw Dz0fn8ds40aZwWuun6doVORnpPh/muldPqeGXqUMO1q6gwKmzFr7FTvBvPHqaCqFEcIBzR3yIb3w gifEB7CnvNNYQ0zqTDzyqe1Am3qSSqv5SD5B6wrUyA== =RcWi -----END PGP SIGNATURE----- --lEC2RAfg9xFSGx0yyn198QqinfJunHQ9d-- From nobody Wed Jun 9 03:44:35 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425243A0C50 for ; Wed, 9 Jun 2021 03:44:33 -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 xzTVWfU-00KT for ; Wed, 9 Jun 2021 03:44:28 -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 795F73A0C4C for ; Wed, 9 Jun 2021 03:44:28 -0700 (PDT) Received: from smtpclient.apple (unknown [212.68.24.84]) (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 72F7260031C; Wed, 9 Jun 2021 13:44:21 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1623235461; bh=MluunOG7nCEoUycLTjfya+6bCLohJB/leoJ4HhpCHis=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=zCrIzua89DiXOHFwarUOrht56OKoGLUAKAxJJh6dM/K7NoEylknuuQlv9iTbfskWi nn0pvs/bTvYIXAyXXW9EFU6B2MvOCCguTsvCKtp8UUOnqQ+7thHwDOaLKpBWexPd8s etggg8G16Di8LAs7HzgNlSyFeB60Qpfjr+Pm2bTc= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_B73BCEB5-7259-4614-A7F9-C84F9BBF1DE6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Wed, 9 Jun 2021 13:44:20 +0300 In-Reply-To: <43D23ECC-4370-4647-8A13-2EF1D7642EAC@mnot.net> Cc: Brian E Carpenter , rfced-future@iab.org To: Mark Nottingham References: <76cdfc9e-3bc4-4811-d763-a404959ac612@gmail.com> <43D23ECC-4370-4647-8A13-2EF1D7642EAC@mnot.net> X-MailScanner-ID: 72F7260031C.AEA62 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Rfced-future] Proposal: Community calls for comment (transparency) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 10:44:33 -0000 --Apple-Mail=_B73BCEB5-7259-4614-A7F9-C84F9BBF1DE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2021-6-9, at 8:40, Mark Nottingham wrote: > Notices will always be sent to the rfc-interest mailing list. When = either the RSAB or the RSWG considers it necessary, a notice will also = be sent to the ietf-announce and irtf-announce mailing lists. there are very few roles that come with posting privileges to the = ietf-announce and irtf-announce mailing lists, and I wouldn't want to = set a precedent for a WG to be able to decide to post something to these = lists. I'd prefer if this said "When either the RSAB or the RSWG considers it = necessary, they will suggest to the IETF and IRTF Chairs that a notice = be sent to the ietf-announce and irtf-announce mailing lists." Thanks, Lars --Apple-Mail=_B73BCEB5-7259-4614-A7F9-C84F9BBF1DE6 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmDAm4QACgkQVLXDCb9w wVcJyhAAzSRDbdCKat527CCnLH7x2TLYJsWpH0y2i6q8zd3dlEXh7WVSt/iPNFDb 3vmxM3dHpT6HwgcddaakEws9d6T9pqymk0Hi8HEoZpLXKmRK1VSoSKMP95BTIeg1 M8r3OXWpFDEol2GdVmzuTcySzzoQNYnpT++94NzQAU7SBlcSp/VkBgJgJQ9WfvBR Ir7cI1lCk993gOYYrFCCaEcosb1/RuE8mSmRNv8fjM5pPS5nRcqBzHivEJjgDYW9 +u43pufJ88m6hhwNAg4VpP7PX2sXdKn//U39yc3zPtWqndyEAkRspodsrBBB8mWT yAoQ+P6Vx/v+fo0TwTMshXJIZhQE65KhqZnotx5gpyppjbCsJDNtrYT+PQTS4zrK qf92bkQo/LsFi+Qjaw29/4P7RC+sJEal/sncMhT/7suBJp3WnBlEbWAhz/mlF8xK 7oO5fQRS0y6JQW8i4pY9aFPihTUOqAHyOCon4CuySZ8nX00cUqyQriLRGpvA11zE 7cA2wvsEEWYQ8IW/pl9QtKlRnsirxCbEXk1LZrNzkNsd5QM+KveseGNbiFNa5VIz VuNzA969s7PIkDZFbEiHgaL1bgen1R6TyDMq+/1nQHxD+CSGjWzYO1KU0acN8KRD ZgfD5DRf8vbrSGCAD40/k3qSGwSDLpLxflr3331hLjdfpw8RO10= =6/Cj -----END PGP SIGNATURE----- --Apple-Mail=_B73BCEB5-7259-4614-A7F9-C84F9BBF1DE6-- From nobody Thu Jun 10 20:38:17 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2EB3A261C for ; Thu, 10 Jun 2021 20:38:14 -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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=aVIIpl0Q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gO/YelIQ 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 otqiYTiKfn9r for ; Thu, 10 Jun 2021 20:38:10 -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 130EE3A261D for ; Thu, 10 Jun 2021 20:38:09 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id A5F1A1855 for ; Thu, 10 Jun 2021 23:38:08 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 10 Jun 2021 23:38:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :date:references:to:in-reply-to:message-id; s=fm2; bh=3/7CIPGSo3 deFdf1iuM/ayPC9AqJ7Uqr17PhkDLrXKE=; b=aVIIpl0QMkhofNHIDaycIHOVFk hkXOG3G1hfd+yi8zcPKjomdM2BJzdGYFbb5e9UIQx+tZz7QTZ0wHgTspTWjEQYXu 6yO0cMvo186V4GXCgoAvNTYqL7/jAkxmxZsgeq/jW/VcH9lI+Es76fE5aUP94/5c KAGhChQTVfikrLezLAI+uIfwdx+fKfu7SjgCgDNRFHHlblUyBw7xudmmeTPMcusN hQ9uKBntumrCSJ2GedcXX9voBri1lOI5yc5gmXtYZ8UxC+LrMgykh+ZIk+pqcCQi eskuOhMFPCf6nk3nUuRSBPY8t1ejSRajWxAuxHS4AQ/3PfYP2OZ6257LZAEg== 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=3/7CIPGSo3deFdf1iuM/ayPC9AqJ7Uqr17PhkDLrX KE=; b=gO/YelIQssypuki+97+C+6ZlTA+ryQXYbZTeRyZBXD5gcjay9fMNaDPag A0kCQVxz5mjeBIuqAHTla2QW2a56+hjmoD0eyAbI6TXfDzsFFgpjREaoVWRBh6iL H+OtPHIwDHQSJpWJw4+Vp0+Hj0biDtQgEcwGhy/57EnMjgJ0C65hdQzLB2+cb6w/ zwvj7JRzBHyTUkj9cYiVIRCc5MFw9OpKLOQBqy+PapvcahNzYS3d4CIAkUMTLQls j49WtKjX2ce9RmhFWkb5mAo/3Q+orm3WASbbbqvpF1G2fdnOFWD7dRJIUv991RML x5q3fH5zIU5Jln5CWFSbjtODnJx4g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeduiedgjeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtgfgggfuffhfvfgjkffosehtqh hmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehm nhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepleffvdffveefiefgtdegjeejuedtie evfeeigfeugeffieekudeuudefhefhkeegnecuffhomhgrihhnpehrfhgtqdgvughithho rhdrohhrghdpmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 10 Jun 2021 23:38:06 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Fri, 11 Jun 2021 13:38:03 +1000 References: <76cdfc9e-3bc4-4811-d763-a404959ac612@gmail.com> <43D23ECC-4370-4647-8A13-2EF1D7642EAC@mnot.net> To: rfced-future@iab.org In-Reply-To: <43D23ECC-4370-4647-8A13-2EF1D7642EAC@mnot.net> Message-Id: <5DAEDA71-EE23-4F95-99D6-BA7F8A717322@mnot.net> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] Proposal: Community calls for comment (transparency) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 03:38:15 -0000 Let's call this v3. ~~~ X.X Community Call for Comment When a community call for comment is made, the RSAB sends a notice = containing: * A Subject: line beginning with 'Call for Comment:' * A clear, concise summary of the proposal * A URL for the proposal document=20 * Any commentary or questions for the community that the RSAB deems = necessary (using their usual decision-making procedures) * Clear instructions on how to provide public comments * A deadline for comments Notices will always be sent to the rfc-interest mailing list. The RSAB = and RSWG can also send notices to other communities that may be = interested in or impacted by a proposal as they see fit, following = policies for those fora as appropriate. Notices are also to be made = available and archived on the rfc-editor.org web site, and other = communication channels can be established for notices (e.g., using an = RSS feed, social media). A comment period will not last less than two weeks. Comments will be = publicly archived on the rfc-editor.org web site. ~~~ -- Mark Nottingham https://www.mnot.net/ From nobody Thu Jun 10 22:13:51 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5059C3A28F1 for ; Thu, 10 Jun 2021 22:13:48 -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, NICE_REPLY_A=-0.001, 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 d7XKqRumv0Ps for ; Thu, 10 Jun 2021 22:13:43 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 A01623A28F0 for ; Thu, 10 Jun 2021 22:13:43 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id q15so1497801pgg.12 for ; Thu, 10 Jun 2021 22:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=jNg+J/6DfqtpZ/Qyl3m4hwjGKFoTyhCs9+n/xTiYl58=; b=tPcMmsM+2kAcso8EVFZBREvN78qh188xqq8tzTcXqmgzUybv9otwAtFIUnO7R6g4xS /Hf0ZeDwD3DcF3JJhMoVQAzqsfH9JPwTC4K4oIgEXGH5fIdrovilfYetEqi/ZaG36rSx eJxoZ4u1Sf/RL/Gb+/Y6y0dNkgJ4wSqt6Wk6FUjBeCBGgUUGF7Sk4GfW2yDPytjoJ6Qt YpQaQZmjGDbAauuiaO/LCLL8M62/5+70YXMsNroK5IoX9EztrBdTTib7ze+oCj8N+Ifs 6K9aBKQVBQzjCfC7UDQCWXR/lc6zS8onjJj/0fMxf++hb1+j5Q0XCpiVuwukYEF3dZKG Z0cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jNg+J/6DfqtpZ/Qyl3m4hwjGKFoTyhCs9+n/xTiYl58=; b=B0ADkcZ1Teo03M5BZWsXv/eEpkqZqfpKMbex/Jb3JWUF8kxyth7AALpPPTYZe6oXs3 H3O0h47UOuLGXgPQqElEKKLaJvJfcNchFe+D7WkAIVlpG5EC110X1hUUEXOMidH1aVCq VhrZOVNVD6HEFdqQdgk44AZbdhibeOq0eS94Qc6GziT/ECqrzEuqr3jn1OEJMgd8eNZ1 ILRzFXf7+1UYxuWW4re72Yy3LU53LM/PiWf7NtVex3HITA13I1cxdb2bXLM1dnojRzna rMkvFRxFWR5ZewqzKA4/8eNrJ3+sMZhcOIqTWNjjgCzSJvZMaNTY98aagk1omQzLMr2i mc9A== X-Gm-Message-State: AOAM530fuF3daM6nz2Z/i9P+c0d1H5LZvkXBZSFag1EweZE23cYj161u PTaKSO/0lBOuo7rriEGdj5KF6TSSsJfbYw== X-Google-Smtp-Source: ABdhPJyKpOBZyGXyNuMuqzX7DSsUruN5+qwJKI5UCwX1h5a7UXTLy68DTxvYn1Gl0I5ZUs1EDfFoxw== X-Received: by 2002:aa7:9f1d:0:b029:2f6:5eb3:a108 with SMTP id g29-20020aa79f1d0000b02902f65eb3a108mr2252643pfr.71.1623388421453; Thu, 10 Jun 2021 22:13:41 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id d15sm3791725pfd.35.2021.06.10.22.13.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Jun 2021 22:13:40 -0700 (PDT) To: Mark Nottingham , rfced-future@iab.org References: <76cdfc9e-3bc4-4811-d763-a404959ac612@gmail.com> <43D23ECC-4370-4647-8A13-2EF1D7642EAC@mnot.net> <5DAEDA71-EE23-4F95-99D6-BA7F8A717322@mnot.net> From: Brian E Carpenter Message-ID: Date: Fri, 11 Jun 2021 17:13:37 +1200 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: <5DAEDA71-EE23-4F95-99D6-BA7F8A717322@mnot.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Proposal: Community calls for comment (transparency) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 05:13:49 -0000 I could live with this, but I'd prefer s/can also send notices to other communities/should also send notices to other communities/. Regards Brian Carpenter On 11-Jun-21 15:38, Mark Nottingham wrote: > Let's call this v3. > > ~~~ > X.X Community Call for Comment > > When a community call for comment is made, the RSAB sends a notice containing: > > * A Subject: line beginning with 'Call for Comment:' > * A clear, concise summary of the proposal > * A URL for the proposal document > * Any commentary or questions for the community that the RSAB deems necessary (using their usual decision-making procedures) > * Clear instructions on how to provide public comments > * A deadline for comments > > Notices will always be sent to the rfc-interest mailing list. The RSAB and RSWG can also send notices to other communities that may be interested in or impacted by a proposal as they see fit, following policies for those fora as appropriate. Notices are also to be made available and archived on the rfc-editor.org web site, and other communication channels can be established for notices (e.g., using an RSS feed, social media). > > A comment period will not last less than two weeks. Comments will be publicly archived on the rfc-editor.org web site. > ~~~ > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Thu Jun 10 23:05:16 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4930F3A2A74 for ; Thu, 10 Jun 2021 23:05:14 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=TkynnKKt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sJCXHaTm 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 eTSiWOssqV2k for ; Thu, 10 Jun 2021 23:05:08 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152973A2A72 for ; Thu, 10 Jun 2021 23:05:07 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 290235C0172; Fri, 11 Jun 2021 02:05:05 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Fri, 11 Jun 2021 02:05:05 -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=fm2; bh=Z TbivXFZjJv/aTZUikBP59w/kxAa0oj3AGBqOZx1hp8=; b=TkynnKKtixhIgylpC 4U3AWS1vanAq80q1diJFCPQfN8SnG60rxDlR/E6dBKsTRTpeDooClnRkHXMf+01J pb7ToMqGZvENvimi7nfBT7jKxYCotSzITm9f8ebo8l9aDETeCbrl3c90GBmxP+Ll JrV+atSNDAxw4UfOuWTTZcJnmMdd8kjlZA8Usv5uhRWP5fMTOPqHeNJwVu94UuXf xgCJHyQo+welgc6kFc7zkC7KGam/ogBdpO2yO+ZN29TO897oLKuMXcXT5fmF1crW MXUFDAmhn910UnFNxaEufj2ZJEddO5DjuK4iN8usFHx6Cj8d0XgQBTOpP7lA/MdY 4TpVw== 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=fm3; bh=ZTbivXFZjJv/aTZUikBP59w/kxAa0oj3AGBqOZx1h p8=; b=sJCXHaTmblNSChXdVo0X5KQhAPa5sonNarAOkHn+gyMYN7oi7vrgt1ots 4jVCd3dksjISn8xfp2uCeM372tCrQ4h65npFa57OCF4F9addDE7Un1Ygf+4fw+uV yzzOkPq0I2LavCgdgCJ+dnOBWUgYt+TF+hw74gWjeWbm5ONu+8m2qfjRi3EHlqSS slDacoLKpD1x9Gh/yEkzVtvxiuTyh09EZ26w5s7taSAL7/hjsmP5CBO72+v+LobJ k7FabJh6LLaHO2bZ7tMNfREqs61PrUVOWn4xxGuN6GEwX8m5HDNzT4Ha8/eBoD10 gCJd0gtxUVRuf7q+ZBnxCzBK2x3Vw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeduiedguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrth htvghrnhepkedukefggeeivdeftefgjeektedtgeehtdevieejtedtledvhfeugedutedu gedunecuffhomhgrihhnpehrfhgtqdgvughithhorhdrohhrghdpmhhnohhtrdhnvghtne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohht sehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 11 Jun 2021 02:05:02 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Mark Nottingham In-Reply-To: Date: Fri, 11 Jun 2021 16:04:59 +1000 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <76cdfc9e-3bc4-4811-d763-a404959ac612@gmail.com> <43D23ECC-4370-4647-8A13-2EF1D7642EAC@mnot.net> <5DAEDA71-EE23-4F95-99D6-BA7F8A717322@mnot.net> To: Brian E Carpenter X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] Proposal: Community calls for comment (transparency) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 06:05:14 -0000 I'm fine with that modification, thanks. I assume you don't intend = SHOULD. Cheers, > On 11 Jun 2021, at 3:13 pm, Brian E Carpenter = wrote: >=20 > I could live with this, but I'd prefer s/can also send notices to = other communities/should also send notices to other communities/. >=20 > Regards > Brian Carpenter >=20 > On 11-Jun-21 15:38, Mark Nottingham wrote: >> Let's call this v3. >>=20 >> ~~~ >> X.X Community Call for Comment >>=20 >> When a community call for comment is made, the RSAB sends a notice = containing: >>=20 >> * A Subject: line beginning with 'Call for Comment:' >> * A clear, concise summary of the proposal >> * A URL for the proposal document=20 >> * Any commentary or questions for the community that the RSAB deems = necessary (using their usual decision-making procedures) >> * Clear instructions on how to provide public comments >> * A deadline for comments >>=20 >> Notices will always be sent to the rfc-interest mailing list. The = RSAB and RSWG can also send notices to other communities that may be = interested in or impacted by a proposal as they see fit, following = policies for those fora as appropriate. Notices are also to be made = available and archived on the rfc-editor.org web site, and other = communication channels can be established for notices (e.g., using an = RSS feed, social media). >>=20 >> A comment period will not last less than two weeks. Comments will be = publicly archived on the rfc-editor.org web site. >> ~~~ >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 -- Mark Nottingham https://www.mnot.net/ From nobody Fri Jun 11 00:47:55 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C9E3A2D7B for ; Fri, 11 Jun 2021 00:47:54 -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, 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 WtXAufpLQ_lm for ; Fri, 11 Jun 2021 00:47:49 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 30AAC3A2D79 for ; Fri, 11 Jun 2021 00:47:49 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id p7so7248818lfg.4 for ; Fri, 11 Jun 2021 00:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rfqUsvSqS9a04o7MnFXKfBTWk49F282mG885h9ALH/I=; b=otwI/44GhBo0jmI92bS6zwd/Bqhw3b2cF0jWgRY0N0RDQU0cE1DnploiXNEqabGlbt 5hh3D+I21F1cXmPUJsF7KxPd3fyPtpuGgoiym/tIszNP5GwNymlFysAzkTUUmlsMQgKH iDn+/AaGVI33Wqg6SJT5yjwblwDwLor1lD3SOi4h9rVKpEsyWvC65ReXzXFO3qqEUIM0 7bNkP1LllRIr6aawDaP5+fiwKWVDAxcOY/WttP+OhGNDaLa1E7w+P2CgthKKMWqagMHG C1T2WlLNE7myx4ywhffRstklyqxTVW2Jwq3MvDBir4MwHvN6qE7UB9sAmsdIfKThBvqi nDhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rfqUsvSqS9a04o7MnFXKfBTWk49F282mG885h9ALH/I=; b=taAR6Kv1rompKgiJY65NUFpxnPqY/+B7dRL0U78vBIp7jSndfa/x7+TA3z0KZPelgr 9+6zO7taNcwSdPKyVwwIrR3dCy8GckxjcKcFFpMChxedZIxkGW/1y0bGuimo8zMaR/Zk JRv37O1Gkwqk0It0kmGg4t1qKhCnYvopTBsRLmoLQICg1NRVBCk81ADhLNr008AmfMhP FmE1SP51UFE2UVu4IOpAqhQz1f5eL/fAvm9iQSG4o5JBOUOZJ0hIxAwPs8gbCX8M+Rtk 9O8BHC5XX9+CtPd/uL76x0rEIQ8l0LFWmkZdsAyO7Fl47eNzPbQ9l2R0FQodUvvlVeh+ 0KLA== X-Gm-Message-State: AOAM532Hj3xekc+NZM3r7LJsg+6KfFevfsztj9zz/Wp1PW/Q60L6teZ2 XYlRtxGrPe4cxSNUz8pnVwJXzN/K9lrEjvZn8Cg= X-Google-Smtp-Source: ABdhPJz0f3Q8lEw3MU/XBUVtuuZzlBPJe2fS16cbbRhneC4BJwykKFAC/eIAhcikkwqSko6LPaa/nEh8wBSB7dn5wSQ= X-Received: by 2002:ac2:528c:: with SMTP id q12mr1921153lfm.105.1623397665777; Fri, 11 Jun 2021 00:47:45 -0700 (PDT) MIME-Version: 1.0 References: <76cdfc9e-3bc4-4811-d763-a404959ac612@gmail.com> <43D23ECC-4370-4647-8A13-2EF1D7642EAC@mnot.net> <5DAEDA71-EE23-4F95-99D6-BA7F8A717322@mnot.net> In-Reply-To: From: Brian Carpenter Date: Fri, 11 Jun 2021 19:47:33 +1200 Message-ID: To: Mark Nottingham Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000032adc905c478b995" Archived-At: Subject: Re: [Rfced-future] Proposal: Community calls for comment (transparency) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 07:47:54 -0000 --00000000000032adc905c478b995 Content-Type: text/plain; charset="UTF-8" Correct. RFC2119 really wasn't designed for this sort of document. Regards, Brian Carpenter (via tiny screen & keyboard) On Fri, 11 Jun 2021, 18:05 Mark Nottingham, wrote: > I'm fine with that modification, thanks. I assume you don't intend SHOULD. > > Cheers, > > > > On 11 Jun 2021, at 3:13 pm, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > > > > I could live with this, but I'd prefer s/can also send notices to other > communities/should also send notices to other communities/. > > > > Regards > > Brian Carpenter > > > > On 11-Jun-21 15:38, Mark Nottingham wrote: > >> Let's call this v3. > >> > >> ~~~ > >> X.X Community Call for Comment > >> > >> When a community call for comment is made, the RSAB sends a notice > containing: > >> > >> * A Subject: line beginning with 'Call for Comment:' > >> * A clear, concise summary of the proposal > >> * A URL for the proposal document > >> * Any commentary or questions for the community that the RSAB deems > necessary (using their usual decision-making procedures) > >> * Clear instructions on how to provide public comments > >> * A deadline for comments > >> > >> Notices will always be sent to the rfc-interest mailing list. The RSAB > and RSWG can also send notices to other communities that may be interested > in or impacted by a proposal as they see fit, following policies for those > fora as appropriate. Notices are also to be made available and archived on > the rfc-editor.org web site, and other communication channels can be > established for notices (e.g., using an RSS feed, social media). > >> > >> A comment period will not last less than two weeks. Comments will be > publicly archived on the rfc-editor.org web site. > >> ~~~ > >> > >> -- > >> Mark Nottingham https://www.mnot.net/ > >> > > -- > Mark Nottingham https://www.mnot.net/ > > --00000000000032adc905c478b995 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Correct. RFC2119 really wasn't designed for this sort= of document.

Regards,
= =C2=A0=C2=A0=C2=A0 Brian Carpenter
=C2=A0=C2=A0=C2=A0 (via tiny screen &= amp; keyboard)

On Fri, 11 Jun 2021, 18:05 Mark Nottingham, <mnot@mnot.net> wrote:
I'm fine with that modification, thanks. I assume y= ou don't intend SHOULD.

Cheers,


> On 11 Jun 2021, at 3:13 pm, Brian E Carpenter <brian.e.car= penter@gmail.com> wrote:
>
> I could live with this, but I'd prefer s/can also send notices to = other communities/should also send notices to other communities/.
>
> Regards
>=C2=A0 =C2=A0Brian Carpenter
>
> On 11-Jun-21 15:38, Mark Nottingham wrote:
>> Let's call this v3.
>>
>> ~~~
>> X.X Community Call for Comment
>>
>> When a community call for comment is made, the RSAB sends a notice= containing:
>>
>> * A Subject: line beginning with 'Call for Comment:'
>> * A clear, concise summary of the proposal
>> * A URL for the proposal document
>> * Any commentary or questions for the community that the RSAB deem= s necessary (using their usual decision-making procedures)
>> * Clear instructions on how to provide public comments
>> * A deadline for comments
>>
>> Notices will always be sent to the rfc-interest mailing list. The = RSAB and RSWG can also send notices to other communities that may be intere= sted in or impacted by a proposal as they see fit, following policies for t= hose fora as appropriate. Notices are also to be made available and archive= d on the rfc-editor.org web site, and other communication channe= ls can be established for notices (e.g., using an RSS feed, social media).<= br> >>
>> A comment period will not last less than two weeks. Comments will = be publicly archived on the rfc-editor.org web site.
>> ~~~
>>
>> --
>> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>>

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

--00000000000032adc905c478b995-- From nobody Sun Jun 13 11:33:48 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE37C3A2470 for ; Sun, 13 Jun 2021 11:33:46 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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=mozilla.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 FPv-HmMVS8Bc for ; Sun, 13 Jun 2021 11:33:42 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 49F2A3A2471 for ; Sun, 13 Jun 2021 11:33:42 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id b9so10304352ilr.2 for ; Sun, 13 Jun 2021 11:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=qAi9bkcsPu70x1pCKAV63dYr0+3DKH+SD8LJyPzgFzc=; b=fDaUIgRfJNKYfkyQfUbrlDAVCAm/TWPZUqzVAXhLWFe8+gLdplm2uNrXVPhMy9gUmq 010jmt/oiOK8C/76nBF4GW4DugEP4MZuymsBHe7dIZJWPcJ9Z0zpBRXY7CLsvotbm4Qx gn7LxSvrOkBQEmbfsa/cmrjlOXW9UPUw6sTtc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qAi9bkcsPu70x1pCKAV63dYr0+3DKH+SD8LJyPzgFzc=; b=Hgt+QQWUf785c+6d6Ox3aSTVQg3lWj2hrZrrvYFxFdRLnlZ10O3ZjynjL7pmgABlBj XdvZHSjVty5e/us8y4DoS4Vf/gkzz+XewXIoDRBjBkrS4ecrconycoO+CDuvmO2V9Tnj DCgIq3rV1+zbFp7+R3iovtIsPre0CaGR0OSDsnqd8OV5BQn4i15JyGrgBIia/+o4sWTM DvhEWadQEJyqAB0qWDQ93AGZ8mZOniEJAqeJULUffNeIpuQydZOLqR8LKH9UaknVLXsq JAG19OuD1JkrE0zwqw7SzpmRTUyncqRWlcyZpNiTGn+JvmdoUgmobmOtZYvu1CvblRgn rfdw== X-Gm-Message-State: AOAM532Ox685AJzEuVrS1zxmuIhPrwo0vxWHHylioxr9kYBtriumwTf9 r3jjxttt4gh1zRvwv2pnLVnrDQ== X-Google-Smtp-Source: ABdhPJyZOLeLg7j/p8wRsmFkogxbH6x+jbq5lBVUBGL7ipqbIj26p8+ON6+92IstRkrTylxSyoBgEg== X-Received: by 2002:a92:d486:: with SMTP id p6mr1744530ilg.57.1623609221083; Sun, 13 Jun 2021 11:33:41 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id d10sm724677ilc.71.2021.06.13.11.33.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 13 Jun 2021 11:33:40 -0700 (PDT) To: rfced-future@iab.org References: <71d8895e-95d8-f599-4f7a-daa4753f01b0@joelhalpern.com> <8f4470e1-e078-66d3-718d-328e4202a6da@gmail.com> From: Peter Saint-Andre Message-ID: <5981c546-8349-d424-c961-db9040117a90@mozilla.com> Date: Sun, 13 Jun 2021 12:33:38 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue 34: Do we need to update Anti-Harrassment policy and WG procedures to make them applicable to WG? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 18:33:47 -0000 On 5/19/21 1:11 AM, Martin Thomson wrote: > > On Wed, May 19, 2021, at 16:53, Eliot Lear wrote: >> * If we go for the easiest path (reusing the IETF process in its >> entirety) and get it wrong, what’s the consequence? Could we just fix >> it later? > > The main consequence is likely to be a good one: we get a well-tested policy and processes. And if issues are found, the IETF is more likely to be the ones to find them and fix them. But I guess if we find some way in which the process fails, that is just a tiny facet of the existing problem we have all acknowledged as being hard: that is, what do we do if we find this RSWG business isn't working out? As Lars pointed out [1] in the GitHub issue: Do we really need to do all this work on BCP25? I'll note that for example the IRTF has no issue to simply say "these IETF rules also apply to us" without the respective IETF rules needing an update to (also) say that. The web page [2] about IRTF policies simply states: The IETF anti-harassment policy also applies to the IRTF. The IRTF strives to create and maintain an environment in which people of many different backgrounds are treated with dignity, decency, and respect. Participants are expected to behave according to professional standards and demonstrate appropriate workplace behavior. See also RFC 7776 and RFC 8716. Perhaps this is an acceptable starting point for the RSWG, too. Peter [1] https://github.com/intarchboard/program-rfced-future/issues/34#issuecomment-839752316 [2] https://irtf.org/policies/ From nobody Sun Jun 13 11:39:14 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45ADA3A24A1 for ; Sun, 13 Jun 2021 11:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=joelhalpern.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 V_aKauvcDb0X for ; Sun, 13 Jun 2021 11:39:07 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 BE9A23A24A0 for ; Sun, 13 Jun 2021 11:39:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4G33JW3cbxz6G9rQ; Sun, 13 Jun 2021 11:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1623609547; bh=k8WH9cDQUict91RLJ196FWE/1XW3zw+iWcag3Fe5xrQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=pDd1RK5o5xFSnDsulR6hvpr3UvFEL4IFMdRxjKN6iiQdHsVnVfIMVdVafvoVdB8Zn r25Z7dK5IugEq3foRrezmTbDXaPzOUCCBdJwmydBE/pXheSc7fJMTva7srvYkLUidR o4FbRyaRgQSYmQlT2MKhe+XgijccySP9Od016+5k= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4G33JV75PTz6G7Yr; Sun, 13 Jun 2021 11:39:06 -0700 (PDT) To: Peter Saint-Andre , rfced-future@iab.org References: <71d8895e-95d8-f599-4f7a-daa4753f01b0@joelhalpern.com> <8f4470e1-e078-66d3-718d-328e4202a6da@gmail.com> <5981c546-8349-d424-c961-db9040117a90@mozilla.com> From: "Joel M. Halpern" Message-ID: <630f4035-ed7d-44ba-1044-ed8d437fa984@joelhalpern.com> Date: Sun, 13 Jun 2021 14:39:04 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <5981c546-8349-d424-c961-db9040117a90@mozilla.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue 34: Do we need to update Anti-Harrassment policy and WG procedures to make them applicable to WG? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 18:39:12 -0000 The difficulty I see is that if someone wants to report a problem with the RSWG (much as we all hope that will not happen), who do they report to? The Obmudsteam? Even if the IESG and Ombudsteam agree to taht, what happens if it needs further escalation? The fact that the IRTF has gotten lucky enough not to explore these messes does not mean we should ignore them. At least in their case, one might well asume the IRSG and IRTF chair fill the needed roles, and that the IESG / Obmudsteam have tactily agreed to the delegation. Yours, Joel On 6/13/2021 2:33 PM, Peter Saint-Andre wrote: > On 5/19/21 1:11 AM, Martin Thomson wrote: >> >> On Wed, May 19, 2021, at 16:53, Eliot Lear wrote: > > > >>> * If we go for the easiest path (reusing the IETF process in its >>> entirety) and get it wrong, what’s the consequence? Could we just fix >>> it later? >> >> The main consequence is likely to be a good one: we get a well-tested policy and processes. And if issues are found, the IETF is more likely to be the ones to find them and fix them. But I guess if we find some way in which the process fails, that is just a tiny facet of the existing problem we have all acknowledged as being hard: that is, what do we do if we find this RSWG business isn't working out? > > As Lars pointed out [1] in the GitHub issue: > > Do we really need to do all this work on BCP25? I'll note that for > example the IRTF has no issue to simply say "these IETF rules also > apply to us" without the respective IETF rules needing an update to > (also) say that. > > The web page [2] about IRTF policies simply states: > > The IETF anti-harassment policy also applies to the IRTF. The IRTF > strives to create and maintain an environment in which people of many > different backgrounds are treated with dignity, decency, and respect. > Participants are expected to behave according to professional > standards and demonstrate appropriate workplace behavior. See also > RFC 7776 and RFC 8716. > > Perhaps this is an acceptable starting point for the RSWG, too. > > Peter > > [1] > https://github.com/intarchboard/program-rfced-future/issues/34#issuecomment-839752316 > > [2] https://irtf.org/policies/ > From nobody Sun Jun 13 11:48:36 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AD53A24DB for ; Sun, 13 Jun 2021 11:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=mozilla.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 HY4tw2x6Dl0E for ; Sun, 13 Jun 2021 11:48:32 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 0835D3A24D9 for ; Sun, 13 Jun 2021 11:48:31 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id z1so10353275ils.0 for ; Sun, 13 Jun 2021 11:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=a7a1La5Vpf1e8Uaw3bEy21ZIOYIatdzhkUbinamjiVk=; b=Qf8pr4ZOSD8HYyeusR1xpdjcFkbzXX0aIhVif1dEXZXaWObFVSoQobsSNE+7/qiqyh U2ZN1vPVPRZITGAvPtpes6OJOk0xGImU6V9EPofbeoDud8oOPvRY6VZ1XTti7Pjc5u05 Gbj7fVnfFSgTwPMGSCLoZ8PwwpMYesV8d/Z2c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=a7a1La5Vpf1e8Uaw3bEy21ZIOYIatdzhkUbinamjiVk=; b=Lh4vZqbJ/tnZnG+Vxu4PV9S+q/vRU6zUzGAL80H2xrXUAdZG6JxZ9qZMO5mVXQN/Rc k6equnNtDFHKGo+0e8MMzLvlvxRH5c4FNNXJQVVyh3Tqz7Vkg39m4TyTKMtRPKHq9uR9 GCxyCQPVAGdxAJOFlvcG+c7wUMeRCwF0B5SP7SKptP8efNANNucCnFSE6zgyT2cjbbmm AxjWXoYEpmkPpW7AOA6Hz9XKS76bE28T7hwbc2KWjZVr7Q0kx3ktQEnur0YQy0Rzp9fR 2Nf9ncT2h27ALm01N6QhV1x9EPbNNaoeJWTH56jQcV9RfXdx3iLmQvljj/qoUv1SQY1E 6+nQ== X-Gm-Message-State: AOAM531l0SOyrXhAUGrdHtCXPXhqtvfHgo30J4FcDfRYBri4EN71deJb bgRmZW5i4fL8pP/Kk2WeQhaIBg== X-Google-Smtp-Source: ABdhPJwff2l6xMz3PHPF1RU10xlZvQUjyqRektr3lYUrr7tyIbTUI5pximoxD2bJLb+DZcmCj6XchQ== X-Received: by 2002:a92:1806:: with SMTP id 6mr10866185ily.268.1623610110543; Sun, 13 Jun 2021 11:48:30 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id c22sm6757844ioz.24.2021.06.13.11.48.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 13 Jun 2021 11:48:29 -0700 (PDT) To: "Joel M. Halpern" , rfced-future@iab.org References: <71d8895e-95d8-f599-4f7a-daa4753f01b0@joelhalpern.com> <8f4470e1-e078-66d3-718d-328e4202a6da@gmail.com> <5981c546-8349-d424-c961-db9040117a90@mozilla.com> <630f4035-ed7d-44ba-1044-ed8d437fa984@joelhalpern.com> From: Peter Saint-Andre Message-ID: Date: Sun, 13 Jun 2021 12:48:27 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <630f4035-ed7d-44ba-1044-ed8d437fa984@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue 34: Do we need to update Anti-Harrassment policy and WG procedures to make them applicable to WG? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 18:48:35 -0000 On 6/13/21 12:39 PM, Joel M. Halpern wrote: > The difficulty I see is that if someone wants to report a problem with > the RSWG (much as we all hope that will not happen), who do they report > to?  One possibility is the same entity to which process appeals are made. For the RSWG, we are thinking that's the RSAB. For the RSAB, it's yet to be determined. Peter From nobody Sun Jun 13 12:29:59 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B2C3A260E for ; Sun, 13 Jun 2021 12:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=joelhalpern.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 aUc3vQpcBaRq for ; Sun, 13 Jun 2021 12:29:53 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 671173A260B for ; Sun, 13 Jun 2021 12:29:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4G34R451VBz6GBf5; Sun, 13 Jun 2021 12:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1623612592; bh=vA7vb717jj7jRflkDwp/XH8zGWyvpUjBbJaA/s+3vLs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=lvPx/LbaMkNL0uKhNqBFcXHHaeeYKw0/X9djmreHbKj4xh85FR69uQfvKv0LCGHRZ F0kQAL3nDcTJfI9BpXjo3BgrgUcDZlij2FCMmMKYxsOR3NdXhBgG/Hkj4cvIhXs+Ry HcqnQQLSXdVwu1/2ivmK02p9oL+LnNLwNmQkH24Y= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4G34R40PC1z6G9GG; Sun, 13 Jun 2021 12:29:51 -0700 (PDT) To: Peter Saint-Andre , rfced-future@iab.org References: <71d8895e-95d8-f599-4f7a-daa4753f01b0@joelhalpern.com> <8f4470e1-e078-66d3-718d-328e4202a6da@gmail.com> <5981c546-8349-d424-c961-db9040117a90@mozilla.com> <630f4035-ed7d-44ba-1044-ed8d437fa984@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <11a632eb-236d-9645-e648-a6cfce7eac1c@joelhalpern.com> Date: Sun, 13 Jun 2021 15:29:49 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Issue 34: Do we need to update Anti-Harrassment policy and WG procedures to make them applicable to WG? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 19:29:58 -0000 My primary concern is that we specify the answer. Thus, the wording from the IRTF while useful is insufficient. Yours, Joel On 6/13/2021 2:48 PM, Peter Saint-Andre wrote: > On 6/13/21 12:39 PM, Joel M. Halpern wrote: >> The difficulty I see is that if someone wants to report a problem with >> the RSWG (much as we all hope that will not happen), who do they report >> to? > > One possibility is the same entity to which process appeals are made. > For the RSWG, we are thinking that's the RSAB. For the RSAB, it's yet to > be determined. > > Peter > From nobody Sun Jun 13 12:32:26 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB70D3A2625 for ; Sun, 13 Jun 2021 12:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 m8oiOoY-c5n0 for ; Sun, 13 Jun 2021 12:32:20 -0700 (PDT) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 4C9BC3A2627 for ; Sun, 13 Jun 2021 12:32:20 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id t6so10365521iln.8 for ; Sun, 13 Jun 2021 12:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=rfxsYHvGDLUfk86ctnlGqo4b2LyMP70mcdmsrI8FJ4E=; b=MUDBX6ZwNuFmlmjxjNi9YBKfB65SlLC/s9movBvXRJ3VQOWpoth9yc8JBETSofUBYX uwN3WaNN8aEmGTOQpTA2iu5UoyEAcc0fnmkUZ0AtO7tw5Pg7MpCzvjG/iZggHjZGA5Nj R1+pbfa3cV6XOW7md/gO4fqoqX0qCJxlgsw3I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rfxsYHvGDLUfk86ctnlGqo4b2LyMP70mcdmsrI8FJ4E=; b=h4X3yJK6HUBR3YAjxRQkkRHjYE/bE6q1QJqzLRopxSlfFES/F0IAEZ8OtodZLnUBS7 JJPx57cXb/XBnDYD1uXjZdqJ5y/Kdj+or4Q2TwCh7lEh4wiuBe6RiQtrbux4/WCupnGF D3NEZFkY3ob61N8dCwwkVouBA49m6EjNdMMnM+nvvhZG0LwI+klKiCZFDcki1ah1vkYz 1bic5hR2wuygkst0dvq+lvIKU5ib11Y1A6m3sRIvNBHds+xllrkSmDpW7gA6rZj8DTzU 335QQDR9fNI16+8g9Z5aexgqWRz/XL/Zg8Z5XyDXa1jrMyjmcnI0IUUNfLppbKkGQ4kF 8PpQ== X-Gm-Message-State: AOAM5320mUHZsPwjUp8rp39o4gDZxLLoZO2xmYz0PgwgWL15a/7e4G6c 0vE68gN08b89IwzHULrY9l7QgQ== X-Google-Smtp-Source: ABdhPJyfeTgUMkq7rhoOyoUb0iK4gwwiZvCmkEHGq3uGR7+xXZmb+NU5F+2h7tF3GU24d7Kz46eYkw== X-Received: by 2002:a92:6610:: with SMTP id a16mr11194730ilc.124.1623612738539; Sun, 13 Jun 2021 12:32:18 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id l6sm7199223iok.9.2021.06.13.12.32.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 13 Jun 2021 12:32:17 -0700 (PDT) To: "Joel M. Halpern" , rfced-future@iab.org References: <71d8895e-95d8-f599-4f7a-daa4753f01b0@joelhalpern.com> <8f4470e1-e078-66d3-718d-328e4202a6da@gmail.com> <5981c546-8349-d424-c961-db9040117a90@mozilla.com> <630f4035-ed7d-44ba-1044-ed8d437fa984@joelhalpern.com> <11a632eb-236d-9645-e648-a6cfce7eac1c@joelhalpern.com> From: Peter Saint-Andre Message-ID: Date: Sun, 13 Jun 2021 13:32:15 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <11a632eb-236d-9645-e648-a6cfce7eac1c@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue 34: Do we need to update Anti-Harrassment policy and WG procedures to make them applicable to WG? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 19:32:25 -0000 On 6/13/21 1:29 PM, Joel M. Halpern wrote: > My primary concern is that we specify the answer.  Thus, the wording > from the IRTF while useful is insufficient. Agreed. That's why I made a concrete suggestion for consideration by the Program. Peter From nobody Sun Jun 13 12:36:47 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D112F3A2653 for ; Sun, 13 Jun 2021 12:36:46 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=joelhalpern.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 Z5X0UXexN7ZT for ; Sun, 13 Jun 2021 12:36:42 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 75EFF3A2652 for ; Sun, 13 Jun 2021 12:36:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4G34Zx6cstz6GBj4; Sun, 13 Jun 2021 12:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1623613001; bh=fSnpyUP2VMRt7wbgYFAjxjNDlpfhAnhX77DrTnJIw3Y=; h=Subject:To:References:From:Date:In-Reply-To:From; b=EnauACzFxNCRHvVDumLhA+IRBK17atc0zJuzYakpCk6Ff+Iw70MKY4+AZ85b13qgI znXrJUZZ8vCfm2bS3W6D7+2L8hcfQF+lgMWWoygV84/4Ksr8zP6TrNctBm5pIyQVR/ S8TgHsUskQnzG4kzgIfpwr1tho9U/qx5vQpYJis4= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4G34Zx2zh6z6GB49; Sun, 13 Jun 2021 12:36:41 -0700 (PDT) To: Peter Saint-Andre , rfced-future@iab.org References: <71d8895e-95d8-f599-4f7a-daa4753f01b0@joelhalpern.com> <8f4470e1-e078-66d3-718d-328e4202a6da@gmail.com> <5981c546-8349-d424-c961-db9040117a90@mozilla.com> <630f4035-ed7d-44ba-1044-ed8d437fa984@joelhalpern.com> <11a632eb-236d-9645-e648-a6cfce7eac1c@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <3fd8fce2-ae0f-4840-d9e6-91049a6aeb51@joelhalpern.com> Date: Sun, 13 Jun 2021 15:36:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue 34: Do we need to update Anti-Harrassment policy and WG procedures to make them applicable to WG? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 19:36:47 -0000 I do not have a better answer than the RSAB for where the process would point, so assuming the IESG / ambudsteam are willing to be pointed to, I can live with that. And given that, saying the process from there goes to wherever we say other appeals from the RSAB go seems to make ssense. Yours, Joel On 6/13/2021 3:32 PM, Peter Saint-Andre wrote: > On 6/13/21 1:29 PM, Joel M. Halpern wrote: >> My primary concern is that we specify the answer.  Thus, the wording >> from the IRTF while useful is insufficient. > > Agreed. That's why I made a concrete suggestion for consideration by the > Program. > > Peter > From nobody Mon Jun 14 23:14:47 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6B03A21B0 for ; Mon, 14 Jun 2021 23:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 ZbnAfdQ4WrvJ for ; Mon, 14 Jun 2021 23:14:38 -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 1A1053A21AC for ; Mon, 14 Jun 2021 23:14:37 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::6] ([IPv6:2001:420:c0c0:1011:0:0:0:6]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15F6EX6D296910 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 15 Jun 2021 08:14:35 +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=1623737676; bh=0XOaWRF2tqEqOPcmj5up6yMW0U627i/3sMvJbHyCbb4=; h=To:From:Subject:Date:From; b=tKzvnMWIEpKRnjIAQ3zGcqOdRMlTctt0ME0hhapf+nykJAKxB9LH93Mjs7aArNX2Q WS3OYUqA7E5FoyjCYY1ghSszWK6oAmSgen5LrexudONrM/wUGHcCM2n1qbEB6TTvgX PQtNYrIBeQ8eX1psFG7pkfX9N4TMdY09Z7d0AvbA= To: rfced-future@iab.org From: Eliot Lear Message-ID: <87a76f93-0dea-f16a-657a-89556f1b2ed9@lear.ch> Date: Tue, 15 Jun 2021 08:14:32 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VAyoeHivMFeFTbAX35dQ4Wft5q96SzFjl" Archived-At: Subject: [Rfced-future] Issue 67: What counts as "community consensus"? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 06:14:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VAyoeHivMFeFTbAX35dQ4Wft5q96SzFjl Content-Type: multipart/mixed; boundary="ovElEas49qBNUbpDUGlUVJZelsVPECxgf"; protected-headers="v1" From: Eliot Lear To: rfced-future@iab.org Message-ID: <87a76f93-0dea-f16a-657a-89556f1b2ed9@lear.ch> Subject: Issue 67: What counts as "community consensus"? --ovElEas49qBNUbpDUGlUVJZelsVPECxgf Content-Type: multipart/alternative; boundary="------------4DD83B5D727635E49EBFD773" Content-Language: en-US This is a multi-part message in MIME format. --------------4DD83B5D727635E49EBFD773 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Our esteemed editor added the following comment: > > The draft current says: > > Once consensus is established in the RSWG, the chairs shall issue > a community call for comments. Should substantial comments be > received, the RSWG will again consider those comments and make > revisions as they see fit. At this same time, the RSAB will > consider the proposal. > > However, it's not clear what the "community" is here. Discussion is=20 > needed within the Program to clarify this. > I suggest we leverage Mark's text to answer this question. Eliot --------------4DD83B5D727635E49EBFD773 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Our esteemed editor added the following comment:

The draft current says:

Once consensus is established in the RSWG, the chairs shall issue a community call for comments. Should substantial comments be received, the RSWG will again consider those comments and make revisions as they see fit. At this same time, the RSAB will consider the proposal.

However, it's not clear what the "community" is here. Discussion is needed within the Program to clarify this.

I suggest we leverage Mark's text to answer this question.

Eliot

--------------4DD83B5D727635E49EBFD773-- --ovElEas49qBNUbpDUGlUVJZelsVPECxgf-- --VAyoeHivMFeFTbAX35dQ4Wft5q96SzFjl Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDIRUgFAwAAAAAACgkQh7ZrRtnSejPP Mgf9EA4D5M5fDtZmrgbiFkeXBjlqzY5/m2yTfeFhc7Yt8whkI0dcgG1bgdmkIeWRLjMODEa3GFxI oINXHUeTDmR1TAp2JTNchPKLFXjO4A+MjDnhzYqlZ0NcMIvfrZLUJ88hwDUe/GwgD75H4mI14WNS TK2ey72goypYg1B95KE/ElrlHH3X6e9iLFE6xIWq+a5iOhQprnq3ctIN9/oGvM48r2x0e7jy9nKI y6CW01z/CTFUMCG5gSzGh347u2nYvuBeS/keQHaflYRyGqXNAfreKi8dwfEpOf+EK8xWYLQQlQHD tnDgLbCwCtOZuhfk+9ju28vl3wKPFXtEmJjSlLBgbQ== =/j8k -----END PGP SIGNATURE----- --VAyoeHivMFeFTbAX35dQ4Wft5q96SzFjl-- From nobody Wed Jun 16 10:27:48 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B733A2036 for ; Wed, 16 Jun 2021 10:27:45 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 Ck49pnn_lI97 for ; Wed, 16 Jun 2021 10:27:43 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 7D42F3A2032 for ; Wed, 16 Jun 2021 10:27:43 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id b9so3045155ilr.2 for ; Wed, 16 Jun 2021 10:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=9tCOMRf4F5B90TVPGCvpDDbM76qCpZs0fh6zFNPFies=; b=KRQ/OMUDQWZhmnjuZKtyBwQc1HqWpMNUSKI19Quv9ncrC/KtsSxRnlViyKzyRDCHlw lgRGtTfI5b7u62BrX34hRiOosBVVWgMA7keAAszK2hpBs7ah3n+7rV1Yo746RWG8PEWG L0IzrUwNRb32GkIdzZGewhUzP4/MM1nXmaAfI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=9tCOMRf4F5B90TVPGCvpDDbM76qCpZs0fh6zFNPFies=; b=Nhbm6SSd7IGpqtBimeIidpRW0LxPRMYt+FwmqKnN/JMtWN0GPm4HHjC46Uk6QPBTDD mV6z1xo143fT+IBKa+bFB36C1yHvI72vJTIvr8wtwgOiosr+4ylVMa4o+WT/rUjYzqTQ W59qs1GCAklHClK+HbOuXrTwk0PUCJ+30iHg3WBwaYOnhZ8ttiwHC8T92KsyaMwqIygH iPWFapnu4hitVvx21u/KkfdL1wJAdXONaBCH3MoVmaX54AxBN6lQrg54qiaJpD+9606T /hKr5BPtZTASwBnpu0lMXaMLPaim2o6qErrY85wO4IAhzEpGk2uxUsrzNUXfsDPUUpgm Fzug== X-Gm-Message-State: AOAM533qUPp6WWhLTQ81eVWAOELWLUnDv0vEzks/9eaUlPMGb1JNFEk7 yusSyQr8o1/ISoVJL0bppeVkIgm2K9cczQ== X-Google-Smtp-Source: ABdhPJxpd6U5rus7zZvlnrqxesPholr3lZ4JE5OA7QM7Md6y7BgHdpZ98paZJzr3nKXbHYVKJtekiQ== X-Received: by 2002:a92:d451:: with SMTP id r17mr533009ilm.109.1623864461942; Wed, 16 Jun 2021 10:27:41 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id k12sm1491109ioh.26.2021.06.16.10.27.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Jun 2021 10:27:41 -0700 (PDT) To: "rfced-future@iab.org" From: Peter Saint-Andre Message-ID: Date: Wed, 16 Jun 2021 11:27:40 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfced-future] What counts as "community consensus"? (ISSUE #67) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 17:27:46 -0000 The draft current says: Once consensus is established in the RSWG, the chairs shall issue a community call for comments. Should substantial comments be received, the RSWG will again consider those comments and make revisions as they see fit. At this same time, the RSAB will consider the proposal. However, it's not clear what the "community" is here. To which venues would the RSWG chairs send their call for comments? Peter From nobody Wed Jun 16 13:14:01 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0111C3A2540 for ; Wed, 16 Jun 2021 13:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, 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 (1024-bit key) header.d=mozilla.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 GbD9eFIj1wc5 for ; Wed, 16 Jun 2021 13:13:55 -0700 (PDT) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 2021C3A253F for ; Wed, 16 Jun 2021 13:13:54 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id b5so3397592ilc.12 for ; Wed, 16 Jun 2021 13:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=l5mcWnFKLTzsK4y/Nyko/wfZfmX+l+hisfPYSPcyboE=; b=QZfFQKTJ7PWQenL7gNh8tsrFiFy37Fh7ybeRH+6FPjfynpKzkNYW0Ih7P3Ott0iqe8 ks+SHxAApvWE8oZZzr339DN1uj68tfgYCZIFMTuENOFzhNBaZC9tZJQ4MuDMCVEMLGMM 8crqtjwecpHr1JW7gBPzx9+/Spa0liVwL8qH8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=l5mcWnFKLTzsK4y/Nyko/wfZfmX+l+hisfPYSPcyboE=; b=rokhec9Uu5VQnEJj5KlcPfd9xb/1Gof7t6EfO/cBvxxhgKU4B5cHvqM1kA57Anx0GT d7qo/15E37Akg5VwIrd9DhdkMt6dkJg5Qx05IUVXYQMOy1OXA2gqYa0fZ1fp6/xJHYSF QhYrjExLqUxcpgYruoEpNO7FZjXr/PDHgvwBdasEChC0/2VODgq7HPND5rlOYGfUhH2N Gwdsz8tv9/lonJphAJriEkeVgiojPwtrKzPGtCb/JTS0/OlRy+zUyToee9vqd7Ih/+1A yWh1wfetBqYqDKquBXA3nGvidNH0warzNEtbxkeUNicFGor7BZX/HU2yTvwuJXJ8nlnV h37A== X-Gm-Message-State: AOAM530VvbhZ857gjfdtSjw0iV7AWdwxJaGZ7vaIiJTQ1ks3RdXSMDWs OGXnAQVIYRIXCaPxPcGPPnUBTw== X-Google-Smtp-Source: ABdhPJycQPsMHIucZSL6qFSFiM8Gm+Enir9sF0PA+8bXBAIdy98Cb70xMV3E74/+MPsM0RhsuPVXgg== X-Received: by 2002:a92:dc46:: with SMTP id x6mr976289ilq.66.1623874432300; Wed, 16 Jun 2021 13:13:52 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id i1sm1644446iol.16.2021.06.16.13.13.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Jun 2021 13:13:51 -0700 (PDT) To: Brian E Carpenter , "rfced-future@iab.org" References: <818e6f57-8920-7b1b-3793-34df3fa332a9@mozilla.com> <78b13225-e9fa-3b9c-3c41-6bf635248b18@gmail.com> From: Peter Saint-Andre Message-ID: <454192a0-8b60-bff3-2e1a-9f6bcd626337@mozilla.com> Date: Wed, 16 Jun 2021 14:13:50 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <78b13225-e9fa-3b9c-3c41-6bf635248b18@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] How to select RSWG chairs (#41) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 20:13:59 -0000 On 5/20/21 6:05 PM, Brian E Carpenter wrote: > On 21-May-21 11:04, Peter Saint-Andre wrote: >> There was a bit of discussion in Issue #41 [1] about how to select >> chairs for the RSWG. The existing strawman text says: >> >> "The IETF Chair and the Independent Submissions Editor shall each >> appoint and oversee a co-chair of the RSWG." > > Three comments on that: > > - Why not say that they *jointly* appoint two co-chairs? My understanding from previous discussion (see also note from Martin) is that the IESG would appoint one chair and the IAB (no longer the ISE as you mention below) would appoint the other chair. > - I'm not sure about "oversee". It's a word that has got us into > trouble in the past. I've removed that from the draft. > - Make the appointments fixed term, please, with no term limits > on renewal. Here's a strawman: ### The RSWG shall have two chairs, one appointed by the IESG and the other appointed by the IAB. Chairs shall serve for a term of two (2) years, with no term limits on renewal. The appointing bodies shall determine their own processes for making these appointments, such as provision for an open nominations period. Community members who have concerns about the performance of an RSWG chair should direct their feedback to the relevant appointing body. ### >> Lars Eggert suggested that the IAB Chair would be a better option than >> the ISE, since "the IAB has direct or indirect oversight over all the >> non-IETF streams" > > Probably right. > > Brian C > From nobody Wed Jun 16 13:38:56 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280ED3A25EE for ; Wed, 16 Jun 2021 13:38:54 -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, NICE_REPLY_A=-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 Jx6d7wmD-drv for ; Wed, 16 Jun 2021 13:38:50 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 EF69F3A25EC for ; Wed, 16 Jun 2021 13:38:49 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id m2so2994445pgk.7 for ; Wed, 16 Jun 2021 13:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=/hnP3v6yVjnVTahl6h3L5cEqEV+ylhO3VwfPwBOOoDg=; b=eIY/oetizVGZ0q40syFWCZuijwN2rRu/w576Kq4/wXIuYtY6AlVyR3jAwOCX7fA41l 7tM263d1wB42c8xa2rqkNf6OxfFV+yanneh2CNvQDRopN5K883d+MnSJKcclcXLXnewK oACO5wFdZgct8OVg5iA4TjrME5gxgO+2RvXXoKz3ZM/1VfGooKLuJBJKC+nGNofooQms ifQ01xsXrSXWWOIbORTv77ihnzBgiMKDs0bq6Ri2++upU2Jg/ZpJuiWtA/3VwOVEJfRY DTOWid0m9lX0pD8dDL3NLMFCbJ12i4S8byxITSMW9XKtZxuD0x/EsXgDm5NBy1C4GL4f ucHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/hnP3v6yVjnVTahl6h3L5cEqEV+ylhO3VwfPwBOOoDg=; b=DkBJTS4AN0rvsyZd+6bQohNwcxj9yM2DI+MTTvh0Ro+m0N/YKFH/j8HdzyadigjcPn wR3zIcY1Vxma60aD0HNbeVka5IAflM9K/7o8CDCi40HYfXmloL6XCJrw/yPeRNp3yX6i tzlerOyBcpGXCnbeiG1TWcRedZf9c/gFQXNbxVLBvoJnxzH334+p20aG4a77KLm+md+v hrmj27RuZthCQbbFjlQ0uTBgU+cSoNqiYa54KQZpf6MxbPPmkTCNK/4d/hS6uI8sg92u 11QGHAFDg/AfqgqVX4aci9W14v09rrs7IWVlT0IPuIc8qyu6VNyO5iq8dwgGcpouyMMb ge1g== X-Gm-Message-State: AOAM533XwuceeI5CrbdJ0C+jPWoCbPt+Iy0YNQFuOLLzfL48jAar86de qwK5Lp7zJvjyp1p2dbyIyaLUr6Poa6XrQA== X-Google-Smtp-Source: ABdhPJwdMQ+4i3F1Isma0+GnFk3uoPr4EGZORuR9eCDZwe3fYRZt6pgHByAyanXFND0MzBtsYKJbXw== X-Received: by 2002:a65:508d:: with SMTP id r13mr1526091pgp.36.1623875928659; Wed, 16 Jun 2021 13:38:48 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id a15sm3045447pfl.100.2021.06.16.13.38.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Jun 2021 13:38:48 -0700 (PDT) To: Peter Saint-Andre , "rfced-future@iab.org" References: From: Brian E Carpenter Message-ID: <5c3863fb-f724-89cb-9a03-364476caf21a@gmail.com> Date: Thu, 17 Jun 2021 08:38:44 +1200 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: [Rfced-future] What counts as "community consensus"? (ISSUE #67) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 20:38:54 -0000 I thought Mark's text answered this: https://mailarchive.ietf.org/arch/msg/rfced-future/FStOazJ_iACtrXg0F6GHnK0ZksI/ Regards Brian Carpenter On 17-Jun-21 05:27, Peter Saint-Andre wrote: > The draft current says: > > Once consensus is established in the RSWG, the chairs shall issue a > community call for comments. Should substantial comments be received, > the RSWG will again consider those comments and make revisions as they > see fit. At this same time, the RSAB will consider the proposal. > > However, it's not clear what the "community" is here. To which venues > would the RSWG chairs send their call for comments? > > Peter > From nobody Wed Jun 16 13:40:29 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3943A25FB for ; Wed, 16 Jun 2021 13:40: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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 zoYEJpx99Xbr for ; Wed, 16 Jun 2021 13:40:24 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 611F13A25F8 for ; Wed, 16 Jun 2021 13:40:24 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id q25so3162125pfh.7 for ; Wed, 16 Jun 2021 13:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=RHOJZM3uuF2cCJcR6Ma3emuacn1dfhJmkmSSL55R49E=; b=cROvmovBd7U7tm9WotkQx45F/TYytyJs9GS63zu4dAgDBVi2Fxx//Ct6D8IfT1/I2l g9L9drLllVOGg20474G/cImDgLJ4Jdd7OeRltLs+SrI4wWzeO3PqYRAS5BPNz55K96d2 TNV0gGIc0ivZ51BfZkUgYMKYO60RKrE4ii7/+TElRHP7Fi5WX+8hq3PPg5OyIEyZOj5z dtFRl5qZjVlMahxEVgYT4h3T1YQbtlVTBiZT2P/JQay40JBPeLg634vZF+N9dm6pfVK/ geSSUqDlL/e6/gz34D5ayf0LraCFL2uTYaQkoEfC5HEeaNXr/onbTjYLGqzIIBD+aeDj e8Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RHOJZM3uuF2cCJcR6Ma3emuacn1dfhJmkmSSL55R49E=; b=SUWF/KaAAzJPZF+RQJqTjqCCZDWqcwgmt//6+dorqo9gG+++uOCns0T5w+lZTg+MIm dLXzJy+eMV4wPnc15QlXWuwubKgFrH6kHRtSHl3YNL+B0CdUDhfyCS+oKubfOowfhask Vsbek5Rt57XiSpIGXfS3MjzkPbvnKxie7jp8We/M6K5sdFUrNVIbusppQL7PmzNA90hg R51rkissgHi210qdHcACRDpnPtRk6aCiZUaDE1oIW8nlLZn1bPMkZiLHJ6XNaGincwzi DPRdw6apW3dSkCbbzObTyHmqShbF6gFP94TVD2uuLDIcN2MYLK5oyJDAylP5w9qh0oe4 MzPA== X-Gm-Message-State: AOAM531HhvMPAsN5h/PpL68b+OETMWs39XRkKYQ7JPvN42XYEqwL5SC9 2r8Nw1AozaGItMakQBmqiX/yWrjLyF1tFQ== X-Google-Smtp-Source: ABdhPJwo98wZFH423mHNFsqRpy7Mgd5qxSdokeytFMFdVVN8pJDhBGyshABz1eMzAxMwZqFQ014xvQ== X-Received: by 2002:a05:6a00:228c:b029:2f9:e608:e110 with SMTP id f12-20020a056a00228cb02902f9e608e110mr1567781pfe.23.1623876023215; Wed, 16 Jun 2021 13:40:23 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id a66sm3074015pfb.162.2021.06.16.13.40.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Jun 2021 13:40:22 -0700 (PDT) To: Peter Saint-Andre , "rfced-future@iab.org" References: <818e6f57-8920-7b1b-3793-34df3fa332a9@mozilla.com> <78b13225-e9fa-3b9c-3c41-6bf635248b18@gmail.com> <454192a0-8b60-bff3-2e1a-9f6bcd626337@mozilla.com> From: Brian E Carpenter Message-ID: Date: Thu, 17 Jun 2021 08:40:19 +1200 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: <454192a0-8b60-bff3-2e1a-9f6bcd626337@mozilla.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] How to select RSWG chairs (#41) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 20:40:28 -0000 wfm Regards Brian Carpenter On 17-Jun-21 08:13, Peter Saint-Andre wrote: > On 5/20/21 6:05 PM, Brian E Carpenter wrote: >> On 21-May-21 11:04, Peter Saint-Andre wrote: >>> There was a bit of discussion in Issue #41 [1] about how to select >>> chairs for the RSWG. The existing strawman text says: >>> >>> "The IETF Chair and the Independent Submissions Editor shall each >>> appoint and oversee a co-chair of the RSWG." >> >> Three comments on that: >> >> - Why not say that they *jointly* appoint two co-chairs? > > My understanding from previous discussion (see also note from Martin) is > that the IESG would appoint one chair and the IAB (no longer the ISE as > you mention below) would appoint the other chair. > >> - I'm not sure about "oversee". It's a word that has got us into >> trouble in the past. > > I've removed that from the draft. > >> - Make the appointments fixed term, please, with no term limits >> on renewal. > > Here's a strawman: > > ### > > The RSWG shall have two chairs, one appointed by the IESG and the > other appointed by the IAB. Chairs shall serve for a term of two (2) > years, with no term limits on renewal. The appointing bodies shall > determine their own processes for making these appointments, such > as provision for an open nominations period. Community members who > have concerns about the performance of an RSWG chair should direct > their feedback to the relevant appointing body. > > ### > >>> Lars Eggert suggested that the IAB Chair would be a better option than >>> the ISE, since "the IAB has direct or indirect oversight over all the >>> non-IETF streams" >> >> Probably right. >> >> Brian C >> From nobody Wed Jun 16 14:15:00 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5093A26FD for ; Wed, 16 Jun 2021 14:14:58 -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, NICE_REPLY_A=-0.001, 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=mozilla.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 sqQlSoysXuK6 for ; Wed, 16 Jun 2021 14:14:54 -0700 (PDT) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 64B9C3A26FB for ; Wed, 16 Jun 2021 14:14:54 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id h3so3549589ilc.9 for ; Wed, 16 Jun 2021 14:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=dGbKKAZ9M3mTk1XDu7NwdMFnqv55sd+NGAMDm/k8nFc=; b=EEgLfMrxpNh16uxlZ/SrGCDalmh2NTVlRpXNvB+p3lmBdMuxDyNv+ZM9QM8ygsaX+7 rvzqDNKHAoOclkGNgLlhrudBVI4nB3MfGM14uavErZlmO9ddcN06zd4HVO6eaqL7e9wp vz8+VmOm69+4BKailvy+wvIKslxisoXPtHOeA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dGbKKAZ9M3mTk1XDu7NwdMFnqv55sd+NGAMDm/k8nFc=; b=bgaKrbAAj5wvjpUv4eL2HY/y96wxDoNrwJ17CbOa0LdvFj7URZk+yudbrMTbyWcgtV NBUQa74a8AufLl8xfMklkvC5Z3W+yJ65DR6Ko+eMSgytDbKpMw7m2JAhRdfl7S7ti4DM pxHyw5qGmqnpAM+qJsDh61hvTFtDGoon/2TwzVbFU0L3IXTcG7xzxOgXbidVc3b8n2lB CuoGi/HgVt2wvkTFOOIgU+8kTQggWullsCHSPNYarnnGJRz0aZ1ISM8Ux4zUW0nch/l5 EfFV+28Z9RUFykDwB3FXYsJOru9SJCuReNopDVYoE2gwXzba8armUriWNnBbMCx2ABhS lvzQ== X-Gm-Message-State: AOAM532Brd4vojbNh7vE3KcIKMeYvXljhBSOYbyU5qs/7BimY7kFp4M7 8U/CYHjeM39Ur7KJZ4DwnPThpQ== X-Google-Smtp-Source: ABdhPJxBP12jR4Ff4XmpHJx1J7NcBsEGvquugiLPyYDI6SMAu7YxhxdgsJXUBUM1JBvOEaEl3JihDw== X-Received: by 2002:a92:dac3:: with SMTP id o3mr1069754ilq.290.1623878092572; Wed, 16 Jun 2021 14:14:52 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id r20sm1638082ilj.56.2021.06.16.14.14.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Jun 2021 14:14:51 -0700 (PDT) To: Brian E Carpenter , "rfced-future@iab.org" References: <5c3863fb-f724-89cb-9a03-364476caf21a@gmail.com> From: Peter Saint-Andre Message-ID: Date: Wed, 16 Jun 2021 15:14:50 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <5c3863fb-f724-89cb-9a03-364476caf21a@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] What counts as "community consensus"? (ISSUE #67) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 21:14:59 -0000 Thanks for the pointer, I had missed that. On 6/16/21 2:38 PM, Brian E Carpenter wrote: > I thought Mark's text answered this: > > https://mailarchive.ietf.org/arch/msg/rfced-future/FStOazJ_iACtrXg0F6GHnK0ZksI/ > > Regards > Brian Carpenter > > On 17-Jun-21 05:27, Peter Saint-Andre wrote: >> The draft current says: >> >> Once consensus is established in the RSWG, the chairs shall issue a >> community call for comments. Should substantial comments be received, >> the RSWG will again consider those comments and make revisions as they >> see fit. At this same time, the RSAB will consider the proposal. >> >> However, it's not clear what the "community" is here. To which venues >> would the RSWG chairs send their call for comments? >> >> Peter >> From nobody Wed Jun 16 15:48:28 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8133A0976 for ; Wed, 16 Jun 2021 15:48:27 -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, RCVD_IN_DNSWL_BLOCKED=0.001, 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=mozilla.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 Hc_7xRFolc3Q for ; Wed, 16 Jun 2021 15:48:22 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 9A6B33A096F for ; Wed, 16 Jun 2021 15:48:22 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id d1so3736818ils.5 for ; Wed, 16 Jun 2021 15:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=2AB09F5/0RRKuAeTzaqy9OM3FDbO8wlKIAIRJ6uPdpw=; b=AUgxlP3HInoJ0HF4nrzu88CKCqYPreIoOw2EPJRUlDfi5ye/sw5cymac+azQ/oCpgB jhu2csC3p8pyQL7PlX19Y81+0c5/bzI1KwK9kE8L+dRFYXsHo3N5paoiG1STjL4J5CYD Up9UhBITEhQ8bspL4wbbxxtA6ADLAmwSEJ6Ks= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=2AB09F5/0RRKuAeTzaqy9OM3FDbO8wlKIAIRJ6uPdpw=; b=TRuVb2ZoKkByHJaL+WPye1IJKCCM4oYfQR2E+indIBIBH3+edHK3pR5glJWQSqKC8L q0Ac5JZl0XyL3sr5290WMYBwJ+znpHMxz2ii0Hs9gSwQ4G5wt1PfLxiqs4v876KF6AaM Yul2ZqLc5LyfYCLqeuKW0a9JQL9aiEDRMXa2WYnw4DeJuKV36KNCkzFmMoj6n+MzUpVU OIVtOixwG62WFQUfc5t3x0WpI6fW7ZbcFkINDXroTvDJ0LciCzy7/mbmGAka7lEipE4a HOkX0QirFOlbclrVcYiB8CR6J9Tt1a2gzMR7PkmkX63y8h3PNx+VoygdPjqPUGnW1jF2 Y8HA== X-Gm-Message-State: AOAM533qInUnNfC27xTmElQAxwOyXO2QuqGQMbSyLGQqCxszkXfSUqvy Nq2ptzgYZ9O3Fi6DfhDwWXGuyw== X-Google-Smtp-Source: ABdhPJw/fWr27ZLAprfuzsv+Jm3DYUN0+H6hJFpsK9DOUaEgRVlhTFQtmS/yWBeyyYcF/VP0vlOXJg== X-Received: by 2002:a92:a302:: with SMTP id a2mr1302660ili.184.1623883700868; Wed, 16 Jun 2021 15:48:20 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id r2sm1779886ilt.52.2021.06.16.15.48.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Jun 2021 15:48:20 -0700 (PDT) To: "rfced-future@iab.org" From: Peter Saint-Andre Message-ID: <6cfa111a-df53-3534-391f-9d064369c74a@mozilla.com> Date: Wed, 16 Jun 2021 16:48:18 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfced-future] version -01 of draft-saintandre-rfced-model X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 22:48:27 -0000 Hi all, Ahead of our interim meeting next week, I've just submitted version -01 of draft-saintandre-rfced-model. Although I can't promise that it covers every issue we've discussed, I've attempted to make this version much more accurate and complete. Any remaining errors are my responsibility. https://datatracker.ietf.org/doc/html/draft-saintandre-rfced-model-01 Peter From nobody Thu Jun 17 09:14:19 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49183A2589 for ; Thu, 17 Jun 2021 09:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 jiMpibe7-bQ8 for ; Thu, 17 Jun 2021 09:14:12 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 6CBC23A2586 for ; Thu, 17 Jun 2021 09:14:12 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15HGE9cO020569 for ; Thu, 17 Jun 2021 17:14:09 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7B4284604E for ; Thu, 17 Jun 2021 17:14:09 +0100 (BST) Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6F7154604C for ; Thu, 17 Jun 2021 17:14:09 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS for ; Thu, 17 Jun 2021 17:14:09 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.47.18]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15HGE86E008284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Jun 2021 17:14:09 +0100 Reply-To: From: "Adrian Farrel" To: References: <818e6f57-8920-7b1b-3793-34df3fa332a9@mozilla.com> <78b13225-e9fa-3b9c-3c41-6bf635248b18@gmail.com> <454192a0-8b60-bff3-2e1a-9f6bcd626337@mozilla.com> In-Reply-To: Date: Thu, 17 Jun 2021 17:14:07 +0100 Organization: Old Dog Consulting Message-ID: <057701d76393$cd635360$6829fa20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJeJZJCpLffrAAT3GL6PXuOiXSQTgD2mslMAtlXUz0BaF3T26nhGa4w X-Originating-IP: 84.93.47.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1017-26226.001 X-TM-AS-Result: No--20.162-10.0-31-10 X-imss-scan-details: No--20.162-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1017-26226.001 X-TMASE-Result: 10--20.161900-10.000000 X-TMASE-MatchedRID: C/snMIRQLS1q0U6EhO9EE3FPUrVDm6jtTJDl9FKHbrmVhb93M3U2aOxy N2l3ChyGSo39/yW5eoOcMKBnIPRFjv+ib4J8UFvaz1H9SpactbgSD4KIWevpX4hJn1AfgbrD0u5 faGP8ztTJZd9TwoD+O+U3L9KUQPrEPg9yfk4YC0bece0aRiX9WjsY2/UEG7fkCDaSBZ23epoTz3 zRCzxSYfq0eR+8f+2C9VnN7eVQVea5PY6WqT/Y1IVMtEwAWsdcAajW+EL+laPfU69XQp4gvGgB5 YfGlEwydNPgsdekIxZgBKW7UCfQnoA/V6M07UuxvHKClHGjjr1nbaiPlnpN7v4rVEL2OXFJYO89 Y81MVOCrKaCIB8U9PQHOcpEKrUTZ4rf59koGAioCOoDG5aR1MVdEEmf6TRVBqt6rfLZlsDx5vY4 YhCIgbmyD63gJEOU9pboK15uSCnDSIgvB03GEksf0rZmodBaWTX6ADbpYH9Gbk3ZgcwPRvwzKt8 /2P4LV33fj+sMArfNRzX47Vf0DMQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] How to select RSWG chairs (#41) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 16:14:17 -0000 This works for me, too. But... =F0=9F=98=8A Do we want to make the appointments expire alternate years to reduce the = chance of a loss in continuity? A -----Original Message----- From: Rfced-future On Behalf Of Brian E = Carpenter Sent: 16 June 2021 21:40 To: Peter Saint-Andre ; rfced-future@iab.org Subject: Re: [Rfced-future] How to select RSWG chairs (#41) wfm Regards Brian Carpenter On 17-Jun-21 08:13, Peter Saint-Andre wrote: > On 5/20/21 6:05 PM, Brian E Carpenter wrote: >> On 21-May-21 11:04, Peter Saint-Andre wrote: >>> There was a bit of discussion in Issue #41 [1] about how to select >>> chairs for the RSWG. The existing strawman text says: >>> >>> "The IETF Chair and the Independent Submissions Editor shall each >>> appoint and oversee a co-chair of the RSWG." >> >> Three comments on that: >> >> - Why not say that they *jointly* appoint two co-chairs? >=20 > My understanding from previous discussion (see also note from Martin) = is > that the IESG would appoint one chair and the IAB (no longer the ISE = as > you mention below) would appoint the other chair. >=20 >> - I'm not sure about "oversee". It's a word that has got us into >> trouble in the past.=20 >=20 > I've removed that from the draft. >=20 >> - Make the appointments fixed term, please, with no term limits >> on renewal. >=20 > Here's a strawman: >=20 > ### >=20 > The RSWG shall have two chairs, one appointed by the IESG and the > other appointed by the IAB. Chairs shall serve for a term of two (2) > years, with no term limits on renewal. The appointing bodies shall > determine their own processes for making these appointments, such > as provision for an open nominations period. Community members who > have concerns about the performance of an RSWG chair should direct > their feedback to the relevant appointing body. >=20 > ### >=20 >>> Lars Eggert suggested that the IAB Chair would be a better option = than >>> the ISE, since "the IAB has direct or indirect oversight over all = the >>> non-IETF streams" >> >> Probably right. >> >> Brian C >> --=20 Rfced-future mailing list Rfced-future@iab.org https://www.iab.org/mailman/listinfo/rfced-future From nobody Thu Jun 17 13:33:35 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394723A2D0D for ; Thu, 17 Jun 2021 13:33:33 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 Niau8s7WHMsY for ; Thu, 17 Jun 2021 13:33:28 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A48E3A2D0C for ; Thu, 17 Jun 2021 13:33:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 867C3300B99 for ; Thu, 17 Jun 2021 16:33:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uEmwGWKIqUhd for ; Thu, 17 Jun 2021 16:33:21 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 9CF67300B50; Thu, 17 Jun 2021 16:33:21 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: <057701d76393$cd635360$6829fa20$@olddog.co.uk> Date: Thu, 17 Jun 2021 16:33:21 -0400 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <438FFBE1-54B7-4CE4-9E2F-79FA088446ED@vigilsec.com> References: <818e6f57-8920-7b1b-3793-34df3fa332a9@mozilla.com> <78b13225-e9fa-3b9c-3c41-6bf635248b18@gmail.com> <454192a0-8b60-bff3-2e1a-9f6bcd626337@mozilla.com> <057701d76393$cd635360$6829fa20$@olddog.co.uk> To: Adrian Farrel X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Rfced-future] How to select RSWG chairs (#41) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 20:33:33 -0000 Yes, that seems wise. Russ > On Jun 17, 2021, at 12:14 PM, Adrian Farrel = wrote: >=20 > This works for me, too. >=20 > But... =F0=9F=98=8A >=20 > Do we want to make the appointments expire alternate years to reduce = the chance of a loss in continuity? >=20 > A >=20 > -----Original Message----- > From: Rfced-future On Behalf Of Brian E = Carpenter > Sent: 16 June 2021 21:40 > To: Peter Saint-Andre ; rfced-future@iab.org > Subject: Re: [Rfced-future] How to select RSWG chairs (#41) >=20 > wfm >=20 > Regards > Brian Carpenter >=20 > On 17-Jun-21 08:13, Peter Saint-Andre wrote: >> On 5/20/21 6:05 PM, Brian E Carpenter wrote: >>> On 21-May-21 11:04, Peter Saint-Andre wrote: >>>> There was a bit of discussion in Issue #41 [1] about how to select >>>> chairs for the RSWG. The existing strawman text says: >>>>=20 >>>> "The IETF Chair and the Independent Submissions Editor shall each >>>> appoint and oversee a co-chair of the RSWG." >>>=20 >>> Three comments on that: >>>=20 >>> - Why not say that they *jointly* appoint two co-chairs? >>=20 >> My understanding from previous discussion (see also note from Martin) = is >> that the IESG would appoint one chair and the IAB (no longer the ISE = as >> you mention below) would appoint the other chair. >>=20 >>> - I'm not sure about "oversee". It's a word that has got us into >>> trouble in the past.=20 >>=20 >> I've removed that from the draft. >>=20 >>> - Make the appointments fixed term, please, with no term limits >>> on renewal. >>=20 >> Here's a strawman: >>=20 >> ### >>=20 >> The RSWG shall have two chairs, one appointed by the IESG and the >> other appointed by the IAB. Chairs shall serve for a term of two (2) >> years, with no term limits on renewal. The appointing bodies shall >> determine their own processes for making these appointments, such >> as provision for an open nominations period. Community members who >> have concerns about the performance of an RSWG chair should direct >> their feedback to the relevant appointing body. >>=20 >> ### >>=20 >>>> Lars Eggert suggested that the IAB Chair would be a better option = than >>>> the ISE, since "the IAB has direct or indirect oversight over all = the >>>> non-IETF streams" >>>=20 >>> Probably right. >>>=20 >>> Brian C >>>=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Thu Jun 17 13:58:34 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3A43A2DD4 for ; Thu, 17 Jun 2021 13:58: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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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=mozilla.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 ovywoR3-cLxA for ; Thu, 17 Jun 2021 13:58:29 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 DC3B63A2DD2 for ; Thu, 17 Jun 2021 13:58:28 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id s19so4687355ioc.3 for ; Thu, 17 Jun 2021 13:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=PgS7DWlu2b7IiVWpV5F8HGLL25UA6vhPiG+o76mDsUM=; b=Jz9f4E+hOaxHYuM0wj0ljIUm8x33O5jF2j3OWx0X4TWsR9j+crdAdMl+Bc5lE7cMPk Zk4xHWEhB5E36m7TA2iHAkTw4jgZa1s+Rc9KP6OuZ4BecHNY4Cc8QmzMzmPa37FbbDr0 9MgI/4EptIHuMtjNPWWSEtMzVmBLUfl3wlAno= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PgS7DWlu2b7IiVWpV5F8HGLL25UA6vhPiG+o76mDsUM=; b=PKpZbCvrmukw9UWsVBdHqUPyO4a08EzMaIGdIb2S45MRH1j6zW2Kg+tiFs3afAYMiZ T4Ji6Pn2Zm///ahr8+veHhwCfSxIk5oBePjqg+HsD5WB6Q4Hf+3TAOryE3BLx/S7z0Yy 8LWf3BWWy7PqeavyPbkYZgs7lrvKBPCrHrz2EXwTD5wlqEk6QM91SXdpUw2JKyZX+b4k zWicn1c/O3a7KInaA2no+3LPmvHO6r/MwyVuegJ1D5t07bTzKNzAnC8s3Uqa6a8dKK2L Ks/2E8KteblnF/O8boKLkW71RXVmPlu5/JA8r+NuMorhZ3vSJkPB4oBpQU7o4fWfNBge uTNA== X-Gm-Message-State: AOAM532E7/xiBqRgZqqBg/yEd3FgKMNnv361NDP8Cps3SkeKOQADCo8U 08llX14W70WOECdh9vOPAbp9a6EU9YRTNQ== X-Google-Smtp-Source: ABdhPJy1de4Z9kuuwv6clAHMX5hgdo/rZmzre66v3Fpz7QQocX1YKZiQwTYy+mnlfWE6Xc0dtMLqEg== X-Received: by 2002:a5d:8d16:: with SMTP id p22mr5453828ioj.90.1623963507464; Thu, 17 Jun 2021 13:58:27 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id i1sm3348975iol.16.2021.06.17.13.58.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Jun 2021 13:58:26 -0700 (PDT) To: adrian@olddog.co.uk, rfced-future@iab.org References: <818e6f57-8920-7b1b-3793-34df3fa332a9@mozilla.com> <78b13225-e9fa-3b9c-3c41-6bf635248b18@gmail.com> <454192a0-8b60-bff3-2e1a-9f6bcd626337@mozilla.com> <057701d76393$cd635360$6829fa20$@olddog.co.uk> From: Peter Saint-Andre Message-ID: Date: Thu, 17 Jun 2021 14:58:25 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <057701d76393$cd635360$6829fa20$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] How to select RSWG chairs (#41) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 20:58:33 -0000 On 6/17/21 10:14 AM, Adrian Farrel wrote: > This works for me, too. > > But... 😊 > > Do we want to make the appointments expire alternate years to reduce the chance of a loss in continuity? Yes. The initial terms should probably be 2 and 3 years, then 2 years after that. Peter From nobody Thu Jun 17 14:01:12 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE563A2DEF for ; Thu, 17 Jun 2021 14:01:09 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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=nthpermutation-com.20150623.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 4MB--A6n3v1L for ; Thu, 17 Jun 2021 14:01:07 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 636233A2DEA for ; Thu, 17 Jun 2021 14:01:07 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id t9so5895557qtw.7 for ; Thu, 17 Jun 2021 14:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=rug9eVcMEhjqjMCvs5WpZf6SjaRY/Sn5TN5WQ6sTUYE=; b=fg6PBCOAy/C/y4x447ufGgm44gh9nq3TiqBCJ4u19q2duN+O5WRK2qOAvGhPExPoUk YP6fpJSWibQLgnTRC75nENy1gMA+Ow4TXQ42QaUHtJun/bFBreL8Cw5Y6zOjn0L3HkTZ LLEvrdRZ1FtSneurMdn/nqfvgRTmDB51sPmkT839aegm1gFvmSf1nQyEwdWjHla4QRIz MiwStAqZZ0nrUC6LAdpcVYSahh/7aL9dt/176R1DjFhFg2kCdhSmtOxamzaSQdmr02j/ Y5Yush+Ke5r0vsMiZg6N5KxSlnBydP7XDkA5UceTnj992IyjKb9OYFzGzfy+fHCmcP5/ E6Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=rug9eVcMEhjqjMCvs5WpZf6SjaRY/Sn5TN5WQ6sTUYE=; b=e2DvoTRVh3Ri+DgRxg69HVlvNocaCJPwKMoGSFtHSSq1JuTmDpfVY8Cf/glUXxkMEc w5MsJWrdFEY4WPS+loz9zeYkvEoiTDNYXXjoI0467ZsOGLguQd9Tg07NOi8wmDPzWjqR cvvIxGpHY8uwqailowmjGbgH8d/Fvh9TwyJrWOOyFLgn4vBA7391JxFg/4QhhJ+/fVnB mOEcVsyp2P/mEJFad/i0+Ag3WYPFfOzYtxgoIW3UL7VnGRl/pUVytM7d8lzlNnVAfP2x DGYG8V9raHUIpb0KVjsULLlI4+QXukLzLibKyUJm0Qekgmh7HEl0PiFUUc+PowT5w1bB ouEA== X-Gm-Message-State: AOAM5328I4CERssDRMRxjiMk8AsNgWRzz6Z3gzwkjqP8MTKneC9dx2ON OyPyRwzpAPf+ItJzhEJ0O6cYv/KNkfp4o76k X-Google-Smtp-Source: ABdhPJwrtHN4bIduZfs6PhLonqJLV0ustkTRTn9ssv2T+SZFUs30+NSY14yu+93dTM/ltZqY3z8IIw== X-Received: by 2002:ac8:7753:: with SMTP id g19mr7192862qtu.336.1623963664884; Thu, 17 Jun 2021 14:01:04 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id i11sm1459076qke.74.2021.06.17.14.01.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Jun 2021 14:01:04 -0700 (PDT) To: rfced-future@iab.org References: <818e6f57-8920-7b1b-3793-34df3fa332a9@mozilla.com> <78b13225-e9fa-3b9c-3c41-6bf635248b18@gmail.com> <454192a0-8b60-bff3-2e1a-9f6bcd626337@mozilla.com> <057701d76393$cd635360$6829fa20$@olddog.co.uk> From: Michael StJohns Message-ID: <3548bf8b-2ca7-0b10-2968-1201b1521e13@nthpermutation.com> Date: Thu, 17 Jun 2021 17:01:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] How to select RSWG chairs (#41) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 21:01:10 -0000 On 6/17/2021 4:58 PM, Peter Saint-Andre wrote: > On 6/17/21 10:14 AM, Adrian Farrel wrote: >> This works for me, too. >> >> But... 😊 >> >> Do we want to make the appointments expire alternate years to reduce the chance of a loss in continuity? > Yes. The initial terms should probably be 2 and 3 years, then 2 years > after that. > > Peter > And on that note - who gets to remove the chairs? Mike From nobody Thu Jun 17 14:03:14 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CC43A2DFC for ; Thu, 17 Jun 2021 14:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=mozilla.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 fhEJGQlg_Kj0 for ; Thu, 17 Jun 2021 14:03:09 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 2FFEC3A2DFA for ; Thu, 17 Jun 2021 14:03:09 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id b14so6609722ilq.7 for ; Thu, 17 Jun 2021 14:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=PIyVQtINJBaqn3XXCrbSF3tTr8gboX41FwExsDV/TZI=; b=OiKjYXINAe12kfG/0b1gLzHGUvlI6DlGfUJMZ/3al3W3nDlTTJUk4SnTQRkkQAHia3 MeChluORFg3sACtVumPsV4bU9dnc039EXh+dvXTqq4asYYtGtJ/QNmcGKIOaMee6damr dRGYMjWnkCBXIsIfd89czKNM5EPAWDti+9YNk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PIyVQtINJBaqn3XXCrbSF3tTr8gboX41FwExsDV/TZI=; b=qbGuIJueHfsPoc04pRm3hb+8efMB66RT0NsOX8YfHeIJU/pglHPtwfJzsJ+7a0eY0Y OoX7MCsv7B8J/RoNZ1SznTGXUrrVc6+umwx/KZoTvwvGduupUKu9JTIyOgqLDqP+a32m LHSAxJS2l3SyucFeuW7E1hjewevDgM0Z9dmj0n6jtxWgEMeFIeupq2nBfD5vRFhbcxKR 6sDBUiwoI/4MX0xsOJ5UVB9+YB2eV3UMjb0sYdli6bqvKnXoENlhrvWSiBN9Ko1LHi4g bbtGWrY690iFfUK3xtQ7Wm6IcAChBpMjk+ErTKAu+Ma5mNd8k1rE+nmEy17DdE1LHCL/ wltA== X-Gm-Message-State: AOAM530AU+hHa8Mu5TTP1s6vLbiFaXV2Ft2hWdg0u63l/Rb6gvWDYlh6 jjB2nKbw32Oi+rebSxF/v1WrdA== X-Google-Smtp-Source: ABdhPJy0cLFR028AHetu3m6+1gg7Xs2+bNwabFx0TjrxzVg0wfwtgqVUwwr7nBRxpfAORy4w6x+fNQ== X-Received: by 2002:a05:6e02:b25:: with SMTP id e5mr4794716ilu.131.1623963787644; Thu, 17 Jun 2021 14:03:07 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id o7sm81092ilt.1.2021.06.17.14.03.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Jun 2021 14:03:06 -0700 (PDT) To: Michael StJohns , rfced-future@iab.org References: <818e6f57-8920-7b1b-3793-34df3fa332a9@mozilla.com> <78b13225-e9fa-3b9c-3c41-6bf635248b18@gmail.com> <454192a0-8b60-bff3-2e1a-9f6bcd626337@mozilla.com> <057701d76393$cd635360$6829fa20$@olddog.co.uk> <3548bf8b-2ca7-0b10-2968-1201b1521e13@nthpermutation.com> From: Peter Saint-Andre Message-ID: <0a3a94ff-2e7e-b134-d4b1-7e27277cd139@mozilla.com> Date: Thu, 17 Jun 2021 15:03:05 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <3548bf8b-2ca7-0b10-2968-1201b1521e13@nthpermutation.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] How to select RSWG chairs (#41) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 21:03:13 -0000 On 6/17/21 3:01 PM, Michael StJohns wrote: > On 6/17/2021 4:58 PM, Peter Saint-Andre wrote: >> On 6/17/21 10:14 AM, Adrian Farrel wrote: >>> This works for me, too. >>> >>> But... 😊 >>> >>> Do we want to make the appointments expire alternate years to reduce >>> the chance of a loss in continuity? >> Yes. The initial terms should probably be 2 and 3 years, then 2 years >> after that. >> >> Peter >> > And on that note - who gets to remove the chairs? Presumably those with the power to appoint have the power to remove, but we should specify that, too. Peter From nobody Mon Jun 21 06:54:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF313A1040 for ; Mon, 21 Jun 2021 06:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 L--DJwzpF6ZU for ; Mon, 21 Jun 2021 06:54:47 -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 47CFE3A103F for ; Mon, 21 Jun 2021 06:54:46 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::2] ([IPv6:2001:420:c0c0:1011:0:0:0:2]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15LDsiHc408157 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Mon, 21 Jun 2021 15:54:45 +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=1624283685; bh=vbcOwKBJmFnTRoX01c1v45FKS9RzCifHk/vvGRPCtQw=; h=To:From:Subject:Date:From; b=FodNi1lKzU+q8x+w+l16mzYL5uKkw0oNbvt8Q6Ovx/FjWQcZgHDa0q4VGVylRLP1M z2jUFmhWartlYyCmLZKqOqeYxRbMWmqqvQbtA7TO2Ov4LemXCCxAK/YQ8/mlGFOoSR qg/KNQQkn0CtK91K2IdWp/29pC1w6y//sAnMteaA= To: rfced-future@iab.org From: Eliot Lear Message-ID: Date: Mon, 21 Jun 2021 15:54:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pp78Qq8Sj9vPEt41xSFVwanX9hnNMj2x4" Archived-At: Subject: [Rfced-future] draft-saintandre-rfced-model-01.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 13:54:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pp78Qq8Sj9vPEt41xSFVwanX9hnNMj2x4 Content-Type: multipart/mixed; boundary="Jz9CNz0D6lsvkW01uRDR61Xki4OwQVpaI"; protected-headers="v1" From: Eliot Lear To: rfced-future@iab.org Message-ID: Subject: draft-saintandre-rfced-model-01.txt --Jz9CNz0D6lsvkW01uRDR61Xki4OwQVpaI Content-Type: multipart/alternative; boundary="------------4048EA21964408E3304FC560" Content-Language: en-US This is a multi-part message in MIME format. --------------4048EA21964408E3304FC560 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Everyone, Please have a good look at Peter=E2=80=99s and*your*latest work before to= day=E2=80=99s=20 call. =C2=A0We=E2=80=99ve come a long way. =C2=A0Now we still have a ways= to go, but a=20 fresh read of this draft will help us keep moving. https://datatracker.ietf.org/doc/draft-saintandre-rfced-model/ Eliot --------------4048EA21964408E3304FC560 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Everyone,

Please have a good look at Peter=E2=80=99s and=C2=A0your=C2=A0latest work before today=E2=80=99s call. =C2=A0We=E2=80=99ve come a long w= ay. =C2=A0Now we still have a ways to go, but a fresh read of this draft will help us keep moving.

https://datatracker.ietf.org/doc/draft-saintandre-= rfced-model/

Eliot
= --------------4048EA21964408E3304FC560-- --Jz9CNz0D6lsvkW01uRDR61Xki4OwQVpaI-- --pp78Qq8Sj9vPEt41xSFVwanX9hnNMj2x4 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDQmiAFAwAAAAAACgkQh7ZrRtnSejOd nwgAoU4SOhoFyD96HKPicouKYGMN/NsQ2edtDolCRIiN8/zbe/WK6TGKXZHMDtKNA1BfccP3lrTI zxoHD5oC/d4HsOE7PI2K9fCzfQ8sBFDOYtUNPOgVwxdtdZzVn60p15ugpX89sqz0TizCGEYkFS3v QgA/IoAWUH28eeOuzJqLWG6dJ5gDAcAbILDotXjKOEj7Vk9Gl5k2fVMiS8W5yAeLgViz2DDv9hMP aRxZrpVJTbhhZzPmQKyHzoVNnNMvV3wAEUZaJnFNjiJHDb5l6wF0i2XD+j1sHHvlGUeGm28VHtR1 iubhoVTgwYBP/xKRJ9dfgTa1doqQRBS3/WHNpKaHVA== =i9Ti -----END PGP SIGNATURE----- --pp78Qq8Sj9vPEt41xSFVwanX9hnNMj2x4-- From nobody Mon Jun 21 12:01:25 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBAC3A164C for ; Mon, 21 Jun 2021 12:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.19 X-Spam-Level: X-Spam-Status: No, score=-0.19 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 gOQqAsRKotk0 for ; Mon, 21 Jun 2021 12:01:10 -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 D41423A16BF for ; Mon, 21 Jun 2021 12:01:03 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::4] ([IPv6:2001:420:c0c0:1011:0:0:0:4]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15LJ103L412024 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Mon, 21 Jun 2021 21:01:01 +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=1624302061; bh=qkD5XMiS8AFuKAjhvvx3qQm0H4cTE+lesQ58prnioLw=; h=To:From:Subject:Date:From; b=gYUivJPMliUBBkJ+4NzxqNjVef+E9qqMgKClzVabqTTxtxICPW4XxfH/84cWQx/nB Vh5sacfy+mzuvJiTIYxPKrp9ukkQoeiODhM7AUikJUdGxOdZfKXayBE6xmjaljVCtV 94Wk+CuU0ih8Ik4Bey3KoT7asWGdzfHOt8WNzhKc= To: rfced-future@iab.org From: Eliot Lear Message-ID: <74756351-b49c-f1bd-280a-00517721aa94@lear.ch> Date: Mon, 21 Jun 2021 21:00:59 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yjYWpzNigykwyJAl0nzuzhIRIksvONbnE" Archived-At: Subject: [Rfced-future] today's meeting X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 19:01:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --yjYWpzNigykwyJAl0nzuzhIRIksvONbnE Content-Type: multipart/mixed; boundary="fWfAKp7jmIEPrr1TA6JSezgA2xAj2pjif"; protected-headers="v1" From: Eliot Lear To: rfced-future@iab.org Message-ID: <74756351-b49c-f1bd-280a-00517721aa94@lear.ch> Subject: today's meeting --fWfAKp7jmIEPrr1TA6JSezgA2xAj2pjif Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Slides are uploaded for discussion. --fWfAKp7jmIEPrr1TA6JSezgA2xAj2pjif-- --yjYWpzNigykwyJAl0nzuzhIRIksvONbnE Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDQ4esFAwAAAAAACgkQh7ZrRtnSejN3 6AgAhMi8LT//CfTUL61bq1sT1mMCUY8VtI9QAH+Kd5v/5UbvBNxfkdkbnNBeDsv1MYK3k7P6A/O5 JsM3rgXMYcLhoFks0XKhs001A5KL1kmu/RyEOxTmYw2MuvGRqR/WIuPns6Scqw1abuGXMTIdO/jX UoMcqrCuv0OKtmMViCXdSEeis86LHoOlAyncW5UFKjVB75f5MvM7GRB7fmdY3IOSWd7eGaPpJOLr wD7Ivh0GPHlUPJNypoQM7qlkjFHpi2feSpLRPc5NIXcN+HrT98tOUhymvg5VYfwQfKK9J59rjBzF 5VHNcTAwL87BTgiIzbh3a8jA6tDM/jbLASbed3Xzlg== =fLdj -----END PGP SIGNATURE----- --yjYWpzNigykwyJAl0nzuzhIRIksvONbnE-- From nobody Mon Jun 21 12:02:58 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E7F3A15F2 for ; Mon, 21 Jun 2021 12:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.335 X-Spam-Level: X-Spam-Status: No, score=-0.335 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, 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=nthpermutation-com.20150623.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 9RvGAKf5QOaf for ; Mon, 21 Jun 2021 12:02:54 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 7CA323A15F1 for ; Mon, 21 Jun 2021 12:02:54 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id g142so33155304qke.4 for ; Mon, 21 Jun 2021 12:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=xNpCyAX1I1cTv/qV5hAJDRj3oa26FzOw4Q1i0Dot2r8=; b=vqa3jmHbVi8+I6qrkOZCrMSxaXcVKsZ/IcGxxSEmaQ5bp4t1/cA08kiccSuV2u2KrI jpMA1fMVcg8wTDyEP36GSskkzsPlo/r7zN8INo9qZW/RHy6AIhKw87lG99MSC7ITxmQT dKT1WCHEh+lpuEl649MjfXsW952VNX82wIqbgjx2MnP9pCxFtJs3/BDBLa2qhjy31MAj Bt8G5Hvzfy8b0Ed5sAEK6VMmd9sYzAQsjtT35llMUuhqCbkJHUZt9HoNeRpBAD0MepiF 5uKFcsewcHlNte9IPpeGKyG7STpyDeQIzmdwTrKc04En4Q95+Vs2b3Sv8XWK3MYtnOHA p5lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=xNpCyAX1I1cTv/qV5hAJDRj3oa26FzOw4Q1i0Dot2r8=; b=S1IDk3xAjIgV/J8M9w+IujhtQ4dqaNHQkFmqN0mtOMaa578Wg3/SLC40onHVGZeJcb od2bshUG5CpNbYPiiORxaEevH06rlM3owQk2IULKjEzzMxsyU/FRB4r0CbvQKEyaOau8 u2uGIPfXmmSOYCMvi/CTV00+jsINWDLrKIUnPQCj34/CR6nptdcckNoYkfBjbOvQ9ZKe n/flArUCPE8b+xxaPoHma0VwvAxImVUHGZJnyrPWkxWIrB0aKN/ki4wDZhSd1/pV/pkc mUqQEFYIj1TyQ+p1RpsLewmX8NUz/I3c07qr8FlSQ/kDVPjQpDPgznJi3sGrDhoVSXZq KPxA== X-Gm-Message-State: AOAM533afuoJkW2N2iTA57t07xHyzwxiYSfLrGmpUwjagKRxUGhrZhhv eaFcBGYl6f3KbWEstWMXwGYCiAwJWXj2s1zp X-Google-Smtp-Source: ABdhPJyMPluiW7G67HhpoOOf2I9+cgslsSMQy7A3ZKQ4P/Rov66TETpniehb5OaSKqW2lpjxvdnVJw== X-Received: by 2002:a37:5c43:: with SMTP id q64mr104538qkb.117.1624302172072; Mon, 21 Jun 2021 12:02:52 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id k1sm10280058qtm.49.2021.06.21.12.02.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Jun 2021 12:02:51 -0700 (PDT) To: rfced-future@iab.org References: <74756351-b49c-f1bd-280a-00517721aa94@lear.ch> From: Michael StJohns Message-ID: <624bae78-5618-b33b-9659-d21035b8cca3@nthpermutation.com> Date: Mon, 21 Jun 2021 15:02:50 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <74756351-b49c-f1bd-280a-00517721aa94@lear.ch> Content-Type: multipart/alternative; boundary="------------D1B2362445AD810A8D30AF50" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] today's meeting X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 19:02:58 -0000 This is a multi-part message in MIME format. --------------D1B2362445AD810A8D30AF50 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 6/21/2021 3:00 PM, Eliot Lear wrote: > Slides are uploaded for discussion. > > > Link for slides and for the meeting please? --------------D1B2362445AD810A8D30AF50 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 6/21/2021 3:00 PM, Eliot Lear wrote:
Slides are uploaded for discussion.



Link for slides and for the meeting please?


--------------D1B2362445AD810A8D30AF50-- From nobody Mon Jun 21 12:03:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9E63A1602 for ; Mon, 21 Jun 2021 12:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=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 d6m-4LSEsacD for ; Mon, 21 Jun 2021 12:03:47 -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 8F42E3A15FC for ; Mon, 21 Jun 2021 12:03:47 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 15LIsrKW011688; Mon, 21 Jun 2021 20:03:42 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Xj7zvyz1fBv2rk9MpRuHLuRA7IdHQCu3/7Vf9PJSIRs=; b=pBwOi+e0fK/v7kfD+ypGfSnBccL8pXJDPgsOggRe9sIerAyOCXB2IqHF2Ai0ITpcvjxn bKwIbNH7yh6RZKUXRODx96067H58XwXQHulVVBt2TNE96MCFnvUn+ikEK3TH7wlzHknC pv6YOq3em74CQdIIPAuRgO0Ww7LnwD2/tBZ0VP++IlWYz/ddpcnRX+osnNXqK25FzsIQ 4oc4kpAM1E4xg5mH/l3uSaNuqIheFkZuc42wQGSZZQQywikyPpiH1WLr1FxrjNgEslDL SeSijUoqyIneZwYyrzysMupwt4Dmwefj1ARSH9YSvFPOup7zsGlgIsYV0RsS3Pxe5cB4 fw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 39ay8a2ntc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Jun 2021 20:03:41 +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 15LInOM0024249; Mon, 21 Jun 2021 15:03:40 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint1.akamai.com with ESMTP id 399bwy6ss8-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 21 Jun 2021 15:03:40 -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.18; Mon, 21 Jun 2021 15:03:38 -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.018; Mon, 21 Jun 2021 15:03:37 -0400 From: "Salz, Rich" To: Eliot Lear , "rfced-future@iab.org" Thread-Topic: [Rfced-future] today's meeting Thread-Index: AQHXZs/zxNDramc/tkSLJiWEZZwawqse0qeA Date: Mon, 21 Jun 2021 19:03:36 +0000 Message-ID: <62BAE288-A473-414C-B715-5FD19FD54A62@akamai.com> References: <74756351-b49c-f1bd-280a-00517721aa94@lear.ch> In-Reply-To: <74756351-b49c-f1bd-280a-00517721aa94@lear.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.50.21060600 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.118.139] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-21_10:2021-06-21, 2021-06-21 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 malwarescore=0 phishscore=0 adultscore=0 mlxlogscore=814 suspectscore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106210110 X-Proofpoint-GUID: Y8X_U2J5oZ1mzqZ0bhm_oJ12fkt3qLBs X-Proofpoint-ORIG-GUID: Y8X_U2J5oZ1mzqZ0bhm_oJ12fkt3qLBs X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-21_11:2021-06-21, 2021-06-21 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 mlxscore=0 mlxlogscore=762 impostorscore=0 suspectscore=0 priorityscore=1501 malwarescore=0 phishscore=0 spamscore=0 lowpriorityscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106210111 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.18) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint1 Archived-At: Subject: Re: [Rfced-future] today's meeting X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 19:03:52 -0000 SSdsbCBtaXNzIHRvZGF5J3Mgc2Vzc2lvbiwgc29ycnkuDQoNCu+7v09uIDYvMjEvMjEsIDM6MDIg UE0sICJFbGlvdCBMZWFyIiA8bGVhckBsZWFyLmNoPiB3cm90ZToNCg0KICAgIFNsaWRlcyBhcmUg dXBsb2FkZWQgZm9yIGRpc2N1c3Npb24uDQoNCg0KDQo= From nobody Mon Jun 21 12:08:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9783A1610 for ; Mon, 21 Jun 2021 12:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 14coy8BilGgS for ; Mon, 21 Jun 2021 12:08:48 -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 112B83A1619 for ; Mon, 21 Jun 2021 12:08:48 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lvPHq-000PRD-9V; Mon, 21 Jun 2021 15:08:46 -0400 Date: Mon, 21 Jun 2021 15:08:39 -0400 From: John C Klensin To: Eliot Lear cc: rfced-future@iab.org Message-ID: <9CCFECFF41DD399EA4AB89BE@PSB> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: [Rfced-future] A voice from the (perhaps lunatic) fringe (was: draft-saintandre-rfced-model-01.txt) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 19:08:53 -0000 --On Monday, June 21, 2021 15:54 +0200 Eliot Lear wrote: > Everyone, >=20 > Please have a good look at Peter's and*your*latest work > before today's call. =C2=A0We've come a long way. =C2=A0Now we > still have a ways to go, but a fresh read of this draft will > help us keep moving. >=20 > https://datatracker.ietf.org/doc/draft-saintandre-rfced-model/ I'm quite sure that I'm far out in the rough part of "rough consensus" but. after studying Peter's latest draft (which I think is excellent given the discussions) and the on-list discussions of the last few weeks, I think we are, very fundamentally, headed in the wrong direction with significant philosophical problems in what we are proposing and doing. I would be surprised if this note changes the minds of anyone reading it and would even be surprised if most of the group bothers to read it at all. However, because I see dangers in the direction in which things are headed, I'm feeling a need to try to summarize a perspective and set of positions that have been raised before and largely ignored. If I were right, most of the discussions of recent months are not analogous to rearranging the deck chairs on the Titanic; they are about forming committees to develop policy for such rearrangements, other committees to review and validate the work of the first committee, and mechanisms for reviewing that process. Glug, glug,... Core issue #1: The function of the RFC Editor Function. The RFC Series predates the IETF by many years. Even though it became the primary venue for publishing IETF work and we have made adjustments along the line, neither RFC 5620 nor 6335/8728 fundamentally changed that model. However, from Jon and Joyce through at least most of Heather's tenure, decisions have been made informally and depending on the assumption that everyone involved is an adult with shared goals about good quality documents and a better Internet (and ARPANET before it). It worked well almost all of the time; when it didn't, things got sorted out on, more or less, a Do The Right Thing principle. We are now trying to make rules and structures to cover every possible case. That has rarely worked well, if only because it encourage little disagreements to turn into large, formal, decision-making processes. In addition, the IETF part of the puzzle is changing. RFCs may still be the formal publication of record, but far more, including documentation of rather fundamental policy decisions, is being done by blogs, statements, datatracker entries, etc. That may be fine, but it may suggest that some clear redrawing of boundaries is important ... and this effort is not addressing those issues. Core issue #2: The question of expertise. While Heather was the first person to be in charge of the Series who came out of a professional publications background, all of her predecessors understood what they didn't know and were good (some better than others, of course) at asking questions, understanding, learning, and thinking through the answers, and then making decisions using that advice and being willing to be accountable for it. The new approach is modeled on IETF WGs, but ignores a fundamental assumption built into the WG model: that a large majority of the participants in a WG will have significant expertise in the subject matter. While I hope we are evolving better ways to deliver the message, when people have spoken up in WGs who have no ideas what they are talking about and are persistent about it, WGs usually have ways to deal with that behavior. By contrast, most people who have participated actively in the IETF for any length of time have probably noticed that the issues that call forth the most passion and the longest threads on the IETF list and elsewhere are those about which people have little expertise but strong opinions of one type or another. What I'm about to say may smack of elitism, putting me further into the rough, but I note that we do not think highly of, e.g., politicians trying to design network architectures and protocols. If our goal is to create structures that turn the RFC Series into something the fraction of the IETF community who are willing and able to invest large amounts of time on these things want (perhaps at the expense of doing Internet technical work), then I think we are right on track. But, noting that subset of the IETF community is almost certainly not representative of IETF participants generally much less the broader Internet community, that is a very significant change in objectives. If we are going to do that, we should be explicit about it. If we are not, the idea of open participation to anyone who wants to be involved and has the time, with no expectations about expertise falls into the "be careful what you wish for" category. (3) Core issue #3: What is a standard and what is a stable document? While, ideally, it should not be a required part of this discussion, it appears to me that there is an ongoing difference of opinion in the IETF was to whether standards (and perhaps IETF Stream documents in general) should be stable specifications that may periodically be revised or replaced but are otherwise threaded together with "updates" and "obsoletes" designations (possibly supplemented by organizing documents along the lines proposed by NEWTRK) or whether we want to move more toward living documents that are updated in place with each correction, changes of experience, or change in community opinion about one or more points. If we are going to move more in the latter direction, it could have a profound effect on the RFC Series, either because IETF Standards and other normative specifications come out of the Series, dramatically changing the mix of documents, or because the system has to adjust to a completely different type of documents for which, e.g., the current production model might not be correct for at least a subset. While a lighter-weight structure might have more ability to adapt to such changes, the current effort to specify details and create an elaborate discussion and approval process seems less likely to do so, especially if the RSWG/RSAB structure ends up not completely agreeing with, e.g., the IESG. The solution is presumably obvious: Convene another Program or WG to more or less start over. Unfortunately, we are pushing toward two years of limited functionality since the actions that apparently convinced Heather that she didn't want more of whatever was going on. I think that has been very damaging and that a repeat would be more so. Others probably disagree but I would ask them whether, if we can go two or more years without an RSEA or any of the structure now proposed, should we be trying to see what we can learn from that and devise something much lighter weight on the basis of the experience? (4) Core issue #4: What got us here and are we fixing it? The chain of events that led to this Program/Group could be seen either as an assertion of power by some bodies over the RSE (aka "the RSE is 'just' a contractor") or an asser5ion of authority by groups who lacked substantive expertise (see (2) above), neither with any transparency as far as the broader community was concerned. It seems to me that the new model probably fixes the transparency problem, but does so partially by increasing the number of non-expert people and organizational structures with an ability to meddle and/or interfere with keeping a clear focus on consistent objectives. Is that a solution? For those who think it is, consider how you would feel if you took a network engineering job, discovered that you were managed by a committee or two, none of whose members understood your job or your areas of expertise, and whose objectives might shift over time (either because of changing membership or to convince themselves or others that they were being useful). I have a longer list, but it is probably better that I keep this rant (comparatively) short and get it out. Do I have alternate suggestions? Yes, but they depend on changes in the decisions about the issues identified above even, or especially, when those decisions were made implicitly or because we started erecting structures without really addressing them in a way that made those decisions moot. Grumpily and from, probably, far out in the rough, john From nobody Mon Jun 21 12:41:05 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847123A1885 for ; Mon, 21 Jun 2021 12:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_SPACE_RATIO=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=isi-edu.20150623.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 vBjrvn5rfOGK for ; Mon, 21 Jun 2021 12:40:59 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 061B53A1883 for ; Mon, 21 Jun 2021 12:40:58 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id v5-20020a0568301bc5b029045c06b14f83so2379893ota.13 for ; Mon, 21 Jun 2021 12:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isi-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nGWDN0bvCOl6EIYhrd9q9SGkrEVKdx6m1ozMED2sfvU=; b=GRPuATlKw/FZvRha5V9h/J3MZiHsLuMFXTdBFf5jqpuwEq8d0XyeaV1RX5lh1SCiYH UMoRB4euj3HdC5C645nBUIF5s7iTme7UVvjRg9+SO5eh0u5R/MUSQDpRoRFr5v7qZG2k 2sK3seGA5YwZkrtSm3hx+8tKqhD4/wt6VGoHaeUckRdDdFrEoFF7o5lhWIGDjvAw7sSO t3UXtMOX8Zj88QfdmGjtiIRiZULXtmjGu3KRihX8800YfRkI3+ljH8eRKPdwWW4p2CWv RXPpB/0CckE0n09H6/DAxnPWAEa+kZYonb53u4j9QYWjKn3eztI+iAB5ZtcLRJWEfy5G iMqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nGWDN0bvCOl6EIYhrd9q9SGkrEVKdx6m1ozMED2sfvU=; b=PMRAJTBcd0vnGcJ17cciAMbxqvZioEtEY7T8TTWG7FRi0MZx2suEuTmzKbF7Or0hsm 5gjgEH1yzst123LY/ubgVtYPYtF2zw64HzWfCPhqFOGpCPcB8wyAhdovJ3tBXWXOTPqN AB3j60DMYfhjCSOkEJh0pwxLzkkDIMgQw4tFgIHvjM4O4hruVC89fv/TNdIpl8/PbAyj mhGZif2SYjL/JTIEXnUq7LWcmdZqFkZcB77ayFgClbx0ZOh17vaEClmtDN4PptV3r4CV maXyS00esco7ZkvRVw9UpRH6lcR5MtJpI+zE19H/fJXVtYpYxIymgmz/eJeQRUQrkyoW Q/7A== X-Gm-Message-State: AOAM530UZv8gpvO2yDpdgeg8TGr2rJVDWSytcvofvZxGMwzrhISfPBUS ISMNQcQix/4gCzUc8ras2ou9aDZ3CGhqqi6go3Jy3w== X-Google-Smtp-Source: ABdhPJxZmYCJ3wd6Fb68oFdIolBwSDaW8HfdvKWnxs+rVXuWJ831wlWkOynR/RsXAJPIiWJnBTv5gPQ8NCr8q+svtoE= X-Received: by 2002:a9d:67cb:: with SMTP id c11mr54130otn.321.1624304457602; Mon, 21 Jun 2021 12:40:57 -0700 (PDT) MIME-Version: 1.0 References: <74756351-b49c-f1bd-280a-00517721aa94@lear.ch> <624bae78-5618-b33b-9659-d21035b8cca3@nthpermutation.com> In-Reply-To: <624bae78-5618-b33b-9659-d21035b8cca3@nthpermutation.com> From: Wes Hardaker Date: Mon, 21 Jun 2021 12:40:21 -0700 Message-ID: To: Michael StJohns Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000033eae705c54bdaa7" Archived-At: Subject: Re: [Rfced-future] today's meeting X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 19:41:04 -0000 --00000000000033eae705c54bdaa7 Content-Type: text/plain; charset="UTF-8" https://datatracker.ietf.org/meeting/interim-2021-rfcefdp-05/session/rfcefdp --00000000000033eae705c54bdaa7 Content-Type: text/html; charset="UTF-8" --00000000000033eae705c54bdaa7-- From nobody Mon Jun 21 13:28:22 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DDB3A1806 for ; Mon, 21 Jun 2021 13:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[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.338, 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 aQ4cZm36s6Kt for ; Mon, 21 Jun 2021 13:28:16 -0700 (PDT) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 4B7D13A1804 for ; Mon, 21 Jun 2021 13:28:16 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id l11so6330481pji.5 for ; Mon, 21 Jun 2021 13:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zeFSpMxGQ4gXh+pG+5XgBFEWWTOeALH4nP64ZfbicDk=; b=VdKOHA+Odvz6RmW7Y/QZ5OyplCwNLdo/3lQ/Sn8XYI2uFc4+DfAa/Irdchr2ZCDPI3 5aLiabFRnW5Vj1/L+XPkLKjhlAFgamnFe8Jb2+ukI8GRUqSXB1ograoJcmPgZJSFDiT5 Fyo4PQ816SVP6dWziQhBjdCm6bNj9V/Qxd0ryBFLw3HO3CoY5lPgWEnr0PD+8urxO8Sn mbKtCPgaWIyLNr/rrIBUpHnHai4nmYLIx7f2xoY02a8S4G0V3D80W8jRdIc/BgMakLy7 2Eft4SDIC16TZquRZXyp6y71bMIbRG7DYc2k4njT/rcayI3DqJ8f/6u8GRxXJjf5i0pv GenQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=zeFSpMxGQ4gXh+pG+5XgBFEWWTOeALH4nP64ZfbicDk=; b=My+3Mkp9IyCeYrlDNT/8r2kvg/ysBgljAVYp3tWPJzkvp/4h9rNA2c9l0PWv931C4s 2PM4AI/C/eCt+377nCqVBTmdg4keVq2FTFW8v2EnLCklUiNaX18BR7dosGtzkPwzmRaq 4YvRl6wdtILs1ZUQlbkW0lD3pRyMpnZX3yjHZ+SMq7c23Oqgnf+obV37RQn4SumJmHEn 5Y+eMrcqOsAOcWhj5Mx/ugibeWzkPvC2icJoC505UOw+dGZmaS+ZRAZbB0W+ZJRSbGy2 50Lg2EjfqQAEaJa3jx+Exh57+KjNp4eg1OOnJB2oCFXkLJupK1rykdDuUI+IfVsT7wqm aP1w== X-Gm-Message-State: AOAM532KBmIMpANmr0hvmJ+KpOVgHWJSIzkiRZ8b3roPuigwmJuTmki2 dDUGs2ayJsXw46BLlJqpCn6dyqD3h7DzoA== X-Google-Smtp-Source: ABdhPJzit8eji85OXAKrQm1qZYF5VnIZGDSY7+ieW41+a0tI58XJBcrqQ8HN3O3JKIvkRhl/nvboEg== X-Received: by 2002:a17:902:ed55:b029:123:d5ab:b38b with SMTP id y21-20020a170902ed55b0290123d5abb38bmr9560067plb.71.1624307293824; Mon, 21 Jun 2021 13:28:13 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id a23sm6929861pfk.146.2021.06.21.13.28.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Jun 2021 13:28:13 -0700 (PDT) To: John C Klensin , Eliot Lear Cc: rfced-future@iab.org References: <9CCFECFF41DD399EA4AB89BE@PSB> From: Brian E Carpenter Message-ID: <511219a5-e451-3071-6f77-dac6d005192b@gmail.com> Date: Tue, 22 Jun 2021 08:28:09 +1200 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: <9CCFECFF41DD399EA4AB89BE@PSB> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] A voice from the (perhaps lunatic) fringe (was: draft-saintandre-rfced-model-01.txt) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 20:28:21 -0000 John, I will respond later in more detail (e.g. when I'm no longer trying to attend to the Webex meeting), but I'd like to say one thing now: > (3) Core issue #3: What is a standard and what is a stable > document? While, ideally, it should not be a required part of > this discussion, it appears to me that there is an ongoing > difference of opinion in the IETF was to whether standards (and > perhaps IETF Stream documents in general) should be stable > specifications that may periodically be revised or replaced but > are otherwise threaded together with "updates" and "obsoletes" > designations (possibly supplemented by organizing documents > along the lines proposed by NEWTRK) or whether we want to move > more toward living documents Yes. And as you know better than anyone, this goes back 20 years, and the bulk of the IETF and/or IESG has never wanted to engage. So IMNITLHO**, we (rfced-future) need to set that concern aside for the purposes of this discussion, and they (the IETF) need to put their own house in order. If the IETF comes back with clearly defined requirements for a new kind of document, that may or may not be a job for the RFC series. Brian Carpenter ** in my not in the least humble opinion On 22-Jun-21 07:08, John C Klensin wrote: >=20 >=20 > --On Monday, June 21, 2021 15:54 +0200 Eliot Lear > wrote: >=20 >> Everyone, >> >> Please have a good look at Peter's and*your*latest work >> before today's call. =C2=A0We've come a long way. =C2=A0Now we >> still have a ways to go, but a fresh read of this draft will >> help us keep moving. >> >> https://datatracker.ietf.org/doc/draft-saintandre-rfced-model/ >=20 > I'm quite sure that I'm far out in the rough part of "rough > consensus" but. after studying Peter's latest draft (which I > think is excellent given the discussions) and the on-list > discussions of the last few weeks, I think we are, very > fundamentally, headed in the wrong direction with significant > philosophical problems in what we are proposing and doing. I > would be surprised if this note changes the minds of anyone > reading it and would even be surprised if most of the group > bothers to read it at all. However, because I see dangers in > the direction in which things are headed, I'm feeling a need to > try to summarize a perspective and set of positions that have > been raised before and largely ignored. If I were right, most > of the discussions of recent months are not analogous to > rearranging the deck chairs on the Titanic; they are about > forming committees to develop policy for such rearrangements, > other committees to review and validate the work of the first > committee, and mechanisms for reviewing that process. Glug, > glug,... >=20 > Core issue #1: The function of the RFC Editor Function. The > RFC Series predates the IETF by many years. Even though it > became the primary venue for publishing IETF work and we have > made adjustments along the line, neither RFC 5620 nor 6335/8728 > fundamentally changed that model. However, from Jon and Joyce > through at least most of Heather's tenure, decisions have been > made informally and depending on the assumption that everyone > involved is an adult with shared goals about good quality > documents and a better Internet (and ARPANET before it). It > worked well almost all of the time; when it didn't, things got > sorted out on, more or less, a Do The Right Thing principle. We > are now trying to make rules and structures to cover every > possible case. That has rarely worked well, if only because it > encourage little disagreements to turn into large, formal, > decision-making processes. In addition, the IETF part of the > puzzle is changing. RFCs may still be the formal publication of > record, but far more, including documentation of rather > fundamental policy decisions, is being done by blogs, > statements, datatracker entries, etc. That may be fine, but it > may suggest that some clear redrawing of boundaries is important > ... and this effort is not addressing those issues. >=20 > Core issue #2: The question of expertise. While Heather was the > first person to be in charge of the Series who came out of a > professional publications background, all of her predecessors > understood what they didn't know and were good (some better than > others, of course) at asking questions, understanding, learning, > and thinking through the answers, and then making decisions > using that advice and being willing to be accountable for it. > The new approach is modeled on IETF WGs, but ignores a > fundamental assumption built into the WG model: that a large > majority of the participants in a WG will have significant > expertise in the subject matter. While I hope we are evolving > better ways to deliver the message, when people have spoken up > in WGs who have no ideas what they are talking about and are > persistent about it, WGs usually have ways to deal with that > behavior. By contrast, most people who have participated > actively in the IETF for any length of time have probably > noticed that the issues that call forth the most passion and the > longest threads on the IETF list and elsewhere are those about > which people have little expertise but strong opinions of one > type or another. What I'm about to say may smack of elitism, > putting me further into the rough, but I note that we do not > think highly of, e.g., politicians trying to design network > architectures and protocols. If our goal is to create > structures that turn the RFC Series into something the fraction > of the IETF community who are willing and able to invest large > amounts of time on these things want (perhaps at the expense of > doing Internet technical work), then I think we are right on > track. But, noting that subset of the IETF community is almost > certainly not representative of IETF participants generally much > less the broader Internet community, that is a very significant > change in objectives. If we are going to do that, we should be > explicit about it. If we are not, the idea of open > participation to anyone who wants to be involved and has the > time, with no expectations about expertise falls into the "be > careful what you wish for" category. >=20 > (3) Core issue #3: What is a standard and what is a stable > document? While, ideally, it should not be a required part of > this discussion, it appears to me that there is an ongoing > difference of opinion in the IETF was to whether standards (and > perhaps IETF Stream documents in general) should be stable > specifications that may periodically be revised or replaced but > are otherwise threaded together with "updates" and "obsoletes" > designations (possibly supplemented by organizing documents > along the lines proposed by NEWTRK) or whether we want to move > more toward living documents that are updated in place with each > correction, changes of experience, or change in community > opinion about one or more points. If we are going to move more > in the latter direction, it could have a profound effect on the > RFC Series, either because IETF Standards and other normative > specifications come out of the Series, dramatically changing the > mix of documents, or because the system has to adjust to a > completely different type of documents for which, e.g., the > current production model might not be correct for at least a > subset. While a lighter-weight structure might have more > ability to adapt to such changes, the current effort to specify > details and create an elaborate discussion and approval process > seems less likely to do so, especially if the RSWG/RSAB > structure ends up not completely agreeing with, e.g., the IESG. > The solution is presumably obvious: Convene another Program or > WG to more or less start over. Unfortunately, we are pushing > toward two years of limited functionality since the actions that > apparently convinced Heather that she didn't want more of > whatever was going on. I think that has been very damaging and > that a repeat would be more so. Others probably disagree but I > would ask them whether, if we can go two or more years without > an RSEA or any of the structure now proposed, should we be > trying to see what we can learn from that and devise something > much lighter weight on the basis of the experience? >=20 > (4) Core issue #4: What got us here and are we fixing it? The > chain of events that led to this Program/Group could be seen > either as an assertion of power by some bodies over the RSE (aka > "the RSE is 'just' a contractor") or an asser5ion of authority > by groups who lacked substantive expertise (see (2) above), > neither with any transparency as far as the broader community > was concerned. It seems to me that the new model probably fixes > the transparency problem, but does so partially by increasing > the number of non-expert people and organizational structures > with an ability to meddle and/or interfere with keeping a clear > focus on consistent objectives. Is that a solution? For those > who think it is, consider how you would feel if you took a > network engineering job, discovered that you were managed by a > committee or two, none of whose members understood your job or > your areas of expertise, and whose objectives might shift over > time (either because of changing membership or to convince > themselves or others that they were being useful). >=20 > I have a longer list, but it is probably better that I keep this > rant (comparatively) short and get it out. >=20 > Do I have alternate suggestions? Yes, but they depend on > changes in the decisions about the issues identified above even, > or especially, when those decisions were made implicitly or > because we started erecting structures without really addressing > them in a way that made those decisions moot. >=20 > Grumpily and from, probably, far out in the rough, > john >=20 >=20 From nobody Tue Jun 22 06:42:37 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55053A25AE for ; Tue, 22 Jun 2021 06:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 o4TSII8xT_xK for ; Tue, 22 Jun 2021 06:42:31 -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 49BD03A25A9 for ; Tue, 22 Jun 2021 06:42:29 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::4] ([IPv6:2001:420:c0c0:1011:0:0:0:4]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15MDgQvo430554 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 22 Jun 2021 15:42:26 +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=1624369346; bh=TSjkFlzPffW5KCLKD0vRUPVrROrqGPxhOgAujumpjHw=; h=To:From:Subject:Date:From; b=LP1Sr5bgFGDUY1FlWcsblMUuo5SgkXbDTKVtMvTZqUMGJ2zOF3AMdGLmEHRXhBhaY qRxe4VbVoLEmo5bScJTHk74XEa4641dhdAD2rKfzt7PtyjHkmteS8mrkJF91jkkEYy GANFOZ4Ft7yQ3nNcZNKBMpBPhCmKy/VoaWOfRBXQ= To: rfced-future@iab.org From: Eliot Lear Message-ID: <5ee969be-dde3-e1ec-bb98-590d108c0c19@lear.ch> Date: Tue, 22 Jun 2021 15:42:22 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6gnJpARrTrfT1ylHhVHVtD6RbfDiwn68S" Archived-At: Subject: [Rfced-future] recording of yesterday's meeting X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 13:42:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6gnJpARrTrfT1ylHhVHVtD6RbfDiwn68S Content-Type: multipart/mixed; boundary="qbQoC5GyhkRmpllizmZtvb1L2JYaCzExq"; protected-headers="v1" From: Eliot Lear To: rfced-future@iab.org Message-ID: <5ee969be-dde3-e1ec-bb98-590d108c0c19@lear.ch> Subject: recording of yesterday's meeting --qbQoC5GyhkRmpllizmZtvb1L2JYaCzExq Content-Type: multipart/alternative; boundary="------------00D09A32291761776F3F9A66" Content-Language: en-US This is a multi-part message in MIME format. --------------00D09A32291761776F3F9A66 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Thanks to those who attended. Recording can be found here=20 . Password:6rRNdDnm --------------00D09A32291761776F3F9A66 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Thanks to those who attended.

Recording can be found here.

Password: 6rRNdDnm

--------------00D09A32291761776F3F9A66-- --qbQoC5GyhkRmpllizmZtvb1L2JYaCzExq-- --6gnJpARrTrfT1ylHhVHVtD6RbfDiwn68S Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDR6L4FAwAAAAAACgkQh7ZrRtnSejMI kgf/aqxL7zS3t+IbAmhqP2nq2hcx3NPRO9WdMcjI8/vrv5O1DZcKodGf3GrSmbC+K2arS4d9Izyb OasQp96hFsK+NXWmfiB+VTtQThb8OPM/kipOiL1la210okgHMum3ui1DK35oPCaKO3oQqGoLeSPO e2on+9hwSq7thKWtW/6MDASIbkOy0N2jrbDOrjkeR9mjUPgkU0L8onSq+LHdsuvQCef3bECTMnsW CMyWc1lXVSI/d62khOljb9sq6yqBQ9jgZLM+3uvZCjngKbcs1MId0Mw2MOzKSBI14C46cNJqOHtc QZKjob0Vr4SgxuuEBwPryh+uz3DRJba2pDVgoUU72A== =HkOY -----END PGP SIGNATURE----- --6gnJpARrTrfT1ylHhVHVtD6RbfDiwn68S-- From nobody Tue Jun 22 07:22:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6053A2717 for ; Tue, 22 Jun 2021 07:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 Y0tnjrvy0nTv for ; Tue, 22 Jun 2021 07:22:18 -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 6B1683A2711 for ; Tue, 22 Jun 2021 07:22:18 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::4] ([IPv6:2001:420:c0c0:1011:0:0:0:4]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15MEMFx2431324 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 22 Jun 2021 16:22:16 +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=1624371736; bh=Xk63htQi3uQ1YzehViQHwFH8x/MprEPLsosdbKHv9E4=; h=To:From:Subject:Date:From; b=PxG3vHPShSPQSxnmhhPE9GBno6SMQDYMUxiTOIl2jxRzH46nsbKU6hLx1Yz5BW01v 3nI5QdzkWekb/oC0arr/O5zfxjDK/xr2iK7PaXNKVCdqTcl27TSLKMUgw5KRY32VZc cDO1wg1tTv2QVQTZZxv/rpBuvvYqi/xxiaEDl78o= To: rfced-future@iab.org From: Eliot Lear Message-ID: Date: Tue, 22 Jun 2021 16:22:14 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d3ZWrD0jkvEZ5Es2DzHc1OgDn5ldnborv" Archived-At: Subject: [Rfced-future] Consensus check: Close Issue 11: Is there a figurehead X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 14:22:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d3ZWrD0jkvEZ5Es2DzHc1OgDn5ldnborv Content-Type: multipart/mixed; boundary="nWBHiwyxDGLrYqZNyZECqQ20Xq9dcakLk"; protected-headers="v1" From: Eliot Lear To: rfced-future@iab.org Message-ID: Subject: Consensus check: Close Issue 11: Is there a figurehead --nWBHiwyxDGLrYqZNyZECqQ20Xq9dcakLk Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US This is more a placeholder issue about whether we have an RSE/A. Propose = to close.=C2=A0 We think we're beyond this point.=C2=A0 Please comment by= 6 July=20 if you disagree. --nWBHiwyxDGLrYqZNyZECqQ20Xq9dcakLk-- --d3ZWrD0jkvEZ5Es2DzHc1OgDn5ldnborv Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDR8hYFAwAAAAAACgkQh7ZrRtnSejMG kggAmqhvq0x9u0vc20O1KTjP/AngMl9fUogw2m6YKLSuMCcH6O3NObVTEWXgAnmA+qYYh6r/CADR TAkaV4RG6iIDKzPwg5/2n+1dOxobDHMwcjyGtx3Okj0cL0KTQQFY7g5+/6k/kiFFvs+LMn73mHy0 E/C5yird627HjC0JpI3+6uAhn4l3YdpwSgBp3298Q/EnMUYVsBSie8qQkVXvX9NAslkhwg/H8Vkl HLz1DWEfbSNtfRISMnEJEVBJzo+R/rhOGdhItArL2Yb+r9NjDryyHfy9TI6+6GOlTl+4YY9ytMd2 tFzV0/Xh4s0bBTqdEkwO8ovVnehSZm1JlC0lpvy5Hw== =2VFV -----END PGP SIGNATURE----- --d3ZWrD0jkvEZ5Es2DzHc1OgDn5ldnborv-- From nobody Tue Jun 22 07:32:27 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76363A274E for ; Tue, 22 Jun 2021 07:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 VBrRzYmQESPb for ; Tue, 22 Jun 2021 07:32:20 -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 2F3103A274D for ; Tue, 22 Jun 2021 07:32:19 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::4] ([IPv6:2001:420:c0c0:1011:0:0:0:4]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15MEWHS9431381 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 22 Jun 2021 16:32:17 +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=1624372337; bh=7+cugWTOcCcDw3R2ds5cvcuXXg0moErOYvDsNsKUs2A=; h=To:From:Subject:Date:From; b=fycsbpF+cEU6Z2Oo4zVhPzUSIET4zrwcs7nSD8Ez3+B7QzWMp2X2LlXTz5wCKn8Ys Cojg7NqEEZ5Z0axEIPOmuRXjffqZvme9FZ7LoC10aSzGtuxST6pCThzQ9mBUkm+ec9 QAr7705LN5bgKSxgu5yWQ7lNGQ+3Tt609/JVI8TA= To: rfced-future@iab.org From: Eliot Lear Message-ID: Date: Tue, 22 Jun 2021 16:32:16 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IMewARb9gWKqf39ZPPSMq99ADUMgyfr78" Archived-At: Subject: [Rfced-future] Consensus check: Issue 14: selection of chairs X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 14:32:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IMewARb9gWKqf39ZPPSMq99ADUMgyfr78 Content-Type: multipart/mixed; boundary="RQTqt8YwM8e5Qfh9cDn18YkcTdfyxx3vy"; protected-headers="v1" From: Eliot Lear To: rfced-future@iab.org Message-ID: Subject: Consensus check: Issue 14: selection of chairs --RQTqt8YwM8e5Qfh9cDn18YkcTdfyxx3vy Content-Type: multipart/alternative; boundary="------------32C2938BF774071246C83FDA" Content-Language: en-US This is a multi-part message in MIME format. --------------32C2938BF774071246C83FDA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Peter has added text into -01 for this in Sections 3.1.1 and 3.1.2.=C2=A0= =20 There are three remaining issues: 1.=C2=A0 Adrian's point about staggered terms.=C2=A0 Peter will address t= his=20 editorially. 2. Chair removal.=C2=A0 A separate issue 72 has been opened for this. 3. Possible term limits for the RSAB.=C2=A0 A separate issue 71 has been = opened for this. If you have any *other* concerns about the text in the draft, please say = so by 6 July 2021. --------------32C2938BF774071246C83FDA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Peter has added text into -01 for this in Sections 3.1.1 and 3.1.2.=C2=A0 There are three remaining issues:

1.=C2=A0 Adrian's point about staggered terms.=C2=A0 Peter will ad= dress this editorially.

2. Chair removal.=C2=A0 A separate issue 72 has been opened for th= is.

3. Possible term limits for the RSAB.=C2=A0 A separate issue 71 ha= s been opened for this.

If you have any other concerns about the text in the draft, please say so by 6 July 2021.

--------------32C2938BF774071246C83FDA-- --RQTqt8YwM8e5Qfh9cDn18YkcTdfyxx3vy-- --IMewARb9gWKqf39ZPPSMq99ADUMgyfr78 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDR9HAFAwAAAAAACgkQh7ZrRtnSejOQ zAf+M5By5xUM2MOU9yzteqWcAHoxa736JfIjosGmcMeiOMSTx4NZWI7Lb/AkwuRsFBjxwsysdwvj gjVRyhBngXmgdjuuLtqZUyTMkqkDlB9MT1KU5hFlL3hPGIyOzA6m0ivpIb2NGWS9+eG65ltPMa/h 3aZl80AIrmsEHMJeR3G9VLS2vIqxY6bbxzSNAA/Q9HXDuPtQy5/6bOdP+FGiV8JPMKhZQZkJAWN9 3LBss4kPn0uGbMpJkmwR8nHK8oY9qarLRK7hPJagjWZEmImz2Esk1z49CjbBnGYLPO9MT6vQgDvB TMmVSdAM0+yrmzZ1fOF8vkbtz6lQ+0NLGOAh9RgMPg== =Q6M/ -----END PGP SIGNATURE----- --IMewARb9gWKqf39ZPPSMq99ADUMgyfr78-- From nobody Tue Jun 22 07:38:04 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D6D3A2766 for ; Tue, 22 Jun 2021 07:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 xW-PIuhR7wXS for ; Tue, 22 Jun 2021 07:37:59 -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 CDD8B3A276A for ; Tue, 22 Jun 2021 07:37:58 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::4] ([IPv6:2001:420:c0c0:1011:0:0:0:4]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15MEbt3Y431424 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 22 Jun 2021 16:37:56 +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=1624372676; bh=20f4jc3p1mLceLQUgJ2Wo3Px8kES4oJ+UphwNOFVQxk=; h=To:From:Subject:Date:From; b=RJ7R6bfItvZFR8/0KpVurWemai9LyAzM0N9KX2/gEct9bz2CHYFq48yBdXAEcFye3 O5rdDw4bsaEoM3xykxJuXxHCe8QtV9X28QrAmt8XQMOW/RjFKoNPXNzpy9UfFs8mtD hpvfWHEvUbmk37fRZAlxZx2ohpYMk2isFNuSnnsE= To: rfced-future@iab.org From: Eliot Lear Message-ID: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> Date: Tue, 22 Jun 2021 16:37:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pC1zjB6IfuML1wdSHJg1mn4KwYB8ZH3j4" Archived-At: Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 14:38:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pC1zjB6IfuML1wdSHJg1mn4KwYB8ZH3j4 Content-Type: multipart/mixed; boundary="lgA5ikCwvpqaSu01EtCYBTff1wlZ6nBjo"; protected-headers="v1" From: Eliot Lear To: rfced-future@iab.org Message-ID: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> Subject: Consensus check: Issue 16: Appeals (RSWG) --lgA5ikCwvpqaSu01EtCYBTff1wlZ6nBjo Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US The following text was proposed to address appeals of the RSWG: > Appeals of RSWG decisions can be made to the RSAB if there are=20 > concerns about the process followed by the RSWG. Appeals should be=20 > made within 30 days of any action. The RSAB then decides if the=20 > process has been followed. Please raise concerns by 6 July if you have any. Eliot --lgA5ikCwvpqaSu01EtCYBTff1wlZ6nBjo-- --pC1zjB6IfuML1wdSHJg1mn4KwYB8ZH3j4 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDR9cIFAwAAAAAACgkQh7ZrRtnSejNr rggAgbNoYeczJsLBU9yrVZGIRmzOaRONqRE9nhgmxZJTAoj5A35BynmSVlzOixYH2zcyWmL6r23r h4MRnVZzx5i8Ykq4wXFRZM/P9wETXD4Jx1zwa5sw3PiNPXBzAGyEypReAr2kbMNHHaNtUpvM1Ngg qJDWOr6qTJ1PHng7P3vbqVE2ra76uIVEl5dGK1AtgsXmS3XqJURjT0sMex8E0gwsSID/CiMe/cqz D2zQtXE0Fd3n3W0pgeyIx+t7M8AU+YPlrpJvp2aZFtOKN5Zkp2izcNp2g0GDLVBVKfZlTHhsvnxi lHfItkw6yCJjEBJL9kiXnosh86Fk5Zs+E5C53x2csQ== =Xa8k -----END PGP SIGNATURE----- --pC1zjB6IfuML1wdSHJg1mn4KwYB8ZH3j4-- From nobody Tue Jun 22 07:47:11 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4573A279F for ; Tue, 22 Jun 2021 07:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 4E8rCNMjl2BL for ; Tue, 22 Jun 2021 07:47:05 -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 6C8983A279E for ; Tue, 22 Jun 2021 07:47:05 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::4] ([IPv6:2001:420:c0c0:1011:0:0:0:4]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15MEl2GR431593 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 22 Jun 2021 16:47:02 +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=1624373222; bh=rYvxOBOJ2wCAVm7H2Ufy7rq6Ov/T1OArD28aQGyb2jE=; h=To:From:Subject:Date:From; b=rQ1C0h/28hjFxTRuUPSbEJgOdfuQj8tf42QRyyfzZeoQaTYiskXw/WlCCtDNMacn7 CSaG2He2E0FK6wPsFCySwwKaWSAL1PwYNyhBA95fbPqeCMgIa7g/DnUL74bFJd26S8 w+If2z4Tn/xiZhN7U9Lg2Rjma32hf8hpGo5sd/7Y= To: rfced-future@iab.org From: Eliot Lear Message-ID: <6ed31a83-d686-59c3-ebdf-e914a0167022@lear.ch> Date: Tue, 22 Jun 2021 16:47:01 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zJ12FTltH7CR9THqkbocPG8XqTL77lW4U" Archived-At: Subject: [Rfced-future] Consensus Check - Issue 20: Decider for hiring RSE/A X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 14:47:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --zJ12FTltH7CR9THqkbocPG8XqTL77lW4U Content-Type: multipart/mixed; boundary="a9bZ53JLDYE4MVCGbKRwZGgrqjEZn2iOk"; protected-headers="v1" From: Eliot Lear To: rfced-future@iab.org Message-ID: <6ed31a83-d686-59c3-ebdf-e914a0167022@lear.ch> Subject: Consensus Check - Issue 20: Decider for hiring RSE/A --a9bZ53JLDYE4MVCGbKRwZGgrqjEZn2iOk Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US In yesterday's call we wordsmithed the following for Section 4.1: > "The RSEA will be selected by a search committee formed by the=20 > Executive Director of the IETF LLC, taking into account the role=20 > definition [13] and any detailed job description defined by the=20 > relevant parties" Please raise any concerns by 6 Jul 2021. Eliot --a9bZ53JLDYE4MVCGbKRwZGgrqjEZn2iOk-- --zJ12FTltH7CR9THqkbocPG8XqTL77lW4U Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDR9+UFAwAAAAAACgkQh7ZrRtnSejOV gwf/e1BrHNHiDgxzS8aM/SYq5oaWneFbCnzXNRv2Zxva4T7wNXqBJdPnxo/jmSTB/eWDfndFTix3 uwUOeGOK2HQL5kz4CMVeX2y5zSlctsSCaK10JdY517EGA1+mVPm2tNwGxmxz8skLU/f8vqp/YA9X jayBfBWbrkV8JwmMiDp21rACk6yW/cZ4tKx/6LLDyVDaCJXB18fadU3kpzkOKM9f2dnTY4nSC0E0 Gg86QQmvNmCJIEX5E+QjI8JoJibs09fR7++Ysk6X8GAE7ZkWRUREWicdlzArUgfczxJbcSuItM+q STuPMA5+u+96pWMZqujOkCoMBDo2iGnvbGMf2EmeQw== =Wcq/ -----END PGP SIGNATURE----- --zJ12FTltH7CR9THqkbocPG8XqTL77lW4U-- From nobody Tue Jun 22 07:51:59 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF8E3A27BC for ; Tue, 22 Jun 2021 07:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 XGt_opfOGKWI for ; Tue, 22 Jun 2021 07:51:53 -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 CA42B3A27BA for ; Tue, 22 Jun 2021 07:51:52 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::4] ([IPv6:2001:420:c0c0:1011:0:0:0:4]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15MEpo3c431625 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 22 Jun 2021 16:51:50 +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=1624373510; bh=nR2LfNb+644OXXtyRb1sSp9koC7XBDmSrV7xTv1SeTY=; h=To:From:Subject:Date:From; b=b3qeKglQDWDRWil3bdFkWmRI92yHyeo16s4laQlR+p9a+nlHWd4kYScYzyvI5wok+ aZ3bvhyduJrZ5HjuQ56dt/MBBN1uaY+Qq5Dm+KntBn1nROuXRtjIpjdITN69xxfJDP ZWYrUMtrFS0VhQi4S+U50QKlUf2G3dFmVKA5UKE0= To: rfced-future@iab.org From: Eliot Lear Message-ID: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> Date: Tue, 22 Jun 2021 16:51:49 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EPx0mLHYbOLVVmcSP31A86W4oDYuey91n" Archived-At: Subject: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 14:51:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EPx0mLHYbOLVVmcSP31A86W4oDYuey91n Content-Type: multipart/mixed; boundary="gc2wUzvXMnNC2T9XIzjb2MCfcl8uVxE94"; protected-headers="v1" From: Eliot Lear To: rfced-future@iab.org Message-ID: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> Subject: =?UTF-8?Q?Consensus_check=3a_Issue_22_=e2=80=93_new_stream_for_RFC_?= =?UTF-8?Q?Editor?= --gc2wUzvXMnNC2T9XIzjb2MCfcl8uVxE94 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US In yesterday's meeting there was general consensus that there should be=20 a new stream, and that the RSE/A should manage it.=C2=A0 The general argu= ment=20 was that there should be no supervisory check performed by the IAB after = the RSAB has approved a document. Please send any concerns by 6 July. Eliot --gc2wUzvXMnNC2T9XIzjb2MCfcl8uVxE94-- --EPx0mLHYbOLVVmcSP31A86W4oDYuey91n Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDR+QUFAwAAAAAACgkQh7ZrRtnSejO6 CAf/fkMlYQaf5kHuTKINliI/MEBO3DoBar1D3KaaJbo6VFEqYec6nbEbXQz3n7+JrOtbVgqgA/d3 Mu6zb+M3BYeMwzZZXJ4cKvI/SAv3owsyyJiXH4KBaH7vMsWQDcSFn2P9n1NljFRNVONA4J5BxHQa AAxZGXKFtHaYkM0t0p/76FPLkVVLU2F39Dd8EoCcK1UV7p4kxnhSdQwuTgekmS7smA8j9Z5IIFus Gy4Pk2bHXtFs4wVQ/rkZpOLnaKs/EEAATX794SWcEYtn/Iz+90Zj71VZDtWNHJknaZx91xOulOng FZf8OpnLFI48Rlr6bGhduf6BrbcR5w0AMp6F6IxwGQ== =+org -----END PGP SIGNATURE----- --EPx0mLHYbOLVVmcSP31A86W4oDYuey91n-- From nobody Tue Jun 22 07:54:44 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B793A27CE for ; Tue, 22 Jun 2021 07:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 9kDzWJcr4B5Y for ; Tue, 22 Jun 2021 07:54:39 -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 B2D7C3A27CB for ; Tue, 22 Jun 2021 07:54:37 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::4] ([IPv6:2001:420:c0c0:1011:0:0:0:4]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15MEsYw0431643 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 22 Jun 2021 16:54:35 +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=1624373675; bh=Do3kSCXEZ55k974l+VpLjl7f7kaQFUqysQqPrdLKN+U=; h=To:From:Subject:Date:From; b=aEHHxDkZKzWVktLgU9xYzLj77BSRftavPq4EpwWScaamzAwZMGBTzZV0HLHriY0g+ bEA1SVDdaJgD03VLmcqV5Jz6zBbiaafcDMMq+OcuMqraSjfQDBqsoYzAc2daSReNL+ Blku0TfjJldZKWDA+a+DBVqTgNdXbZL2q9RZOR3k= To: rfced-future@iab.org From: Eliot Lear Message-ID: Date: Tue, 22 Jun 2021 16:54:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6h9VjzKnHBUmNtFGEDGPCvSSlyrlnqr3p" Archived-At: Subject: [Rfced-future] Consensus check- Issue 53: Do new streams necessarily imply new RSAB members? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 14:54:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6h9VjzKnHBUmNtFGEDGPCvSSlyrlnqr3p Content-Type: multipart/mixed; boundary="z9S5dpPdCaU5Cr57m5iL9wt2vdP8T4DUr"; protected-headers="v1" From: Eliot Lear To: rfced-future@iab.org Message-ID: Subject: Consensus check- Issue 53: Do new streams necessarily imply new RSAB members? --z9S5dpPdCaU5Cr57m5iL9wt2vdP8T4DUr Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US General agreement that this matter can be deferred into whatever RFC=20 defines the stream.=C2=A0 If you have concerns about this approach, pleas= e=20 make them known by 6 July. Eliot --z9S5dpPdCaU5Cr57m5iL9wt2vdP8T4DUr-- --6h9VjzKnHBUmNtFGEDGPCvSSlyrlnqr3p Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDR+acFAwAAAAAACgkQh7ZrRtnSejNT qwf/Um+im7moTJI4GcckZj9axud3qkmpKXBMcnwhyCfD/AcwcIAkGF0M4CQ/X0D7bwel5Sf4V9b5 eUOJC3rD5xYowSLP5mhCeHn0AUbG0De2FS+Aj1ZJ1Zzl3cOBTc/fkYlkf28MyktUTa1eIFHoie2D Yu1caZ7WCsNAAo1ICHoa1118J4j5IC65hsHZv+CZorvXpHG62KMzk39iUYfbz3p2/q4a/U6L/1LH bibpRZULYYHDFxwn967C58kUBOFO06rk1f2h81wp1OVaamM8qBrLS1bvNg4OOdSUrAD9wx31/jb2 mkDkxIl3asii4465jHnMt+5TVxK9gaGYefbBpywrzg== =PubV -----END PGP SIGNATURE----- --6h9VjzKnHBUmNtFGEDGPCvSSlyrlnqr3p-- From nobody Tue Jun 22 08:10:16 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D69D3A00E0 for ; Tue, 22 Jun 2021 08:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 dYdSMeB7zrxX for ; Tue, 22 Jun 2021 08:10:08 -0700 (PDT) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 9491E3A00E2 for ; Tue, 22 Jun 2021 08:10:08 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15MFA5fZ026597; Tue, 22 Jun 2021 16:10:05 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3998D4604B; Tue, 22 Jun 2021 16:10:05 +0100 (BST) Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2DE9F46048; Tue, 22 Jun 2021 16:10:05 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS; Tue, 22 Jun 2021 16:10:05 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.47.18]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15MFA3mA011414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Jun 2021 16:10:04 +0100 Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , References: In-Reply-To: Date: Tue, 22 Jun 2021 16:10:02 +0100 Organization: Old Dog Consulting Message-ID: <0a5f01d76778$adce3db0$096ab910$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A60_01D76781.0F92F3D0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQCyXEC+H6qKQ8aULWBrc5cKfHy5Wq1qNoaQ X-Originating-IP: 84.93.47.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1017-26236.000 X-TM-AS-Result: No--25.625-10.0-31-10 X-imss-scan-details: No--25.625-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1017-26236.000 X-TMASE-Result: 10--25.625100-10.000000 X-TMASE-MatchedRID: xcONGPdDH5q8rRvefcjeTb7u5vMMMVTtaMmm586o4gBn41le04enaqgF 8LHYfOYG/f0mS3TRGSILUyRiKEP+AWJQK9wIJ221uVFL9NtjSQJMGTMF+LRLahQUOSCpbPwOscH l370W0VE7J3wcIYUbOnbtxm2jKR0WGe2ebekQcim9NsL2xEmLyxUuc8ufuGB9a73+XlYDLuwRbq HHqRKW2/obDz0cFNgwA4S6rJfSNyOInRC94WJcCu9VsdrlGzy3Q6/DFZugyt1bYv6Kt+uF2MxFQ xp3PhHymoRv4vCWtWMfvo9UW9ImXv+z7xWvCPyPWcC0gYMYIWiOVGny5q72hiPS9JdK3W4/zU4H 2c6gTjr/ENcaY0e0P1DQ43dkW3a5RS5eRZNKL9GL6bUMM+bbIn2K2idm6bheWUtm6AJIkCDUGht zq3pqRVSwGvCl8CreFABeLgZr0ZGVxY39DRAHLFOrNp5VU581+gtHj7OwNO0XnNprp3a9NgNdXs UeZTYKhowGpg489ZLDlDn7WdwhFi+koy8MxFz3 X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 14: selection of chairs X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 15:10:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0A60_01D76781.0F92F3D0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So far so good. A =20 From: Rfced-future On Behalf Of Eliot = Lear Sent: 22 June 2021 15:32 To: rfced-future@iab.org Subject: [Rfced-future] Consensus check: Issue 14: selection of chairs =20 Peter has added text into -01 for this in Sections 3.1.1 and 3.1.2. = There are three remaining issues: 1. Adrian's point about staggered terms. Peter will address this = editorially. 2. Chair removal. A separate issue 72 has been opened for this. 3. Possible term limits for the RSAB. A separate issue 71 has been = opened for this. If you have any other concerns about the text in the draft, please say = so by 6 July 2021. ------=_NextPart_000_0A60_01D76781.0F92F3D0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

So far so = good.

A

 

From: Rfced-future = <rfced-future-bounces@iab.org> On Behalf Of Eliot = Lear
Sent: 22 June 2021 15:32
To: = rfced-future@iab.org
Subject: [Rfced-future] Consensus check: = Issue 14: selection of chairs

 

Peter has added text into -01 = for this in Sections 3.1.1 and 3.1.2.  There are three remaining = issues:

1.  Adrian's point about staggered = terms.  Peter will address this editorially.

2. = Chair removal.  A separate issue 72 has been opened for = this.

3. Possible term limits for the RSAB.  A = separate issue 71 has been opened for this.

If you have = any other concerns about the text in the draft, please say so by = 6 July 2021.

------=_NextPart_000_0A60_01D76781.0F92F3D0-- From nobody Tue Jun 22 08:10:19 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304093A00E1 for ; Tue, 22 Jun 2021 08:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 z-sGYZYrZ8ay for ; Tue, 22 Jun 2021 08:10:08 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 761F03A00E0 for ; Tue, 22 Jun 2021 08:10:07 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15MFA5OK007096; Tue, 22 Jun 2021 16:10:05 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DDFE546082; Tue, 22 Jun 2021 16:10:04 +0100 (BST) Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D04F846078; Tue, 22 Jun 2021 16:10:04 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS; Tue, 22 Jun 2021 16:10:04 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.47.18]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15MFA3m9011414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Jun 2021 16:10:04 +0100 Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> In-Reply-To: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> Date: Tue, 22 Jun 2021 16:10:02 +0100 Organization: Old Dog Consulting Message-ID: <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQDwm4h/OuxJzo06clSw5zQRx8klMqztuFmA X-Originating-IP: 84.93.47.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1017-26236.000 X-TM-AS-Result: No--5.018-10.0-31-10 X-imss-scan-details: No--5.018-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1017-26236.000 X-TMASE-Result: 10--5.018100-10.000000 X-TMASE-MatchedRID: hls5oAVArl+8rRvefcjeTb7u5vMMMVTtaMmm586o4gC8JrL0g2bdmiMn HClP1IKbhhY02xS4bY+Pz06y4K7HmXbI+PVdeqUp3nHtGkYl/VpRwfT2oEaYdH/MYPiXwGPQ8NB MdiM0xvM6t8E2/nibiETisnJWJxU7MKK3MQ624rWQDCPIwePW3hg6dAPBanTEgn6pqeAeoD2oBf Cx2HzmBv39Jkt00RkiC1MkYihD/gFiUCvcCCdttbrbxxduc6FPMwDRsJ0tggSqvcIF1TcLYGkhv 2xiC2mz0ic5nN68VGVZiVkglZyW0qMb9ZRAzSYjngIgpj8eDcArN8z0HohG3voLR4+zsDTtvks7 sIjSe3vJ6deeMjYdXA0xfZtouNniAHjELXJGXRcfo9wl3UFsVVZca9RSYo/b X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 15:10:14 -0000 I completely agree with the sentiment, but I think the wording may have = issues. What the proposal does is say what can be done "if there are concerns = about the process followed by the RSWG." It does not say (but I think it = is meant to imply) that the content of the decisions cannot be appealed. The "should" is also slightly ambiguous. And "any action" presumably means the action being appealed. I would... Decisions of the RSWG can only be appealed on grounds of failure to = follow the correct process. Such an appeal must be made to the RSAB = within 30 days of the action being appealed. The RSAB will then decide = whether the process was followed correctly. Cheers, Adrian -----Original Message----- From: Rfced-future On Behalf Of Eliot = Lear Sent: 22 June 2021 15:38 To: rfced-future@iab.org Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) The following text was proposed to address appeals of the RSWG: > Appeals of RSWG decisions can be made to the RSAB if there are=20 > concerns about the process followed by the RSWG. Appeals should be=20 > made within 30 days of any action. The RSAB then decides if the=20 > process has been followed. Please raise concerns by 6 July if you have any. Eliot From nobody Tue Jun 22 08:20:14 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4439B3A076F for ; Tue, 22 Jun 2021 08:20:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 Rz4rY9XfQkev for ; Tue, 22 Jun 2021 08:20:09 -0700 (PDT) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 BF3E73A076E for ; Tue, 22 Jun 2021 08:20:08 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15MFK5hE013861; Tue, 22 Jun 2021 16:20:05 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 547FF46050; Tue, 22 Jun 2021 16:20:05 +0100 (BST) Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 46A8A4604C; Tue, 22 Jun 2021 16:20:05 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS; Tue, 22 Jun 2021 16:20:05 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.47.18]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15MFK40c017108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Jun 2021 16:20:04 +0100 Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , References: <6ed31a83-d686-59c3-ebdf-e914a0167022@lear.ch> In-Reply-To: <6ed31a83-d686-59c3-ebdf-e914a0167022@lear.ch> Date: Tue, 22 Jun 2021 16:20:03 +0100 Organization: Old Dog Consulting Message-ID: <0a6401d7677a$137b07a0$3a7116e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJkJv7VKIWx7nHjxqPykerTEkkToaoGoypw X-Originating-IP: 84.93.47.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1017-26236.000 X-TM-AS-Result: No--3.498-10.0-31-10 X-imss-scan-details: No--3.498-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1017-26236.000 X-TMASE-Result: 10--3.498200-10.000000 X-TMASE-MatchedRID: 6otD/cJAac28rRvefcjeTb7u5vMMMVTtys3RmVG6Es2vloAnGr4qhtxB 5Mvigla/DqoRrI2CByvyYssb+xl0YWmhrOl03qGfCuDAUX+yO6bYt7feNOis5tctGlxeXl/oRs2 rHpIoaW056UleuofCzckRvuDaypE+tOedlyVAU7OHpfBSejqaSRtPDNiPbNC633Nl3elSfsoa6G pwVKJBqIdQvM6LDqFKUtYaEhKToJj8CQHhkzk/UjTk6JGbrQhuKZoK1F/O1EkcYLTBy2i6Auem9 neOhcTObHiAQxu0LV534EaNoQAMFW6rU5KSKOvUxti5Nvr5xCDjAcZeNJgY96Hr6eS9NQNK3n8e BZjGmUzkwjHXXC/4I66NVEWSRWyb66P8PAFRxacQOYipS4B/lpDLxpaU5zkb8G74lL8ca9yRryv 5mPQXl30/SZZ/6IXH7xGykbeQ9z24d8sEV080kVwhxvEMJlwFNhaOBHxzal2OTCSnRTeg+iPVIU GLlI4nRt01ZrBZr355ekLjAaeHxA== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Consensus Check - Issue 20: Decider for hiring RSE/A X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 15:20:13 -0000 "and any detailed job description" tends to imply that if the LLC = doesn't ask, they might not receive. Can the job description be forced = upon them? Or s/any/the/ "defined by the relevant parties" is very tricky because who is to say = which parties are relevant? Can we be more precise? (I don't much mind = what we define as relevant, but I feel we should scope it.) A -----Original Message----- From: Rfced-future On Behalf Of Eliot = Lear Sent: 22 June 2021 15:47 To: rfced-future@iab.org Subject: [Rfced-future] Consensus Check - Issue 20: Decider for hiring = RSE/A In yesterday's call we wordsmithed the following for Section 4.1: > "The RSEA will be selected by a search committee formed by the=20 > Executive Director of the IETF LLC, taking into account the role=20 > definition [13] and any detailed job description defined by the=20 > relevant parties" Please raise any concerns by 6 Jul 2021. Eliot From nobody Tue Jun 22 09:03:01 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CE33A07C2 for ; Tue, 22 Jun 2021 09:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 kXOoalOcbGvx for ; Tue, 22 Jun 2021 09:02:54 -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 5793E3A0A78 for ; Tue, 22 Jun 2021 09:02:53 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::4] ([IPv6:2001:420:c0c0:1011:0:0:0:4]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15MG2nW9432353 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 22 Jun 2021 18:02:50 +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=1624377770; bh=Me3VDKVJi51bguIrJBgAmmm0apopVMrcH6ETguMVS0M=; h=To:From:Subject:Date:From; b=LjDHEZu2ec+lOXUOTYzXmvb4y91lT7hMLJQlKukEGzHWqQhDmwxM86oYpHnwlwWRP tdzNZadpkN3jjL9R5DlxUNNHdHpiQYRyGtIN54VJpKY7mbkdS43UMTs+0SzLlNH4za OQf7iMMv81aDmtvVsZu/Wt3G6kvktJHjK/58vdKc= To: rfced-future@iab.org From: Eliot Lear Message-ID: <5977bd11-ca97-6516-57ee-cb1f71ed92d3@lear.ch> Date: Tue, 22 Jun 2021 18:02:47 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ObR8bGhRkGTTBnOykmCHxRyV3y5dmB4DX" Archived-At: Subject: [Rfced-future] Call for Adoption: draft-saintandre-rfced-model-01 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 16:02:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ObR8bGhRkGTTBnOykmCHxRyV3y5dmB4DX Content-Type: multipart/mixed; boundary="fbqtytWvfanmA0jwVV3DFyDFWfEggjEoo"; protected-headers="v1" From: Eliot Lear To: rfced-future@iab.org Message-ID: <5977bd11-ca97-6516-57ee-cb1f71ed92d3@lear.ch> Subject: Call for Adoption: draft-saintandre-rfced-model-01 --fbqtytWvfanmA0jwVV3DFyDFWfEggjEoo Content-Type: multipart/alternative; boundary="------------046295A79FE7BD44FB4C6252" Content-Language: en-US This is a multi-part message in MIME format. --------------046295A79FE7BD44FB4C6252 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Dear Colleagues, As discussed in the May interim, we are now issuing a Call for Adoption=20 of draft-saintandre-rfced-model-01 as the draft this group will use as=20 intended output. =C2=A0We hope that this call is a mere formality. =C2=A0= Our=20 procedures for content going into that draft and issues raised do not=20 change. =C2=A0The purpose of adoption is to make clear our group=E2=80=99= s ownership=20 of its content and intent to pursue that work as WG output, with the=20 very generous and kind help of Peter. Please raise any concerns by 6 July 2021. Eliot --------------046295A79FE7BD44FB4C6252 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Dear Colleagues,

As discussed in the May interim, we are now issuing a Call for Adoption of draft-saintandre-rfced-model-01 as the draft this group will use as intended output. =C2=A0We hope that this call is a mere formal= ity. =C2=A0Our procedures for content going into that draft and issues= raised do not change. =C2=A0The purpose of adoption is to make cl= ear our group=E2=80=99s ownership of its content and intent to pursue= that work as WG output, with the very generous and kind help of Peter.

Please raise any concerns by 6 July 2021.

Eliot

--------------046295A79FE7BD44FB4C6252-- --fbqtytWvfanmA0jwVV3DFyDFWfEggjEoo-- --ObR8bGhRkGTTBnOykmCHxRyV3y5dmB4DX Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDSCacFAwAAAAAACgkQh7ZrRtnSejMA Qwf9EjpDOhAuGKOPCBr7mopXSlaDSY03CTNRWOBoFd2AlIlpBNY7CEHDJTn+5Pf2+l3xE/371dPd 4Z4z+9w+1sMjvn/4AKAh3D+7Qlyw2bpcy3v6lG96dobWR6uNK0YbdZxiXSy4wshMcTMKgqrLKQvf A/3N1IgPL6TUFTLgCcAFRQUb9shOl7mOAjtWa4L0jqIlhhyotP4tUtgE2qS0cGufGS0C+KlzoHvv BEOOf6Ns+NNYqBTDLDRkPC/44bE9kDDR274uAhBqG2mVBumrtsAnJz/udiG08FiEdBxyrtYSwbbo YbSbR2p4seVQ4CV7e7QZH18+f2G1KkCq9SpWwv8O3Q== =FILN -----END PGP SIGNATURE----- --ObR8bGhRkGTTBnOykmCHxRyV3y5dmB4DX-- From nobody Tue Jun 22 09:56:29 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6328F3A0D25 for ; Tue, 22 Jun 2021 09:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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=elandsys.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 N1Z1rqDyK8DU for ; Tue, 22 Jun 2021 09:56:22 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E413A0D20 for ; Tue, 22 Jun 2021 09:56:22 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.188.234]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id 15MGu8Ch012589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jun 2021 09:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1624380980; x=1624467380; i=@elandsys.com; bh=yBEL7ip8RYqPqLVtgN8LePSCvfP2nk85TWfdRKzw/qc=; h=Date:To:From:Subject:In-Reply-To:References; b=QGPllHW25Pst+C8p8Ok/GXCJHS7s1c/CXnirUNM7yCBjBje+ZQ6k0tOQU4bnk4Lzq vPd7vcWXx2ZxNihX91kDWZOm5UVK1dPYrQF85nhAAFGgURB00Gzaa/OrC/ojj1Fy3z yoYj2kMfHaqWyf5HT5HprS/8opnSylOL3vonK0TI= Message-Id: <6.2.5.6.2.20210622085825.0ae0b5c8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 22 Jun 2021 09:54:35 -0700 To: John C Klensin , rfced-future@iab.org From: S Moonesamy In-Reply-To: <9CCFECFF41DD399EA4AB89BE@PSB> References: <9CCFECFF41DD399EA4AB89BE@PSB> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Rfced-future] A voice from the (perhaps lunatic) fringe (was: draft-saintandre-rfced-model-01.txt) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 16:56:27 -0000 Hi John, At 12:08 PM 21-06-2021, John C Klensin wrote: >(4) Core issue #4: What got us here and are we fixing it? The >chain of events that led to this Program/Group could be seen >either as an assertion of power by some bodies over the RSE (aka >"the RSE is 'just' a contractor") or an asser5ion of authority >by groups who lacked substantive expertise (see (2) above), >neither with any transparency as far as the broader community >was concerned. It seems to me that the new model probably fixes Yes. >the transparency problem, but does so partially by increasing >the number of non-expert people and organizational structures >with an ability to meddle and/or interfere with keeping a clear >focus on consistent objectives. Is that a solution? For those >who think it is, consider how you would feel if you took a >network engineering job, discovered that you were managed by a >committee or two, none of whose members understood your job or >your areas of expertise, and whose objectives might shift over >time (either because of changing membership or to convince >themselves or others that they were being useful). It takes some time to understand what the objectives are and to be consistent in moving towards them. During that time there may be new persons coming on board and old persons leaving. There will be persons meddling or interfering. The second option, to avoid meddling, is to avoid bringing in new persons. I prefer the first option as it can inject fresh input into the group. I am not convinced that the group should be modeled on the IETF WG. Such groups do not work well when discussing non-technical matters. One of the points which should, in my opinion, be reviewed is the role of the IAB. What role does it having in the model, as proposed in draft-saintandre-rfced-model-01? The performance targets are negotiated by the IETF LLC. That dilutes the authority of the RSE. In addition, it does not allow for performance targets to be cascaded from the RSE's targets. Some of the "process" stuff could be procedures instead of something specified in a RFC. The question which comes to mind is whether the main concern is about accountability or entity politics sprinkled with a semblance of transparency. Regards, S. Moonesamy From nobody Tue Jun 22 10:00:18 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787103A0D47 for ; Tue, 22 Jun 2021 10:00:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 AgJenmmg9YAq for ; Tue, 22 Jun 2021 10:00:13 -0700 (PDT) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 048D93A0D46 for ; Tue, 22 Jun 2021 10:00:12 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15MH09k0014501; Tue, 22 Jun 2021 18:00:09 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4DD3F4604F; Tue, 22 Jun 2021 18:00:09 +0100 (BST) Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 417CC4604E; Tue, 22 Jun 2021 18:00:09 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS; Tue, 22 Jun 2021 18:00:09 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.47.18]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15MH08SN028370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Jun 2021 18:00:08 +0100 Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , References: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> In-Reply-To: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> Date: Tue, 22 Jun 2021 18:00:06 +0100 Organization: Old Dog Consulting Message-ID: <0a8101d76788$0e1af5a0$2a50e0e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQKeL0b/5i17ua5CtPab+yN4aSHniqmSlCBw X-Originating-IP: 84.93.47.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1017-26236.001 X-TM-AS-Result: No--5.046-10.0-31-10 X-imss-scan-details: No--5.046-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1017-26236.001 X-TMASE-Result: 10--5.045700-10.000000 X-TMASE-MatchedRID: +f/wAVSGjui8rRvefcjeTb7u5vMMMVTtaMmm586o4gB/Z0SyQdcmEFEt MRGFGDWDb+7vqosU/TC7BxlnBatlVDdo3G+ad8Nf0XO+Yq6CqgIpA2ExuipmWiVuRe2PaRI7cfI ublHY1q0/yISm21cxkVv9ie1ACao8xBdQH2+4tBDwpAypldoLOb/I3arxTrviHzKz4AvJrgUhgV U1JTxZmMZG/XwAlayy3IsW8GtAmI+mWOD8X0TFhJr5ykm9NtIcIVpGz/U+S0ipjZQdHTnCmwKFZ 0L1cycYF2GG9DuV3YJGUJPwsrOuV9aSgJLPelTm+LORUvwlJdvjAcZeNJgY96Hr6eS9NQNKsOzO ncrmCoP3FLeZXNZS4JFOlJCK/1ftHwyRKA7hsdbGndwBzVZAKg6El4TvzUcw0+6OvTPS69kRRKY xqJyoQue/iaShuHdzftwZ3X11IV0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 17:00:18 -0000 I don't have a problem with this idea, but I also think it is massively = missing the point. The RFC Series is not owned by the IAB. Formerly it was owned by the RSE = and it will become owned by the RSWG&RSAB. Thus, decisions about creating new streams (as many as are wanted) will = be made by the RSWG&RSAB. So I don't think we need to document it, or if = we do, let's do it in a more general way such as... "The RSWG with approval of the RSAB may create additional streams as = necessary." Of course, a slightly tricky question is on which stream *this* document = will get published. Adrian -----Original Message----- From: Rfced-future On Behalf Of Eliot = Lear Sent: 22 June 2021 15:52 To: rfced-future@iab.org Subject: [Rfced-future] Consensus check: Issue 22 =E2=80=93 new stream = for RFC Editor In yesterday's meeting there was general consensus that there should be=20 a new stream, and that the RSE/A should manage it. The general argument = was that there should be no supervisory check performed by the IAB after = the RSAB has approved a document. Please send any concerns by 6 July. Eliot From nobody Tue Jun 22 10:16:21 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3193A0E03 for ; Tue, 22 Jun 2021 10:16:19 -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 HV6hNGHx-Phz for ; Tue, 22 Jun 2021 10:16:17 -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 043A13A0E00 for ; Tue, 22 Jun 2021 10:16:16 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lvk0U-0004QI-7O; Tue, 22 Jun 2021 13:16:14 -0400 Date: Tue, 22 Jun 2021 13:16:08 -0400 From: John C Klensin To: Brian E Carpenter , Eliot Lear cc: rfced-future@iab.org Message-ID: In-Reply-To: <511219a5-e451-3071-6f77-dac6d005192b@gmail.com> References: <9CCFECFF41DD399EA4AB89BE@PSB> <511219a5-e451-3071-6f77-dac6d005192b@gmail.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: [Rfced-future] A voice from the (perhaps lunatic) fringe (was: draft-saintandre-rfced-model-01.txt) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 17:16:19 -0000 Brian, TL:DR summary: We agree that this Program should not try to solve, or even seriously engage with that third issue. It could easily be a prince, perhaps an emperor, among rat holes. However I believe this effort should be mindful of it to avoid changing the RFC Editor Function in a way that would overconstrain that discussion when and if it occurs. ----- We don't disagree about what should be done in the near term, but let give a slightly different perspective.... --On Tuesday, June 22, 2021 08:28 +1200 Brian E Carpenter wrote: > John, > > I will respond later in more detail (e.g. when I'm no longer > trying to attend to the Webex meeting), but I'd like to say > one thing now: > >> (3) Core issue #3: What is a standard and what is a stable >> document? While, ideally, it should not be a required part of >> this discussion, it appears to me that there is an ongoing >> difference of opinion in the IETF was to whether standards >> (and perhaps IETF Stream documents in general) should be >> stable specifications that may periodically be revised or >> replaced but are otherwise threaded together with "updates" >> and "obsoletes" designations (possibly supplemented by >> organizing documents along the lines proposed by NEWTRK) or >> whether we want to move more toward living documents > Yes. And as you know better than anyone, this goes back 20 > years, and the bulk of the IETF and/or IESG has never wanted > to engage. Yes, but it would be equally reasonable to say that some of these issues with the RFC Editor function go back 20 (or 30 or more) years, that the bulk of the IETF has never wanted to engage in depth, and that we are where we are now (with the bulk of the IETF _still_ not engaged) only after a proposal that interacted with the "what is the Series for?" question produced a forceful (if short-lived) community response to one of the "who is the decision-maker and how are decisions made?" questions and that was followed, presumably coincidentally, by a series of administrative actions (and perhaps attitudes) that led to a resignation and a crisis that could not be ignored. Because of that, while I agree that Core Issue #3 is, and ought to be, of less immediate interest to this group/Program than the other two, I see it as inexorably intertwined with both the others and with what we are, and ought to be, doing here. > So IMNITLHO**, we (rfced-future) need to set that concern aside > for the purposes of this discussion, and they (the IETF) need > to put their own house in order. If the IETF comes back with > clearly defined requirements for a new kind of document, that > may or may not be a job for the RFC series. The counterargument (perhaps even too paranoid for me, but perhaps not), and IMPELHO [1], is that there are people participating in this effort who, deep down, believe that, in the modern age, many of the concepts and principles that drove the first 50 or so years of the RFC Series are simply obsolete, with notions of static/archival documents and not having all documents under the control of the IETF/IESG topping the list. If one believed that strongly enough [2], then, if this effort produced a structure that was inefficient or ineffective in getting documents out in a timely manner, it might not be a terrible outcome... because it would make it far easier to argue that we should abandon the current/failed way of doing things in favor of a model that better (and exclusively) served the needs of the IETF and served them through a much more dynamic set of documentation arrangements. If we make decisions that could lead to such outcomes -- i.e., that could have impact on, or reduce choices about, that third core issue -- we should be very, very, explicit about that. john > Brian Carpenter > > ** in my not in the least humble opinion [1] In my probably even less humble opinion [2] I am not paranoid enough to believe that anyone participating in this effort does or would behave this way, but I think the point is useful nonetheless. From nobody Tue Jun 22 10:20:17 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240383A0E23 for ; Tue, 22 Jun 2021 10:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 4omxUBCG4oDa for ; Tue, 22 Jun 2021 10:20:11 -0700 (PDT) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 954473A0E24 for ; Tue, 22 Jun 2021 10:20:11 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15MHK9d3030696; Tue, 22 Jun 2021 18:20:09 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E65DD46048; Tue, 22 Jun 2021 18:20:08 +0100 (BST) Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DA77F4604C; Tue, 22 Jun 2021 18:20:08 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS; Tue, 22 Jun 2021 18:20:08 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.47.18]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15MHK8cB021816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Jun 2021 18:20:08 +0100 Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , References: <5977bd11-ca97-6516-57ee-cb1f71ed92d3@lear.ch> In-Reply-To: <5977bd11-ca97-6516-57ee-cb1f71ed92d3@lear.ch> Date: Tue, 22 Jun 2021 18:20:06 +0100 Organization: Old Dog Consulting Message-ID: <0a8401d7678a$d92c8400$8b858c00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A85_01D76793.3AF16130" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQEw8AgyGmGIefgIjpcsVB4HhTPYgKxtLydg X-Originating-IP: 84.93.47.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1017-26236.001 X-TM-AS-Result: No--22.998-10.0-31-10 X-imss-scan-details: No--22.998-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1017-26236.001 X-TMASE-Result: 10--22.997800-10.000000 X-TMASE-MatchedRID: TmlY9+XBoTnxIbpQ8BhdbCxaglEO8YXM4NNiN6MhlPC4gUyzJIDbFkrq 9Go/uoBcx2uAPiRbl9xjjjwN+e2Pq/+ib4J8UFvalVHM/F6YkvRGI9Mwxz8yaYbY4t4Fw8BRLcZ GfN51yqgUG4ajH0IrW47gvOUZPpAt0USkb6XRrHnlCjTeYR3AAXFd5+Cf9M1DVyfzU4GikKbyPJ L3JcO6/eX69OtAtycbZ+8zf7X568SHdRPQsQpSrM9R/UqWnLW4OhJ9m53n4aBi9nX42xclV8DBo T9Fo4P/P2zusnonFBYObt0SH5YPyUdb73gUDwkXKwi7MItzaY2uiAW0p38/twsFkS6ogv1Kn3HS 2bO+krbCfvo3UgFFJH7Iz4Xfn0uR1LFdtmiebE6A3KVVsj8QDKgJ/sh288AnGHWakJc1ULypFku oLGicpBiZsVhauLEn4V06hzww1cbkWZrPAyKWDxlLm7Fc/E3pBaExZeqJZbLDv5dDcuT2eZmeFG asJpDYd8YnkYARK3YUAF4uBmvRkZXFjf0NEAcsU6s2nlVTnzX6C0ePs7A07dBWtiPydAf18ziao HEwkWQa2TcidXFLsPuK7/53SmViz26Iu4ObLUo= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Call for Adoption: draft-saintandre-rfced-model-01 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 17:20:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0A85_01D76793.3AF16130 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Notwithstanding ongoing discussions we should adopt this document now. Adoption, of course, does not imply agreement with the words in the = document, but you knew that. Adrian =20 From: Rfced-future On Behalf Of Eliot = Lear Sent: 22 June 2021 17:03 To: rfced-future@iab.org Subject: [Rfced-future] Call for Adoption: = draft-saintandre-rfced-model-01 =20 Dear Colleagues, As discussed in the May interim, we are now issuing a Call for Adoption = of draft-saintandre-rfced-model-01 as the draft this group will use as = intended output. We hope that this call is a mere formality. Our = procedures for content going into that draft and issues raised do not = change. The purpose of adoption is to make clear our group=E2=80=99s = ownership of its content and intent to pursue that work as WG output, = with the very generous and kind help of Peter. Please raise any concerns by 6 July 2021. Eliot ------=_NextPart_000_0A85_01D76793.3AF16130 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Notwithstanding ongoing discussions = we should adopt this document now.

Adoption, = of course, does not imply agreement with the words in the document, but = you knew that.

Adrian

 

From: Rfced-future = <rfced-future-bounces@iab.org> On Behalf Of Eliot = Lear
Sent: 22 June 2021 17:03
To: = rfced-future@iab.org
Subject: [Rfced-future] Call for = Adoption: = draft-saintandre-rfced-model-01

 

Dear Colleagues,

As discussed in the May interim, we are now = issuing a Call for Adoption of draft-saintandre-rfced-model-01 as the = draft this group will use as intended output.  We hope that this = call is a mere formality.  Our procedures for content going into = that draft and issues raised do not change.  The purpose of = adoption is to make clear our group=E2=80=99s ownership of its content = and intent to pursue that work as WG output, with the very generous and = kind help of Peter.

Please raise any concerns by 6 July = 2021.

Eliot

------=_NextPart_000_0A85_01D76793.3AF16130-- From nobody Tue Jun 22 11:26:48 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1D33A118D for ; Tue, 22 Jun 2021 11:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 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, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 yslCIv-L8QKF for ; Tue, 22 Jun 2021 11:26:43 -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 E06A73A1188 for ; Tue, 22 Jun 2021 11:26:41 -0700 (PDT) Received: from Lear-Air.local ([IPv6:2a02:aa15:4101:2a80:30b7:e5f4:91df:5ed5]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15MIQYQo433854 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 22 Jun 2021 20:26:34 +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=1624386394; bh=bMNsk7Oj/DyXyJoYQXJpkA3rLiE67yJfHg1MBXQ8Hwk=; h=To:References:From:Subject:Date:In-Reply-To:From; b=CR/7rOhl/lFEYBXpGpLoOEXbcAAgq2UgmY+KtWBmDHyvJV4hqezLAAwz7wL+NeOOT 4yvb/1CGa6hkl1rv0even3u6D3R5All1UbfKoctTqkQgxtqQcDAgKmw6Dk3UJFlZX0 Zs0KMskB6MO9zCOf72pJAxdhAHy3oAZP07y5Zb3o= To: adrian@olddog.co.uk, rfced-future@iab.org References: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> <0a8101d76788$0e1af5a0$2a50e0e0$@olddog.co.uk> From: Eliot Lear Message-ID: Date: Tue, 22 Jun 2021 20:26:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <0a8101d76788$0e1af5a0$2a50e0e0$@olddog.co.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qwcePI2rwmqVafMInYkObwKpcmwC7h3hB" Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 18:26:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qwcePI2rwmqVafMInYkObwKpcmwC7h3hB Content-Type: multipart/mixed; boundary="gnHxGQX1Cr2UOeDoVgvKNzAPYOLcAI7kF"; protected-headers="v1" From: Eliot Lear To: adrian@olddog.co.uk, rfced-future@iab.org Message-ID: Subject: =?UTF-8?Q?Re=3a_=5bRfced-future=5d_Consensus_check=3a_Issue_22_?= =?UTF-8?Q?=e2=80=93_new_stream_for_RFC_Editor?= References: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> <0a8101d76788$0e1af5a0$2a50e0e0$@olddog.co.uk> In-Reply-To: <0a8101d76788$0e1af5a0$2a50e0e0$@olddog.co.uk> --gnHxGQX1Cr2UOeDoVgvKNzAPYOLcAI7kF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Adrian, On 22.06.21 19:00, Adrian Farrel wrote: > "The RSWG with approval of the RSAB may create additional streams as ne= cessary." I think this is actually an open question.=C2=A0 What is the process for = creating a new stream?=C2=A0 Which body does that?=C2=A0 A stream usually= itself=20 represents an organization.=C2=A0 The RSAB wouldn't create orgs, tho perh= aps=20 they might recognize an org. Now Issue 73. Eliot --gnHxGQX1Cr2UOeDoVgvKNzAPYOLcAI7kF-- --qwcePI2rwmqVafMInYkObwKpcmwC7h3hB Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDSK1cFAwAAAAAACgkQh7ZrRtnSejMZ sggAkUKg80FkC0NPGGzYIJkr3ffY1d5NYMe0GhFTBazzp1hDTawJcJmCRA/yKLz1h69nHgqkC3JX 7XufHIEdleQiSLpVUb8/rAwbJ8kNouw4ipIWnhvZ+qUpzj3gjACR0qN2i2ewVmG2OkiKH6lgwiae DL5qV2mzexZQfpXZVn/KxceEIYQ5K8Hzvsdt/L+341PzRZEtK7Fzxmw0Vcixb13xbqvKZPfEp7qu 1S3ha6Od7dilk2TV/bpPEQaWAvw77E88UzN1HLxIxzzhyo2sXI05Hv7h35yNaCj5t7/0bGbqX3PU v6mo++15uCBrZm5zprR5835B2CrwYrIDTcHAWWQTCw== =HYx4 -----END PGP SIGNATURE----- --qwcePI2rwmqVafMInYkObwKpcmwC7h3hB-- From nobody Tue Jun 22 13:29:06 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5743A16E2 for ; Tue, 22 Jun 2021 13:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 RJj3tsxpYbCz for ; Tue, 22 Jun 2021 13:29:01 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 BA21C3A16E4 for ; Tue, 22 Jun 2021 13:28:59 -0700 (PDT) Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15MKSuGr006113; Tue, 22 Jun 2021 21:28:56 +0100 Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id ADEA14604A; Tue, 22 Jun 2021 21:28:56 +0100 (BST) Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A26CA46043; Tue, 22 Jun 2021 21:28:56 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs4.iomartmail.com (Postfix) with ESMTPS; Tue, 22 Jun 2021 21:28:56 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.47.18]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15MKSts9009622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Jun 2021 21:28:56 +0100 Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , References: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> <0a8101d76788$0e1af5a0$2a50e0e0$@olddog.co.uk> In-Reply-To: Date: Tue, 22 Jun 2021 21:28:53 +0100 Organization: Old Dog Consulting Message-ID: <0ace01d767a5$39001350$ab0039f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQKeL0b/5i17ua5CtPab+yN4aSHnigK0KP5NAbezZw2pb4sBYA== X-Originating-IP: 84.93.47.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1017-26236.002 X-TM-AS-Result: No--2.135-10.0-31-10 X-imss-scan-details: No--2.135-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1017-26236.002 X-TMASE-Result: 10--2.135100-10.000000 X-TMASE-MatchedRID: u7Yf2n7Ca/28rRvefcjeTb7u5vMMMVTtaMmm586o4gAZSz1vvG+0mneT 8UBawk/XyLw02+lay9yDcZNsbMgFcA8LKInWUps81a9nQumsfmopA2ExuipmWlAoBBK61BhcKMY zpi5TbqWaaBYwlL5lPpfucML7iAp6Eb0RuLqy8KGVUcz8XpiS9ARryDXHx6oXCDaSBZ23epqXid r9etFZ1v8nv9x3PStamKxXZqqGOgmwiGsT9HMfJhfqkKQlk1I5eFyzQYzPQ+Rhi+qQVejLGdG6R Yo2Y1dvRMR9kQkhA0GtqCg3ldkM2cfEYAf1qh/lngIgpj8eDcBTqzaeVVOfNfoLR4+zsDTt9xS3 mVzWUuB9IxzED4RL2TC2bm+IpRTvMvN/rHLA7NGQePyNBfl/1FcsN5Gz+oW7CjSsDX+d+Mb971q +mnxqjOyXtG142WwJIV6rstSLX5JTgxoB7fAIRk3+9BzFCkVzNAW83zYDw/v1OlCIPxKfizngMR AgrdeEPYigHtZ0QM5+3BndfXUhXQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 20:29:06 -0000 I think a stream exists because an organisation has requested to publish = within the RFC Series.=20 The owner of the Series surely decides whether to allow publication and = whether a new stream is appropriate. I'm also interested in how a stream is shut down. Who makes that = decision? Cheers, Adrian -----Original Message----- From: Eliot Lear =20 Sent: 22 June 2021 19:27 To: adrian@olddog.co.uk; rfced-future@iab.org Subject: Re: [Rfced-future] Consensus check: Issue 22 =E2=80=93 new = stream for RFC Editor Hi Adrian, On 22.06.21 19:00, Adrian Farrel wrote: > "The RSWG with approval of the RSAB may create additional streams as = necessary." I think this is actually an open question. What is the process for=20 creating a new stream? Which body does that? A stream usually itself=20 represents an organization. The RSAB wouldn't create orgs, tho perhaps=20 they might recognize an org. Now Issue 73. Eliot From nobody Tue Jun 22 14:16:48 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2A33A19FF for ; Tue, 22 Jun 2021 14:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 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.338, 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 P9lwru60oKu0 for ; Tue, 22 Jun 2021 14:16:42 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0: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 7FF893A1A0C for ; Tue, 22 Jun 2021 14:16:42 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id c5so560928pfv.8 for ; Tue, 22 Jun 2021 14:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=bHYuCqtGlVIebVxVLukkHUt9WsF3FE/d1fF/DI/dLkI=; b=YOj/iGDeA/riMub2ob2lKvsgGW+nL6Zizb3oegzkNjA4fEV6Gi5xy3KQkxF5Xd7kto Wwf2CXRf8fo0oIZKs/jfNvG9dpAEEQ6EzDcth899XgnX9sPQWzfb2V6gS9kTIN+fQOvS pt6FJeDFTjFo9LOmdc7Bx5X3p5oyUWJZuAe3uz+c/gDxnRPvQoEgzCoGQitYxkUG6dGC cNlzEGkH2LmmBXCuT1nTS1vsMs7TFk6QHOBz5Ix2XMH145IwdgtFw+WiIzOO3ZtPKtC7 a2tCoD8WNcY0VSg9IwBh0K2dE+rh5FuSgL/0wck+VGrbIz0F9sNqcSHLYAEdUB3198vS 0sJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bHYuCqtGlVIebVxVLukkHUt9WsF3FE/d1fF/DI/dLkI=; b=uUXxU8xTrZJTDxrBDmiZ/BdtgD+oMMEwtZ6PxpSSUP5rb7lmRM9Dw3OE2TVIyUZO7o +efQBrVueGha+GqXlCBVfIi37+rnIpbao5eIEd6if6FXLOARXFFIYeLyjDqM3TWX9uhj ENC0ynOOsjBtCV8fZh0ZgcN/ijCC2bCBxyfqWDLM2lBHIQIkRM7dIGnFY8dF+3hwgPNt 4L/AUiWmCfnV9DsDkAEmn56BBZGn3G8klHuFQhn3++ryIXFeoDNrvWgqeB/Pu6+0GDiZ ElA4sZ5qBe/hE1uhE84v5hTRCwT4InjDjIM5Ly531MJ3tplwnDvKDA5505hmON9PLCOX lK4A== X-Gm-Message-State: AOAM5329LkeWd9ldL+hXU3Asa+N8wNUR5+JqDw5ZdfUqt7hCMffshVYP cjzsIpi12ehgQzchcQoAgVApK5CcNQbsjg== X-Google-Smtp-Source: ABdhPJzpD06pj2HeSkKx2gWFyG2K1ALUOBizH3EAO9cUt5Mgk2S65SHXfxiMkbUuZPgm0huTWjg37A== X-Received: by 2002:aa7:9905:0:b029:301:ec7c:f73c with SMTP id z5-20020aa799050000b0290301ec7cf73cmr5500640pff.68.1624396601086; Tue, 22 Jun 2021 14:16:41 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id 92sm3312661pjv.29.2021.06.22.14.16.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Jun 2021 14:16:40 -0700 (PDT) To: adrian@olddog.co.uk, 'Eliot Lear' , rfced-future@iab.org References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> From: Brian E Carpenter Message-ID: <3c65c3f1-4932-5a1f-ab3f-cb393403be9f@gmail.com> Date: Wed, 23 Jun 2021 09:16:37 +1200 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: <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 21:16:47 -0000 I think this is right, but let's be clear: it says that the RSWG is infallible, as long as it is correctly seated when it speaks ex cathedra. [https://en.wikipedia.org/wiki/Papal_infallibility#Ex_cathedra] Regards Brian Carpenter On 23-Jun-21 03:10, Adrian Farrel wrote: > I completely agree with the sentiment, but I think the wording may have issues. > > What the proposal does is say what can be done "if there are concerns about the process followed by the RSWG." It does not say (but I think it is meant to imply) that the content of the decisions cannot be appealed. > > The "should" is also slightly ambiguous. > And "any action" presumably means the action being appealed. > > I would... > > Decisions of the RSWG can only be appealed on grounds of failure to follow the correct process. Such an appeal must be made to the RSAB within 30 days of the action being appealed. The RSAB will then decide whether the process was followed correctly. > > Cheers, > Adrian > > -----Original Message----- > From: Rfced-future On Behalf Of Eliot Lear > Sent: 22 June 2021 15:38 > To: rfced-future@iab.org > Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) > > The following text was proposed to address appeals of the RSWG: > >> Appeals of RSWG decisions can be made to the RSAB if there are >> concerns about the process followed by the RSWG. Appeals should be >> made within 30 days of any action. The RSAB then decides if the >> process has been followed. > > Please raise concerns by 6 July if you have any. > > Eliot > > > From nobody Tue Jun 22 14:20:48 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1462D3A1A2F for ; Tue, 22 Jun 2021 14:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.136 X-Spam-Level: X-Spam-Status: No, score=-3.136 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, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=joelhalpern.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 Z9vTFKsz350j for ; Tue, 22 Jun 2021 14:20:42 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 409C93A1A2C for ; Tue, 22 Jun 2021 14:20:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4G8fSn3YxHz1nw8q; Tue, 22 Jun 2021 14:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1624396841; bh=JilURQuhcVkprKfn5BsvZSsxjhPBTtbYL58WIV4AhfM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=D3iYw30HgEvrKlkeyQQ5fjyh4HU/wKPe6eFKp1xdpUVM+EQ1CIq62xMGL1/04vpM2 ED5wFXUpGrArjtyYeEpteUpjopMv94A5njsMdv6sPUIeDz9BFnRTUfeQl7NXqNTqK6 733uXzBOO1Q1Ewd2fS7+9pkB5ob/uZEt3P88KL5I= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4G8fSm6YVDz1nvHF; Tue, 22 Jun 2021 14:20:40 -0700 (PDT) To: Brian E Carpenter , rfced-future@iab.org References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <3c65c3f1-4932-5a1f-ab3f-cb393403be9f@gmail.com> From: "Joel M. Halpern" Message-ID: <56093fe9-3c39-3075-9b0f-cf82aff24f90@joelhalpern.com> Date: Tue, 22 Jun 2021 17:20:41 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <3c65c3f1-4932-5a1f-ab3f-cb393403be9f@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 21:20:47 -0000 No, at the very least the RSAB is allowed to say "no, this is wrong" separately from any formal appeal. We are not creating any other way to "appeal" the content of decisions. But we did include in other parts of the document that the RSAB is supposed to pay attention to feedback it receives during the final call for comment. WHile I have concerns withthis whole process, I do not have bettter answers. And we should avoid overstating the limitiations of teh construct we are building. Yours, Joel On 6/22/2021 5:16 PM, Brian E Carpenter wrote: > I think this is right, but let's be clear: it says that the RSWG is infallible, as long as it is correctly seated when it speaks ex cathedra. > > [https://en.wikipedia.org/wiki/Papal_infallibility#Ex_cathedra] > > Regards > Brian Carpenter > > On 23-Jun-21 03:10, Adrian Farrel wrote: >> I completely agree with the sentiment, but I think the wording may have issues. >> >> What the proposal does is say what can be done "if there are concerns about the process followed by the RSWG." It does not say (but I think it is meant to imply) that the content of the decisions cannot be appealed. >> >> The "should" is also slightly ambiguous. >> And "any action" presumably means the action being appealed. >> >> I would... >> >> Decisions of the RSWG can only be appealed on grounds of failure to follow the correct process. Such an appeal must be made to the RSAB within 30 days of the action being appealed. The RSAB will then decide whether the process was followed correctly. >> >> Cheers, >> Adrian >> >> -----Original Message----- >> From: Rfced-future On Behalf Of Eliot Lear >> Sent: 22 June 2021 15:38 >> To: rfced-future@iab.org >> Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) >> >> The following text was proposed to address appeals of the RSWG: >> >>> Appeals of RSWG decisions can be made to the RSAB if there are >>> concerns about the process followed by the RSWG. Appeals should be >>> made within 30 days of any action. The RSAB then decides if the >>> process has been followed. >> >> Please raise concerns by 6 July if you have any. >> >> Eliot >> >> >> > From nobody Tue Jun 22 14:31:27 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9596E3A1A97 for ; Tue, 22 Jun 2021 14:31:24 -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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=wLTW0qJn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UnpsAHDa 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 EiXkoQwICXoZ for ; Tue, 22 Jun 2021 14:31:19 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581203A1A92 for ; Tue, 22 Jun 2021 14:31:19 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 309875C00E1 for ; Tue, 22 Jun 2021 17:31:18 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute4.internal (MEProxy); Tue, 22 Jun 2021 17:31:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=RqHiINBxs3GTOc7TH5Ey8Rls7TE0b/+ 56q7lslmClsw=; b=wLTW0qJnaI3DUCiN6hJxmN/5rYWY4rUmuMVxq/+6yPJ2Xy5 SMm33mPJ5mobAwysaxZaPgm1moxJod4M4S4wWIoEtJk3QOdVmehpPCwjyDj8kGh7 EiGfCJO6afPFayMBwogUi31xurCHUPdx/BV5mrH/nOGkg/+SkDJbw5FUHpAVmqjL P24ywoTEGKfiDRI8SKsG+ehoDwUmM0KkLMRJIPsi/sUFLRHwjwweGkPF6owrsjZy YQFD1cDPut1FI1b47jURk2cFb8edoTKLpgZQO9w6gEQYri9bdyJdyQA6An2KXEV9 vCf6l+zcNrbUBB7UvHaOMuq/10Qu4Dh1wp1MliA== 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=fm3; bh=RqHiIN Bxs3GTOc7TH5Ey8Rls7TE0b/+56q7lslmClsw=; b=UnpsAHDaJHSIMhq1QedjVn gALIQXvTWmQmP4lXXS9mU/Atseor12lMcXBHqKRWn5zVGYMdwgLduB2kNIsOGUba tM6e4ImgLHgjphm/cjtz7Zal3x/h4h7d7qHuT4NA7IPKijXy2IeCbHqHbpm8xB6s wTx1pFO08k0iPB3sQ3cEBX8Q2qRnAQLw2yYGgz6C/KMFJemkQJAwdq9axJA5fDh0 yHbrJmQSFf3OFPNYGdSPqmEGcP1JQJfjAxYsDoKdfrq6Vl23kZxLX/ORXO/M2QX+ I1t+zMN6dIsW8sRMAzNIrz+4Jnm188vth+wmeVqRv8FmaBmnXiLYwSkX5Xr7KqkA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeeguddgudeiudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepheefteduudduhedtke fhvdfhteelffdujeegjeffheffveekudeigfeuveekfeelnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnh gvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 813C54E00AA; Tue, 22 Jun 2021 17:31:17 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-530-gd0c265785f-fm-20210616.002-gd0c26578 Mime-Version: 1.0 Message-Id: <7bda1df1-307b-4370-ad94-71af09af12c4@www.fastmail.com> In-Reply-To: <0ace01d767a5$39001350$ab0039f0$@olddog.co.uk> References: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> <0a8101d76788$0e1af5a0$2a50e0e0$@olddog.co.uk> <0ace01d767a5$39001350$ab0039f0$@olddog.co.uk> Date: Wed, 23 Jun 2021 07:30:56 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 21:31:25 -0000 On Wed, Jun 23, 2021, at 06:28, Adrian Farrel wrote: > I think a stream exists because an organisation has requested to > publish within the RFC Series. > The owner of the Series surely decides whether to allow publication and > whether a new stream is appropriate. > > I'm also interested in how a stream is shut down. Who makes that decision? My simple answer to both of these is: the RSWG proposes a change to the structure (add a stream, remove a stream) and the RSAB approves it. I think that both warrant publishing an RFC that documents the addition. From nobody Tue Jun 22 14:42:58 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026113A1AF8 for ; Tue, 22 Jun 2021 14:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 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.338, RCVD_IN_DNSWL_BLOCKED=0.001, 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 hcfg5h9ecrsn for ; Tue, 22 Jun 2021 14:42:52 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 BDB043A1B01 for ; Tue, 22 Jun 2021 14:42:52 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id e33so18174556pgm.3 for ; Tue, 22 Jun 2021 14:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=3IFlGKuXyPgb0Rx6ZOEE/W1yYxxEUfsg0dXWCaIVaWI=; b=cR4zoSqIFJXRMzsSPpNRkT9wut0jo1PevXbrC+sIfKLGYpgLtJ/JpNM6q87BBO7zAO Q1rdQgi0NhllAagQphAOP56NrXvP9CgZPGsWrnDhmjNjp1p6q34t06BSQ9dyR8mtDu9Z Ob3/97DUsAyLSbFSeKAZBW9l7ScQFrQh+1XNi5738VY7IM/a/4KcA5XNZ8+rrOSWPkCq w2JTrBl6Gom7QoUQPtXCcrJq1+gAx45VFeer1ga9I4bfPH1NXJ537RnWgBbhEMSChKPH jnhKZse/uqFugTE3LRdWmrTVR2+5+XA2VKulYM0SrFjal1QKc2YwP0ASLv1VN9fb9JGr Jfiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3IFlGKuXyPgb0Rx6ZOEE/W1yYxxEUfsg0dXWCaIVaWI=; b=rkRgx6vQK0PjqlW+jJ2Ddr+LnHlVG3e3g7OXshk2NvXjTLJIIb7vp7kqDXgd/z4pjs QsvW2PZPWC9AQbsXa6aZLGjzCIgslPPgq2j/Fdf6BwW4/gst1kd573GKWLuEz0cUwpsI pieEuFet4tdWp6q2vs0OwIoOCQGFEUw89q0MhTPCcvgCevU85cbPCvMDta3lUz7w66Om SDh8ApryXZmpBdS38G8q9zoNGkyisrfzURJYP5V2OZDgG8shEkP7/g6qHo/rLDc+9Q6J p3bud1cI9uG6c3aOSIAE/LagChJ1qY/hBR2nrxjdSzI9DICQtXzLeRDKAVqhDTo/S6Ps XBOg== X-Gm-Message-State: AOAM5303z6BDx25QoJ4u+9tZl0Iiq997Rf4Q2vI/vLf05BCFWWlPu6CS wDwdTGiGwQJO0hvh/C2F8atE94RJYD+oPA== X-Google-Smtp-Source: ABdhPJxO3646KMuG+2aXHkU5+0UtO4pCp5EasMshO4pMbKG/2MAS0x8I/JhjodfSLtIB0bfU7sT3Pw== X-Received: by 2002:a62:30c2:0:b029:289:116c:ec81 with SMTP id w185-20020a6230c20000b0290289116cec81mr5697892pfw.42.1624398171515; Tue, 22 Jun 2021 14:42:51 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id p10sm249635pfn.147.2021.06.22.14.42.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Jun 2021 14:42:50 -0700 (PDT) To: adrian@olddog.co.uk, 'Eliot Lear' , rfced-future@iab.org References: <5977bd11-ca97-6516-57ee-cb1f71ed92d3@lear.ch> <0a8401d7678a$d92c8400$8b858c00$@olddog.co.uk> From: Brian E Carpenter Message-ID: <6d33079c-4dc4-3c34-d500-7428f2c07977@gmail.com> Date: Wed, 23 Jun 2021 09:42:46 +1200 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: <0a8401d7678a$d92c8400$8b858c00$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Call for Adoption: draft-saintandre-rfced-model-01 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 21:42:57 -0000 +1 Regards Brian Carpenter On 23-Jun-21 05:20, Adrian Farrel wrote: > Notwithstanding ongoing discussions we should adopt this document now. >=20 > Adoption, of course, does not imply agreement with the words in the doc= ument, but you knew that. >=20 > Adrian >=20 > =C2=A0 >=20 > *From:*Rfced-future *On Behalf Of *Eliot=20 Lear > *Sent:* 22 June 2021 17:03 > *To:* rfced-future@iab.org > *Subject:* [Rfced-future] Call for Adoption: draft-saintandre-rfced-mod= el-01 >=20 > =C2=A0 >=20 > Dear Colleagues, >=20 > As discussed in the May interim, we are now issuing a Call for Adoption=20 of draft-saintandre-rfced-model-01 as the draft this group will use as in= tended output. =C2=A0We hope that this call is a mere formality. =C2=A0Ou= r procedures for content going into that draft and issues raised do not c= hange. =C2=A0The purpose of adoption is to make clear our group=E2=80=99s=20 ownership of its content and intent to pursue that work as WG output, wit= h the very generous and kind help of Peter. >=20 > Please raise any concerns by 6 July 2021. >=20 > Eliot >=20 >=20 From nobody Tue Jun 22 14:47:23 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243AB3A1B48 for ; Tue, 22 Jun 2021 14:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 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.338, RCVD_IN_DNSWL_BLOCKED=0.001, 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 HBUSq0GEWKsh for ; Tue, 22 Jun 2021 14:47:17 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 9C9803A1B42 for ; Tue, 22 Jun 2021 14:47:17 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id w71so631822pfd.4 for ; Tue, 22 Jun 2021 14:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=DB253+LPH2Vg4uogF3FDE/KK4fZYCu0tqgUloa79TWg=; b=om2wROilRVp3fYcJuVVjPxRqFVmg1vVL9DnWuN/wipEewSJN05lnyqVPUMo1BMY+CA vE2I0woPCggjBHvqD9C5AoXcnruKAjY5F8b7Wfe6hcLaymxD9hmEJXOtWrbNY50oWfgN 2V6jp+joCruTtaPPMm4Mol4vqBgsGHs87sg40eN11j9e2pLAEO4/kBZX/oNKh1YxJeR3 a8YvTcM78DyIlrUxLbThjiXi+wTP/8D1R6VMofymWS+JU5pjUgbAj03ykDqt9bR1UrJH dyYTC4b+lF9O00HUa/S2gPNLLq1jmBKzYgMCcArFvJc8N5g0dQOjFQ5xbBJe7ITd9Qpa tmtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DB253+LPH2Vg4uogF3FDE/KK4fZYCu0tqgUloa79TWg=; b=IY+8jY79JQFSmo+tlnRLGAJxq+KpFIE4M6DCWCwtbWZUtQQOLpi7U6Z7MU35VTKyno YU85ZskNwJW/D3S3ReozlL7KC646fDTjyKnxt60axp/duD5dIhrWpeQObeOM8saY4u5X rzMBE6wamaOiFZynJX0tKAOyqtJBnEZMkvB8e5WTDN4xkv7R5/0YMi2ClAgnIXEs/vsD PqgyjlYxWm/17L+6conFF9fX5iYyj3Zz5ryDpAnLAAREBHCKhYClMTR9oJesyQcJK4SJ 2G/6JQQlJ6YnL4CXblv4BfUmdNvVGWJsJOmzEMqXiNUkuFQDz60wTKSRG8dR/QLdEnvO leRw== X-Gm-Message-State: AOAM533WJE+JY9X0SgQ11I9FmvRVdPiqm/v/5od31lAVyFw28faucViS +ThGzfjglEda8P87RRwv7ghPX60deUlFcg== X-Google-Smtp-Source: ABdhPJwSSxhBUJ8sCbPpxNefmpuB3eAEhh4Ai73PjsC7ywYTZn4ySxM+7VSS4Uwxkkj3eTYuoK4t5A== X-Received: by 2002:a63:b0b:: with SMTP id 11mr637964pgl.341.1624398436556; Tue, 22 Jun 2021 14:47:16 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id mj17sm3215544pjb.12.2021.06.22.14.47.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Jun 2021 14:47:14 -0700 (PDT) To: "Joel M. Halpern" , rfced-future@iab.org References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <3c65c3f1-4932-5a1f-ab3f-cb393403be9f@gmail.com> <56093fe9-3c39-3075-9b0f-cf82aff24f90@joelhalpern.com> From: Brian E Carpenter Message-ID: <2c37340c-e746-bc19-f710-172b208d6810@gmail.com> Date: Wed, 23 Jun 2021 09:47:11 +1200 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: <56093fe9-3c39-3075-9b0f-cf82aff24f90@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 21:47:22 -0000 On 23-Jun-21 09:20, Joel M. Halpern wrote: > No, at the very least the RSAB is allowed to say "no, this is wrong" > separately from any formal appeal. We are not creating any other way > to "appeal" the content of decisions. But we did include in other parts > of the document that the RSAB is supposed to pay attention to feedback > it receives during the final call for comment. Right, but all it can do after that is remit the document back to the RSWG. I think that's OK. Brian > WHile I have concerns withthis whole process, I do not have bettter > answers. And we should avoid overstating the limitiations of teh > construct we are building. > > Yours, > Joel > > On 6/22/2021 5:16 PM, Brian E Carpenter wrote: >> I think this is right, but let's be clear: it says that the RSWG is infallible, as long as it is correctly seated when it speaks ex cathedra. >> >> [https://en.wikipedia.org/wiki/Papal_infallibility#Ex_cathedra] >> >> Regards >> Brian Carpenter >> >> On 23-Jun-21 03:10, Adrian Farrel wrote: >>> I completely agree with the sentiment, but I think the wording may have issues. >>> >>> What the proposal does is say what can be done "if there are concerns about the process followed by the RSWG." It does not say (but I think it is meant to imply) that the content of the decisions cannot be appealed. >>> >>> The "should" is also slightly ambiguous. >>> And "any action" presumably means the action being appealed. >>> >>> I would... >>> >>> Decisions of the RSWG can only be appealed on grounds of failure to follow the correct process. Such an appeal must be made to the RSAB within 30 days of the action being appealed. The RSAB will then decide whether the process was followed correctly. >>> >>> Cheers, >>> Adrian >>> >>> -----Original Message----- >>> From: Rfced-future On Behalf Of Eliot Lear >>> Sent: 22 June 2021 15:38 >>> To: rfced-future@iab.org >>> Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) >>> >>> The following text was proposed to address appeals of the RSWG: >>> >>>> Appeals of RSWG decisions can be made to the RSAB if there are >>>> concerns about the process followed by the RSWG. Appeals should be >>>> made within 30 days of any action. The RSAB then decides if the >>>> process has been followed. >>> >>> Please raise concerns by 6 July if you have any. >>> >>> Eliot >>> >>> >>> >> From nobody Tue Jun 22 15:01:08 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A7B3A1BC2 for ; Tue, 22 Jun 2021 14:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 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.338, RCVD_IN_DNSWL_BLOCKED=0.001, 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 FKVU4rftBuhc for ; Tue, 22 Jun 2021 14:59:21 -0700 (PDT) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 982543A1BC0 for ; Tue, 22 Jun 2021 14:59:21 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id f10so35938plg.0 for ; Tue, 22 Jun 2021 14:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=stQZF9RRnGOoXycMGyEEiHwVZCoILz6B3EnRFN34cdE=; b=qaQli51vQEsaX61B39z8MlLpfO87Ic98ycEHyI7fAGfoXSIbm2etkZxBlHkVlalWZK 73Kv6QK9VdZwKnFa3rikn4lqm5YmGDRpflGSgLQ0SPfTNPK3Bh7KlApYftd0QT5rT0MU O3fGpcz7Ln9wF5gVnRB7noeY3jP9gspd+yMvyoXV4+ZMhyYybMn9Fpo2xNZpz8MQpw/K w53NW+6Si/Mori+4FfU0xQ0szvWysB3r+jvHZre/RYVtWyGJsAWGxV83iILBguVcWNaG +BO1UhXqZHivOeShS+Wp2tT2vTLu1UzbnUq9pDY4T0HP2pWSJor0bL5Ev6LzMoHKfFre cuDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=stQZF9RRnGOoXycMGyEEiHwVZCoILz6B3EnRFN34cdE=; b=tLLFAnOciG38k32I1/IsV9LTAG2UDFxQdrdfJA2PD5jdbUcNqWIp+TCeSBF8L4cJMB 9BScis4/dmeqf0C8xSD9YbmScqfgMsfS+2nfFIktofkef8ZO0OyQXrNo04K2L/C6eYGg xMbN+9DSDNXIyPKSNhBq9lk972Y6flOcLz49x/rUJ8l3yzgJH0F5Ifw9LLt3IyRSeDjE ODIQPWx1I5yGxH/buxRyRQvGOwRt0gmaTruz2/atLMa4Ru/UInGt2Fz/ov2iWLqzxDeW q2KP5x/PmwrMF9FZWLhvf7ysgLBdqQbGRyRVG64U9Xy4yjWm52KSf2358BIXKp8NgLXG sfew== X-Gm-Message-State: AOAM531ceDsW3uMqADe9QvsvC6gqV8EXQ3Xdr50dhUkHoxi3UZegaksz KwBegzE9uPiw4Cw8DKcgKXwactin4QM9TA== X-Google-Smtp-Source: ABdhPJzE/ayVD9iPBgbyY4N0llxYFRyLPOY6MQEENUQHUUCnFvrM0FsHjdS2YUcxteljqY8kheORvw== X-Received: by 2002:a17:902:8b8a:b029:108:7849:dae0 with SMTP id ay10-20020a1709028b8ab02901087849dae0mr24060552plb.36.1624399160348; Tue, 22 Jun 2021 14:59:20 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id v1sm3100585pjg.19.2021.06.22.14.59.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Jun 2021 14:59:19 -0700 (PDT) To: adrian@olddog.co.uk, 'Eliot Lear' , rfced-future@iab.org References: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> <0a8101d76788$0e1af5a0$2a50e0e0$@olddog.co.uk> From: Brian E Carpenter Message-ID: Date: Wed, 23 Jun 2021 09:59:16 +1200 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: <0a8101d76788$0e1af5a0$2a50e0e0$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 21:59:26 -0000 On 23-Jun-21 05:00, Adrian Farrel wrote: > I don't have a problem with this idea, but I also think it is massively=20 missing the point. >=20 > The RFC Series is not owned by the IAB. Formerly it was owned by the RS= E=20 Well, it all depends on what you mean by "owned". The IETF has a BCP that=20 says: "The IAB must approve the appointment of an organization to act as RFC Editor and the general policy followed by the RFC Editor." so that is going to need changing in the not too distant future. The copyright in the RFC Series is currently owned by the IETF Trust (to = over-simplify things in a way that an IPR lawyer would hate). > and it will become owned by the RSWG&RSAB. Not really. They will "own" the policy-formation bit. =20 > Thus, decisions about creating new streams (as many as are wanted) will=20 be made by the RSWG&RSAB. So I don't think we need to document it, or if = we do, let's do it in a more general way such as... >=20 > "The RSWG with approval of the RSAB may create additional streams as ne= cessary." >=20 > Of course, a slightly tricky question is on which stream *this* documen= t will get published. Exactly why IMHO we need to create the editorial stream and fix the IAB c= harter, simultaneously with publishing the new model in the editorial sch= eme. Brian >=20 > Adrian >=20 > -----Original Message----- > From: Rfced-future On Behalf Of Eliot Le= ar > Sent: 22 June 2021 15:52 > To: rfced-future@iab.org > Subject: [Rfced-future] Consensus check: Issue 22 =E2=80=93 new stream = for RFC Editor >=20 > In yesterday's meeting there was general consensus that there should be=20 > a new stream, and that the RSE/A should manage it. The general argumen= t=20 > was that there should be no supervisory check performed by the IAB afte= r=20 > the RSAB has approved a document. >=20 > Please send any concerns by 6 July. >=20 > Eliot >=20 >=20 >=20 From nobody Tue Jun 22 15:01:33 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4493A1BD4 for ; Tue, 22 Jun 2021 15:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 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.338, RCVD_IN_DNSWL_NONE=-0.0001, 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 xAb0Rjpx0OA9 for ; Tue, 22 Jun 2021 15:01:28 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 EC0B93A1BD2 for ; Tue, 22 Jun 2021 15:01:27 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id v7so18223461pgl.2 for ; Tue, 22 Jun 2021 15:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Byfwu+722Yo/eqzJjJuKadsR7quoQ1flxKtKFZqOrFE=; b=jEBXU+qU8/DV8Yq6H28AYNWD3uVgZ7c1TWZao/RU/U5Q7/DDZFkyG/M1zNUmwhAeWn aBBrWMjjZS8uK3fZVdroRcF4+K5aUrI5dqBM8ng9pCquZs65TZzthVrrbntHxpUvK4Ps +QH3Ym+u4pGFaEjPJct0GSsIcz1G8G18xoYMZLUBn83TCDRSCWlQOpf/w/gXtJSKzQB0 jKm5H8KKnR16KvtoUiwrIygG9np1uATIjFnBOgcW5ex3q8iHgF32ZAQZXV1xMEDOWn8p TEytZ7QdSWpEz1q0F/WqzeOgCXw7/Tli99LcP2VTAC0i1B7+yzPsEHbxgcD+TXPE3uA8 vv8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Byfwu+722Yo/eqzJjJuKadsR7quoQ1flxKtKFZqOrFE=; b=HCkXfsugPQsT9Vr3/EGBj6fpBrejHmS51PSNAUPh73IubGfA1qCugR4PRVJUKgmAKK NYZYsokGe4YJTtBsPnkRFpcsev3d3M62ZmURkxr5ccvCOqQAgoJTbMvhpc/wuPS03ZKW dXsUmN3EkN6B/m202sJMoNVhDlUq/B/2ZaQTE1vAAy1g5ZSwUYHRXwSxYoJISKHlqsVm sPwtWY0h3eF9d7eZQSlX/erXsf0tsWm/NecEj1Abn3qCE4wA5IABLyFhnA7k07IGkRAV ealb2jUk7+dZuLVWCkieM7ba5qIJuLEKitvpRcLiO6nnCO91aK82NjlA1H8Sq99lWNK2 Y/Ew== X-Gm-Message-State: AOAM530zMU7XuKB1gAra9LdJE+uCBwUNaPtigVBg1L2fJJrRX/WKZ/DB 5akyyJWSIWUKch99Z9rN01GST+8ptxMwvg== X-Google-Smtp-Source: ABdhPJyow7oHCvRgeGx63MwWoVUpkSyhk5Kl0B+eL38qAiu17m2mR1sj6AwBHc2GmRAHcAKZ/sZPJw== X-Received: by 2002:a63:f20:: with SMTP id e32mr703884pgl.235.1624399286532; Tue, 22 Jun 2021 15:01:26 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id w2sm3169362pjq.5.2021.06.22.15.01.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Jun 2021 15:01:26 -0700 (PDT) To: Martin Thomson , rfced-future@iab.org References: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> <0a8101d76788$0e1af5a0$2a50e0e0$@olddog.co.uk> <0ace01d767a5$39001350$ab0039f0$@olddog.co.uk> <7bda1df1-307b-4370-ad94-71af09af12c4@www.fastmail.com> From: Brian E Carpenter Message-ID: <47618d03-3136-a4db-cd5b-66a1e89216ac@gmail.com> Date: Wed, 23 Jun 2021 10:01:22 +1200 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: <7bda1df1-307b-4370-ad94-71af09af12c4@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 22:01:29 -0000 On 23-Jun-21 09:30, Martin Thomson wrote: > On Wed, Jun 23, 2021, at 06:28, Adrian Farrel wrote: >> I think a stream exists because an organisation has requested to >> publish within the RFC Series. >> The owner of the Series surely decides whether to allow publication and >> whether a new stream is appropriate. >> >> I'm also interested in how a stream is shut down. Who makes that decision? > > My simple answer to both of these is: the RSWG proposes a change to the structure (add a stream, remove a stream) and the RSAB approves it. I think that both warrant publishing an RFC that documents the addition. Fully agreed, except that as just noted, I believe that creating the editorial stream, publishing the new model, and fixing the IAB charter must be done as a piece of synchronized swimming. Brian C. From nobody Tue Jun 22 15:20:13 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4C83A1C8A for ; Tue, 22 Jun 2021 15:20:11 -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, 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 1NK_9vR8SDX1 for ; Tue, 22 Jun 2021 15:20:07 -0700 (PDT) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 ECEA83A1C89 for ; Tue, 22 Jun 2021 15:20:06 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id x1so409400vsc.1 for ; Tue, 22 Jun 2021 15:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jz1cC3mR9qGuADomNQdXfvyb01/wjZFt4hxw7i3eiVQ=; b=Qx34f7yrttpzGh0sp78pA59twD2ueyH4evTEIr/gJiVCwKz5bPs41N4nsswXtKvuEa 649dO2YnzsAVY2UretM3dAVrBCXooeiWrKQoAUNtzn1n+h75ptX5QZdCXHi+rEiqP02b 7v2giiV9RaZR5qND4rxjGLtrxL1NTo6+ZNE6e239y+Ym4DTPR7ScyIlEBE8bOofvWrat 3+wbytP/HfvxIEFsBZ1wWiIAyfWcRenYBGOYiABQQ788tjxj9tB9HKVocNHvHboMdgBP DljJXx6KVNI89ceX3B6Q+AlsjCjkBqj9e+oQwUrdgnUyfeDn3SbNE1Don5cw2YIl+XZH BMJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jz1cC3mR9qGuADomNQdXfvyb01/wjZFt4hxw7i3eiVQ=; b=PIAaZmagGmd2fcxB3jLL1cEnK/xrYH346y2xBtg3NJi69y1/H6rEADmUHKIpBInTQW lRSNNKA9sQMXX7wiYTKralYb3maRcQLxTVHgcorQblHRe0x3IWcbIHTuuc6LsLX03xzI 5OSGcrgSCPRU8beyPTPh876cVsga31reHjzfmYV3CDxPcMB5DKGvLLhjGkW11Q2OvYDq GVLx26DKARYyR9CRUaktXwynizigP7fAWsN2JFsjy8uHjz2h5MlRo/fhMP7ezWQZ24+f b1fbnK+1BTTp7FTzaZbDwNSQD4lCPyeGTsOQNJg34LsJ/CWVH8IbjtQByxV6/VoW6Trh SOxw== X-Gm-Message-State: AOAM533o1c8bWkGRP8XEUyOU3ILNmSwXZsqKhr9WSaZs+12pMn6BVP0V qvtqt3WCpEVW+KPAZkdTYrQr/GWbY4q08Atu0uI+50/Yjig= X-Google-Smtp-Source: ABdhPJznAu7LSbuI/qzVCegq6mv855fI8wri9MptFygsLuFrVUqhse5thQbKG6GeMS/ajje1KZeWZqroJxuYL/i9tD8= X-Received: by 2002:a05:6102:10c8:: with SMTP id t8mr14354643vsr.27.1624400404231; Tue, 22 Jun 2021 15:20:04 -0700 (PDT) MIME-Version: 1.0 References: <5977bd11-ca97-6516-57ee-cb1f71ed92d3@lear.ch> In-Reply-To: <5977bd11-ca97-6516-57ee-cb1f71ed92d3@lear.ch> From: Nevil Brownlee Date: Wed, 23 Jun 2021 10:19:37 +1200 Message-ID: To: Eliot Lear Cc: rfced-future@iab.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Call for Adoption: draft-saintandre-rfced-model-01 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 22:20:12 -0000 +1 Cheers, Nevil On Wed, Jun 23, 2021 at 4:03 AM Eliot Lear wrote: > > Dear Colleagues, > > As discussed in the May interim, we are now issuing a Call for Adoption o= f draft-saintandre-rfced-model-01 as the draft this group will use as inten= ded output. We hope that this call is a mere formality. Our procedures fo= r content going into that draft and issues raised do not change. The purpo= se of adoption is to make clear our group=E2=80=99s ownership of its conten= t and intent to pursue that work as WG output, with the very generous and k= ind help of Peter. > > Please raise any concerns by 6 July 2021. > > Eliot > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 ----------------------------------- Nevil Brownlee, Taupo, NZ From nobody Tue Jun 22 16:31:18 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71BD93A1F42 for ; Tue, 22 Jun 2021 16:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=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=nthpermutation-com.20150623.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 sHZfegbW_UUm for ; Tue, 22 Jun 2021 16:31:13 -0700 (PDT) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 503D83A1F3F for ; Tue, 22 Jun 2021 16:31:13 -0700 (PDT) Received: by mail-qv1-xf2c.google.com with SMTP id r19so495951qvw.5 for ; Tue, 22 Jun 2021 16:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=h88HqV72KH5Wxu0k8METr0J9qdoEYFiba9mtzrn61Fk=; b=RQRFYxBBuuohh0ZY8AZSnwbJodE191q27pdZLuSb/Mw6CndOrL7jwtz5oA2C/wubGo ruuY288nv6bTQOdLjEsdzmla8UajgM156KVdtBJ1O+BNmcDxGKz0xt4fr83pelxmT/PU PasLdRjL1rFLy2Wdw8xrRfV2d9FWpaIa6srTbhwA/UYSI/rxQLNQFybztcb4mSVn2qs1 nktC5/Ye8i+0LloGWCIOYhRBbz7TRzPaAw+dyq4gLQJxFS4CWELC5H8gChI3kvFUa8v5 zKfvBiZJsFF3lxeGbNVrYczonKRjkho/jz29deXP9iONTEfV9Pc3nQtq58YXFi2Tnz/c awIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=h88HqV72KH5Wxu0k8METr0J9qdoEYFiba9mtzrn61Fk=; b=e+ju840Jk+A/5AzSSHRgT5bNNJi5U9EuXTkG9YwAIYHB53eYOqu8M/0Rz+vMYsdoOt 1NEgSonDvzHGNphBk5avfxu3Ga/oTmPLANdfas0vJI1Brzcl9K8Bmy0iiLP4jSM6yygT Z0oGXnm/PhkkBaMRyRpKRvoCGkNn+9phsikvGStASIwB1rrFwDD8P3Ataud/v1RBDYdO P9Qk5fQtWwqZbBt7WrAdleRNY/ridsaVEsgEMb8z62MsUp6EG1C6XRmQ1C+k52WXaFmj o7c6Bvh0ucGM7KnWjTz1W3xD1NW5zr5YFTT+GtKkbJ+e4XN/uP+Rr3ctpI/4MiFcFPfY 7Glw== X-Gm-Message-State: AOAM5304wsmFUi1VvhrJ4skcRSSH5KHGpqmq/epgziShyX+pXesiObxM p2vf/7TfmHUqpbUxwmFHAuTt5+8ZBgH28DoI X-Google-Smtp-Source: ABdhPJwaj7in5KywdNrvYagc00A1tjgc7HI4JZkA+GzpV3R6aoTVQiozTTurg0Q4tc3jXiSxDJ6RBQ== X-Received: by 2002:a05:6214:242f:: with SMTP id gy15mr271942qvb.9.1624404671094; Tue, 22 Jun 2021 16:31:11 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id k139sm14376970qke.96.2021.06.22.16.31.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Jun 2021 16:31:10 -0700 (PDT) To: rfced-future@iab.org References: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> <0a8101d76788$0e1af5a0$2a50e0e0$@olddog.co.uk> <0ace01d767a5$39001350$ab0039f0$@olddog.co.uk> <7bda1df1-307b-4370-ad94-71af09af12c4@www.fastmail.com> <47618d03-3136-a4db-cd5b-66a1e89216ac@gmail.com> From: Michael StJohns Message-ID: <492d7b65-33b9-e749-3297-85fe6779531c@nthpermutation.com> Date: Tue, 22 Jun 2021 19:31:09 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <47618d03-3136-a4db-cd5b-66a1e89216ac@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 23:31:16 -0000 On 6/22/2021 6:01 PM, Brian E Carpenter wrote: > On 23-Jun-21 09:30, Martin Thomson wrote: >> On Wed, Jun 23, 2021, at 06:28, Adrian Farrel wrote: >>> I think a stream exists because an organisation has requested to >>> publish within the RFC Series. >>> The owner of the Series surely decides whether to allow publication and >>> whether a new stream is appropriate. >>> >>> I'm also interested in how a stream is shut down. Who makes that decision? >> My simple answer to both of these is: the RSWG proposes a change to the structure (add a stream, remove a stream) and the RSAB approves it. I think that both warrant publishing an RFC that documents the addition. > Fully agreed, except that as just noted, I believe that creating the editorial stream, publishing the new model, and fixing the IAB charter must be done as a piece of synchronized swimming. Nah.  The last can be done by something like" "This document supersedes and replaces any previous grant or assumption of authority to the IAB  claimed in the IAB charter (ref...) or other documents as applies to the selection and oversight of the RFC Editor  and the RFC series".   Add "Updates: " to the tag line to refer back to the IAB charter.  No reason to require anything more than that I would expect. For the stream:  "This document mandates the creation of the Editorial stream to be managed by the RSA/E and for the publication of documents created through the auspices of the RSWG and the RSAB."   Maybe one or both additional statements: "Stream is limited to documents that affect the operation, publication and sustainment of the RFC Series" and "The RSWG and RSAB shall issue additional documents as necessary to refine the processes for acceptance and publication of documents on the Editorial stream and the implementation of related changes to the operation of the RFC publication process." Mike > > Brian C. > > From nobody Tue Jun 22 16:44:36 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A333A1FA3 for ; Tue, 22 Jun 2021 16:44:34 -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, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 zHwIHPWxbPtO; Tue, 22 Jun 2021 16:44:28 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 1D47B3A1FA2; Tue, 22 Jun 2021 16:44:27 -0700 (PDT) From: Jay Daley Message-Id: <1841B01F-42B9-4515-9819-1CA14FA5FA65@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_E77B967F-8C73-4044-B9FF-9D3EBC17D27D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Wed, 23 Jun 2021 11:44:24 +1200 In-Reply-To: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> Cc: rfced-future@iab.org To: Eliot Lear References: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 23:44:34 -0000 --Apple-Mail=_E77B967F-8C73-4044-B9FF-9D3EBC17D27D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23/06/2021, at 2:51 AM, Eliot Lear wrote: >=20 > In yesterday's meeting there was general consensus that there should = be a new stream, and that the RSE/A should manage it.=20 Thinking about this overnight, it seems misaligned with the rest of the = proposed new structure for the RSE/A to manage this stream. The new = process is quite clear that all of the content of this new stream is = generated by the RSWG and approved by the RSAB, so would it not make = more sense for the RSAB to manage this stream? If not then I=E2=80=99d = like to understand why it should be the RSE/A and what "manage" means in = practice given this new process, because AFAICT it doesn=E2=80=99t mean = anything. Jay > The general argument was that there should be no supervisory check = performed by the IAB after the RSAB has approved a document. >=20 > Please send any concerns by 6 July. >=20 > Eliot >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_E77B967F-8C73-4044-B9FF-9D3EBC17D27D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 23/06/2021, at 2:51 AM, Eliot Lear <lear@lear.ch> = wrote:

In yesterday's meeting there was general consensus that there = should be a new stream, and that the RSE/A should manage = it. 

Thinking = about this overnight, it seems misaligned with the rest of the proposed = new structure for the RSE/A to manage this stream.  The new process = is quite clear that all of the content of this new stream is generated = by the RSWG and approved by the RSAB, so would it not make more sense = for the RSAB to manage this stream?  If not then I=E2=80=99d like = to understand why it should be the RSE/A and what "manage" means in = practice given this new process, because AFAICT it doesn=E2=80=99t mean = anything.

Jay

The general argument was that there should be no supervisory = check performed by the IAB after the RSAB has approved a document.

Please send any concerns by 6 July.

Eliot


--
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

-- 
Jay Daley
IETF = Executive Director
jay@ietf.org

= --Apple-Mail=_E77B967F-8C73-4044-B9FF-9D3EBC17D27D-- From nobody Tue Jun 22 17:22:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819F23A20DD for ; Tue, 22 Jun 2021 17:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 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.338, RCVD_IN_DNSWL_BLOCKED=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 OCMNQSXth-7s for ; Tue, 22 Jun 2021 17:22:20 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 10FB23A20DC for ; Tue, 22 Jun 2021 17:22:19 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id x16so843450pfa.13 for ; Tue, 22 Jun 2021 17:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=wJ027ZgE+pFqRZWMHst3lXbxVZcWgqyCqgT7e3OqMCA=; b=YhOs9uLfr+TvriUfIZr0wGss2bGsXSZrMifg3eGzE+io86g9RwIlTLn5bPQC4bYzL+ /Pi9ZpvHLkFNAONSgVNxdOnLFzPx39RffBZ19XkMKRC4cB2PqQvumiu3oh52NidHjfi3 tmxd/Hw9RSHXmqeulryjqhFpQOM8gH/UlsShYQ/kqearO6WCvbSF9lTyqy+ZqnkNTFH0 mw8gMCT+rPsblqVZv+NHeDQqbjc+v1couCQkwKulwJgN+h5g8xZoWythJsiNGThsG4Ie 01gmz1M4R4JwzKwh07q1lTMTFFu4WSYKqFsTZ5qJEi+rVSe48cND2mHZAsfbVk013JRX BfEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wJ027ZgE+pFqRZWMHst3lXbxVZcWgqyCqgT7e3OqMCA=; b=UKGETSj8/OQ4GuFCbtrddir6P29ZBHO7fMhhEpoyyJBl4qUM1xE7oX7vr4YxJEOFhp mOM12W5I+bOEOvaSV489L/qx2KkVzE9j163YcXd3qvpmjmRgHBnNz5vs/WtVClURjSUY esHxTSt4HxTC6YpG5WMNTS9XWux6U/mngLlhAFv9I4MBa5jYKfJDXXdNN3gFtaknEDee cBUWeb7bA34uZRL/qSVuXUcZceREhbFPgk+H62IZfQ30Uyp3jYpftoettIXXPI6LOZHO V8d25Xny/Np+SzLFGNaZMqzOr7q3kop+5yf7eSpmkNX6CNWBX0WHe2CxE3A6s79zSa+N 99PA== X-Gm-Message-State: AOAM533Hdt8RVY42ymaWPgWaBj71lIQ7SIXucQUfqwHq4FUJhvFm/zpA gXw+xtIMAz5IhNfcj2qnGWBRQrcaGTWCYw== X-Google-Smtp-Source: ABdhPJwC6qG/IopUEAs/FxUyzUkQabJiaTxM4h85yN4j6iV6ipmTmsZagfGyy7ytDx0bJrzLloOmtw== X-Received: by 2002:aa7:953c:0:b029:305:1028:8f45 with SMTP id c28-20020aa7953c0000b029030510288f45mr6168374pfp.11.1624407738746; Tue, 22 Jun 2021 17:22:18 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id g17sm21434943pgh.61.2021.06.22.17.22.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Jun 2021 17:22:18 -0700 (PDT) To: Michael StJohns , rfced-future@iab.org References: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> <0a8101d76788$0e1af5a0$2a50e0e0$@olddog.co.uk> <0ace01d767a5$39001350$ab0039f0$@olddog.co.uk> <7bda1df1-307b-4370-ad94-71af09af12c4@www.fastmail.com> <47618d03-3136-a4db-cd5b-66a1e89216ac@gmail.com> <492d7b65-33b9-e749-3297-85fe6779531c@nthpermutation.com> From: Brian E Carpenter Message-ID: <16ab1107-6e4c-aaa4-80ef-7675ca05b13a@gmail.com> Date: Wed, 23 Jun 2021 12:22:14 +1200 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: <492d7b65-33b9-e749-3297-85fe6779531c@nthpermutation.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 00:22:23 -0000 On 23-Jun-21 11:31, Michael StJohns wrote: > On 6/22/2021 6:01 PM, Brian E Carpenter wrote: >> On 23-Jun-21 09:30, Martin Thomson wrote: >>> On Wed, Jun 23, 2021, at 06:28, Adrian Farrel wrote: >>>> I think a stream exists because an organisation has requested to >>>> publish within the RFC Series. >>>> The owner of the Series surely decides whether to allow publication = and >>>> whether a new stream is appropriate. >>>> >>>> I'm also interested in how a stream is shut down. Who makes that dec= ision? >>> My simple answer to both of these is: the RSWG proposes a change to t= he structure (add a stream, remove a stream) and the RSAB approves it. I=20 think that both warrant publishing an RFC that documents the addition. >> Fully agreed, except that as just noted, I believe that creating the e= ditorial stream, publishing the new model, and fixing the IAB charter mus= t be done as a piece of synchronized swimming. >=20 > Nah.=C2=A0 The last can be done by something like" "This document super= sedes=20 > and replaces any previous grant or assumption of authority to the IAB=C2= =A0=20 > claimed in the IAB charter (ref...) or other documents as applies to th= e=20 > selection and oversight of the RFC Editor=C2=A0 and the RFC series".=C2= =A0=C2=A0 Add=20 > "Updates: " to the tag line to refer back to the IAB charter.=C2=A0 No = reason=20 > to require anything more than that I would expect. Process wonk says "Wrong answer!" :-) The IAB charter is an IETF BCP, so it can only be updated by an IETF standards action. It can practically be a one line document except for boilerplate, but it's gonna have to be done. OLD: The IAB must approve the appointment of an organization to act as RFC Editor and the general policy followed by the RFC Editor. NEW: The RFC Editor function is described in [I-D.saintandre-rfced-model]. >=20 > For the stream:=C2=A0 "This document mandates the creation of the Edito= rial=20 > stream to be managed by the RSA/E and for the publication of documents = > created through the auspices of the RSWG and the RSAB."=C2=A0=C2=A0 May= be one or=20 > both additional statements: "Stream is limited to documents that affect=20 > the operation, publication and sustainment of the RFC Series" and "The = > RSWG and RSAB shall issue additional documents as necessary to refine=20 > the processes for acceptance and publication of documents on the=20 > Editorial stream and the implementation of related changes to the=20 > operation of the RFC publication process." Sure, something like that. Regards, Brian From nobody Tue Jun 22 18:14:18 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4A43A224C for ; Tue, 22 Jun 2021 18:14: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, URIBL_BLOCKED=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 rNTD32pkBXwO for ; Tue, 22 Jun 2021 18:14:15 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 7E2C03A224B for ; Tue, 22 Jun 2021 18:14:15 -0700 (PDT) From: Jay Daley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Message-Id: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> Date: Wed, 23 Jun 2021 13:14:12 +1200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 01:14:17 -0000 Here is my proposed text to address the following issues #56 - Process for RPC work not requiring consensus #57 - How are RPC priorities set? #61 - Replacing the previous RSE role in gathering requirements for the = RPC #62 - Communicating decisions about RPC projects/priorities to the = community The RPC have not had a chance to comment on this text, but I am hoping = they will on list in due course. =E2=80=94=E2=80=94=20 ## RFC Production Center The RFC Production Center (RPC) shall develop and maintain a work=20 program for the implementation of community requirements. In=20 developing this work program, the RPC should consult with the RSAB so=20 that the RSAB may: * Inform the RPC of any community requirements that it should consider in addition to policy proposals emanating from the RSWG. * Advise the RPC on what degree of community consultation and=20 engagement is required for any proposed or planned work item. * Advise the RPC on the relative priorities of proposed and planned=20 work items. All matters of budget, timetable and impact on its performance=20 targets, are between the RPC and IETF LLC. In the event that the RPC is required to make a decision without=20 consultation that would normally deserve consultation, or makes a=20 decision against the advice of the RSAB then it must notify the=20 RSAB. The RPC shall report regularly to the RSAB, RSWG and broader=20 community, on the contents and progress of its work program and any=20 key risks or issues affecting it.=20 =E2=80=94=E2=80=94=20 --=20 Jay Daley IETF Executive Director jay@ietf.org From nobody Tue Jun 22 18:44:05 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D9D3A2345 for ; Tue, 22 Jun 2021 18:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 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_LOW=-0.7, 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=lowentropy.net header.b=dJF/HShb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TDOcVpqZ 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 NdWK-Ghydvq6 for ; Tue, 22 Jun 2021 18:43:58 -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 7419F3A2344 for ; Tue, 22 Jun 2021 18:43:58 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 30B965C013C for ; Tue, 22 Jun 2021 21:43:57 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute4.internal (MEProxy); Tue, 22 Jun 2021 21:43:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=QrvQ6nhqeq/xH+FQPn+3vM2gYgcBLM0 65C/dQOGLHEo=; b=dJF/HShbH4rtW87D+g/OzCZluSPsFp3pFCrpiVF/jOWh3Eu xrOD/7Dvo8p9X5N9xEo6l2XviSmOLksrhSLkRsIjaOiUvzINi5vK8s7YEFeeM8bA Gze2kwz+lnEsWQsfAKoB6LSk5hLKZgLclvBpr+vWh2n0RimYjNRyw07AbmvIT510 53Ts7OBljZks3kA4y6cJ51arIwIVNAG97sdxYR9VZ4/J1IIaBOcndjLHHZ0BDjfz VnUh5EBt8wYznd6Hoqwgap9E+jtRo8Yrn+ke8ado95ZAkbR521ndek5gRWH6p12f eWbTlmr64+45rWd4PxS9/uVGCByRweER/gd1+UQ== 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=fm3; bh=QrvQ6n hqeq/xH+FQPn+3vM2gYgcBLM065C/dQOGLHEo=; b=TDOcVpqZkyP8eTRM7xiO1E Lb0A3pdaGXUsYphhvN/W/7enMhYx5PPTWbJFJSkrjVjRJb93iu+7C3q53pWyxbpU YjN/h9rdK34rY9vo6ybs9ht8Z+Njrn9YY3dMKJ7Bw6H7KfI2izP30i6y21JCycPi VTSpzq0jifEHfA5RtnrNrtwch/uiuR0B82ft6TfxBSzPJpNgisZZ6yvOY03DVMOM 1lKGsLw2rCrUbfqQRhpia5krPludBpSFpnNYrLTI4NP1T7pp8VTvMFU3/Hrci6dP ZZNjgcNtxETi6E46DRo5yC10aDp799V7zDXivUGT1I7EotFbNe2QTpI8FVp1yf3w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeegvddggedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9E77D4E0097; Tue, 22 Jun 2021 21:43:56 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-530-gd0c265785f-fm-20210616.002-gd0c26578 Mime-Version: 1.0 Message-Id: <09ba8d20-0793-4068-9857-04350b6e64ee@www.fastmail.com> In-Reply-To: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> Date: Wed, 23 Jun 2021 11:43:38 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 01:44:04 -0000 On Wed, Jun 23, 2021, at 11:14, Jay Daley wrote: > ## RFC Production Center > > The RFC Production Center (RPC) shall develop and maintain a work > program for the implementation of community requirements. Thanks Jay, This is a good start, though I would move the first chunk down to reduce the emphasis on it. Reasoning below... This should be item 1: > All matters of budget, timetable and impact on its performance > targets, are between the RPC and IETF LLC. Item 2: > The RPC shall report regularly to the RSAB, RSWG and broader > community, on the contents and progress of its work program and any > key risks or issues affecting it. Item 3: > In the event that the RPC is required to make a decision without > consultation that would normally deserve consultation, or makes a > decision against the advice of the RSAB then it must notify the > RSAB. Item 4: The RPC will develop this program using the strategic direction set by the community as input. The RPC can consult with the RSAB directly, rather than relying on public consultation. As stream managers, the RSAB can provide input on stream-specific policies or requirements. The RSAB should be able to advise on whether a decision might need to be made by the RSWG and what items are currently under discussion in the RSWG. The RSAB might be able to provide input on how work items on the program are prioritized. However, I'm concerned that this last item gives considerable power to the RSAB. Setting priority is a very good proxy for setting policy. As stream managers, that is probably fine (hence my suggested tweak), as a body, that risks undermining the RSWG process: "the WG decided this, but it's silly, so deprioritize its implementation". From nobody Tue Jun 22 18:58:44 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A479B3A23B1 for ; Tue, 22 Jun 2021 18:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_NONE=-0.0001, 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=nthpermutation-com.20150623.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 Yfl4PtCpVUiv for ; Tue, 22 Jun 2021 18:58:37 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 1E16A3A23B0 for ; Tue, 22 Jun 2021 18:58:36 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id g14so972484qtv.4 for ; Tue, 22 Jun 2021 18:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=GlRhEClE5AW/EbDjbV+wHCt/Una+6QTHpQsc2S/DiTY=; b=T5J/JqGT0Fset067SdIdOCe/EgxrEUPgFU2PeCio0Be9dkZuhi3rUprDBCAgFLynnA F82ynpGm76ddhQebWxIYVgXqMkvzqASr1o/gMTDT0DT8TlTa/AjkF4GrgbAfkeiETepK b6p1WK23lHwOsBxJzwvrwrrYVw/kYZxhSmKOAG90CKx3GcVkLbk/O2ifoer8lcIl1lvi Za89F0R0aBP8uL+EEQ7jU+y0HGAaDf7yQcNS3wyz1pmMo2cMMYKq7xVi5WknYRsRhm3v 8UlS0t0iWMKPG3UXpELGzK8/p1NWIvo7QlTp1kP6etG4o6S4/zcQe1pwBblSXQageic5 shrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=GlRhEClE5AW/EbDjbV+wHCt/Una+6QTHpQsc2S/DiTY=; b=pdNaYqf50uiRS/ZD8suct3J9McC0mgOWX4X7b52wRHHHgniHH8uK1ZdVxmgrUSEBq5 7SjtRHSf1VqkKpK/o7IMb3jjDUD84UeztNnHslLwsiX7fztIzf/4GgEdBpwrAMGp7oSJ STrPtUhqxR5pw/CY+At22+q71/qicGdvJwQtaYLO2m+ci8YsCIeSevNjB9+ZThsNsOpn dJVmQvOJ2/0YZKQ1MLYNs5sFA1dvHuw+IS9Tzo9Cgkmepgh1n8/fvI8QH9oqhbaLIFGP QedBWr+N022LO0J5mwYh/iJt+a5c/YkTFxyrNH7Ak6ejZlqcDRaUpm1Up64tBjtCyT+L W+1Q== X-Gm-Message-State: AOAM530xAsFD3mITNV8oLUkM9emuZJFcK3NgpgMXjxmdqtgds1vsbWSp jKUnn1LpQFahHRC6FPhTv6OFRFXEcm/kt5fiOgU= X-Google-Smtp-Source: ABdhPJwTxMBEOV1hBWNuTFHtT6MPo7NB3wESTGL1qloIGtCg3LWahEzJaPECaLbF0a21Bf7mydhzxQ== X-Received: by 2002:a05:622a:612:: with SMTP id z18mr1734529qta.212.1624413510159; Tue, 22 Jun 2021 18:58:30 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id k6sm2841308qtg.78.2021.06.22.18.58.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Jun 2021 18:58:29 -0700 (PDT) To: rfced-future@iab.org References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> <09ba8d20-0793-4068-9857-04350b6e64ee@www.fastmail.com> From: Michael StJohns Message-ID: <25bbe57b-f2fb-b07a-c5e4-0027156f03a7@nthpermutation.com> Date: Tue, 22 Jun 2021 21:58:28 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <09ba8d20-0793-4068-9857-04350b6e64ee@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 01:58:40 -0000 Jay I like your text a lot.  It provides a needed bright line in (martin's renumber 1) between contractual direction and non-contractual discussion and work plan directions. Martin - I think the reordering is fine.  But see comments on the last chunk you wrote. On 6/22/2021 9:43 PM, Martin Thomson wrote: > On Wed, Jun 23, 2021, at 11:14, Jay Daley wrote: >> ## RFC Production Center >> >> The RFC Production Center (RPC) shall develop and maintain a work >> program for the implementation of community requirements. > Thanks Jay, > > This is a good start, though I would move the first chunk down to reduce the emphasis on it. Reasoning below... > > This should be item 1: > >> All matters of budget, timetable and impact on its performance >> targets, are between the RPC and IETF LLC. > SAB. > Item 4: > > The RPC will develop this program using the strategic direction set by the community as input. The RPC can consult with the RSAB directly, rather than relying on public consultation. As stream managers, the RSAB can provide input on stream-specific policies or requirements. The RSAB should be able to advise on whether a decision might need to be made by the RSWG and what items are currently under discussion in the RSWG. The RSAB might be able to provide input on how work items on the program are prioritized. > > However, I'm concerned that this last item gives considerable power to the RSAB. Setting priority is a very good proxy for setting policy. As stream managers, that is probably fine (hence my suggested tweak), as a body, that risks undermining the RSWG process: "the WG decided this, but it's silly, so deprioritize its implementation". > Ultimately, legally and effectively, the timing and priority of any work by the RPC is an LLC/RPC decision.  Ditto for any hired/contracted for RSA/E (mutual agreement consistent with the contract/employment agreement).  So yes - the RSAB may say "deprioritize" vs RSWG "emphasize" at which point if there's disagreement, that's going to be an interesting contractual discussion between the LLC contract manager and the RPC based on input from both the RSAB and the RSWG.  That's just reality and I don't really thing we need to spend a lot of time on trying to change how those levers of power are manipulated.  If there's a massive failure later, AND someone has a better idea, AND it can be implemented through contractual language, THEN we can readdress this point. Which also has me asking a question:  Should the LLC provide a liaison to the RSAB as mandatory requirement? (Jay - sorry if any of this makes your life harder... ) Mike From nobody Tue Jun 22 19:19:58 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E583A0933 for ; Tue, 22 Jun 2021 19:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 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_LOW=-0.7, 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=lowentropy.net header.b=S2sCRirR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EqUwQGRq 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 Pag3XYUAlAQL for ; Tue, 22 Jun 2021 19:19:52 -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 ED22A3A2452 for ; Tue, 22 Jun 2021 19:19:51 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id D9AAC5C00F8 for ; Tue, 22 Jun 2021 22:19:50 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute4.internal (MEProxy); Tue, 22 Jun 2021 22:19:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=7f6Km jaBlPdbaYjXA3mXMBBF0y2DiOZTwHrM6l9DKbQ=; b=S2sCRirR182H/5aHHGsqg gRow4kPxWnE3lENpfkrNilJAZeEoHB+yPw6L3TArR55984LSsI3W5l+njHw53/Z9 0QQSD8JoDZeArSMJ1KREZkmAfTdj5cQ/PqFR6Ss834GMY74WyIluxkraDpSrbFUB C3cT24MVfSQBLJm5igu608MNu9gsnd0rMFSZ8j5esxXv9386Fb/jQLgEcwQJNcc7 Ywzk/dw2GKeP21/neEJsq0/Co6WqRCtpvxQeXM4zQhA5kt7faXdzZOPyrz7VwvMO INZ7I1pKTGMHya47nbNahNpmRx0QDKkpKKJcowPdRkzPPiT9w1Scv+rNdxSq4wun w== 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=7f6KmjaBlPdbaYjXA3mXMBBF0y2DiOZTwHrM6l9DK bQ=; b=EqUwQGRqqjBCQhl5am9mlk4Hg4ACAPt3B/qu0lQ7ysICabYJiB4Ok4/eu iTlQX2GyacnV8aFRhDGPqBfcVkpjELHtc1ErLkzT3LkcyV1GJVy4I/njRLYQUg+Y A/4m+O+G0SQGVeKUW0NrLWVOAeO2LdPU3fCZwK+afu6Qdsvg2HRbVdXs0DH8to0b h7MK9WgWskpZmY9RR2vwTxQREB/NsXB0MVHlvJW2tHWCq14bRkcqf+nfvCGiaxIZ hU5smnSPYzUX9vJ1rxYJY5o5CVn2PhU6um+9lbaXpvF1Wi+iSg6tXdvoNAZ346+4 uk5+1FxynPfCZTROWZfDiPr4cWRKg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeegvddghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepgfejueduieffledtge elheejvdettdejudduhefggeefgfekgfeuieetgefftddtnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnh gvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 837DB4E00AA; Tue, 22 Jun 2021 22:19:50 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-530-gd0c265785f-fm-20210616.002-gd0c26578 Mime-Version: 1.0 Message-Id: In-Reply-To: <25bbe57b-f2fb-b07a-c5e4-0027156f03a7@nthpermutation.com> References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> <09ba8d20-0793-4068-9857-04350b6e64ee@www.fastmail.com> <25bbe57b-f2fb-b07a-c5e4-0027156f03a7@nthpermutation.com> Date: Wed, 23 Jun 2021 12:19:33 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 02:19:57 -0000 On Wed, Jun 23, 2021, at 11:58, Michael StJohns wrote: > Ultimately, legally and effectively, the timing and priority of any wo= rk=20 > by the RPC is an LLC/RPC decision.=C2=A0 Ditto for any hired/contracte= d for=20 > RSA/E (mutual agreement consistent with the contract/employment=20 > agreement).=C2=A0 So yes - the RSAB may say "deprioritize" vs RSWG=20 > "emphasize" at which point if there's disagreement, that's going to be= =20 > an interesting contractual discussion between the LLC contract manager= =20 > and the RPC based on input from both the RSAB and the RSWG.=C2=A0 That= 's just=20 > reality and I don't really thing we need to spend a lot of time on=20 > trying to change how those levers of power are manipulated.=C2=A0 If t= here's=20 > a massive failure later, AND someone has a better idea, AND it can be=20= > implemented through contractual language, THEN we can readdress this p= oint. I wasn't suggesting that we needed to change the substance here, just to= change the emphasis on the text. You'll note that I just reworded Jay'= s text, not changed the bullet points. =20 > Which also has me asking a question:=C2=A0 Should the LLC provide a li= aison=20 > to the RSAB as mandatory requirement? Not mandatory, and I don't think we need formal encouragement for everyo= ne to be proactively consultative. I'd rather stay silent (for reasons = similar to those you outline above). From nobody Tue Jun 22 19:30:33 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6C13A24A4 for ; Tue, 22 Jun 2021 19:30:32 -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, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 DjZyjArljTht; Tue, 22 Jun 2021 19:30:27 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id E946C3A24A0; Tue, 22 Jun 2021 19:30:26 -0700 (PDT) From: Jay Daley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_408481C2-6ED1-4B41-B34D-D142FA32313A" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Wed, 23 Jun 2021 14:30:23 +1200 In-Reply-To: Cc: rfced-future@iab.org To: Martin Thomson References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> <09ba8d20-0793-4068-9857-04350b6e64ee@www.fastmail.com> <25bbe57b-f2fb-b07a-c5e4-0027156f03a7@nthpermutation.com> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 02:30:33 -0000 --Apple-Mail=_408481C2-6ED1-4B41-B34D-D142FA32313A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23/06/2021, at 2:19 PM, Martin Thomson wrote: >=20 > On Wed, Jun 23, 2021, at 11:58, Michael StJohns wrote: >> Ultimately, legally and effectively, the timing and priority of any = work=20 >> by the RPC is an LLC/RPC decision. Ditto for any hired/contracted = for=20 >> RSA/E (mutual agreement consistent with the contract/employment=20 >> agreement). So yes - the RSAB may say "deprioritize" vs RSWG=20 >> "emphasize" at which point if there's disagreement, that's going to = be=20 >> an interesting contractual discussion between the LLC contract = manager=20 >> and the RPC based on input from both the RSAB and the RSWG. That's = just=20 >> reality and I don't really thing we need to spend a lot of time on=20 >> trying to change how those levers of power are manipulated. If = there's=20 >> a massive failure later, AND someone has a better idea, AND it can be=20= >> implemented through contractual language, THEN we can readdress this = point. >=20 > I wasn't suggesting that we needed to change the substance here, just = to change the emphasis on the text. You'll note that I just reworded = Jay's text, not changed the bullet points. >=20 >> Which also has me asking a question: Should the LLC provide a = liaison=20 >> to the RSAB as mandatory requirement? >=20 > Not mandatory, and I don't think we need formal encouragement for = everyone to be proactively consultative. I'd rather stay silent (for = reasons similar to those you outline above). I think there should be an LLC liaison as a non-voting member. That=E2=80= =99s what we have with RSOC and what I think is necessary for the LLC in = it=E2=80=99s role of setting the performance targets for the RPC and = negotiating the work plan budget/timetables. Jay >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_408481C2-6ED1-4B41-B34D-D142FA32313A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 23/06/2021, at 2:19 PM, Martin Thomson <mt@lowentropy.net> = wrote:

On Wed, Jun 23, 2021, at 11:58, Michael StJohns wrote:
Ultimately, legally and = effectively, the timing and priority of any work
by the = RPC is an LLC/RPC decision.  Ditto for any hired/contracted for
RSA/E (mutual agreement consistent with the = contract/employment
agreement).  So yes - the RSAB = may say "deprioritize" vs RSWG
"emphasize" at which point = if there's disagreement, that's going to be
an = interesting contractual discussion between the LLC contract manager
and the RPC based on input from both the RSAB and the = RSWG.  That's just
reality and I don't really thing = we need to spend a lot of time on
trying to change how = those levers of power are manipulated.  If there's
a = massive failure later, AND someone has a better idea, AND it can be
implemented through contractual language, THEN we can = readdress this point.

I wasn't = suggesting that we needed to change the substance here, just to change = the emphasis on the text.  You'll note that I just reworded Jay's = text, not changed the bullet points.

Which also has me asking = a question:  Should the LLC provide a liaison
to the = RSAB as mandatory requirement?

Not mandatory, and I don't think we need formal encouragement = for everyone to be proactively consultative.  I'd rather stay = silent (for reasons similar to those you outline above).

I = think there should be an LLC liaison as a non-voting member. =  That=E2=80=99s what we have with RSOC and what I think is = necessary for the LLC in it=E2=80=99s role of setting the performance = targets for the RPC and negotiating the work plan = budget/timetables.

Jay


--
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

-- 
Jay Daley
IETF = Executive Director
jay@ietf.org

= --Apple-Mail=_408481C2-6ED1-4B41-B34D-D142FA32313A-- From nobody Tue Jun 22 19:50:28 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3ADD3A2542 for ; Tue, 22 Jun 2021 19:50:25 -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, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 BXpkbLmKE0Wj; Tue, 22 Jun 2021 19:50:20 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 6D1583A2539; Tue, 22 Jun 2021 19:50:20 -0700 (PDT) From: Jay Daley Message-Id: <6E47DC4E-E798-4216-8C81-F80A38E1DD16@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_00912415-2F91-4B41-AE34-8D8E34A34F3B" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Wed, 23 Jun 2021 14:50:17 +1200 In-Reply-To: <09ba8d20-0793-4068-9857-04350b6e64ee@www.fastmail.com> Cc: rfced-future@iab.org To: Martin Thomson References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> <09ba8d20-0793-4068-9857-04350b6e64ee@www.fastmail.com> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 02:50:26 -0000 --Apple-Mail=_00912415-2F91-4B41-AE34-8D8E34A34F3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23/06/2021, at 1:43 PM, Martin Thomson wrote: >=20 > On Wed, Jun 23, 2021, at 11:14, Jay Daley wrote: >> ## RFC Production Center >>=20 >> The RFC Production Center (RPC) shall develop and maintain a work=20 >> program for the implementation of community requirements.=20 >=20 > Thanks Jay, >=20 > This is a good start, though I would move the first chunk down to = reduce the emphasis on it. Reasoning below... >=20 > This should be item 1: >=20 >> All matters of budget, timetable and impact on its performance=20 >> targets, are between the RPC and IETF LLC. >=20 > Item 2: >=20 >> The RPC shall report regularly to the RSAB, RSWG and broader=20 >> community, on the contents and progress of its work program and any=20= >> key risks or issues affecting it.=20 >=20 > Item 3: >=20 >> In the event that the RPC is required to make a decision without=20 >> consultation that would normally deserve consultation, or makes a=20 >> decision against the advice of the RSAB then it must notify the=20 >> RSAB. >=20 > Item 4: >=20 > The RPC will develop this program using the strategic direction set by = the community as input. =20 I don=E2=80=99t think we should give the RPC a wide-ranging community = engagement role by default because that will inevitably create a = parallel mechanism for changes outside of the RSWG/RSAB process, and all = the tensions that come with that. A narrower constraint, whereby = changes are normally funnelled through the RSWG/RSAB, while leaving the = door open for an extraordinary widespread consultation seems more = appropriate. > The RPC can consult with the RSAB directly, rather than relying on = public consultation. =20 Similarly, my proposed text had the RSAB as the first stop for the RPC = for advice on how/where to consult, rather than the RPC making that = decision and choosing or not choosing the RSAB. This was following a = principle that the community manages/decides/advises on how it is = consulted rather than any support function to the community.=20 > As stream managers, the RSAB can provide input on stream-specific = policies or requirements. The RSAB should be able to advise on whether = a decision might need to be made by the RSWG and what items are = currently under discussion in the RSWG. The RSAB might be able to = provide input on how work items on the program are prioritized. >=20 > However, I'm concerned that this last item gives considerable power to = the RSAB. Setting priority is a very good proxy for setting policy. As = stream managers, that is probably fine (hence my suggested tweak), as a = body, that risks undermining the RSWG process: "the WG decided this, but = it's silly, so deprioritize its implementation". My proposal was only for the RSAB to be able to advise the RPC on = priorities not instruct them. And don=E2=80=99t forget we expect that = to be public. Rather than seeing this as a risk, I would say that as = the RSAB is basically the four stream managers plus the RSE/A, this kind = of advisory power is a useful check and balance to the RSWG. Jay >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future >=20 --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_00912415-2F91-4B41-AE34-8D8E34A34F3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 23/06/2021, at 1:43 PM, Martin Thomson <mt@lowentropy.net> = wrote:

On Wed, Jun 23, 2021, at 11:14, Jay Daley wrote:
## RFC Production = Center

The RFC Production Center (RPC) = shall develop and maintain a work
program for the = implementation of community requirements.

Thanks Jay,

This is a good = start, though I would move the first chunk down to reduce the emphasis = on it.  Reasoning below...

This should = be item 1:

All matters of budget, timetable and impact on its = performance
targets, are between the RPC and IETF LLC.

Item 2:

The RPC shall report = regularly to the RSAB, RSWG and broader
community, on the = contents and progress of its work program and any
key = risks or issues affecting it.

Item 3:

In the event that the RPC is required to make a decision = without
consultation that would normally deserve = consultation, or makes a
decision against the advice of = the RSAB then it must notify the
RSAB.

Item 4:

The RPC will develop this program using the strategic = direction set by the community as input. =  

I don=E2=80=99= t think we should give the RPC a wide-ranging community engagement role = by default because that will inevitably create a parallel mechanism for = changes outside of the RSWG/RSAB process, and all the tensions that come = with that.  A narrower constraint, whereby changes are normally = funnelled through the RSWG/RSAB, while leaving the door open for an = extraordinary widespread consultation seems more appropriate.

The RPC can consult with the RSAB directly, rather than = relying on public consultation.  

Similarly, my proposed text had the RSAB as the = first stop for the RPC for advice on how/where to consult, rather than = the RPC making that decision and choosing or not choosing the RSAB. =  This was following a principle that the community = manages/decides/advises on how it is consulted rather than any support = function to the community. 

As stream = managers, the RSAB can provide input on stream-specific policies or = requirements.  The RSAB should be able to advise on whether a = decision might need to be made by the RSWG and what items are currently = under discussion in the RSWG.  The RSAB might be able to provide = input on how work items on the program are prioritized.

However, I'm concerned that this last item gives considerable = power to the RSAB.  Setting priority is a very good proxy for = setting policy.  As stream managers, that is probably fine (hence = my suggested tweak), as a body, that risks undermining the RSWG process: = "the WG decided this, but it's silly, so deprioritize its = implementation".

My proposal was only for the RSAB to be able to = advise the RPC on priorities not instruct them.  And don=E2=80=99t = forget we expect that to be public.  Rather than seeing this as a = risk, I would say that as the RSAB is basically the four stream managers = plus the RSE/A, this kind of advisory power is a useful check and = balance to the RSWG.

Jay


--
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future


-- 
Jay Daley
IETF = Executive Director
jay@ietf.org

= --Apple-Mail=_00912415-2F91-4B41-AE34-8D8E34A34F3B-- From nobody Tue Jun 22 20:06:38 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31ECC3A25A9 for ; Tue, 22 Jun 2021 20:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 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.338, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 mco1LkpWvNmV for ; Tue, 22 Jun 2021 20:06:34 -0700 (PDT) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 D226C3A25A8 for ; Tue, 22 Jun 2021 20:06:34 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id p4-20020a17090a9304b029016f3020d867so496323pjo.3 for ; Tue, 22 Jun 2021 20:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=XYvlOlAXG75j4OXbFPeTVKK/dNhlLkp6T0bt9d6Rz4w=; b=egOenW6Jdw8iLgYVQPV3OIsOBnzP2mjWYkhkmIMcxOqitPe6s6SCaj4+KfcBjWPcQZ ZB02fIfKZwFXaXxwUOuaPvANcQa3+bm9jq/nx5nql3yocv1EpYSGNmln28DuC9WbyZj5 LJAC1rJ6y/BHVeJDnHawsn79ZWzCe/zm5AMeNe0qN8MkJVraY69IVYdynN+auW02eCxW GcSliVBrwvixXnH+XlBmRMFGfhGtCrRIyfKhLa/XNoPKsp3ZCftKk8fyJctvep3+fX9a IakiIV4zmiym85/ndyGJL3dIDPFopDb3cMfsEltsxsdMDpt1J9rm7uHXHDXRyDr8IOjX dyrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XYvlOlAXG75j4OXbFPeTVKK/dNhlLkp6T0bt9d6Rz4w=; b=NWPjFjcwy/bR12xZxKghE7O+ZxGwT0S++KTtfk2sYRUnTdTy6yoGE2ecgpb0HsI4M1 KrzQ2I5kI02EtIEpPdorne6uNTdOciYnBCs1R+rDeErm1JyOKyI6zhU5ozVmsPTS6rqN rJ/HS4gmulgiIXrRiN1v0JKAsh1g9DYyt9TSokC5VSyUHmRoMSm8sGlkZALW2/O9OxDs eHq5h0qvKvoISS80cJJa98S+0LS174OTdXv6iKbuPYnWPROb7ElhWfHtYZ2o1xp6RrWi NFBbkhgWRLgK47f5Jf+LHUVF+TwGEeHreWiezMXqjRN5qOs0wbe6pnB/rO2DXfFyhocm VFfw== X-Gm-Message-State: AOAM531Bm+xCeMJ3mSuxoF3Ul8YZ5WUnz9A/2bq8axLJhXHAFEQg5KMR uuMr1xjlwZzBmv4HNztxrs7rPChruh22tg== X-Google-Smtp-Source: ABdhPJy+sfqLDbiSU5b9QShkZMdTffQTuJxf2I+EQwvl8cqFHKWBcN/OeSmzWaXi6uCDEsVve5mXbw== X-Received: by 2002:a17:90a:640b:: with SMTP id g11mr252526pjj.18.1624417593354; Tue, 22 Jun 2021 20:06:33 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id c22sm596321pfv.121.2021.06.22.20.06.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Jun 2021 20:06:32 -0700 (PDT) To: Jay Daley , rfced-future@iab.org References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> From: Brian E Carpenter Message-ID: <39f83475-e0bb-5ca7-ecfe-d6756a581fb5@gmail.com> Date: Wed, 23 Jun 2021 15:06:29 +1200 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: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 03:06:36 -0000 On 23-Jun-21 13:14, Jay Daley wrote: > Here is my proposed text to address the following issues >=20 > #56 - Process for RPC work not requiring consensus > #57 - How are RPC priorities set? > #61 - Replacing the previous RSE role in gathering requirements for the=20 RPC I understand why that becomes an RSWG and RSAB function, but I think we n= eed it to be clear elsewhere in the document that we expect the RSEA to h= ave a major role in this work (and very likely be the de facto communicat= ions channel from the RSWG and RSAB to the RPC). I may have missed it, but I don't there's a github issue for finalizing t= he role and title of the RSEA. That's where I would like to hang this com= ment. Brian C > #62 - Communicating decisions about RPC projects/priorities to the comm= unity >=20 > The RPC have not had a chance to comment on this text, but I am hoping = they will on list in due course. >=20 > =E2=80=94=E2=80=94=20 > ## RFC Production Center >=20 > The RFC Production Center (RPC) shall develop and maintain a work=20 > program for the implementation of community requirements. In=20 > developing this work program, the RPC should consult with the RSAB so=20 > that the RSAB may: >=20 > * Inform the RPC of any community requirements that it should consider > in addition to policy proposals emanating from the RSWG. > * Advise the RPC on what degree of community consultation and=20 > engagement is required for any proposed or planned work item. > * Advise the RPC on the relative priorities of proposed and planned=20 > work items. >=20 > All matters of budget, timetable and impact on its performance=20 > targets, are between the RPC and IETF LLC. >=20 > In the event that the RPC is required to make a decision without=20 > consultation that would normally deserve consultation, or makes a=20 > decision against the advice of the RSAB then it must notify the=20 > RSAB. >=20 > The RPC shall report regularly to the RSAB, RSWG and broader=20 > community, on the contents and progress of its work program and any=20 > key risks or issues affecting it.=20 > =E2=80=94=E2=80=94=20 >=20 From nobody Tue Jun 22 20:18:18 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC703A25FA for ; Tue, 22 Jun 2021 20:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=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=rtfm-com.20150623.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 T-k8iebBOW8v for ; Tue, 22 Jun 2021 20:18:12 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 061A73A25F8 for ; Tue, 22 Jun 2021 20:18:12 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id b7so1554088ioq.12 for ; Tue, 22 Jun 2021 20:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KhWUeoMk1ZKFkWov20YfnKXfIPPAOBXndmDLtNQKEPc=; b=ZXaW+rBFDCwgnJSPSeKm9v3PK/jzUmsts8ViqD3BDLHAyYHcTq4yRkhhnxXFichWk9 3ySp0nZV2c0GHjtjGIzG5S/RgcEBKNPKUlAYJ0ulOO4HnXduJ4NT9zDO5rqLE36mAAwa B1DorDXDh8XV558MbGmFNSnD6rbkThBH78phHWs+Xn2u58bkpClVAxwpgDvdp0BIX6nz awnotHGmfu4GxFGv8X5QkD7CQB2GXOvQ6dVcpKFdJn8cdkmghnRK3gN2IzgngEa35qJe sntrOj8pXoKgpji4/2jyBFqi/9X1tF9RMMO2yOD4pWEnU+TaKAnEzwnu6aLi9mYjfC2f DYSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KhWUeoMk1ZKFkWov20YfnKXfIPPAOBXndmDLtNQKEPc=; b=Odq5O6cjY2DllI0FRWw3Lg3ou3Gozp2v6QVi0hPPMngQKLSvz8uFPQBaQxh8aSCExW 36/TXgUq8Ye3ZnQZiEhXZpymGqZbAsBUPiqEpIamoS1jFFoQR7tafwQQSdAtfzSbhigo 2mzZux80gZFLJASyI+mkjyzVSYWxYbFWhllJaGtRb5X53QKL3LGF4FfjaE7M1FlfMk8S 7wpNcpVXF1rll1elZo2Ub4gm0u4AjTzELiJZAVm3hVPb6lhjKajbO+RgJ0B9lkUZvvHc V5++/Ge+z7JiB3nerWwk3JD6ksRpq+vKDwHSyrtmYDT7y+Wpykz/add1SC72yeAGw9Lh QcdA== X-Gm-Message-State: AOAM530ZXTfKXM8c9IOC0VO99XFa7Y80JjcwQfgX4ptTrWc4IYYvGrIw 2BADGhwA+3ctOwCVpqq2X7jjQ7GY9kqHRMTTQSMtdQ== X-Google-Smtp-Source: ABdhPJzTb2ZSlv8Oi8O9Kq2XTXSOz7Kw5PEN3ekI3OCljP6Dvyx57rvgO+meFhbjJ5ZsuqyNGiD2+r2rn2x7AG3BkKw= X-Received: by 2002:a5e:9513:: with SMTP id r19mr5587794ioj.98.1624418290532; Tue, 22 Jun 2021 20:18:10 -0700 (PDT) MIME-Version: 1.0 References: <5977bd11-ca97-6516-57ee-cb1f71ed92d3@lear.ch> In-Reply-To: <5977bd11-ca97-6516-57ee-cb1f71ed92d3@lear.ch> From: Eric Rescorla Date: Tue, 22 Jun 2021 20:17:34 -0700 Message-ID: To: Eliot Lear Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000002c9ad205c5665bd7" Archived-At: Subject: Re: [Rfced-future] Call for Adoption: draft-saintandre-rfced-model-01 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 03:18:17 -0000 --0000000000002c9ad205c5665bd7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am in favor of adoption On Tue, Jun 22, 2021 at 9:03 AM Eliot Lear wrote: > Dear Colleagues, > > As discussed in the May interim, we are now issuing a Call for Adoption o= f > draft-saintandre-rfced-model-01 as the draft this group will use as > intended output. We hope that this call is a mere formality. Our > procedures for content going into that draft and issues raised do not > change. The purpose of adoption is to make clear our group=E2=80=99s own= ership of > its content and intent to pursue that work as WG output, with the very > generous and kind help of Peter. > > Please raise any concerns by 6 July 2021. > > Eliot > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --0000000000002c9ad205c5665bd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am in favor of adoption

On Tue, Jun 22, 2021 at 9:03 = AM Eliot Lear <lear@lear.ch> wrot= e:
=20 =20 =20

Dea= r Colleagues,

As d= iscussed in the May interim, we are now issuing a Call for Adoption of draft-saintandre-rfced-model-01 as the draft this group will use as intended output.=C2=A0 We hope that this call is a mere formalit= y. =C2=A0Our procedures for content going into that draft and issues raised do not change.=C2=A0 The purpose of adoption is to make clea= r our group=E2=80=99s ownership of its content and intent to pursue t= hat work as WG output, with the very generous and kind help of Peter.

Plea= se raise any concerns by 6 July 2021.

Eli= ot

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--0000000000002c9ad205c5665bd7-- From nobody Tue Jun 22 21:17:14 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACD63A27D6 for ; Tue, 22 Jun 2021 21:17:13 -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_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=lowentropy.net header.b=ZtTpBaYP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=isEeu2RD 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 3IK3-_-8TP_B for ; Tue, 22 Jun 2021 21:17:08 -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 348F93A27D4 for ; Tue, 22 Jun 2021 21:17:07 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id F2D1D5C011C; Wed, 23 Jun 2021 00:17:05 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute4.internal (MEProxy); Wed, 23 Jun 2021 00:17:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm2; bh=zO A3nwLk1ivzRSaG/OAkqagM15bG1roIIZeAGrMOhU4=; b=ZtTpBaYPRFPY+54OJX DaQS/l1UcI1EVBb6TkNOVabN1FdxzgQF/oq8In5Q/GGEhLgOsNLwIZlmcRVJDvlI kn8nMs14mf72aOLJaO1uJZQSKheMMXcbuVCnCTvC9KCpGiyG6s4PJAOzj9CHQrut VTe5/j5YkDhdmJnorNDAmymTo08rZ1xTzO3IU/JF8xlp8wA9in/ZJ47p5vYxoaRW cAzxMlyjTy+U0ubXiwx97NsoTc1kVFZF5puoZfYCz9akDfXk9aRh0kx0EJfPqt7D /SDy0df+OwHlciYPxt2qddSNFDgQejLlYo95+YJZw45sADg2B2NQoAppiIont3dX 67kg== 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=fm3; bh=zOA3nwLk1ivzRSaG/OAkqagM15bG1roIIZeAGrMOh U4=; b=isEeu2RDMYVNgPUY3qgZI2bLxfk8HPdiJh7J2f7ukRywFalUWX4VeE55G WCO28S7oSOwfr+HI2n1gfjPWnFGmiuaFIMzE6ENh8H3Pift3aSo5W/R+iPJNQ07Y ztfTrrUb3IooUBM6RkW1Ygy63/JHPAJyQuHlEMXsxa0C+Fs11ac+N/dWq/tmZGd8 64TIvmxiX87I1R/wA5Oyz5AWcaLiOgHC4OVUMS6J3JEkQe4XE1e1DL0kCCxWcZnu Lz/+y01HWvka4TncHTIcNIC6ewwCbb3cIh1LreqW7GpfE51mwawdMDkHuUBkR8yr d5ddfZQnwsuUCk0UD2utsCT78rBHQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeegvddgjeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepgfejueduieffledtge elheejvdettdejudduhefggeefgfekgfeuieetgefftddtnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnh gvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 807864E00AA; Wed, 23 Jun 2021 00:17:05 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-530-gd0c265785f-fm-20210616.002-gd0c26578 Mime-Version: 1.0 Message-Id: In-Reply-To: <6E47DC4E-E798-4216-8C81-F80A38E1DD16@ietf.org> References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> <09ba8d20-0793-4068-9857-04350b6e64ee@www.fastmail.com> <6E47DC4E-E798-4216-8C81-F80A38E1DD16@ietf.org> Date: Wed, 23 Jun 2021 14:16:45 +1000 From: "Martin Thomson" To: "Jay Daley" Cc: rfced-future@iab.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 04:17:14 -0000 On Wed, Jun 23, 2021, at 12:50, Jay Daley wrote: > My proposal was only for the RSAB to be able to advise the RPC on=20 > priorities not instruct them. And don=E2=80=99t forget we expect that= to be=20 > public. Rather than seeing this as a risk, I would say that as the=20= > RSAB is basically the four stream managers plus the RSE/A, this kind o= f=20 > advisory power is a useful check and balance to the RSWG. In terms of checks and balances, I'm far more worried about the RSAB tha= n the open processes of the RSWG. The RSWG is far less likely to do som= ething the RSAB doesn't like because the RSAB forms the core of the RSWG= anyway. Yes, we've done a lot to improve transparency through this process, but = I have seen that dynamic. The meeting will be at 3am, the decision migh= t be questionable, but the minutes won't capture sufficient nuance and t= he RSAB will close ranks in defense of the decision, not wanting to re-l= itigate it. This is already a problematic dynamic in the IETF where editor teams and= design teams form, one that I've seen from both sides. It is in fact o= ne of the major shortcomings of us moving to GitHub and it happens even = though there is a marked improvement in transparency and accountability.= The clique makes decisions that are hard to overturn. This is part of why it is important - at least in my opinion - that the = board is able to approve only. For permanent outcomes, they approve dec= isions from the RSWG; for temporary decisions with time constraints, the= y approve decisions the RPC makes (in consultation with the well-informe= d and affected). As I noted in response to Mike, I don't think that the substance of what= you have is wrong, just the emphasis. This sort of consultation is per= fectly fine and might not even need to be formally recognized, because i= n formal recognition we establish an expectation and that expectation ca= n be exploited to exert power. I would prefer that the sort of text here be left out now. The RPC form= ulates its work plan and can consult with the nominated representatives = of its customers (i.e., stream managers) rather than the amorphous mass = that is the community to inform its decisions. That this also happens t= o be the RSAB is convenient, but it isn't a formal responsibility of tha= t body. From nobody Tue Jun 22 23:40:48 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E223A2C43 for ; Tue, 22 Jun 2021 23:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=itaoyama.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 mIjfM9Dho-Lk for ; Tue, 22 Jun 2021 23:40:43 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410114.outbound.protection.outlook.com [40.107.141.114]) (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 A42D53A2C3B for ; Tue, 22 Jun 2021 23:40:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n8sjmhDjspk1qGnhZHcV1HJY2HSCsqF0u11aleLFXsAgf8mfNtI+FsZ7MuSeXvMi2P0ySu5cn4ge16F/GUlsVPcJPuupGtBfUkdc7KYnz/TBX4E2HIHWmTHbbuG+jKDjUvKStgA9vf/fUtbGwADN1XZPEd1rP1k7TMzZWSbrcqdoYJDfEOgoeR/0sv1fyfGrjmHgqb1luLvASDlgKfNZWY3FMSyPua/gEAUniqfCKjbH1LyqH4mBgsmqfAuVw2Omv2/wmo4tNUINd3s2BWpIj0e0YJ/XJqeh0//7QJqBjrCRbRcU15uKGqLAkL/kzIeW1i7QMwSw0JV+XY+DQ3TD3g== 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-SenderADCheck; bh=vC8ryDvl/l6ZM06mCXWVaVTgKWELHXOFymYmom5ttDI=; b=JTJaPOTYjwKUe4xNR8zGOls8Maf0WTvYCRpsqAZ4B6ZOvE3ppY3/h3d+6CtfkHuG8SEA173Ic3Vjrl+YSz4s5niE4R+yXGyKu4zzGWcT3klcLAhlXpyVNx4fM9OGffY9JkF/0Wl8BJnDyHC/2lDss6IPB60/BwwiCTEH0A6UBLXetLBhnzE0D9Dz9zUnpaG+RU825WBIMd5jsfc22VqjwTEN2kUnKncY7iv9dP0OKC8QySXqDUzV9AhSaKvihQj2Q4NzQYFT2lHXOUeVmYwlGMepbR+Qk013qTgvY3GDN8LHKGiecjLD3YmQUmWPjxWsM5irmxXzfydBTl0ml1yQxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vC8ryDvl/l6ZM06mCXWVaVTgKWELHXOFymYmom5ttDI=; b=iFbK99gRD7g17zffkJCc/200Iy8gXllHQ4hvSgNoAq7hwgdxNsjMEUhu0L8x14l2x+c+kMhfYb2PrT9eEYNgLuQ6/mPrvLx4tOLiWyLzkd0Yydot4ggeJsgy0fnQfGScs59J4E8w1jeQDwJABq5ex4sP7eoVrcFLzzqNUIQzhzc= Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYCPR01MB6962.jpnprd01.prod.outlook.com (2603:1096:400:b9::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.16; Wed, 23 Jun 2021 06:40:40 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::a103:800c:b1ed:48ba]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::a103:800c:b1ed:48ba%8]) with mapi id 15.20.4242.024; Wed, 23 Jun 2021 06:40:40 +0000 To: Eliot Lear , rfced-future@iab.org References: <5977bd11-ca97-6516-57ee-cb1f71ed92d3@lear.ch> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Wed, 23 Jun 2021 15:40:37 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: <5977bd11-ca97-6516-57ee-cb1f71ed92d3@lear.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.0.86] X-ClientProxiedBy: TYAPR01CA0158.jpnprd01.prod.outlook.com (2603:1096:404:7e::26) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [100.70.31.230] (133.2.0.86) by TYAPR01CA0158.jpnprd01.prod.outlook.com (2603:1096:404:7e::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18 via Frontend Transport; Wed, 23 Jun 2021 06:40:39 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c920a89d-aa94-4ca8-aa26-08d93611d111 X-MS-TrafficTypeDiagnostic: TYCPR01MB6962: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: EAd7Z4IK1kD3J2J7DiqQ7QGvzcF/X9CL35mFPWR17O7Yw9Ex3mqIRndMMXdundVtDb3JQfu8sfpp76g0hnNKSf6QBjjv7sZevhkHIxfelToRAsaxg2Ytg4GgkONJ3VB0o577CIkC8xl67N2lJKZV0WD9n6Rm0e+6hGblR84KkNirueW34bKmAXfsAX8GZqNrAyTDaEc/Dssyp1jkEwPHiUPDF9thHu5B/AnuDZnG/N/2WDXCgOYRDcUMPhfforJ2N1eMQtZPn1yRvabjlLYVpxmMqPOYU7iI1c073Zhq+DGhN+GoIDsONx0yHRmlnYSJp1ElukMe9ETFFHNnoz08+Vfyw49H+Rp8HJ9NBQlSL/KYr1+kD1jTPfgk5wOLwSNBlb3H9wQLfHa8T9L7wQZqCpmxiCRGCxeuWFimbDZMejTGuRkhJrVMC6/l+fY+M2uEpiIyzGIYYcnb9NTII8ssmPyr9q984U1wwS7ytPTBX5SO7vdWRWqEgTQkWuOs4N0tQabO1Qkowep5yyJTSuI8PYw6SIalR4E53a1GbgIKGnpETPlQqb/SREYs9HwYvYF2US8VLlEgJHqCp0nRZIphtXb02jdNcHcSU9q5BaPZEDz723TQBjxUk1NnFbj1xupfRRpKFVfCYNBhLRBPZhZRVkG/+dXZay6Q6XceuouzEiMQQHLsvtQ0rnrnjEI2U3UzohSwAPocLWlvKV108SiYaBX8ZX6kFnc8Bs6z8wso5fw5Y7hWVY7TgCRh/J1lUEjY X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(39830400003)(396003)(346002)(136003)(376002)(366004)(186003)(16526019)(6706004)(36916002)(31686004)(83380400001)(52116002)(4744005)(8676002)(8936002)(38350700002)(2906002)(38100700002)(66556008)(16576012)(316002)(786003)(26005)(6486002)(66946007)(5660300002)(2616005)(86362001)(66476007)(956004)(31696002)(53546011)(478600001)(78286007)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Ym1wN3dXWEJJSjhKZzFjNzhGUFc0YlRqc0tNbTVTdGVvMnBCNEloMisvWGg1?= =?utf-8?B?bU01b3pSUmJ0dC9ldmxyVHg0WmlkbnYwQWxxeGZ4bjdITm1RSXBGY250VjVx?= =?utf-8?B?V1lZcEoxS3hpcmJGSC8rdUhUSVB2QXpmTmhRQXFOV2lpbEJIaitkQ2hycWxC?= =?utf-8?B?Zm5WUVAvanc4STZvNXNsRGtmbEVud3Z1ZmV1VE1YUGVIYlE3WjFUR0RmUXFN?= =?utf-8?B?cEt2bS85VUtJSUxaSUYvbFpJYXZ3UjVmdi9sb1pMU1oremowdkc0UFhTbTdJ?= =?utf-8?B?Z2UrNWErM0JXeFNvSTYxVEtGQm56RlVOSElqZ2sydEl4dFk1ek1pSlVINTI1?= =?utf-8?B?WjBRc1lUbHpsSGVZWkp0Vlg0ejJNejhKZndJY2hwTzY3V2srTHg0SGZCMVp6?= =?utf-8?B?RTl2ZVFJVzlRK3ZUYi9kODFhSmlXa1VhYTNuSE52TGRpanZHOGxjZnZpZ01r?= =?utf-8?B?amNJWFUwQlZQQ1VBNitHZkYrcTd5QitJOVN3RTY1WlA0dTJlVDlabFhHc3c1?= =?utf-8?B?R0tvSkhsRE1zMS9QbVByVklsdEdVQ016YWJJMTh6UjBGRFd4NGhVb1FBMERJ?= =?utf-8?B?U0ExR1VhLzBOZWZFME9tK3VOZ1hUQVdCWkZRQzdkZ1B4bjFMOGRNRXZQUEQz?= =?utf-8?B?R003MlZpWHhCalhadDMvVWlmVURRajhTdkJiU1hTWDFVMXY5VVZLMVBBWmk0?= =?utf-8?B?NnpQekxJNHZJeEhTUy9VSm0vcXV6WHY0aW9zczZqc2Rpc00zVVVtUjVKUVBa?= =?utf-8?B?a0FuWkJBSzJOdzM3Y1cybGtrVHE1K3dOSlkzM0E1ejB6MkxzZEtuUU55M3VB?= =?utf-8?B?Tzg4aG9kUWcwSy9UYW5BRjd0NFdRYlc2aDM4UDBDYmlyYzlpMStEUHBMU0h3?= =?utf-8?B?Zys4OG1YSjQ4NnAvVEZacUJDblRLUXFGcFNwNytLTWJmczdXaVh0L2VtR1hW?= =?utf-8?B?WXNXU0xTZTFhbWtTOTBSUGUvUFFRZWowbHEvbFZQTDJLVks4WXVaMXZrdndv?= =?utf-8?B?MWc2RlFnVW82bFZLV1VZZXZ3TlczZWZGUkllMTF6NTdLUjV3ZForVHUxWHF1?= =?utf-8?B?dHdsVTJ3cGJSTjZ3MjNOTjZKQUFIUlJkRzBMSjdxWVVsb1BBdnlnTldmaEZS?= =?utf-8?B?T2hkVlppMXkrcS94V0hCcDh5a1QzN0JPRDJNVmxiMTdzUksvV3lpaWZwWWg5?= =?utf-8?B?Mm1xREdlY24xMmx3MFlmbVdpR3Bkb0pJKzRBblhCcXFGOFFoUHpiVjhVR3Bj?= =?utf-8?B?Ym5EVFZPN1lqc1kvcmtiWmN0T2xzTVQ4V1Jid0pDWVZQVkdqM0luZHNQNTBt?= =?utf-8?B?L05JY0huazlrTmVPN25iS0NuY3NYWllia3Q0aTM2Z3NJcWtyRkFsbTIwdVRH?= =?utf-8?B?d3VQMEpCaWhTN0xCazlPaUY2bVNnZWdLYmpSRWVXUGhlTVl5bi90OW1zRU1C?= =?utf-8?B?TVp6Q3VqK3pYVlpJS3FNa1VxbEtpVDQyTmM2NHB5SVFpZU8vS0tHZThUZEx4?= =?utf-8?B?QldPdy9TMmdDSDl4aERBeVJRR2ZMaElTSU5RY091clBFM3BkbWtoUHZhOXQw?= =?utf-8?B?aUdjZTFFOXRNVUY2TXQ4TEV0UktvMk5nVjdjMUpmWFl1T1ZjSFQ4SjRXN09D?= =?utf-8?B?c3dQQnVVeFhDUG9jdWpnWWpiNVpTWjFoTkFiWkJMT1c4clhyU054YUhMNlEx?= =?utf-8?B?SGc2OUpoTEY2MkQrOXlLS3Z2UERQaE5qWDlidUJxaEhCaDBJVWhwVkdUZ3Z3?= =?utf-8?Q?rj3NKdgcod7GW27oplHSKCmlpanDSH2BtoeKry7?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: c920a89d-aa94-4ca8-aa26-08d93611d111 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jun 2021 06:40:40.1208 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: f18h+JuG8bLM0y9XlRyM00eSH4vZb2l55ffpYGxv1DTGau0+Vkz0eYp9GxU2h3xixn7dw/sqdPuUElZCp5hxcA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCPR01MB6962 Archived-At: Subject: Re: [Rfced-future] Call for Adoption: draft-saintandre-rfced-model-01 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 06:40:46 -0000 Yes, please!   Martin. On 2021-06-23 01:02, Eliot Lear wrote: > Dear Colleagues, > > As discussed in the May interim, we are now issuing a Call for Adoption > of draft-saintandre-rfced-model-01 as the draft this group will use as > intended output.  We hope that this call is a mere formality.  Our > procedures for content going into that draft and issues raised do not > change.  The purpose of adoption is to make clear our group’s ownership > of its content and intent to pursue that work as WG output, with the > very generous and kind help of Peter. > > Please raise any concerns by 6 July 2021. > > Eliot From nobody Wed Jun 23 00:51:27 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BC13A2E55; Wed, 23 Jun 2021 00:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.227 X-Spam-Level: X-Spam-Status: No, score=-1.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=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 KGdhftvOh6kN; Wed, 23 Jun 2021 00:51:20 -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 6C8E23A2E53; Wed, 23 Jun 2021 00:51:20 -0700 (PDT) Received: from [192.168.0.185] (31-10-155-187.cgn.dynamic.upc.ch [31.10.155.187]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15N7pBlH443201 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 23 Jun 2021 09:51:12 +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=1624434672; bh=9xyTfMuLyoqI4zHe76ooUqL1pjuEAh8tlB+73UiIrS4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=gYZKV/Cv3r8/tl7uGJ04X5mo6udN7NjZ4I95D520oHIlLgTBhfdOdq3IQzROxlbbQ W4pZgNwxvXh6aSbq2EFDtZwZ+9ZjKM3kJ8deeC1u64Tqw+AOeXT2Vlet91SD6VpUr9 lW4Ykxp4ZKm1cpNV+f3w1z+/w1mAi9iUSkxrLoM8= To: Brian E Carpenter , Jay Daley , rfced-future@iab.org References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> <39f83475-e0bb-5ca7-ecfe-d6756a581fb5@gmail.com> From: Eliot Lear Message-ID: <3ad917f6-d965-cbf2-0217-38c7e01e9340@lear.ch> Date: Wed, 23 Jun 2021 09:51:08 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <39f83475-e0bb-5ca7-ecfe-d6756a581fb5@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="l31YPW5bFy1au6eTQyfpQIZHHtWK1nu8b" Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 07:51:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --l31YPW5bFy1au6eTQyfpQIZHHtWK1nu8b Content-Type: multipart/mixed; boundary="k5GLm8sIqUeQH1AXKdyFlGhvF8VHiYWpg"; protected-headers="v1" From: Eliot Lear To: Brian E Carpenter , Jay Daley , rfced-future@iab.org Message-ID: <3ad917f6-d965-cbf2-0217-38c7e01e9340@lear.ch> Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> <39f83475-e0bb-5ca7-ecfe-d6756a581fb5@gmail.com> In-Reply-To: <39f83475-e0bb-5ca7-ecfe-d6756a581fb5@gmail.com> --k5GLm8sIqUeQH1AXKdyFlGhvF8VHiYWpg Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 23.06.21 05:06, Brian E Carpenter wrote: > I may have missed it, but I don't there's a github issue for finalizing= the role and title of the RSEA. That's where I would like to hang this c= omment. There are several, one of which we just are in the process of closing.=C2= =A0=20 The title one I have deferred discussing for the moment.=C2=A0 We also ha= ve=20 the agreed text from Issue 12: > This person will be a senior professional with deep knowledge of=20 > technical publishing. > > The RSE will operate by providing expert advice to the RSAWG, and if=20 > requested, to the RPC, on any relevant matters. The value this=20 > individual provides is an understanding of the process of technical=20 > publishing. They expected to learn how the process is applied in the=20 > RFC series. They will be asked to produce regular reviews of the=20 > process and identify problems and opportunities for improvement. There = > are also opportunities to spontaneously learn of these problems,=20 > likely the result of interactions with day-to-day operations. The=20 > person may be requested to draft documents > > For example, the RSE might be consulted about proposed changes to the=20 > style guide, RFC formatting in general, web presence, copyright=20 > matters, or archiving policy, or might of their own initiative suggest = > such changes to the RSAWG. > > The RSE is expected to attend all RSAWG meetings, and to have an=20 > ongoing working relationship with the RPC and tooling team. > https://github.com/intarchboard/program-rfced-future/blob/master/Issue12-= RSE-role.md This text needs to make its way into the draft.=C2=A0 That is not to say = this=20 text can't improve, but this was what we agreed. Eliot --k5GLm8sIqUeQH1AXKdyFlGhvF8VHiYWpg-- --l31YPW5bFy1au6eTQyfpQIZHHtWK1nu8b Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDS5+wFAwAAAAAACgkQh7ZrRtnSejPJ Fgf7BIcmisIsDzUcJgBrhYllbRdeJ91FRCF5mZa2o56T6gVlXTNhcveCyeYSd3qYWItqpr8SCpIU 8mV+VPNLC8ldUdYfUIWNIM3lMUaowCD+RI37xfvfIeSyGzXB2+OXkOL/JoEGq9Rl34WfrD7H/yTf wYHGvFyKmHTWou6wDrvV+elaQivKlehBeiRQd3Y+KxwOwbvscg3uqNALTfSaP1aFEti2VcLf3TZr mT+DDCyZXZI0WTRROh8MNWkH089vlYjyU2kifOUV6PoHppy7jQSnksJ5Mg5Ca1//yEtlj8g2DKeN oQEfS/+ZEOZHBSUjW28nwbWJkI7NJ/A5tIE5XwHfVA== =hWz5 -----END PGP SIGNATURE----- --l31YPW5bFy1au6eTQyfpQIZHHtWK1nu8b-- From nobody Wed Jun 23 01:04:56 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C423A18F4 for ; Wed, 23 Jun 2021 01:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 G24Z1KNoF50x for ; Wed, 23 Jun 2021 01:04:50 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 0A05E3A2EBB for ; Wed, 23 Jun 2021 01:04:49 -0700 (PDT) Received: from p200300dee70cfa000c59a854c52a9569.dip0.t-ipconnect.de ([2003:de:e70c:fa00:c59:a854:c52a:9569]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1lvxsG-0007pW-Vr; Wed, 23 Jun 2021 10:04:41 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: Date: Wed, 23 Jun 2021 10:04:39 +0200 Cc: Eliot Lear , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5977bd11-ca97-6516-57ee-cb1f71ed92d3@lear.ch> To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1624435490;34b915f3; X-HE-SMSGID: 1lvxsG-0007pW-Vr Archived-At: Subject: Re: [Rfced-future] Call for Adoption: draft-saintandre-rfced-model-01 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 08:04:55 -0000 +1 > On 23. Jun 2021, at 08:40, Martin J. D=C3=BCrst = wrote: >=20 > Yes, please! Martin. >=20 > On 2021-06-23 01:02, Eliot Lear wrote: >> Dear Colleagues, >> As discussed in the May interim, we are now issuing a Call for = Adoption of draft-saintandre-rfced-model-01 as the draft this group will = use as intended output. We hope that this call is a mere formality. = Our procedures for content going into that draft and issues raised do = not change. The purpose of adoption is to make clear our group=E2=80=99s = ownership of its content and intent to pursue that work as WG output, = with the very generous and kind help of Peter. >> Please raise any concerns by 6 July 2021. >> Eliot >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Wed Jun 23 01:18:27 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50353A2F12 for ; Wed, 23 Jun 2021 01:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 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, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=joelhalpern.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 XOdLF7x6FvBs for ; Wed, 23 Jun 2021 01:18:21 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 220683A2F15 for ; Wed, 23 Jun 2021 01:18:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4G8x3c682lz1nsLZ; Wed, 23 Jun 2021 01:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1624436300; bh=cs0cHA1OUf7J2aSppTAGtay647oR10pHAO9jaZg823w=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Gw1jBZ6SMZ5gAJO4O5BAOISlLyLJ3jM12bX9+sIm5Uqel4fhoDziixLixJXbuHv02 V0556L83zmtxcL7TQYw23KsaRh4kii8Hfq0Zdoa3OBeTl4TyTm3zdruEO0BkjTvYkq vsUIqCpHdttZiubdd11go2iJid+9a77twiARC3Zw= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4G8x3c0Rznz1nsKq; Wed, 23 Jun 2021 01:18:19 -0700 (PDT) To: Jay Daley , Eliot Lear Cc: rfced-future@iab.org References: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> <1841B01F-42B9-4515-9819-1CA14FA5FA65@ietf.org> From: "Joel M. Halpern" Message-ID: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> Date: Wed, 23 Jun 2021 04:18:20 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <1841B01F-42B9-4515-9819-1CA14FA5FA65@ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 08:18:26 -0000 From my perspective, you are correct that it is a bit of a misalignment. But... A committee is not a stream manager. And giving any of the members of the RSAB a second stream confuses the streams identity. Thus, we bend / stretch the RSEA role a bit? Yours, Joel On 6/22/2021 7:44 PM, Jay Daley wrote: > > >> On 23/06/2021, at 2:51 AM, Eliot Lear > > wrote: >> >> In yesterday's meeting there was general consensus that there should >> be a new stream, and that the RSE/A should manage it. > > Thinking about this overnight, it seems misaligned with the rest of the > proposed new structure for the RSE/A to manage this stream.  The new > process is quite clear that all of the content of this new stream is > generated by the RSWG and approved by the RSAB, so would it not make > more sense for the RSAB to manage this stream?  If not then I’d like to > understand why it should be the RSE/A and what "manage" means in > practice given this new process, because AFAICT it doesn’t mean anything. > > Jay > >> The general argument was that there should be no supervisory check >> performed by the IAB after the RSAB has approved a document. >> >> Please send any concerns by 6 July. >> >> Eliot >> >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > > -- > Jay Daley > IETF Executive Director > jay@ietf.org > > From nobody Wed Jun 23 01:49:53 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350013A2FF2 for ; Wed, 23 Jun 2021 01:49:51 -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, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=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 nPCtURVqMhLB; Wed, 23 Jun 2021 01:49:46 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id B87603A2FF1; Wed, 23 Jun 2021 01:49:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jay Daley Mime-Version: 1.0 (1.0) Date: Wed, 23 Jun 2021 20:49:42 +1200 Message-Id: <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> Cc: Eliot Lear , rfced-future@iab.org In-Reply-To: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: iPhone Mail (18F72) Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 08:49:51 -0000 > On 23/06/2021, at 8:18 PM, Joel M. Halpern wrote: >=20 > =EF=BB=BF=46rom my perspective, you are correct that it is a bit of a misa= lignment. But... A committee is not a stream manager. And giving any of t= he members of the RSAB a second stream confuses the streams identity. It=E2=80=99s not a =E2=80=9Ccontent=E2=80=9D stream though - it=E2=80=99s a =E2= =80=9Cmeta=E2=80=9D stream that all the other streams have a strong stake in= , which gives it a distinct identity.=20 > Thus, we bend / stretch the RSEA role a bit? But what does that mean in practice given that all the decisions about this s= tream are made by the RSWG? If I may introduce a useful English expression i= nto IETF discourse, it=E2=80=99s as much use to the RSEA as a chocolate teap= ot.=20 Jay (sent from my phone) --=20 Jay Daley IETF Executive Director +64 21 678840 >=20 > Yours, > Joel >=20 > On 6/22/2021 7:44 PM, Jay Daley wrote: >>>> On 23/06/2021, at 2:51 AM, Eliot Lear > wrote: >>>=20 >>> In yesterday's meeting there was general consensus that there should be a= new stream, and that the RSE/A should manage it.=20 >> Thinking about this overnight, it seems misaligned with the rest of the p= roposed new structure for the RSE/A to manage this stream. The new process i= s quite clear that all of the content of this new stream is generated by the= RSWG and approved by the RSAB, so would it not make more sense for the RSAB= to manage this stream? If not then I=E2=80=99d like to understand why it s= hould be the RSE/A and what "manage" means in practice given this new proces= s, because AFAICT it doesn=E2=80=99t mean anything. >> Jay >>> The general argument was that there should be no supervisory check perfo= rmed by the IAB after the RSAB has approved a document. >>>=20 >>> Please send any concerns by 6 July. >>>=20 >>> Eliot >>>=20 >>>=20 >>> --=20 >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >> --=20 >> Jay Daley >> IETF Executive Director >> jay@ietf.org >=20 From nobody Wed Jun 23 01:56:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921193A3021 for ; Wed, 23 Jun 2021 01:56:52 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=ha4opi9t; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=c8b0/KN6 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 pSYMtzYIK0Fh for ; Wed, 23 Jun 2021 01:56:48 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29FD83A3020 for ; Wed, 23 Jun 2021 01:56:48 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 012A85C0164 for ; Wed, 23 Jun 2021 04:56:47 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute4.internal (MEProxy); Wed, 23 Jun 2021 04:56:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=V7RIa bljXBdc6tTBjlEBArF3mBYYYBfGExQoPHlFfSw=; b=ha4opi9tRjcvhfBlT8kLb jrqhUyJFlyWrCK/8RJc9J+5KasNIoWL+y0NtdY2zvDEtvN86ge/Erk6ih6xMnPmP gbpyzjfakEn1wKBwMmNRngzFWRpvKKjVSxB6sAQTnkN5aWsVkobMDzqADk7Lylpe WWF0792QHoOvSZ8O3leCrSdjn3LwcJuAamjxwpZ3KzV/QxA2G1jQ27EwEfxyE8Cv Ojsb/rubjyYWMqmeisgfGZbuADt1/v3Uc1YQ5o5KEsWmd+zpBmosCc9r23xwjndn D3DMMUv5oNPjrsM4fpjblERzHBYiX2xibAF9gCr963iU5ah0/4hA8suUb9ldkJED w== 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=V7RIabljXBdc6tTBjlEBArF3mBYYYBfGExQoPHlFf Sw=; b=c8b0/KN6dOMCTKSUfdcTCiYXYu+FFcDk+W6Qncluvu4TFwrJaCNBMB4Xw pvDxkEoO3IUDWVuQn4dk9TcnTdU/F34b41aRdfUpOCRsMn8K94SOzguhb0HKD4oo M0kjMxZxixe1NdwM9gOk/VhbtdKxxiu9Czsz0OJ9trghUeFt2/VC/eDlHnOcoRZO vTSaPTQDsuMo3WI3LHbHHiLdVvpjlyDtlZU18iBALoSvQAlwwX2Yug4bWtRB6abV 78/lrWTF40lEOqvtC95IxZEUrOqSN8Tl5/kQqdUlZcEMAHmxHXR8cMvL5x6ELLiw 4uLpjvcTg/e2nQhs+Ly0VCdmewWbQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeegfedgudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepgfejueduieffledtge elheejvdettdejudduhefggeefgfekgfeuieetgefftddtnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnh gvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8F06C4E00D7; Wed, 23 Jun 2021 04:56:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-530-gd0c265785f-fm-20210616.002-gd0c26578 Mime-Version: 1.0 Message-Id: <0c78625b-2770-4670-be23-760804695cb5@beta.fastmail.com> In-Reply-To: <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> Date: Wed, 23 Jun 2021 18:56:24 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 08:56:53 -0000 On Wed, Jun 23, 2021, at 18:49, Jay Daley wrote: > But what does that mean in practice given that all the decisions about= =20 > this stream are made by the RSWG? If I may introduce a useful English=20= > expression into IETF discourse, it=E2=80=99s as much use to the RSEA a= s a=20 > chocolate teapot.=20 The RSWG decides for all streams. So it is already special. The IESG might have greater editorial control over the content of their = stream, but not a great deal more. The job of a stream manager is to rep= resent the interests of the stream, and it seems like the RSA/E is well = positioned to do that for an editorial stream. The RSWG chairs might als= o do it, but it seems better to give the RSAE the task. Circular reasoning doesn't have to be rejected because it is circular. From nobody Wed Jun 23 01:57:02 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9110A3A301C; Wed, 23 Jun 2021 01:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 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, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 w4cNM1h8Z16J; Wed, 23 Jun 2021 01:56:55 -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 B03693A3022; Wed, 23 Jun 2021 01:56:54 -0700 (PDT) Received: from [192.168.0.185] (31-10-155-187.cgn.dynamic.upc.ch [31.10.155.187]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15N8ul5P443809 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 23 Jun 2021 10:56:47 +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=1624438607; bh=qe2SqUkOpn456UPDiOeSrmF07lu2P+cKI0nGFDcQ7ao=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ud6GAlBLiimZ7PTqeBdOp8r7HGGTt/Va/3feC/FSDuaD45d/lo9Ck4lUOGWOo5EmF 3zRgYQ/yDtiZPCd/S/2i9f3A6zDj4sl7udAKECdXm/7Qds59x2XjcgQdNTdYkjWyV4 VWydiCyzFihmz9IvbFNJj2vJfAQG4ZwNAqdBycn0= To: Jay Daley , "Joel M. Halpern" Cc: rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> From: Eliot Lear Message-ID: Date: Wed, 23 Jun 2021 10:56:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="R2Hfc0J8vlqfPNqNWbgJm8OK9mOADisZw" Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 08:57:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --R2Hfc0J8vlqfPNqNWbgJm8OK9mOADisZw Content-Type: multipart/mixed; boundary="msd3DAQ8qvRmzwfQcfyN79M4sTVm64aaP"; protected-headers="v1" From: Eliot Lear To: Jay Daley , "Joel M. Halpern" Cc: rfced-future@iab.org Message-ID: Subject: =?UTF-8?Q?Re=3a_=5bRfced-future=5d_Consensus_check=3a_Issue_22_?= =?UTF-8?Q?=e2=80=93_new_stream_for_RFC_Editor?= References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> In-Reply-To: <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> --msd3DAQ8qvRmzwfQcfyN79M4sTVm64aaP Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US If you're suggesting that the RSAB itself hold the stream, that's=20 certainly an alternative.=C2=A0 However, the RSAB should probably be boun= d by=20 policies of This document in the use of the stream.=C2=A0 This would be=20 similar in nature to how the IAB stream is operated. On 23.06.21 10:49, Jay Daley wrote: > >> On 23/06/2021, at 8:18 PM, Joel M. Halpern wrote= : >> >> =EF=BB=BFFrom my perspective, you are correct that it is a bit of a mi= salignment. But... A committee is not a stream manager. And giving an= y of the members of the RSAB a second stream confuses the streams identit= y. > It=E2=80=99s not a =E2=80=9Ccontent=E2=80=9D stream though - it=E2=80=99= s a =E2=80=9Cmeta=E2=80=9D stream that all the other streams have a stron= g stake in, which gives it a distinct identity. > >> Thus, we bend / stretch the RSEA role a bit? > But what does that mean in practice given that all the decisions about = this stream are made by the RSWG? If I may introduce a useful English exp= ression into IETF discourse, it=E2=80=99s as much use to the RSEA as a ch= ocolate teapot. > > Jay > > (sent from my phone) > --msd3DAQ8qvRmzwfQcfyN79M4sTVm64aaP-- --R2Hfc0J8vlqfPNqNWbgJm8OK9mOADisZw Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDS904FAwAAAAAACgkQh7ZrRtnSejPr fAf/W1iaHCo1vb8LqmYJiW4koo1J61mACJpshWrBxEP84GdADsH/O6x2qLI2kNsYFjLLBgo2ohqY RM0Sb1KdS6X3YBYdxLopirF6lOk9BZCfmh7i+QyrtpTqOGUaWX2Lv3rSlwTTfvl/dxtC1xYzU/vH rRZWtCxfL2y04O1tZj/4pdGuPRbBcDgBZLU51l78CSBcjCjbokt/XNSupcPZcwZov+1M/69m8OD6 Agzgzs5IfUnK939NqS7ZluammWnnkLHyfEr0r1n8OwhN5Jn0kcFchKxtXwIYOrSDxlVQ4XeqpwaV lL7Cxa2TycoZ3991C9EGAwMlJsKklVRz76RYYo+lmA== =WiLa -----END PGP SIGNATURE----- --R2Hfc0J8vlqfPNqNWbgJm8OK9mOADisZw-- From nobody Wed Jun 23 02:05:03 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937073A3054 for ; Wed, 23 Jun 2021 02:05:01 -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, URIBL_BLOCKED=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 CWTJ0NRNFx-q; Wed, 23 Jun 2021 02:04:56 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 32B1A3A304C; Wed, 23 Jun 2021 02:04:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jay Daley Mime-Version: 1.0 (1.0) Date: Wed, 23 Jun 2021 21:04:52 +1200 Message-Id: <73037DB4-4F98-4784-80D6-1B3AC350B678@ietf.org> References: <0c78625b-2770-4670-be23-760804695cb5@beta.fastmail.com> Cc: rfced-future@iab.org In-Reply-To: <0c78625b-2770-4670-be23-760804695cb5@beta.fastmail.com> To: Martin Thomson X-Mailer: iPhone Mail (18F72) Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 09:05:02 -0000 > On 23/06/2021, at 8:57 PM, Martin Thomson wrote: >=20 > =EF=BB=BF >=20 >> On Wed, Jun 23, 2021, at 18:49, Jay Daley wrote: >> But what does that mean in practice given that all the decisions about=20= >> this stream are made by the RSWG? If I may introduce a useful English=20 >> expression into IETF discourse, it=E2=80=99s as much use to the RSEA as a= =20 >> chocolate teapot.=20 >=20 > The RSWG decides for all streams. So it is already special. >=20 > The IESG might have greater editorial control over the content of their st= ream, but not a great deal more. The job of a stream manager is to represent= the interests of the stream, and it seems like the RSA/E is well positioned= to do that for an editorial stream. If that was the sole role of a stream manager then the RSEA would be a feasi= ble choice, but there=E2=80=99s much more to the role. For example, recent d= ecisions by stream managers include how errata should be processed and wheth= er or not to adopt the terminology decision of the IETF stream. Those are sq= uarely RSWG decisions.=20 Jay (sent from my phone) --=20 Jay Daley IETF Executive Director +64 21 678840 =20 > The RSWG chairs might also do it, but it seems better to give the RSAE the= task. >=20 > Circular reasoning doesn't have to be rejected because it is circular. >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Wed Jun 23 02:06:52 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E333A3067 for ; Wed, 23 Jun 2021 02:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 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, NICE_REPLY_A=-0.338, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=joelhalpern.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 cOUP86Vrobnv for ; Wed, 23 Jun 2021 02:06:45 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 7F79C3A3065 for ; Wed, 23 Jun 2021 02:06:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4G8y7T1z2wz1nsL9; Wed, 23 Jun 2021 02:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1624439205; bh=hHU5vlul29HV52ej1AsenS80wgG5577/5HfpioNubgw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=iuGhVNddTReFkHjw7bC20U41IRL3yngdl/G/+eed1FxQfNDQLxSpRo9fiCdOQGv6w yKUCmgFy8GmbX1+eOcCOKz8RtG8P4CS/GPo64tioE7fvnBjqvAi+etZ1LFfz1/0yJ6 6PlbXlaIExaaY3tpK8hVTSESr2/Grvqhm5EeWuys= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4G8y7S4wpJz1ns8G; Wed, 23 Jun 2021 02:06:44 -0700 (PDT) To: Eliot Lear , Jay Daley Cc: rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> From: Joel Halpern Direct Message-ID: <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> Date: Wed, 23 Jun 2021 05:06:44 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 09:06:50 -0000 I am wondering if we are mixing the concept of stream manager with stream content owner. The IESG is responsible for the content of the IETF stream. The IETF Chair or their delegate is the IETF stream manager. That role is making sure that there are no issues with the practical publication of the stream, including interacting with the RPC. Declaring the RSAB to be the stream manager hurts my head. That is not a person. And will create confusion about the role of the RSAB. WHile the obvious analogy is to declare that the RSAB chair is the stream manager for this new stream, it seems to me that creates confusion since that person is (unless they are the RSE/A) the stream head for some other stream. Yours, Joel PS: One answer may be that there is no stream manager for this stream? Because the role is redundant with the defined roles for the RSAB? On 6/23/2021 4:56 AM, Eliot Lear wrote: > If you're suggesting that the RSAB itself hold the stream, that's > certainly an alternative.  However, the RSAB should probably be bound by > policies of This document in the use of the stream.  This would be > similar in nature to how the IAB stream is operated. > > On 23.06.21 10:49, Jay Daley wrote: >> >>> On 23/06/2021, at 8:18 PM, Joel M. Halpern wrote: >>> >>> From my perspective, you are correct that it is a bit of a >>> misalignment.  But...   A committee is not a stream manager.  And >>> giving any of the members of the RSAB a second stream confuses the >>> streams identity. >> It’s not a “content” stream though - it’s a “meta” stream that all the >> other streams have a strong stake in, which gives it a distinct identity. >> >>>   Thus, we bend / stretch the RSEA role a bit? >> But what does that mean in practice given that all the decisions about >> this stream are made by the RSWG? If I may introduce a useful English >> expression into IETF discourse, it’s as much use to the RSEA as a >> chocolate teapot. >> >> Jay >> >> (sent from my phone) >> > From nobody Wed Jun 23 02:57:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269B33A31C1 for ; Wed, 23 Jun 2021 02:57:22 -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 rTMsSL-Yhv3G for ; Wed, 23 Jun 2021 02:57:20 -0700 (PDT) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 176403A31C0 for ; Wed, 23 Jun 2021 02:57:19 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15N9vGYh022432 for ; Wed, 23 Jun 2021 10:57:16 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4AA3C4604A for ; Wed, 23 Jun 2021 10:57:16 +0100 (BST) Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3F0B24604B for ; Wed, 23 Jun 2021 10:57:16 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS for ; Wed, 23 Jun 2021 10:57:16 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.47.18]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15N9vFqY012077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 23 Jun 2021 10:57:15 +0100 Reply-To: From: "Adrian Farrel" To: References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> In-Reply-To: Date: Wed, 23 Jun 2021 10:57:14 +0100 Organization: Old Dog Consulting Message-ID: <0b9a01d76816$25690dd0$703b2970$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQFeB7wLGpfp4ou+LlCxukcXuovX/QFGv76aAvm9xwSr8hZ8oA== X-Originating-IP: 84.93.47.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1017-26236.006 X-TM-AS-Result: No--6.554-10.0-31-10 X-imss-scan-details: No--6.554-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1017-26236.006 X-TMASE-Result: 10--6.554100-10.000000 X-TMASE-MatchedRID: scwq2vQP8OG8rRvefcjeTb7u5vMMMVTtaMmm586o4gBVjXcpQOPL2wSD CUdk18WiZWI/41dR8d9LTxZI1do3QY5S/4bo68Nb8irf7wNB3SgCC8zqHvcG2tRGf5c57+FFbYd a9H3QEXWrKaCIB8U9PexBC7yoarHzT5gVH5B/9XD5TWyhseEO1AEoHzC4m9uQvfScyRtKaR2sSI 0mH7EmmZAuc7XR18tKt+GvuYPoobwYB2fOueQzj91asM/801mntHIYYgLGbjZQSFbL1bvQAXnN0 DN7HnFmoBKX3XDeG+RZTROX7bSsh8jSWwFzbDVTgeprWlf1rRJ1iui33Anvi5RMZUCEHkRt X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 09:57:22 -0000 Oh, by the way, if we create a new stream, how shall we handle = "interference" with other streams? Today we have 5742 to allow the IESG to provide guidance on how IRTF and = IS stream documents might adversely interfere with IETF work. However, there is no such filter on the IAB stream (possibly because the = IAB can go for community feedback, possibly because there is a liaison = between IAB and IESG, and possibly because of history). Suppose a new stream published something that impeded in some way IETF = work? I'm sure it is not our intent to open up a channel for end runs or = subversion. A From nobody Wed Jun 23 03:08:16 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A8B3A3214 for ; Wed, 23 Jun 2021 03:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 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, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 L8qSF3Bj5luJ for ; Wed, 23 Jun 2021 03:08:10 -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 EB6813A3212 for ; Wed, 23 Jun 2021 03:08:08 -0700 (PDT) Received: from [IPv6:2a02:aa15:4101:2a80:48eb:1cc0:feae:3cbd] ([IPv6:2a02:aa15:4101:2a80:48eb:1cc0:feae:3cbd]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15NA818d444664 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 23 Jun 2021 12:08:01 +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=1624442881; bh=ZoyKfZWUnDbvRywFADp49fafxpBFzCOGhYdIlDrwQGI=; h=To:References:Cc:From:Subject:Date:In-Reply-To:From; b=PNIBYzLxoAUR5wIbf3B0dq9sEojAI+6hdtU/cMwEvYFF5zGNP5hM7BCWidR0+lPRn 5VDZZ8y9GN8bUje2tthtKOhahuTmFXHy2vkJiH4A3xJmidmoRlpruCImrhPkfqVQls mq4822WMPCMm7ijqUCDeGzuyIQMYDGrDX8m+FuAs= To: adrian@olddog.co.uk References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <0b9a01d76816$25690dd0$703b2970$@olddog.co.uk> Cc: rfced-future@iab.org From: Eliot Lear Message-ID: Date: Wed, 23 Jun 2021 12:07:59 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <0b9a01d76816$25690dd0$703b2970$@olddog.co.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zMWy7gMP5VUS30X3Nj8oApiMrC5aWVXOo" Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 10:08:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --zMWy7gMP5VUS30X3Nj8oApiMrC5aWVXOo Content-Type: multipart/mixed; boundary="ktTAddxMPwf79oDZvJqRbk9bUJgfGR6yg"; protected-headers="v1" From: Eliot Lear To: adrian@olddog.co.uk Cc: rfced-future@iab.org Message-ID: Subject: =?UTF-8?Q?Re=3a_=5bRfced-future=5d_Consensus_check=3a_Issue_22_?= =?UTF-8?Q?=e2=80=93_new_stream_for_RFC_Editor?= References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <0b9a01d76816$25690dd0$703b2970$@olddog.co.uk> In-Reply-To: <0b9a01d76816$25690dd0$703b2970$@olddog.co.uk> --ktTAddxMPwf79oDZvJqRbk9bUJgfGR6yg Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Adrian, On 23.06.21 11:57, Adrian Farrel wrote: > Suppose a new stream published something that impeded in some way IETF = work? I'm sure it is not our intent to open up a channel for end runs or = subversion Assuming that the stream is exclusively for use for documents that are=20 approved via the process we are now defining, then the ultimate step is=20 for the RSAB to approve the document.=C2=A0 As part of that process, othe= r=20 stream manager representatives get a shot at raising CONCERNs.=C2=A0 In a= =20 sense, therefore, a check is built in. Indeed the document already says=20 the following: > =C2=A0=C2=A0 Notices will always be sent to the rfc-interest mailing li= st.=C2=A0 The > =C2=A0=C2=A0 RSAB and RSWG should also send notices to other communitie= s that may > =C2=A0=C2=A0 be interested in or impacted by a proposal as they see fit= , following > =C2=A0=C2=A0 policies for those fora as appropriate. And so this allows each stream to apply whatever conflict resolution=20 process they would choose in order to determine whether a CONCERN should = be raised. And of course, as you pretty much laid out a cornerstone of continuous=20 consultation (that I have put to annoyingly apt alliteration), hopefully = such concerns can be addressed.=C2=A0=C2=A0 But need we say more? Eliot --ktTAddxMPwf79oDZvJqRbk9bUJgfGR6yg-- --zMWy7gMP5VUS30X3Nj8oApiMrC5aWVXOo Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDTB/8FAwAAAAAACgkQh7ZrRtnSejMt Iwf9FnWB7s32XdYFArLWe8RtwdXuNnd3dvwyTCHjV8oTEBCXW5UNny0v/jjFJKM79pksn+18V+QM OHFSRj4ipdwt3zXGaXSZymOysW35e/qE/dxBqfXiS6jL8gKYAJO2VWoXmrjjL3CC7+zVwniwp75x d90rJsrYPHHxoxPi4IQCS+4s2TkPZape2srGQ6gSuFxuSxMAq0zhokPjFol7xGItO6EY0L007cD3 1Hz1ukdqvgWlS79CsNHrORrhsTh3aY3XoNgCu8dhzh7PgOu6LUJGIc2GxSyw6EW7VwIgovjERkWY 39PrKTe/yvSppQiP18Cu+vloRXnhC+PVSnNVEuHQJw== =lUCL -----END PGP SIGNATURE----- --zMWy7gMP5VUS30X3Nj8oApiMrC5aWVXOo-- From nobody Wed Jun 23 09:33:07 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86CB3A3D0A for ; Wed, 23 Jun 2021 09:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 SkjHRKj8vqBL for ; Wed, 23 Jun 2021 09:33:02 -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 EFE6F3A3D07 for ; Wed, 23 Jun 2021 09:33:01 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::e] ([IPv6:2001:420:c0c0:1011:0:0:0:e]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15NGWwjT448614 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Wed, 23 Jun 2021 18:32:59 +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=1624465979; bh=NJKxTMGP3un2+ynrZA8nP/uQBIQFhoM9/eBHbLh2Kno=; h=To:From:Subject:Date:From; b=TWVr7UEgJasoWBsT6NxsxC8WbbsLuP8w5jPHvDlzdt7iwJAXJBOa1EdbhpQHM2Ng8 pqALgAYLuHp5G7wbpAZqvzfsp0F88dONnXhaWLkJ9oBy1mXXuAOnVj+VaHiYJ7oNdG pQgBm3clsaxQICil2n3ltewro8fqUOFPHsVQdiR8= To: rfced-future@iab.org From: Eliot Lear Message-ID: Date: Wed, 23 Jun 2021 18:32:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WGMBeqwIpVZbkaaNE8yD1vvre2WtzGbKZ" Archived-At: Subject: [Rfced-future] draft minutes uploaded X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 16:33:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WGMBeqwIpVZbkaaNE8yD1vvre2WtzGbKZ Content-Type: multipart/mixed; boundary="oXPXeRxHbZ87SFdVy1asj3bwxLpGAfJ0J"; protected-headers="v1" From: Eliot Lear To: rfced-future@iab.org Message-ID: Subject: draft minutes uploaded --oXPXeRxHbZ87SFdVy1asj3bwxLpGAfJ0J Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Thanks to those who participated.=C2=A0 Draft minutes and bluesheets have= =20 been uploaded. Please see=20 https://datatracker.ietf.org/doc/minutes-interim-2021-rfcefdp-05-20210621= 2000/. --oXPXeRxHbZ87SFdVy1asj3bwxLpGAfJ0J-- --WGMBeqwIpVZbkaaNE8yD1vvre2WtzGbKZ Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDTYjkFAwAAAAAACgkQh7ZrRtnSejOr hggAnHczDaJmfiP8w0YhbvJrlivmxFfQvlJFzcYlQQmuD+j3DTOlGYOAn0tasw4s39+YWoYIHhzI CXbUJS1c0pDEMVGhPqK8xogPyA5H8AspmGcNLwgFC3ZnDWkocIcDd5yXg7UiBixCG1FV4PaIxPXB lZRHrxNmllj+MeCfr0XKxwDy97bBUTDRDQppwYAIcbB9mJZhgOfj8HTWZbiRxBPemWS1hWJl37uY 4qZmLBUufjAmhMhzB2t0b4bMx/hZspKXMc1t/rM6k7Yb6TMZ3cZxKYg82djJGBppLQtPFysDYBjp GF1h1LzXIIVil5HLRmAkEWX8PHV9gxNyUiUSCsKg5A== =LBxL -----END PGP SIGNATURE----- --WGMBeqwIpVZbkaaNE8yD1vvre2WtzGbKZ-- From nobody Wed Jun 23 12:43:48 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9395D3A0E00 for ; Wed, 23 Jun 2021 12:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.338, 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 rqm63WzYwj27 for ; Wed, 23 Jun 2021 12:43:41 -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 68DA83A0DFB for ; Wed, 23 Jun 2021 12:43:41 -0700 (PDT) Received: from Lear-Air.local ([IPv6:2a02:aa15:4101:2a80:e06b:c14b:ed19:6b55]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15NJhaDT451885 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 23 Jun 2021 21:43:36 +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=1624477417; bh=iI2VshMSKqWEzv956/vnLlqJcFfsa9Wt6+e+ezkfLa4=; h=To:References:From:Subject:Date:In-Reply-To:From; b=wEA6xG6YcidVheFZD+kcQYOKq5AANSVPUf4AUVhMOeLdkxImXMImTvuJmahuIuktc Rozuzr6vK0SBWaqeb2EI+4iBMgfnisMAzCdm+YYoXFpPdbD3vujgfFb2lqYZEtg2Nn 57xGnWiC7kkaDePHXpylFrQKteZIo6XSaWKu7xYU= To: Brian E Carpenter , Michael StJohns , rfced-future@iab.org References: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> <0a8101d76788$0e1af5a0$2a50e0e0$@olddog.co.uk> <0ace01d767a5$39001350$ab0039f0$@olddog.co.uk> <7bda1df1-307b-4370-ad94-71af09af12c4@www.fastmail.com> <47618d03-3136-a4db-cd5b-66a1e89216ac@gmail.com> <492d7b65-33b9-e749-3297-85fe6779531c@nthpermutation.com> <16ab1107-6e4c-aaa4-80ef-7675ca05b13a@gmail.com> From: Eliot Lear Message-ID: Date: Wed, 23 Jun 2021 21:43:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <16ab1107-6e4c-aaa4-80ef-7675ca05b13a@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="a4xOSVD6ZLg2Jdrjbrh5gCqBl8naGVzJk" Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 19:43:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --a4xOSVD6ZLg2Jdrjbrh5gCqBl8naGVzJk Content-Type: multipart/mixed; boundary="YUpBrlwNBJ9pYKYONV1wGlOpi8nGjPxfm"; protected-headers="v1" From: Eliot Lear To: Brian E Carpenter , Michael StJohns , rfced-future@iab.org Message-ID: Subject: =?UTF-8?Q?Re=3a_=5bRfced-future=5d_Consensus_check=3a_Issue_22_?= =?UTF-8?Q?=e2=80=93_new_stream_for_RFC_Editor?= References: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> <0a8101d76788$0e1af5a0$2a50e0e0$@olddog.co.uk> <0ace01d767a5$39001350$ab0039f0$@olddog.co.uk> <7bda1df1-307b-4370-ad94-71af09af12c4@www.fastmail.com> <47618d03-3136-a4db-cd5b-66a1e89216ac@gmail.com> <492d7b65-33b9-e749-3297-85fe6779531c@nthpermutation.com> <16ab1107-6e4c-aaa4-80ef-7675ca05b13a@gmail.com> In-Reply-To: <16ab1107-6e4c-aaa4-80ef-7675ca05b13a@gmail.com> --YUpBrlwNBJ9pYKYONV1wGlOpi8nGjPxfm Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US As a matter of history: On 23.06.21 02:22, Brian E Carpenter wrote: > The IAB charter is an IETF BCP, so it can only be updated by an > IETF standards action. It can practically be a one line document > except for boilerplate, but it's gonna have to be done. My personal view: I don't think we should let the tail wag the dog, nor=20 block this work on a new charter for the IAB.=C2=A0 This document could j= ust=20 as easily be processed as a BCP; the only issue being that the IESG=20 would have to approve it.=C2=A0 If we want, we can get both IAB and IESG = assent.=C2=A0 That has been previously done for RFC 7979. It'd require that an IESG member, presumably the chair, sponsor the doc, = and that it go through IETF last call and IESG evaluation.=C2=A0 If the I= ESG=20 is unwilling to do this, we could revisit the matter. Eliot --YUpBrlwNBJ9pYKYONV1wGlOpi8nGjPxfm-- --a4xOSVD6ZLg2Jdrjbrh5gCqBl8naGVzJk Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDTjuMFAwAAAAAACgkQh7ZrRtnSejOn SggAvLybShYjVkEMrvET7xLnMhco6lFr3wiHbNMDtDcBQu98Qmu9yvQ+LWHtW46dXOyiV1G6Kp23 0dYVel80oZ3elPKDkNVFioRD31e78dsUIv3aXdS9lzyPWvgFPy2KiaUgrPd4lcYt5c9brPfBIPdS YbQytVzD80K7WrO6UBPfr16vA/yR3oo3lC3g9d8/W1UESVQ0W7zEq5GUTUg0wlF4rrUnq6ZU5Jgh Zeh1f4mIgnXqorXdOqd3uc1QzX60hSAoo3JUFzJpM33XcZfH8lzB6cC+wWd3EOPeqRavn1/Hk7Mg b/NqdKl97tBjf+/5/QzkcPhZq0lfwsbui201QsI+3Q== =jqEv -----END PGP SIGNATURE----- --a4xOSVD6ZLg2Jdrjbrh5gCqBl8naGVzJk-- From nobody Wed Jun 23 13:07:29 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE813A1267 for ; Wed, 23 Jun 2021 13:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.338, 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=nthpermutation-com.20150623.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 kkUS-jXFTX9H for ; Wed, 23 Jun 2021 13:07:23 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 DF6923A11FD for ; Wed, 23 Jun 2021 13:07:22 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id o6so8450021qkh.4 for ; Wed, 23 Jun 2021 13:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=mKoCqpNcUHfDd8PvjaFiNUImPADrEPdYlIRzqcJbZsY=; b=Vc6845FmxU2HG7g1oXsRhf0D9YlA7cbKu9tGGbHn/uvYptwwcZhmOk3fORXHFx59Ek eKH7LHuxVs5mofTf6M+jIuIPU7yUjLbxkaVCSQ3EbcymTftVS7JDXxq0xBoI5Q8sTRer o5d5rCUXsKEGSFbCCf83uxrCAfguNb107Cymg1+LB7LhJEdjYroGruHlQnbQWhawdfpB BP/DuC/051uB7BhPxzacKYouWT3Du2s5OcsEk/fZl/VNurSPRBFz9ptEteypEbDKALTZ CAIkI76f8Kzh30IsimD30SYGSE188pvmetyeNiG9Kpquo34XlTSowtduEpbZ/PLWhEMS 1nJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=mKoCqpNcUHfDd8PvjaFiNUImPADrEPdYlIRzqcJbZsY=; b=ODiXg76ax0CBCUm8qKkwAT97w8J4Xpqvl8MHRuYmiYroAZs4MFWBDpCCY8UCWuW9dE IiS9w8SyX+INukPRkGN/N+FiUlJGxkAxGJWYq0wzZA7IMVTr6GRfgi2omtcubXZnt/BB oUkqlhYswtn1ojzjBk5AHafgi6K/xAPWRn/+lfuoUBZ1C/ce5oxqZ+KRg+FMP7p/GFHr UHTFsoo6BUUf0QbDO1aPFl9cPjlmGWdlA8TM14INhNuQraQcIe/29anNu/PnR0bNy5Hw mWw0Er3cvpwKrGUqyYkStExpnUMPXFbaBKDW6njk+mcVuMzauDYoY63MGcL3ZE9d6LZB 6beQ== X-Gm-Message-State: AOAM533rpyXyTi1wqO2jF4lhGbd9FnABhGwJoacOcA50YpdDlWiCsF9f 4DH2NOS1vOrtBJA4pArXj+/CCs0jtLiUoyh4h28= X-Google-Smtp-Source: ABdhPJzEGbH1RAVMxkZSc1ptrtutJM6ptBHn0IUnweYdyfrARRUx0IGjkDSXYH8yK9BLEpEz519Siw== X-Received: by 2002:ae9:c304:: with SMTP id n4mr1807586qkg.393.1624478840747; Wed, 23 Jun 2021 13:07:20 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id d8sm590076qtx.83.2021.06.23.13.07.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Jun 2021 13:07:20 -0700 (PDT) To: Eliot Lear , Brian E Carpenter , rfced-future@iab.org References: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> <0a8101d76788$0e1af5a0$2a50e0e0$@olddog.co.uk> <0ace01d767a5$39001350$ab0039f0$@olddog.co.uk> <7bda1df1-307b-4370-ad94-71af09af12c4@www.fastmail.com> <47618d03-3136-a4db-cd5b-66a1e89216ac@gmail.com> <492d7b65-33b9-e749-3297-85fe6779531c@nthpermutation.com> <16ab1107-6e4c-aaa4-80ef-7675ca05b13a@gmail.com> From: Michael StJohns Message-ID: <836bbdfd-8e61-ad18-ea8f-ff45331ed66b@nthpermutation.com> Date: Wed, 23 Jun 2021 16:07:19 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 20:07:28 -0000 On 6/23/2021 3:43 PM, Eliot Lear wrote: > As a matter of history: > > On 23.06.21 02:22, Brian E Carpenter wrote: >> The IAB charter is an IETF BCP, so it can only be updated by an >> IETF standards action. It can practically be a one line document >> except for boilerplate, but it's gonna have to be done. > > My personal view: I don't think we should let the tail wag the dog, > nor block this work on a new charter for the IAB.  This document could > just as easily be processed as a BCP; the only issue being that the > IESG would have to approve it.  If we want, we can get both IAB and > IESG assent.  That has been previously done for RFC 7979. > > It'd require that an IESG member, presumably the chair, sponsor the > doc, and that it go through IETF last call and IESG evaluation.  If > the IESG is unwilling to do this, we could revisit the matter. > > Eliot > > +1 - I'd actually extend this to the ISE and the IRTF for approval as it will affect them as well. All of this could be done in parallel rather than serially as the datatracker seems to enforce. Mike From nobody Wed Jun 23 14:30:17 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D1F3A412A for ; Wed, 23 Jun 2021 14:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 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.338, RCVD_IN_DNSWL_NONE=-0.0001, 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 Q0gcadeIvUab for ; Wed, 23 Jun 2021 14:30:14 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 9603B3A4128 for ; Wed, 23 Jun 2021 14:30:14 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id u190so2875883pgd.8 for ; Wed, 23 Jun 2021 14:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=tW1O6VZVn3gIYstZKKEs/5cBfRFqwtouM5YMXZoSzHg=; b=dB+6yJ5SW8qurXUncCVG3erTRsYSTRjeEaesaoruabm7F2ExhFFs183gGo6nLD5t0u I62+ARHpssW+apJjuZPKSNjcOEL6t/Xi4U90A8j7w+4LEZpaE1F/+uEdPz6lFr9EBXML iejW1cmLlYKIqZUwdktZMqG70SnXwtWJeynySrFLX5Z45oHkDoy725m51qkcJsXb0waW PH9ap1689VxH51O3/8t+6AY+7y7pswEGKRXJnglDx0oFf/NcEQK252jLW4974QglDHcd +0zNwPvaumg95TxdTou/pcBOU3QQVgW3NWBrybwFnNpvJFM8PgN83DXm2h6ViadeL2ab YtmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tW1O6VZVn3gIYstZKKEs/5cBfRFqwtouM5YMXZoSzHg=; b=S/oXapHmRIacadanBwWfsj/uH2E9+ox0Eli/RZb4wfSDWaSAFcn/mr+7lw+10BFROq Gwv4rjnadgrMeBIvdT0KDm5k1GcQ7KjmSDVVx9xXJk91KgIcR5h71nMTqk5Ft8e3qLKu jb4ixIlAAvGF491YFe7wRJspKrOwlBbsMWI2T1GyoG1b51EtEuKPWKqnaPSeITmfKvDf YiVfgN/UWXgfbIy6iX8zEg1Y51icnUjoVOqw2u3dKRrFSTzorSK20Al2iYGL5v+ZmXNQ Kr5j4D42Oh4PwnZtjftYNgCLvSPoPX5qvb+4HJjNlGoeJF1dT5hMAWn6r5rp/zzpGSfo ytxA== X-Gm-Message-State: AOAM531gXiSxP5/cEMjBcHBnWLnQdZ+2omkFjiVZoXf1NTiAmSbxFtdr QrKc2PRxfr1AsF2DMU2zBrVX29J9lZ510g== X-Google-Smtp-Source: ABdhPJw3iXkeh4X23hlCCrPXZxj44YkvKHjdRm92gmWDaOcs5t9TLnFeN5SGkUHcqh4O/7F0fRNivA== X-Received: by 2002:a63:3143:: with SMTP id x64mr1460100pgx.14.1624483813302; Wed, 23 Jun 2021 14:30:13 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id h21sm642157pfv.190.2021.06.23.14.30.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Jun 2021 14:30:12 -0700 (PDT) To: Eliot Lear , Jay Daley , rfced-future@iab.org References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> <39f83475-e0bb-5ca7-ecfe-d6756a581fb5@gmail.com> <3ad917f6-d965-cbf2-0217-38c7e01e9340@lear.ch> From: Brian E Carpenter Message-ID: Date: Thu, 24 Jun 2021 09:30:08 +1200 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: <3ad917f6-d965-cbf2-0217-38c7e01e9340@lear.ch> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 21:30:16 -0000 On 23-Jun-21 19:51, Eliot Lear wrote: >=20 > On 23.06.21 05:06, Brian E Carpenter wrote: >> I may have missed it, but I don't there's a github issue for finalizin= g the role and title of the RSEA. That's where I would like to hang this = comment. >=20 > There are several, one of which we just are in the process of closing.=C2= =A0=20 > The title one I have deferred discussing for the moment.=C2=A0 We also = have=20 > the agreed text from Issue 12: Fair enough (but see below) but in my defence, the title of that issue di= dn't seem like it covered the role definition. >=20 >> This person will be a senior professional with deep knowledge of=20 >> technical publishing. >> >> The RSE will operate by providing expert advice to the RSAWG, and if=20 >> requested, to the RPC, on any relevant matters.=20 Yes, we agreed on that, but I think we missed the question of who will be=20 tasked with communicating RSWG and/or RSAB decisions and advice to the RP= C. So there's an open issue either here in #12 or in Jay's proposed texts= =2E I'd be inclined to fill it here, something like: The RSEA will communicate relevant RSWG and RSAB decisions and advice to = the RPC. (The alternative would be to task the RSWG and RSAB chairs with this, but=20 if we're hiring an expert, that would seem like the normal person to do i= t.) Brian >> The value this=20 >> individual provides is an understanding of the process of technical=20 >> publishing. They expected to learn how the process is applied in the=20 >> RFC series. They will be asked to produce regular reviews of the=20 >> process and identify problems and opportunities for improvement. There=20 >> are also opportunities to spontaneously learn of these problems,=20 >> likely the result of interactions with day-to-day operations. The=20 >> person may be requested to draft documents >> >> For example, the RSE might be consulted about proposed changes to the = >> style guide, RFC formatting in general, web presence, copyright=20 >> matters, or archiving policy, or might of their own initiative suggest=20 >> such changes to the RSAWG. >> >> The RSE is expected to attend all RSAWG meetings, and to have an=20 >> ongoing working relationship with the RPC and tooling team. >> > https://github.com/intarchboard/program-rfced-future/blob/master/Issue1= 2-RSE-role.md >=20 > This text needs to make its way into the draft.=C2=A0 That is not to sa= y this=20 > text can't improve, but this was what we agreed. >=20 > Eliot >=20 >=20 From nobody Wed Jun 23 15:06:08 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEFC3A10B8 for ; Wed, 23 Jun 2021 15:06:07 -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, RCVD_IN_DNSWL_BLOCKED=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 RCiuVu-CrM3K for ; Wed, 23 Jun 2021 15:06:06 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 048D33A10B7 for ; Wed, 23 Jun 2021 15:06:05 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id p4-20020a17090a9304b029016f3020d867so2219716pjo.3 for ; Wed, 23 Jun 2021 15:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=lP23Tv8Vkrl0sCUt1EmXifYbD6cqL0Tyy8ADDkBfPx4=; b=EeeytPcFepe0/BBL5fcxocaho4biOWPcnIy+8Oi4pjLUQy1EHXTO4Uts3O1ynwvylF I0NM+coY1FfTY3aVhAN/wBJO4n+yT0g3UKzmkO+nO7ZjjUUfUnXAWBP67uQ5SmIJv4N+ v3v4tgHgQB0skOTZ2cQka2fLb1ql7nGiNVX3jEJ3NV0CdyxTRrYKg7RnWH1h6YtHeaSI nQH5NpmXqVXDlJODVKbMLpWEAG24blg7UJNFsfLoc7zEAhcY40cXRUPgDHHIh6mRIFgj VXUHO1Xr00ir6Klm4WHrJXBS4Bn0HIgeBbENsSwZmA/gIRhdyt+mhqLMe9fEdNCiUp3d JWoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lP23Tv8Vkrl0sCUt1EmXifYbD6cqL0Tyy8ADDkBfPx4=; b=k8ujCWKVjJwca3vPZvILjuYdOmBf623pu7JGIBv8utL3mEBOdzCiGkFzjZjWQ0p2op ANgfcZQutBrdqhs6+uvfv/pelPsTypyXC9w+h/Y2SuFul1nYN7vJJQaNUhRH3xiM+E0e 4Eei6rvi9EOqLOprpIe7GxV4z/cPkZRtd1wqv85mvRoEfDQg6M3bRDHkDU/zDe3eVL88 9MzELysYlBaP7v3T5CnVQdWVJQ3QmbDBJdfdH9qBVRXYmAW/QlKyuksvGa5wvfWzb9OH QCUT3TiGTFDfnr5sTubghupMXw7VN6RhWwjssgANsywo9iOlO/NQCFuqp3Jp/GXWJMvw o+aQ== X-Gm-Message-State: AOAM530LQ507DRyhvFDTeVRbRlD7ga7ktzXThV2duboB/J1vNqZWXGyg ZJ+enZrbLGqYuqw3CC0wRdJV8CpkrY0UdA== X-Google-Smtp-Source: ABdhPJxV3TubR1eItP+THA0lVgtqMk9tmVqkFeyQr7qCeDLbrMs3kSfEcxIR2Z4WQwlj1x1nbYy6Ig== X-Received: by 2002:a17:90a:4812:: with SMTP id a18mr11724545pjh.40.1624485964006; Wed, 23 Jun 2021 15:06:04 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id u38sm96451pgm.14.2021.06.23.15.06.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Jun 2021 15:06:03 -0700 (PDT) To: Michael StJohns , Eliot Lear , rfced-future@iab.org References: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> <0a8101d76788$0e1af5a0$2a50e0e0$@olddog.co.uk> <0ace01d767a5$39001350$ab0039f0$@olddog.co.uk> <7bda1df1-307b-4370-ad94-71af09af12c4@www.fastmail.com> <47618d03-3136-a4db-cd5b-66a1e89216ac@gmail.com> <492d7b65-33b9-e749-3297-85fe6779531c@nthpermutation.com> <16ab1107-6e4c-aaa4-80ef-7675ca05b13a@gmail.com> <836bbdfd-8e61-ad18-ea8f-ff45331ed66b@nthpermutation.com> From: Brian E Carpenter Message-ID: <9fca165a-ae2a-3a37-65a2-cd7d74f13528@gmail.com> Date: Thu, 24 Jun 2021 10:05:58 +1200 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: <836bbdfd-8e61-ad18-ea8f-ff45331ed66b@nthpermutation.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Rfced-future] =?utf-8?q?BCP_or_not_=5Bwas=3A_Consensus_check=3A?= =?utf-8?q?_Issue_22_=E2=80=93_new_stream_for_RFC_Editor=5D?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 22:06:07 -0000 This seems like a new issue, hence the subject change. I don't actually care whether this is a BCP, or the last RFC model issued=20 under the existing authority of the IAB, or the first editorial stream RF= C approved by the RSAB, or all three of those things. As I said, it's syn= chronized swimming. But I do think it's cleaner to make the necessary update to the IAB Chart= er in a simple separate document. In the end, it will make life simpler (= especially if the IAB wants to further update its charter in future). Brian On 24-Jun-21 08:07, Michael StJohns wrote: > On 6/23/2021 3:43 PM, Eliot Lear wrote: >> As a matter of history: >> >> On 23.06.21 02:22, Brian E Carpenter wrote: >>> The IAB charter is an IETF BCP, so it can only be updated by an >>> IETF standards action. It can practically be a one line document >>> except for boilerplate, but it's gonna have to be done. >> >> My personal view: I don't think we should let the tail wag the dog,=20 >> nor block this work on a new charter for the IAB.=C2=A0 This document = could=20 >> just as easily be processed as a BCP; the only issue being that the=20 >> IESG would have to approve it.=C2=A0 If we want, we can get both IAB a= nd=20 >> IESG assent.=C2=A0 That has been previously done for RFC 7979. >> >> It'd require that an IESG member, presumably the chair, sponsor the=20 >> doc, and that it go through IETF last call and IESG evaluation.=C2=A0 = If=20 >> the IESG is unwilling to do this, we could revisit the matter. >> >> Eliot >> >> > +1 - >=20 > I'd actually extend this to the ISE and the IRTF for approval as it wil= l=20 > affect them as well. >=20 > All of this could be done in parallel rather than serially as the=20 > datatracker seems to enforce. >=20 > Mike >=20 >=20 From nobody Wed Jun 23 15:11:44 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197EB3A10E9 for ; Wed, 23 Jun 2021 15:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 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.338, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Kso3MxVm8GM1 for ; Wed, 23 Jun 2021 15:11:38 -0700 (PDT) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 EAA173A10E8 for ; Wed, 23 Jun 2021 15:11:37 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id a127so3441099pfa.10 for ; Wed, 23 Jun 2021 15:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jBxiUyQNt0t5bwpP1UWcPcyt2HbfWeEY7ZXQromgHf4=; b=ILR8fNaegzcuwpVF6N0H+Rj4C3PdTNjz1AUwUOgupqsZPxezO0raavrTxCGFGIVStt HhanBX39A/bCjHjbfGQlDFqllXOTEN7kT44bjj9vPKd+kLCfbzd5vtgjsNvH5Un1djiu inuu8jF58kBMXkQcaXRbK4vwR5CG2txh63K9X5BTGr76x2WkpUALN5ii47mjjcNGuKm+ gFLDRNGe0oHG++n6GcBtDLLU+b5OgWOK4PClWAE8BILohgeP+e5Pj5036u4de+OJkXAO yoZTGMFSYiQD8J4e94UMvmcKzwN9bwEY6QUa1FG8eA5uVCurcHteOQzTvfkwQIATDi83 wTPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=jBxiUyQNt0t5bwpP1UWcPcyt2HbfWeEY7ZXQromgHf4=; b=UU3YWQ/9/ipED+KwuHyqJjKxEhJ7Z6URFutBlCCOX6HkqSs0iB7ibmwxX4z9GSOd+3 uZCMU5hrXbMULBAzY+rPDqUb1ovkP8Fk6ewHnJWz+4X4Tu/9GR1scQiIYXwS2wIEv1JW EqaDryJBURRHtRKeRFrwBATUnVelYjbi/i+Xp1/Fbty0ynSlzKhQpox5bqethZSLsvhj Qdyxu7cbLjSWIZ4Cf/FmsrkCE7RdDnAT8vYAw2Bju3O3lHptFaUzsXu6+MSW3C2Y30fQ KnOmW1Wxi+DfCGGNpwu/OutiMnKuXuIzn0DGJzf+WztVkPWKjzx9WGmfFuB20A36AABR 6+/w== X-Gm-Message-State: AOAM531wPnP9diD7Jq4/MSqJ/gUw+1GeaIgnCLGM6KVFPJPg66YwdNI6 UGOFGGjlCb2VQFQrWfI0Ctzx8LOeaelyow== X-Google-Smtp-Source: ABdhPJygtm5RVMCenqGgzCyhBOQi2YeacuuhJQLgDlAZ7agdgTPlx+CEmamepx0OD++JRDoQR6Xm8w== X-Received: by 2002:a62:7616:0:b029:305:f420:49cc with SMTP id r22-20020a6276160000b0290305f42049ccmr1797136pfc.51.1624486296741; Wed, 23 Jun 2021 15:11:36 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id c20sm722683pfp.203.2021.06.23.15.11.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Jun 2021 15:11:36 -0700 (PDT) To: Joel Halpern Direct , Eliot Lear , Jay Daley Cc: rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> From: Brian E Carpenter Message-ID: <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> Date: Thu, 24 Jun 2021 10:11:31 +1200 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: <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 22:11:43 -0000 > Declaring the RSAB to be the stream manager hurts my head. Mine too. It needs to be a person and I don't think this is a job we should overload any of the RSWG/RSAB chairs with. The stream manager job in this case should be very light anyway: not many documents & very unlikely that those documents will raise unexpected technical issues for the RPC. As Joel says, content issues are handled by the RSWG/RSAB process anyway. Declaring the RSEA to be the stream manager works for me. Regards Brian C On 23-Jun-21 21:06, Joel Halpern Direct wrote: > I am wondering if we are mixing the concept of stream manager with=20 > stream content owner. The IESG is responsible for the content of the=20 > IETF stream. The IETF Chair or their delegate is the IETF stream=20 > manager. That role is making sure that there are no issues with the=20 > practical publication of the stream, including interacting with the RPC= =2E >=20 > Declaring the RSAB to be the stream manager hurts my head. That is not=20 > a person. And will create confusion about the role of the RSAB. WHile=20 > the obvious analogy is to declare that the RSAB chair is the stream=20 > manager for this new stream, it seems to me that creates confusion sinc= e=20 > that person is (unless they are the RSE/A) the stream head for some=20 > other stream. >=20 > Yours, > Joel >=20 > PS: One answer may be that there is no stream manager for this stream? = > Because the role is redundant with the defined roles for the RSAB? >=20 > On 6/23/2021 4:56 AM, Eliot Lear wrote: >> If you're suggesting that the RSAB itself hold the stream, that's=20 >> certainly an alternative.=C2=A0 However, the RSAB should probably be b= ound by=20 >> policies of This document in the use of the stream.=C2=A0 This would b= e=20 >> similar in nature to how the IAB stream is operated. >> >> On 23.06.21 10:49, Jay Daley wrote: >>> >>>> On 23/06/2021, at 8:18 PM, Joel M. Halpern wro= te: >>>> >>>> =EF=BB=BFFrom my perspective, you are correct that it is a bit of a = >>>> misalignment.=C2=A0 But...=C2=A0=C2=A0 A committee is not a stream m= anager.=C2=A0 And=20 >>>> giving any of the members of the RSAB a second stream confuses the=20 >>>> streams identity. >>> It=E2=80=99s not a =E2=80=9Ccontent=E2=80=9D stream though - it=E2=80= =99s a =E2=80=9Cmeta=E2=80=9D stream that all the=20 >>> other streams have a strong stake in, which gives it a distinct ident= ity. >>> >>>> =C2=A0 Thus, we bend / stretch the RSEA role a bit? >>> But what does that mean in practice given that all the decisions abou= t=20 >>> this stream are made by the RSWG? If I may introduce a useful English=20 >>> expression into IETF discourse, it=E2=80=99s as much use to the RSEA = as a=20 >>> chocolate teapot. >>> >>> Jay >>> >>> (sent from my phone) >>> >> >=20 From nobody Wed Jun 23 15:16:40 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA8E3A111E for ; Wed, 23 Jun 2021 15:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 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.338, RCVD_IN_DNSWL_BLOCKED=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 6jK7K5v3gOmx for ; Wed, 23 Jun 2021 15:16:35 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 2072F3A111A for ; Wed, 23 Jun 2021 15:16:34 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id 69so1895975plc.5 for ; Wed, 23 Jun 2021 15:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=irJ872qELhG1UUAWvC1rSyPA0MEE2a6vCqiwioliGew=; b=VGMUanUaI3bz5Z6ipWy7ZVidLnnhHhYS9p1dmDo2I2hPW9Q2hI/MDuUORm03Fnk0Oh E1iExbgooVi80lK9pYuX9F7g7uT0wrd8yWKb0VEwPFayugXHb7/LSXbA4m2WbiJKOxbX zzZQ1RznZ/GFiV1A9htze4iGTrL+cHyeMNRhMnNUVSJwoxPMSblFX0LTnukpVvUc83G5 mft07TkMpcotjPpib6MdFM7njhf7pNljOa4sxiZFk/pQC+ek6kcn5IxGIisvxLHd+wTh 3K+EXOzki5M24kjWc4d+scmeIjCM78USdGkNok6M58E668wLA4pkFzwPhah/FZj9f7y9 R5Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=irJ872qELhG1UUAWvC1rSyPA0MEE2a6vCqiwioliGew=; b=L5CFm5Jz8wmxwlAAVXHwvHJkp30J5E72jg3nwut+vLDl3iHoa+73tcdSJ4gsH4vNYH jdW0jev5UTwfRuOyjd+NL43HY3mCwgnQG7+WTOicoMCiAVu1olsbFN9zG73AbFNIVMit tdzYrXvUox5rzcXdCE5DH/NTn88ENYvLiAgWjD7LtNTY+LinEFJi24UiEd7mCvjjONfD eDXcYNN44XzytQL+G4euUNKZ25TXmM1f8wRdI/euqtSC1VrVUG3XNQcZufLEi3F/X7My PC98CNL4uV6L3cvsA6c1qA9ulWaFcYITj2ilUyJHXBIcRJsk07d4i53t872HPcx2xQ0C aKog== X-Gm-Message-State: AOAM5314UQJJqdS/cevEzeg1bwFZeBeptEoPBzAwXN430ssU1tmNp+c7 eASmR2xJA4BOjquqRrmXXZPI/rIEf7YeVQ== X-Google-Smtp-Source: ABdhPJzxaKvuf8uiRBaWvTaJYhnXoXUY0E84wukkz65xj1Nvvb6IACx9SJIhdIliVRaG5SAj/lAFsg== X-Received: by 2002:a17:902:ff0c:b029:11d:3e9e:41ec with SMTP id f12-20020a170902ff0cb029011d3e9e41ecmr1453239plj.1.1624486593893; Wed, 23 Jun 2021 15:16:33 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id o12sm101537pgq.83.2021.06.23.15.16.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Jun 2021 15:16:33 -0700 (PDT) To: rfced-future@iab.org References: From: Brian E Carpenter Message-ID: <9d07bb14-4650-52e6-7094-3bf2fed19d01@gmail.com> Date: Thu, 24 Jun 2021 10:16:29 +1200 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: [Rfced-future] draft minutes uploaded X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 22:16:39 -0000 I had to drop off early, so I missed the discussion that led to: The RPC will routinely encounter novel situations that require that decisions be made. The RPC can -- with consultation with stream managers, the RSAB, or others in the community -- make decisions. The RPC should document and periodically report on the details of these situations to the community. The RSWG might use these reports to inform discussions on strategy. FWIW I support that text. Regards Brian From nobody Wed Jun 23 17:45:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E9E3A16D4 for ; Wed, 23 Jun 2021 17:45:52 -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, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 mHRFIY9bsTZo; Wed, 23 Jun 2021 17:45:47 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 7E4893A16D1; Wed, 23 Jun 2021 17:45:46 -0700 (PDT) From: Jay Daley Message-Id: <351774DB-C6DC-439F-9B5C-FB427EC9F6FE@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_62BB467E-15A1-49BF-8608-F922634ECF4E" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 24 Jun 2021 12:45:42 +1200 In-Reply-To: <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> Cc: Joel Halpern Direct , Eliot Lear , rfced-future@iab.org To: Brian E Carpenter References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 00:45:53 -0000 --Apple-Mail=_62BB467E-15A1-49BF-8608-F922634ECF4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 24/06/2021, at 10:11 AM, Brian E Carpenter = wrote: >=20 >> Declaring the RSAB to be the stream manager hurts my head. >=20 > Mine too. It needs to be a person and I don't think this is > a job we should overload any of the RSWG/RSAB chairs with. > The stream manager job in this case should be very light > anyway: not many documents & very unlikely that those > documents will raise unexpected technical issues for the > RPC. As Joel says, content issues are handled by the > RSWG/RSAB process anyway. >=20 > Declaring the RSEA to be the stream manager works for me. Could you perhaps explain why and how the RSEA will in practice carry = out that role given the lack of authority they have over the stream? = The only reason I=E2=80=99ve heard so far is that neither the RSAB nor = the RSWG or their chairs are suitable, which doesn=E2=80=99t explain why = the RSEA is suitable. Jay >=20 > Regards > Brian C >=20 > On 23-Jun-21 21:06, Joel Halpern Direct wrote: >> I am wondering if we are mixing the concept of stream manager with=20 >> stream content owner. The IESG is responsible for the content of the=20= >> IETF stream. The IETF Chair or their delegate is the IETF stream=20 >> manager. That role is making sure that there are no issues with the=20= >> practical publication of the stream, including interacting with the = RPC. >>=20 >> Declaring the RSAB to be the stream manager hurts my head. That is = not=20 >=20 >> a person. And will create confusion about the role of the RSAB. = WHile=20 >=20 >> the obvious analogy is to declare that the RSAB chair is the stream=20= >> manager for this new stream, it seems to me that creates confusion = since=20 >> that person is (unless they are the RSE/A) the stream head for some=20= >> other stream. >>=20 >> Yours, >> Joel >>=20 >> PS: One answer may be that there is no stream manager for this = stream?=20 >> Because the role is redundant with the defined roles for the RSAB? >>=20 >> On 6/23/2021 4:56 AM, Eliot Lear wrote: >>> If you're suggesting that the RSAB itself hold the stream, that's=20 >>> certainly an alternative. However, the RSAB should probably be = bound by=20 >>> policies of This document in the use of the stream. This would be=20= >>> similar in nature to how the IAB stream is operated. >>>=20 >>> On 23.06.21 10:49, Jay Daley wrote: >>>>=20 >>>>> On 23/06/2021, at 8:18 PM, Joel M. Halpern = wrote: >>>>>=20 >>>>> =EF=BB=BF=46rom my perspective, you are correct that it is a bit = of a=20 >>>>> misalignment. But... A committee is not a stream manager. And=20= >>>>> giving any of the members of the RSAB a second stream confuses the=20= >>>>> streams identity. >>>> It=E2=80=99s not a =E2=80=9Ccontent=E2=80=9D stream though - it=E2=80= =99s a =E2=80=9Cmeta=E2=80=9D stream that all the=20 >>>> other streams have a strong stake in, which gives it a distinct = identity. >>>>=20 >>>>> Thus, we bend / stretch the RSEA role a bit? >>>> But what does that mean in practice given that all the decisions = about=20 >>>> this stream are made by the RSWG? If I may introduce a useful = English=20 >=20 >>>> expression into IETF discourse, it=E2=80=99s as much use to the = RSEA as a=20 >>>> chocolate teapot. >>>>=20 >>>> Jay >>>>=20 >>>> (sent from my phone) >>>>=20 >>>=20 >>=20 >=20 --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_62BB467E-15A1-49BF-8608-F922634ECF4E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 24/06/2021, at 10:11 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Declaring the RSAB to be = the stream manager hurts my head.

Mine too. It needs to be a person and I don't think this = is
a job we should overload any of the RSWG/RSAB chairs = with.
The stream manager job in this case should be very = light
anyway: not many documents & very unlikely that = those
documents will raise unexpected technical issues for = the
RPC. As Joel says, content issues are handled by = the
RSWG/RSAB process anyway.

Declaring the RSEA to be the stream manager works for me.

Could = you perhaps explain why and how the RSEA will in practice carry out that = role given the lack of authority they have over the stream?  The = only reason I=E2=80=99ve heard so far is that neither the RSAB nor the = RSWG or their chairs are suitable, which doesn=E2=80=99t explain why the = RSEA is suitable.

Jay


Regards
  Brian C

On 23-Jun-21 21:06, Joel Halpern Direct = wrote:
I am wondering = if we are mixing the concept of stream manager with
stream = content owner.  The IESG is responsible for the content of the
IETF stream.  The IETF Chair or their delegate is the = IETF stream
manager.  That role is making sure that = there are no issues with the
practical publication of the = stream, including interacting with the RPC.

Declaring the RSAB to be the stream manager hurts my head. =  That is not

a person.  And will create confusion about = the role of the RSAB.  WHile

the obvious analogy is = to declare that the RSAB chair is the stream
manager for = this new stream, it seems to me that creates confusion since
that person is (unless they are the RSE/A) the stream head = for some
other stream.

Yours,
Joel

PS: = One answer may be that there is no stream manager for this stream?
Because the role is redundant with the defined roles for the = RSAB?

On 6/23/2021 4:56 AM, Eliot Lear = wrote:
If you're = suggesting that the RSAB itself hold the stream, that's
certainly an alternative.  However, the RSAB should = probably be bound by
policies of This document in the use = of the stream.  This would be
similar in nature to = how the IAB stream is operated.

On 23.06.21 = 10:49, Jay Daley wrote:

On = 23/06/2021, at 8:18 PM, Joel M. Halpern <jmh@joelhalpern.com>= wrote:

=EF=BB=BF=46rom my perspective, you = are correct that it is a bit of a
misalignment.  = But...   A committee is not a stream manager.  And
giving any of the members of the RSAB a second stream = confuses the
streams identity.
It=E2=80=99s not a =E2=80=9Ccontent=E2=80=9D = stream though - it=E2=80=99s a =E2=80=9Cmeta=E2=80=9D stream that all = the
other streams have a strong stake in, which gives it = a distinct identity.

  Thus, we bend / stretch the RSEA role a = bit?
But what does that mean in practice = given that all the decisions about
this stream are made = by the RSWG? If I may introduce a useful English

expression into IETF = discourse, it=E2=80=99s as much use to the RSEA as a
chocolate teapot.

Jay

(sent from my phone)





-- 
Jay Daley
IETF = Executive Director
jay@ietf.org

= --Apple-Mail=_62BB467E-15A1-49BF-8608-F922634ECF4E-- From nobody Wed Jun 23 18:11:39 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF273A192C for ; Wed, 23 Jun 2021 18:11:37 -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, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 v14JorvbhHwH; Wed, 23 Jun 2021 18:11:33 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 5E47C3A1929; Wed, 23 Jun 2021 18:11:32 -0700 (PDT) From: Jay Daley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F62A0339-7505-4A8D-ACA6-999DF5B611D0" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 24 Jun 2021 13:11:29 +1200 In-Reply-To: Cc: Eliot Lear , rfced-future@iab.org To: Brian E Carpenter References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> <39f83475-e0bb-5ca7-ecfe-d6756a581fb5@gmail.com> <3ad917f6-d965-cbf2-0217-38c7e01e9340@lear.ch> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 01:11:38 -0000 --Apple-Mail=_F62A0339-7505-4A8D-ACA6-999DF5B611D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 24/06/2021, at 9:30 AM, Brian E Carpenter = wrote: >=20 > On 23-Jun-21 19:51, Eliot Lear wrote: >>=20 >> On 23.06.21 05:06, Brian E Carpenter wrote: >>> I may have missed it, but I don't there's a github issue for = finalizing the role and title of the RSEA. That's where I would like to = hang this comment. >>=20 >> There are several, one of which we just are in the process of = closing. =20 >> The title one I have deferred discussing for the moment. We also = have=20 >> the agreed text from Issue 12: >=20 > Fair enough (but see below) but in my defence, the title of that issue = didn't seem like it covered the role definition. >=20 >>=20 >>> This person will be a senior professional with deep knowledge of=20 >>> technical publishing. >>>=20 >>> The RSE will operate by providing expert advice to the RSAWG, and if=20= >>> requested, to the RPC, on any relevant matters.=20 >=20 > Yes, we agreed on that, but I think we missed the question of who will = be=20 > tasked with communicating RSWG and/or RSAB decisions and advice to the = RPC. So there's an open issue either here in #12 or in Jay's proposed = texts. I'd be inclined to fill it here, something like: >=20 > The RSEA will communicate relevant RSWG and RSAB decisions and advice = to the RPC. >=20 > (The alternative would be to task the RSWG and RSAB chairs with this, = but=20 > if we're hiring an expert, that would seem like the normal person to = do it.) For me this is a backward step. We appear to have agreed in principle = that the RPC is stepping up and engaging much more directly with the = community (though we=E2=80=99re still discussing if that=E2=80=99s = primarily through the RSAB/RSWG or more directly) and we appear to have = agreed that the RSEA is not the manager of the RPC. Under those = conditions, breaking the direct connection between the RSAB/RSWG and the = RPC by inserting the RSEA into the chain seems retrograde and reopens = multiple questions about the nature of the relationship between the RSEA = and the RPC that are otherwise moot. Jay >=20 > Brian >=20 >>> The value this=20 >>> individual provides is an understanding of the process of technical=20= >>> publishing. They expected to learn how the process is applied in the=20= >>> RFC series. They will be asked to produce regular reviews of the=20 >>> process and identify problems and opportunities for improvement. = There=20 >=20 >>> are also opportunities to spontaneously learn of these problems,=20 >>> likely the result of interactions with day-to-day operations. The=20 >>> person may be requested to draft documents >>>=20 >>> For example, the RSE might be consulted about proposed changes to = the=20 >>> style guide, RFC formatting in general, web presence, copyright=20 >>> matters, or archiving policy, or might of their own initiative = suggest=20 >=20 >>> such changes to the RSAWG. >>>=20 >>> The RSE is expected to attend all RSAWG meetings, and to have an=20 >>> ongoing working relationship with the RPC and tooling team. >>>=20 >> = https://github.com/intarchboard/program-rfced-future/blob/master/Issue12-R= SE-role.md >>=20 >> This text needs to make its way into the draft. That is not to say = this=20 >> text can't improve, but this was what we agreed. >>=20 >> Eliot >>=20 >>=20 >=20 --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_F62A0339-7505-4A8D-ACA6-999DF5B611D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 24/06/2021, at 9:30 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

On = 23-Jun-21 19:51, Eliot Lear wrote:

On 23.06.21 05:06, Brian E Carpenter = wrote:
I may have = missed it, but I don't there's a github issue for finalizing the role = and title of the RSEA. That's where I would like to hang this = comment.

There are several, = one of which we just are in the process of closing. 
The title one I have deferred discussing for the = moment.  We also have
the agreed text from Issue = 12:

Fair enough (but see = below) but in my defence, the title of that issue didn't seem like it = covered the role definition.


This person will be a senior professional with deep knowledge = of
technical publishing.

The = RSE will operate by providing expert advice to the RSAWG, and if
requested, to the RPC, on any relevant matters.

Yes, we agreed on = that, but I think we missed the question of who will be
tasked with communicating RSWG and/or RSAB decisions and = advice to the RPC. So there's an open issue either here in #12 or in = Jay's proposed texts. I'd be inclined to fill it here, something = like:

The RSEA will communicate relevant = RSWG and RSAB decisions and advice to the RPC.

(The alternative would be to task the RSWG and RSAB chairs = with this, but
if we're hiring an expert, that would seem = like the normal person to do it.)

For = me this is a backward step.  We appear to have agreed in principle = that the RPC is stepping up and engaging much more directly with the = community (though we=E2=80=99re still discussing if that=E2=80=99s = primarily through the RSAB/RSWG or more directly) and we appear to have = agreed that the RSEA is not the manager of the RPC.  Under those = conditions, breaking the direct connection between the RSAB/RSWG and the = RPC by inserting the RSEA into the chain seems retrograde and reopens = multiple questions about the nature of the relationship between the RSEA = and the RPC that are otherwise moot.

Jay



  Brian

The value this
individual provides is an = understanding of the process of technical
publishing. = They expected to learn how the process is applied in the
RFC series. They will be asked to produce regular reviews of = the
process and identify problems and opportunities for = improvement. There

are also opportunities to spontaneously learn of these = problems,
likely the result of interactions with = day-to-day operations. The
person may be requested to = draft documents

For example, the RSE might = be consulted about proposed changes to the
style guide, = RFC formatting in general, web presence, copyright
matters,= or archiving policy, or might of their own initiative suggest

such = changes to the RSAWG.

The RSE is expected = to attend all RSAWG meetings, and to have an
ongoing = working relationship with the RPC and tooling team.

https://github.com/intarchboard/program-rfced-future/blob/maste= r/Issue12-RSE-role.md

This text needs = to make its way into the draft.  That is not to say this
text can't improve, but this was what we agreed.

Eliot




-- 
Jay Daley
IETF = Executive Director
jay@ietf.org

= --Apple-Mail=_F62A0339-7505-4A8D-ACA6-999DF5B611D0-- From nobody Wed Jun 23 18:15:03 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D494F3A1946 for ; Wed, 23 Jun 2021 18:15:01 -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, URIBL_BLOCKED=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 1i85oEQWjjNX; Wed, 23 Jun 2021 18:15:00 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 4689D3A1944; Wed, 23 Jun 2021 18:15:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Jay Daley In-Reply-To: <9d07bb14-4650-52e6-7094-3bf2fed19d01@gmail.com> Date: Thu, 24 Jun 2021 13:14:56 +1200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <9d07bb14-4650-52e6-7094-3bf2fed19d01@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rfced-future] draft minutes uploaded X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 01:15:02 -0000 > On 24/06/2021, at 10:16 AM, Brian E Carpenter = wrote: >=20 > I had to drop off early, so I missed the discussion that led to: >=20 > The RPC will routinely encounter novel situations that require that = decisions be made. The RPC can -- with consultation with stream = managers, the RSAB, or others in the community -- make decisions. The = RPC should document and periodically report on the details of these = situations to the community. The RSWG might use these reports to inform = discussions on strategy. >=20 > FWIW I support that text. My proposed text yesterday [1] was intended to cover that in a more = detailed way thereby clearing up some holes. It is consistent with the = text above. Jay [1] = https://mailarchive.ietf.org/arch/msg/rfced-future/Ne15u5clm_h-iEy3DIuH4A0= 4ebc/ >=20 > Regards > Brian >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future >=20 --=20 Jay Daley IETF Executive Director jay@ietf.org From nobody Wed Jun 23 21:57:33 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA35A3A43C0 for ; Wed, 23 Jun 2021 21:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 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.338, 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 Sthnlq7M0oHk for ; Wed, 23 Jun 2021 21:57:26 -0700 (PDT) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 09DC93A43BC for ; Wed, 23 Jun 2021 21:57:25 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id k5so2762794pjj.1 for ; Wed, 23 Jun 2021 21:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=W6TcVuuM0i5KBGhXkIa6qHl3bsS50EyZwhHSBrPJKgM=; b=BYVjb2jLftNHH86OU6qAwG+uD6expFrtJGNMyDji9QFebj+K3HBUP+XaNsXnbZDgD9 uctg1+4d8Doa5XtmR0OSY+WgctYyoyxd5w+5arPINAkSUqkE9HiyASKt2WgPZOOxnaoU l3DZkwya4MNjme0iZ5hTvqZ3kqWWs1icAKVX/+X3LqEaM2zUjpZAXW6tabF/fLzUMWCo eo58YH/f/anMGR/bmfhktYEyas7n8SU3tOktHe5lY7bQ0dI4TR52ZSguvSJ5QCgXxdwv SyEPXfdUAIncZo5uWK/ba/OqV+fjVoBzCeuPSqIxK0IErR+5RYI28PdwN08hjG7ipkED pBwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=W6TcVuuM0i5KBGhXkIa6qHl3bsS50EyZwhHSBrPJKgM=; b=LYPwzYoSySdl1ozRfnUBUBMADOo3ixLp8h/P+7NTqN3MJdb9ksiZONfEaDMQaD0QE/ NsPKhZivu+PhzzFapV5yywQcoMV2EDYXDK1n6yeoRZ30/srCWYo/C60cPopAQ0HJLmbb wrBYLSe/9UVdSgx4uaFtBfe6RvyHCqHrooHWlyh5wVLBJBrNeM0UXSTOkZXrXcgDdr5k teX25g9JBvN9NeWzlNXUzFmZ0VVSLvVwErB5dD4nV+bmN3QZxunWmznNcYnIhYVBunM3 gcW2PFnBIJQqtomirdZwLVBBhPGpu4+Sy1JcT3U/59CstEbUs4rVzhr7gIgVsXDdJmvP fInQ== X-Gm-Message-State: AOAM5329Q3cfKozfxiZDZvUSI2ciL/cuDIvAgKS/juIc1vz8YIUfMe8W V+QjgUmgRAPPSo5vOU+QDSl2lKfWhXw77Q== X-Google-Smtp-Source: ABdhPJz4STMDFImE00akP4Bpim7dq1inAoPRQuBKSu4t8GXTbSL/xU37CpvzcU2Ue7/GaT7HSrbQZA== X-Received: by 2002:a17:902:ed8b:b029:124:668d:926 with SMTP id e11-20020a170902ed8bb0290124668d0926mr2615767plj.46.1624510644865; Wed, 23 Jun 2021 21:57:24 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id w20sm1539524pff.90.2021.06.23.21.57.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Jun 2021 21:57:24 -0700 (PDT) To: Jay Daley Cc: Joel Halpern Direct , Eliot Lear , rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> <351774DB-C6DC-439F-9B5C-FB427EC9F6FE@ietf.org> From: Brian E Carpenter Message-ID: Date: Thu, 24 Jun 2021 16:57:20 +1200 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: <351774DB-C6DC-439F-9B5C-FB427EC9F6FE@ietf.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 04:57:31 -0000 On 24-Jun-21 12:45, Jay Daley wrote: >=20 >=20 >> On 24/06/2021, at 10:11 AM, Brian E Carpenter > wrote: >> >>> Declaring the RSAB to be the stream manager hurts my head. >> >> Mine too. It needs to be a person and I don't think this is >> a job we should overload any of the RSWG/RSAB chairs with. >> The stream manager job in this case should be very light >> anyway: not many documents & very unlikely that those >> documents will raise unexpected technical issues for the >> RPC. As Joel says, content issues are handled by the >> RSWG/RSAB process anyway. >> >> Declaring the RSEA to be the stream manager works for me. >=20 > Could you perhaps explain why and how the RSEA will in practice carry o= ut that role given the lack of authority they have over the stream? =C2=A0= The only reason I=E2=80=99ve heard so far is that neither the RSAB nor th= e RSWG or their chairs are suitable, which doesn=E2=80=99t explain why th= e RSEA is suitable. As somebody else said, this stream by its very nature is going to be spec= ial and even self-referential. The notion we have of a stream being a cli= ent of the RFC Series just doesn't apply, so the normal notion of a strea= m manager doesn't apply**. But surely we need someone to act as progress = chaser and nit resolver when a document has left the RSAB and is inside t= he RPC? And who will that be if it's not the RSEA? ** It would be rather curious for someone inside the RFC Series tent to a= ct as the RFC Series' interface with the RFC Series... Brian >=20 > Jay >=20 >> >> Regards >> =C2=A0=C2=A0Brian C >> >> On 23-Jun-21 21:06, Joel Halpern Direct wrote: >>> I am wondering if we are mixing the concept of stream manager with >>> stream content owner. =C2=A0The IESG is responsible for the content o= f the >>> IETF stream. =C2=A0The IETF Chair or their delegate is the IETF strea= m >>> manager. =C2=A0That role is making sure that there are no issues with=20 the >>> practical publication of the stream, including interacting with the R= PC. >>> >>> Declaring the RSAB to be the stream manager hurts my head. =C2=A0That=20 is not >> >>> a person. =C2=A0And will create confusion about the role of the RSAB.=20 =C2=A0WHile >> >>> the obvious analogy is to declare that the RSAB chair is the stream >>> manager for this new stream, it seems to me that creates confusion si= nce >>> that person is (unless they are the RSE/A) the stream head for some >>> other stream. >>> >>> Yours, >>> Joel >>> >>> PS: One answer may be that there is no stream manager for this stream= ? >>> Because the role is redundant with the defined roles for the RSAB? >>> >>> On 6/23/2021 4:56 AM, Eliot Lear wrote: >>>> If you're suggesting that the RSAB itself hold the stream, that's >>>> certainly an alternative.=C2=A0 However, the RSAB should probably be=20 bound by >>>> policies of This document in the use of the stream.=C2=A0 This would=20 be >>>> similar in nature to how the IAB stream is operated. >>>> >>>> On 23.06.21 10:49, Jay Daley wrote: >>>>> >>>>>> On 23/06/2021, at 8:18 PM, Joel M. Halpern > wrote: >>>>>> >>>>>> =EF=BB=BFFrom my perspective, you are correct that it is a bit of = a >>>>>> misalignment.=C2=A0 But...=C2=A0=C2=A0 A committee is not a stream=20 manager.=C2=A0 And >>>>>> giving any of the members of the RSAB a second stream confuses the= >>>>>> streams identity. >>>>> It=E2=80=99s not a =E2=80=9Ccontent=E2=80=9D stream though - it=E2=80= =99s a =E2=80=9Cmeta=E2=80=9D stream that all the >>>>> other streams have a strong stake in, which gives it a distinct ide= ntity. >>>>> >>>>>> =C2=A0 Thus, we bend / stretch the RSEA role a bit? >>>>> But what does that mean in practice given that all the decisions ab= out >>>>> this stream are made by the RSWG? If I may introduce a useful Engli= sh >> >>>>> expression into IETF discourse, it=E2=80=99s as much use to the RSE= A as a >>>>> chocolate teapot. >>>>> >>>>> Jay >>>>> >>>>> (sent from my phone) >>>>> >>>> >>> >> >=20 > --=C2=A0 > Jay Daley > IETF Executive Director > jay@ietf.org >=20 From nobody Wed Jun 23 22:06:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51713A43FF for ; Wed, 23 Jun 2021 22:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 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.338, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 VnMxeftJavAp for ; Wed, 23 Jun 2021 22:06:50 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 751DA3A43FC for ; Wed, 23 Jun 2021 22:06:50 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id y4so4151272pfi.9 for ; Wed, 23 Jun 2021 22:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FQgBpgGTLl28k95yLhS4Mi2vx/pu5cf8gH1NvbQV8VU=; b=WIzT3WyOMXx/9nLEOjBoPjDanKSSBFFkpslrswPuFTgreGvgDVQ6/noliw+QbhP/Lg 6WLdfrByzaAU0D+L3AGAvDcJt3nDr/ECmjO49kwZrJy4yidhxCAC3Z55CBDvvEB4Xz0g TT//fciY3DQKQxz+6F0Mrlfl3CLbHN9qc2iCZX3v9yEhAcaWU4+uIdaem+q0BasoCiOr kmc0Pe12Ly1IQ2YveV85RjFjTcqaa0ed/CMSVgID0ByHkwLzxcGIOxNsjjyValICQOzI 7dzU9F4rbVN482/aLOB/im5/1tF12oYRSiX7JjZBct4yIMbNzuM6f7qJh4s9Ypil+6JF n1Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=FQgBpgGTLl28k95yLhS4Mi2vx/pu5cf8gH1NvbQV8VU=; b=Tv1QlaXsdPXjzAMOHacdnjARmN60mXgIDT0TqUc+X8rfeiNYajzDY2qTcv0Xl+k1q/ 1kQzngXtpxXB400ZhH2xFAkgT7VpqlOkEoK/2nIIHvUlqCNNkxx99MTCN9prPGVtMRvJ gVjx7RXX88CXtTNOwnxUHzPIOFV5OSsqmpTrKloMQTt5cbG86fL9FSIsbuwF2SwSxKZK nwKLOv6v+fiSjEMteled2N+a4PqaTwy6K6d+VJOGgn6+KhwOs6NH37mguq1BylHPjH+1 v4G4TFcyje/rBNTSRDaMMiT3I4zGNFzJq6KmtRl3DJ5DVJ6r5zLO1oa+bEK9N82KBBlv 4gjw== X-Gm-Message-State: AOAM532k6472+DyTflCr7m6AB1T3MVQowbLNB3oC3USgZ3YKmbwy2fXs cgkK0uQYwvLP1krP1SUrqEzqFitKkCkJHA== X-Google-Smtp-Source: ABdhPJwUxX7JhhPOnZz/hAKbqkpFak2lhU+no5btVZVhtBMrJB5YPcp4NRWopR+kBfrGM5ij7JBtqw== X-Received: by 2002:a63:235b:: with SMTP id u27mr3058799pgm.350.1624511209175; Wed, 23 Jun 2021 22:06:49 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id i6sm6692451pjg.31.2021.06.23.22.06.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Jun 2021 22:06:48 -0700 (PDT) To: Jay Daley Cc: Eliot Lear , rfced-future@iab.org References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> <39f83475-e0bb-5ca7-ecfe-d6756a581fb5@gmail.com> <3ad917f6-d965-cbf2-0217-38c7e01e9340@lear.ch> From: Brian E Carpenter Message-ID: Date: Thu, 24 Jun 2021 17:06:44 +1200 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: quoted-printable Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 05:06:53 -0000 On 24-Jun-21 13:11, Jay Daley wrote: >=20 >=20 >> On 24/06/2021, at 9:30 AM, Brian E Carpenter > wrote: >> >> On 23-Jun-21 19:51, Eliot Lear wrote: >>> >>> On 23.06.21 05:06, Brian E Carpenter wrote: >>>> I may have missed it, but I don't there's a github issue for finaliz= ing the role and title of the RSEA. That's where I would like to hang thi= s comment. >>> >>> There are several, one of which we just are in the process of closing= =2E=C2=A0 >>> The title one I have deferred discussing for the moment.=C2=A0 We als= o have >>> the agreed text from Issue 12: >> >> Fair enough (but see below) but in my defence, the title of that issue=20 didn't seem like it covered the role definition. >> >>> >>>> This person will be a senior professional with deep knowledge of >>>> technical publishing. >>>> >>>> The RSE will operate by providing expert advice to the RSAWG, and if= >>>> requested, to the RPC, on any relevant matters. >> >> Yes, we agreed on that, but I think we missed the question of who will=20 be >> tasked with communicating RSWG and/or RSAB decisions and advice to the=20 RPC. So there's an open issue either here in #12 or in Jay's proposed tex= ts. I'd be inclined to fill it here, something like: >> >> The RSEA will communicate relevant RSWG and RSAB decisions and advice = to the RPC. >> >> (The alternative would be to task the RSWG and RSAB chairs with this, = but >> if we're hiring an expert, that would seem like the normal person to d= o it.) >=20 > For me this is a backward step. =C2=A0We appear to have agreed in princ= iple that the RPC is stepping up and engaging much more directly with the=20 community (though we=E2=80=99re still discussing if that=E2=80=99s primar= ily through the RSAB/RSWG or more directly) and we appear to have agreed = that the RSEA is not the manager of the RPC. =C2=A0Under those conditions= , breaking the direct connection between the RSAB/RSWG and the RPC by ins= erting the RSEA into the chain seems retrograde and reopens multiple ques= tions about the nature of the relationship between the RSEA and the RPC t= hat are otherwise moot. I probably phrased it wrongly. Yes, in the normal case the RPC will be fu= lly aware of what's going on and will hopefully be fully aware of RSWG/RS= AB outcomes. But the RSEA is supposedly a subject matter expert and if we= 're paying for that, the RSEA is surely a resource we want to use. For su= re, the RSEA is not giving orders to the RPC. "The RSEA's expertise will be available to the RPC when implementing RSWG=20 and RSAB decisions and advice." Better? Brian >=20 > Jay >=20 >=20 >> >> =C2=A0=C2=A0Brian >> >>>> The value this >>>> individual provides is an understanding of the process of technical >>>> publishing. They expected to learn how the process is applied in the= >>>> RFC series. They will be asked to produce regular reviews of the >>>> process and identify problems and opportunities for improvement. The= re >> >>>> are also opportunities to spontaneously learn of these problems, >>>> likely the result of interactions with day-to-day operations. The >>>> person may be requested to draft documents >>>> >>>> For example, the RSE might be consulted about proposed changes to th= e >>>> style guide, RFC formatting in general, web presence, copyright >>>> matters, or archiving policy, or might of their own initiative sugge= st >> >>>> such changes to the RSAWG. >>>> >>>> The RSE is expected to attend all RSAWG meetings, and to have an >>>> ongoing working relationship with the RPC and tooling team. >>>> >>> https://github.com/intarchboard/program-rfced-future/blob/master/Issu= e12-RSE-role.md >>> >>> This text needs to make its way into the draft.=C2=A0 That is not to = say this >>> text can't improve, but this was what we agreed. >>> >>> Eliot >>> >>> >> >=20 > --=C2=A0 > Jay Daley > IETF Executive Director > jay@ietf.org >=20 From nobody Wed Jun 23 22:16:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198E23A4445 for ; Wed, 23 Jun 2021 22:16:23 -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, 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 r-IMPptoR3ou for ; Wed, 23 Jun 2021 22:16:18 -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 0B2163A4444 for ; Wed, 23 Jun 2021 22:16:17 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id bb20so2770503pjb.3 for ; Wed, 23 Jun 2021 22:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=G0WeLHaLWo5Cd6w/f+5frJ3tod1b82ejImm9U8xHPL0=; b=bPpjjAlT1Hpe1JLQqMgQpV92yLvlhbjqOUKbN1bf7YcbnXouUu14AKPe61nFix1Ja8 MsNTTkN5jWTMCbCSEm+uf7f+7wzdUAFHAGYCbslfhaKr3zjtF/2WKoazOHT3xWXwpU6S AS2Pu1Qvcmlrxc1zstIJmp139uRccHJd8GTB3ApVYtA9qI0NUNM7e5Zf9hTsAE7tp2aI BgHsvXzVQfr2ZowcGNsMZ2YIkbj+2LIpTOq6sxhXtJ9JsmEfLXyqrJwbhoWfOt9jiZK0 AzFhr0xcLG8unzfGGipqAtSZhB2W2eE3qqxJ4INhSvwSvG2aOL6wfoL1SgytVODSsuyr 0n6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=G0WeLHaLWo5Cd6w/f+5frJ3tod1b82ejImm9U8xHPL0=; b=DLArJAO2yS/Si03JIWv6JY/astgsJlcz8JhaASiyb7bvLA7oRVSbhwCR47MbzpQxIH RqJLib/4p44QU8OXXM4AfV0CNC0w5OyATjT3P40RhiV2IBYmQ8Or5C4wLfNSTll1GZ3T HzvQsIhblDIetx7FES6tTooFQ/LZ7kZokOB+6amDo3Lzxi80oQOd/zAn338xCt7kwqnV c0R6y7O2/v+9ghpIjWdBEqibqkqEQQzuLDilgHY+svV7dDoZO9ADDhd/RRvzyJGRw7Si UQFQjld266xe+dQs4mrXaEzR04NK1uZX5eJjxZZcKJ6IWsjbf/ttZL2jiQkS42+p3kSW HxLw== X-Gm-Message-State: AOAM531OOlvaTS6JTJL2HPdZuANlB9nWeVxedFJOaYvWgWzeaHGbZk4J J047RxpXJJGa6VGdNIw6tSn9GIBFQMhe+A== X-Google-Smtp-Source: ABdhPJzjkleKwoQcmx04WAYtbALgs0JK2gSttKOQsn7WXnytC8IRq3+wDL15UUT9kwEbWF/+Hjklrg== X-Received: by 2002:a17:90a:f291:: with SMTP id fs17mr3416695pjb.47.1624511775922; Wed, 23 Jun 2021 22:16:15 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id d13sm597634pjr.49.2021.06.23.22.16.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Jun 2021 22:16:15 -0700 (PDT) References: <162451008003.7099.4376055862411365079@ietfa.amsl.com> To: rfced-future@iab.org From: Brian E Carpenter X-Forwarded-Message-Id: <162451008003.7099.4376055862411365079@ietfa.amsl.com> Message-ID: <6ce7065b-805d-e101-cd7f-3862429f9a87@gmail.com> Date: Thu, 24 Jun 2021 17:16:12 +1200 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: <162451008003.7099.4376055862411365079@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfced-future] Fwd: I-D Action: draft-carpenter-rfced-iab-charter-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 05:16:23 -0000 I thought I'd better put my keyboard where my mouth was. IMHO this as a stand-alone document is much less clumsy than hiding it in draft-standre, and would make it much simpler for the IAB if they wish to propose further charter revisions. (For reasons that I don't understand, this showed up in xml2rfcv2 format, sorry, I pressed the button thinking it would be v3.) It does bring up another issue for us. RFC 2850 states that the RFC Editor appoints a liaison member to the IAB. We need to define who does that. RSAB? Brian -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-rfced-iab-charter-00.txt Date: Wed, 23 Jun 2021 21:48:00 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IAB Charter Update for RFC Editor Model Author : Brian E. Carpenter Filename : draft-carpenter-rfced-iab-charter-00.txt Pages : 3 Date : 2021-06-23 Abstract: This document updates the IAB Charter (RFC 2850) to be consistent with the new model for the RFC Editor (draft-saintandre-rfced-model). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-rfced-iab-charter/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-carpenter-rfced-iab-charter-00 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 Thu Jun 24 00:19:48 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0883A0C5B for ; Thu, 24 Jun 2021 00:19:45 -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, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=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 MTlytkBG60sA; Thu, 24 Jun 2021 00:19:41 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 58B2E3A0C58; Thu, 24 Jun 2021 00:19:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jay Daley Mime-Version: 1.0 (1.0) Date: Thu, 24 Jun 2021 19:19:37 +1200 Message-Id: <39E9AF56-0BFB-4982-A715-12BECE7AE012@ietf.org> References: Cc: rfced-future@iab.org, Eliot Lear In-Reply-To: To: Brian E Carpenter X-Mailer: iPhone Mail (18F72) Archived-At: Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 07:19:46 -0000 > On 24/06/2021, at 5:06 PM, Brian E Carpenter = wrote: >=20 > =EF=BB=BFOn 24-Jun-21 13:11, Jay Daley wrote: >>=20 >>=20 >>>> On 24/06/2021, at 9:30 AM, Brian E Carpenter > wrote: >>>=20 >>> On 23-Jun-21 19:51, Eliot Lear wrote: >>>>=20 >>>> On 23.06.21 05:06, Brian E Carpenter wrote: >>>>> I may have missed it, but I don't there's a github issue for finalizin= g the role and title of the RSEA. That's where I would like to hang this com= ment. >>>>=20 >>>> There are several, one of which we just are in the process of closing.=20= >>>> The title one I have deferred discussing for the moment. We also have >>>> the agreed text from Issue 12: >>>=20 >>> Fair enough (but see below) but in my defence, the title of that issue=20= > didn't seem like it covered the role definition. >>>=20 >>>>=20 >>>>> This person will be a senior professional with deep knowledge of >>>>> technical publishing. >>>>>=20 >>>>> The RSE will operate by providing expert advice to the RSAWG, and if >>>>> requested, to the RPC, on any relevant matters. >>>=20 >>> Yes, we agreed on that, but I think we missed the question of who will=20= > be >>> tasked with communicating RSWG and/or RSAB decisions and advice to the=20= > RPC. So there's an open issue either here in #12 or in Jay's proposed text= s. I'd be inclined to fill it here, something like: >>>=20 >>> The RSEA will communicate relevant RSWG and RSAB decisions and advice to= the RPC. >>>=20 >>> (The alternative would be to task the RSWG and RSAB chairs with this, bu= t >>> if we're hiring an expert, that would seem like the normal person to do i= t.) >>=20 >> For me this is a backward step. We appear to have agreed in principle th= at the RPC is stepping up and engaging much more directly with the=20 > community (though we=E2=80=99re still discussing if that=E2=80=99s primari= ly through the RSAB/RSWG or more directly) and we appear to have agreed that= the RSEA is not the manager of the RPC. Under those conditions, breaking t= he direct connection between the RSAB/RSWG and the RPC by inserting the RSEA= into the chain seems retrograde and reopens multiple questions about the na= ture of the relationship between the RSEA and the RPC that are otherwise moo= t. >=20 > I probably phrased it wrongly. Yes, in the normal case the RPC will be ful= ly aware of what's going on and will hopefully be fully aware of RSWG/RSAB o= utcomes. But the RSEA is supposedly a subject matter expert and if we're pay= ing for that, the RSEA is surely a resource we want to use. For sure, the RS= EA is not giving orders to the RPC. >=20 > "The RSEA's expertise will be available to the RPC when implementing RSWG=20= > and RSAB decisions and advice." >=20 > Better? Yes thanks. There=E2=80=99s already some relevant text along these lines in t= he bullet points off section 4 in the draft.=20 Jay (sent from my phone) --=20 Jay Daley IETF Executive Director +64 21 678840 >=20 > Brian >>=20 >> Jay >>=20 >>=20 >>>=20 >>> Brian >>>=20 >>>>> The value this >>>>> individual provides is an understanding of the process of technical >>>>> publishing. They expected to learn how the process is applied in the >>>>> RFC series. They will be asked to produce regular reviews of the >>>>> process and identify problems and opportunities for improvement. There= >>>=20 >>>>> are also opportunities to spontaneously learn of these problems, >>>>> likely the result of interactions with day-to-day operations. The >>>>> person may be requested to draft documents >>>>>=20 >>>>> For example, the RSE might be consulted about proposed changes to the >>>>> style guide, RFC formatting in general, web presence, copyright >>>>> matters, or archiving policy, or might of their own initiative suggest= >>>=20 >>>>> such changes to the RSAWG. >>>>>=20 >>>>> The RSE is expected to attend all RSAWG meetings, and to have an >>>>> ongoing working relationship with the RPC and tooling team. >>>>>=20 >>>> https://github.com/intarchboard/program-rfced-future/blob/master/Issue1= 2-RSE-role.md >>>>=20 >>>> This text needs to make its way into the draft. That is not to say thi= s >>>> text can't improve, but this was what we agreed. >>>>=20 >>>> Eliot >>>>=20 >>>>=20 >>>=20 >>=20 >> --=20 >> Jay Daley >> IETF Executive Director >> jay@ietf.org >>=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Thu Jun 24 01:46:39 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6333A11B8 for ; Thu, 24 Jun 2021 01:46:37 -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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 ruzxmsUG4V9y for ; Thu, 24 Jun 2021 01:46:32 -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 A06AF3A11AF for ; Thu, 24 Jun 2021 01:46:32 -0700 (PDT) Received: from smtpclient.apple (unknown [212.68.24.84]) (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 23092600329; Thu, 24 Jun 2021 11:46:27 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1624524387; bh=FQ4Lb14Afb/yV39O3o2C7hf+zycaQ3QxPRM5E47pOp4=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=b4W16nyhSwWcvij0wx6O74z8GUygC7XalV5UJSHmLbRW6JG06CCTL5esCDM+7Z7eJ U0UEYvH3B37BWQD7D27OwExJcA/Epi7igP4/f+SLDCj02qM0LQrU3Q25rPFl0M/jPT 4EWJrUxI7wosVmDwoV1UrEamk8RN8d6k0cdOYABY= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9C392902-9697-4E61-B074-D03DF7434134"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 24 Jun 2021 11:46:26 +0300 In-Reply-To: Cc: Jay Daley , rfced-future@iab.org, Joel Halpern Direct , Eliot Lear To: Brian E Carpenter References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> <351774DB-C6DC-439F-9B5C-FB427EC9F6FE@ietf.org> X-MailScanner-ID: 23092600329.A2FE5 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 08:46:37 -0000 --Apple-Mail=_9C392902-9697-4E61-B074-D03DF7434134 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2021-6-24, at 7:57, Brian E Carpenter = wrote: > As somebody else said, this stream by its very nature is going to be = special and even self-referential. The notion we have of a stream being = a client of the RFC Series just doesn't apply, so the normal notion of a = stream manager doesn't apply**. But surely we need someone to act as = progress chaser and nit resolver when a document has left the RSAB and = is inside the RPC? And who will that be if it's not the RSEA? I still remain unconvinced that we even need a new stream. I may be in = the rough, but I would be OK with using the IAB stream and leaving the = IAB a role here. Thanks, Lars --Apple-Mail=_9C392902-9697-4E61-B074-D03DF7434134 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmDURmIACgkQVLXDCb9w wVfBwBAAnW02gsVdJT+046gw0rM9eqyovDBrwwmjBnU3c0q8NQ1O+GFAhRLKf7OP ecKfpY/dRi8o0PvHp67Rk0hNkxEXkQkhR9vAkDvINNnYQtjHEdPxahfEZ7MY/xvA famkLnY3JHrE3scCpNYAwRINXE2EU2ComEsxZRtczYOMFMYh4vz3C0nzXeoQU1sL P5KaxXYYgr+F4CLgIXStstInCquyNvZSQKu0RzaLhSUG3NNxWcCpVr5BeJhwvnAH ZWuDlyzktwLhCP9L0N9d2Xv6bFfcMXBpQBKEii67H2P2K7avu3fHofIaVFcaCDfY mDAExH8x29qtZjKY3JAmh9d8/4gM1F9xlWNCrC4XRADEHzJdLWaACnQVLJ5gDI1W zITmzslw9MO671LZ4+moiJ1NIvN/+JohmXdMU4RRsLfFeQK5unf+uEuWlIbDDmh6 4BPSfJYmaaFNnLV4O2+YfFAEP63PGcomeuuELm/l1/h8V1vfm/EWp3nzO/VMHm+t Fkq3MLqXX41ML8WJ4ZkBVK4bGiANPDhFE4gl1VyRnAePI6MI3w5DdC60OPDdntso wwVGSoibTqOGkYjnFGChUv0Qi9DUbs2DOYU/R6ltGt+0k9DHvLB+ziqXPUYKISFY 5RMslj2xxREU+ZlSOPAeRHE2Z3kyCL4fe+VmFFYKhQ8HWRSpiM4= =PPm7 -----END PGP SIGNATURE----- --Apple-Mail=_9C392902-9697-4E61-B074-D03DF7434134-- From nobody Thu Jun 24 01:57:31 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3113A121C for ; Thu, 24 Jun 2021 01:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=itaoyama.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 ftHh-JTSbxdK for ; Thu, 24 Jun 2021 01:57:27 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410125.outbound.protection.outlook.com [40.107.141.125]) (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 E7C4F3A121B for ; Thu, 24 Jun 2021 01:57:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MFb61Ah8EBm0Tq41/g3NDa3dT2HRp0QHVE6mprnwcx4dI8M5Qx4df3Cnkx4NLLBaqpWSQdSAIszHv/qNj50qyUspq95KmwTm5IJ0m0dkPr1mxTlF6KNz+P6L5qIBzRTSDNCxPYB9QkFo7/AUcigbOj+5J2xQryQ8NDs7n8WK/Y0Ldyyg8fd7gWZ3+/7cu04v7P1J/wqUAkntW+nG9ZSd7eBvYzgGuFzt1WC3L2DWXSIXzVceknBu/OLLgFW8SB4h89OndgrW1zXsxcOS3zQ6jxTQ+zDJh6pMMF5gd3NHobVmXJr3IIl53fZO9P+o5g4iTAoVa+Lpt5ngu4nHGnxNWQ== 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-SenderADCheck; bh=Nu7vfxY8vOT7sMBEhqyYYIrdlT8EPD1ZQLBCvzGOqw4=; b=GleX/uh+NhAfNIC1CmmB4Ff4DyDS3GKnBfcRRFriK+6mCqXVc06WBLNX5S8ZWraittGjaPod8OgnMSf3R61tpMs5addX5YRf9W8Td5SI7tb2Qd8QuNV3F0GiNF8occuzXY60fQRBfcJbAHyppJn9fIIXJP+UTFuISslJECUdvD1f8KPKXPWKUpOftHDi4KEewIqddDi0jRXKs0likwzk4YkbHZcE4nu8TUMEe6lGzTxd5qY7kPBSp2GceDEFGy3ucFM48Az3R680Q9MY5FK/pQF/GYSLI1O/XKYyig/4lE2oK47RAxD4tD9kkH3quT5A2kxpV1mAnjT1HJI4T/MNpA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nu7vfxY8vOT7sMBEhqyYYIrdlT8EPD1ZQLBCvzGOqw4=; b=E6SJa5BxXkOjjkayZQVhSbS1of2BBQiAy50gjfjN6NHO/V5d/sU3Kp3OxuETdr4SoW1eXd2aN1ye4tCphhcDEXvfLhgzMsyL9E/Rl9OKmQRdgUpPZusa4+M2IhZlH7G92XtGquy3lR9eWI39VTRJRXPaEFMr0xZHFsFuNLb8CNc= Authentication-Results: lear.ch; dkim=none (message not signed) header.d=none;lear.ch; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYCPR01MB6688.jpnprd01.prod.outlook.com (2603:1096:400:9d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18; Thu, 24 Jun 2021 08:57:24 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::4c2b:a1b2:2e7f:358]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::4c2b:a1b2:2e7f:358%8]) with mapi id 15.20.4264.020; Thu, 24 Jun 2021 08:57:23 +0000 To: Lars Eggert , Brian E Carpenter Cc: rfced-future@iab.org, Joel Halpern Direct , Jay Daley , Eliot Lear References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> <351774DB-C6DC-439F-9B5C-FB427EC9F6FE@ietf.org> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <0a778f3b-c32e-abba-6e7f-305387adf3ad@it.aoyama.ac.jp> Date: Thu, 24 Jun 2021 17:57:21 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.39] X-ClientProxiedBy: TYAPR01CA0212.jpnprd01.prod.outlook.com (2603:1096:404:29::32) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [133.2.210.39] (133.2.210.39) by TYAPR01CA0212.jpnprd01.prod.outlook.com (2603:1096:404:29::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18 via Frontend Transport; Thu, 24 Jun 2021 08:57:23 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1935ba0c-b1e2-491d-35d8-08d936ee154e X-MS-TrafficTypeDiagnostic: TYCPR01MB6688: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: wVEhggTE2TK15neBWnAQD7e7/GCRzmZK1W+ZtOLgR2uzMr8W2sje5aS1byXIg2g29c4RoJm4PNEfKjLS8EV5mf4LbHwLW/fD4NDn9PYdcwj0iPxHDHSHpdao1835b/wXtAxjKhzTS7ZxMqc2CBfHAkoAZKW6uQJuV4UOksfdpyHembTswyz8PGPN0YU+DKiKarBc8LOIU5+RU3oHW1aR9yaPj+1b/8LGamXGFjOMrlQS4Y+omY2j9hvV4JdBYxu0jN9Y/hY7/gQV/JjpsX3SI3jkvG5KcOlhzSE+4aWtuQsTEeF2e1PgjLKGVwboLcVP+pF+mRSRSlNBkT2dBxzi64XlW9BKNpxnKGqWiJvzX5TowDD+1PBEVUmRHtCxq7d+LLkoVP7ACuuNaNGYieeN1Q+RHi7vBC85MNMvgVI3gwVaztOXyHhNaUgesgR5oI6NfG6U+aupjmNJ2yONIcME7lVOnEpGadsog0Xf81Vg/3LwECjDmRCUUvTiZGxWhNltl+WejW0/KSu58NhC0yaQFmiM4dq4eH7A0z93s3MIEZeQYrfq1TZmbq9FzkSPbAD7MOJtAo7BMZtQRfaK7JBvoEkYSt3ncXfuNsRHjbdMijmDzytrZVBquw7m0YRmTr4pRrpiOXmDQPbOWPR4ZLNpOtEjgCPj9v6Fjft/RDPyaN6awXSh45blXfi226BYj1lfnuzt/Sq0C6oXsfd8y+CO2Hl3x3Pf3379QDX5Rb6OIacXR7cTBkveE3pGuzCrz6WL X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39830400003)(346002)(396003)(366004)(376002)(6706004)(52116002)(956004)(31686004)(36916002)(26005)(31696002)(2616005)(53546011)(6486002)(66946007)(4001150100001)(4744005)(66476007)(66556008)(86362001)(38350700002)(316002)(5660300002)(8936002)(478600001)(16576012)(54906003)(786003)(110136005)(38100700002)(186003)(16526019)(4326008)(2906002)(3940600001)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Umh4Q2V6aWc2SHZHdy9KclpBWlFucFhkenBvZTZJbUN5NkIraCt6bU5LR3V4?= =?utf-8?B?RFY0TnkyMERqMjJJdUtZNlV6dXNDYXhRL1duN2oxVk5WZit6NjJXSjlGeU9E?= =?utf-8?B?WnMzNzVKVkU4WCtxSm9WTUc1M05uY0tWODRJUUEvWFpzK3BId3UzODBZYldP?= =?utf-8?B?dzJod0dVNjRzbWkyRHZnT3I0c3dhSjJTV2Nna3FDbUxxWC9pOEFEaHZsK3RC?= =?utf-8?B?MzhDOStSZ3p3ellQM2pSbUxCNmlpR3EzVHQ2VjR6ZFNIUXZhQWF3aGwvbzRN?= =?utf-8?B?eTZGNkUwN05INGwvb3RkRDk3WHZoMkRqenRBaGJFZkx2bTU5SWhJMjdycnNV?= =?utf-8?B?U0QyT2RZNUxrU1NhQXpwYlpiU21BRGh0ZjE5ZEI0QlA1bTFkM2RIbW5VZklu?= =?utf-8?B?UXY1TzEvaEY3ZFc2by9waHJHUU43QVhnMk94M2prQ3NVeXJDN0RLU3gwRVQx?= =?utf-8?B?V2RjblNqRm5TQTZsN1FOVGlkQWJ0RFJGMk9yV1NXbFJRY2dzVDVINk5PNVo4?= =?utf-8?B?dlV6bXZZUEFUYmNyKzZ0V2J3OUJmejRGMFZtc1BXcW83NzVLRCtZMHhTRCtl?= =?utf-8?B?Y0I5cHVjb2hnZkdGTXNRZFMvekp0SmRqcjdjZTE0SzMxeVVyMXAvTkhtYVp6?= =?utf-8?B?N09Fbk1icGQ2cnVxRFVaenJhZXNraTZYcW5oY3FUcWdoNk5TM3M5K1NRczVi?= =?utf-8?B?MU5SNzd0SjZIQmlTODFzUWdrbnhxU0dPZGFZYVZTWVNuUFdhYkJidUJhTXZE?= =?utf-8?B?ckhPeC9qNjNDRTZBUHdJNE5HTFJSTk5KUHVMYXhtdUQvVXJkQi9OZjlXWVph?= =?utf-8?B?RlU0ZWk3Y2IreGVpRFM2QTFFUGFHQmdKNWNPNGVNR3dXV0FqbWlPakNIT1NZ?= =?utf-8?B?Y0kxTENXVDBmMXlUa09JcVdIYUlSSWtzSVNQaHdRZXJFVC9hS1MvR3BHZnlQ?= =?utf-8?B?ZVJUT2dOd1R0UFM4SXhnVk9ZK3ZteERGaHRyMFN5ZStxVzFhOHhIaGlhM3ZU?= =?utf-8?B?M2E2ZFRtMDNTSTUrY2Z5MVZLb2lZQ3BGZ2d0NFIyK3dxY211aHF3em5BYmFT?= =?utf-8?B?WVl2VkFDM1ErbVBjeWhLSXlzWm9heVVvNXFsNDVhTWMzNjBxbm9yVVkwWEZF?= =?utf-8?B?dVdKcHNwcFdnSzVxVWhNU2Z2RmNPRmRoQVgrU3hiZWZ2N1B1b3NGck8wcG9C?= =?utf-8?B?dDFFdjNiOTlPblY3aS9Fem93TkdLTXI4bFFlQTk4czYrZHdyZ0dUL1JBMEpT?= =?utf-8?B?a3JqdWtCbUlaWlpDUXIwTVZ0NCttNXF2TzJvRTZQbjlwY0NTbElUZDQ1UCt1?= =?utf-8?B?TlJYaUc2MC9kS21RWUNPeG9EZXdaaUd2ZzJobzBFNFd1V25nT0s4VnpEc24z?= =?utf-8?B?aDVNaFoxQVhYWjNJVE4yM3Jmc20xVGhvVHNsN2tGNk9JcWJ2S05SZDRFb3dx?= =?utf-8?B?QVJGdzBDbVJZMVRoVkR5VFJyWDV6VnhmdEpPQkRJdnhNYWZPMDkzVE1pQktQ?= =?utf-8?B?UzN4V0RLZ0lLTEYyOHpya3FDRTR2bmJISDlFSjhoZUhYb1FubzJQSlFUOTdB?= =?utf-8?B?S3ZWaGUrTWtyWFc5RGlIeE9vOXphZ3lSc0xreGxKNWluVkd5akJYOHdMRnVP?= =?utf-8?B?NlZ2OUhtVlVIR0FNSWgvSHpDY0pZbUtlc0lKWEthL2NwZ1JHWXZ2Z1UxbVkr?= =?utf-8?B?K25JcDFRSUJlcHRIMEd1WWQ0OXdGcFJxQjZYQk9jd3U1cVVJQ3VWa0J4UEpM?= =?utf-8?Q?z29FSl7eFf+cl5v1ut4e9zsCqcbiUlflHvspMM6?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 1935ba0c-b1e2-491d-35d8-08d936ee154e X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2021 08:57:23.8732 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: NlXlms80OxwEns0DfxKL+5/8L0qTw0t0Zs7qTA74TdUgpEkTs78eY0R3L6GoccfYo9xDlZSzxB6ncBMoBe843Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCPR01MB6688 Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 08:57:30 -0000 Hello Lars, others, On 2021-06-24 17:46, Lars Eggert wrote: > Hi, > > On 2021-6-24, at 7:57, Brian E Carpenter wrote: >> As somebody else said, this stream by its very nature is going to be special and even self-referential. The notion we have of a stream being a client of the RFC Series just doesn't apply, so the normal notion of a stream manager doesn't apply**. But surely we need someone to act as progress chaser and nit resolver when a document has left the RSAB and is inside the RPC? And who will that be if it's not the RSEA? > > I still remain unconvinced that we even need a new stream. I may be in the rough, but I would be OK with using the IAB stream and leaving the IAB a role here. What would that role be exactly? Giving the label "IAB stream" to these documents without actually being able to approve or decline any of them? Regards,   Martin. > Thanks, > Lars > > From nobody Thu Jun 24 13:35:11 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823F03A2A44 for ; Thu, 24 Jun 2021 13:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 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.338, RCVD_IN_DNSWL_NONE=-0.0001, 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 GED-Fab_lD0F for ; Thu, 24 Jun 2021 13:35:08 -0700 (PDT) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 066B53A2A42 for ; Thu, 24 Jun 2021 13:35:07 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id s17-20020a17090a8811b029016e89654f93so6647882pjn.1 for ; Thu, 24 Jun 2021 13:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hfm7NrvZ/gFeJhGjhdiee0hlGnZLicQG4qUPBmxNsdM=; b=Jo4QBf6bMUuJxTRmW77lQVRdcVo2TektFXfgmQ08Iyqxp6/VojwcXuqUYLNWatez7f WGOT3zLQn63bn2iLFSvLY0Ic5l+eD5BNIqpWQUL0Qt8BXte6IHnV/lD4T39U3ht7SYi5 NK34+TOqGIEm3i7OrVZ0ZAN+/DrsnQrQERNv0OYwBDiY3ofwpGNyvlzFSBvAUfvyqMS9 mEiANGSfrPmtfDoQhDw6I+R5JeNrLjAdkeH4z1MrtjFDmYUh4kF4RV7UDp5UWqmYit+j bzZOgHv/NaK0iT/7wGIIIyUa5aXAm7TqJI7d23dF/lceUkyy7RBTO7cFBpRjWB1Uff8n 9KbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=hfm7NrvZ/gFeJhGjhdiee0hlGnZLicQG4qUPBmxNsdM=; b=LYgG4C/+gM/fO7LYgEyBviHCBv/ZGi5x8jx1s0fK4nUjiAdfxs6y8S3KsV0/s8M8Oc 2TIE+CUQyx8ev554zgmIeA1qmM8y5/0Lj4THWES9ZVFrxGLIa2vaCgMSXbpcAyxAqCbk Xx1cBVpo5y2sTdko+1lppRAVlbJQmSMl60SlW6EVAq2WoQxw9Fk2NC2Qxrkbhm3MQ+di ncYm4OJ3wT9l6DTBbxAvqGuQgPMw7gD11Bk5qbvYjmg4v4xBLfhcPVl8te5+zTODMpIk 1ifmFPHYXKFSuKjqHySCNrlJu5+iClqXgWhUYT3uto6VWTNn3KF1ErDMYPm4inVO8NXz DD+w== X-Gm-Message-State: AOAM532C3lZE3+yIoqU1/Y7VrJxs/WOVjlbGvJepHKAIJFpYjjL4CkgE pVe6ezNjsNPdBciDBM1ulCI= X-Google-Smtp-Source: ABdhPJyfDiL9rO3JSVXhCEU+bHcPtKk5coaUFmcRwNIUd0/8LvxpgY/62iTyoq1DwL0JuaDdbN1cLA== X-Received: by 2002:a17:902:c18d:b029:127:9c3d:6e93 with SMTP id d13-20020a170902c18db02901279c3d6e93mr3969159pld.73.1624566907012; Thu, 24 Jun 2021 13:35:07 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id u24sm3833933pfm.156.2021.06.24.13.35.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Jun 2021 13:35:06 -0700 (PDT) To: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , Lars Eggert Cc: rfced-future@iab.org, Joel Halpern Direct , Jay Daley , Eliot Lear References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> <351774DB-C6DC-439F-9B5C-FB427EC9F6FE@ietf.org> <0a778f3b-c32e-abba-6e7f-305387adf3ad@it.aoyama.ac.jp> From: Brian E Carpenter Message-ID: <0d91a5c0-8dd5-cbe8-2ff9-c5b3fed3cbb2@gmail.com> Date: Fri, 25 Jun 2021 08:35:01 +1200 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: <0a778f3b-c32e-abba-6e7f-305387adf3ad@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 20:35:10 -0000 On 24-Jun-21 20:57, Martin J. D=C3=BCrst wrote: > Hello Lars, others, >=20 > On 2021-06-24 17:46, Lars Eggert wrote: >> Hi, >> >> On 2021-6-24, at 7:57, Brian E Carpenter =20 wrote: >>> As somebody else said, this stream by its very nature is going to be = special and even self-referential. The notion we have of a stream being a=20 client of the RFC Series just doesn't apply, so the normal notion of a st= ream manager doesn't apply**. But surely we need someone to act as progre= ss chaser and nit resolver when a document has left the RSAB and is insid= e the RPC? And who will that be if it's not the RSEA? >> >> I still remain unconvinced that we even need a new stream. I may be in=20 the rough, but I would be OK with using the IAB stream and leaving the IA= B a role here. >=20 > What would that role be exactly? Giving the label "IAB stream" to these=20 > documents without actually being able to approve or decline any of them= ? I think that's exactly the problem. The IAB stream labels documents as representing the IAB's opinion, and would imply that the IAB is approving the RSAB's opinion, which is not the new model at all. Brian From nobody Fri Jun 25 01:59:29 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFB13A0B89; Fri, 25 Jun 2021 01:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 of3FoeqIn4Vp; Fri, 25 Jun 2021 01:59:23 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 5F2123A0B83; Fri, 25 Jun 2021 01:59:23 -0700 (PDT) Received: from p200300dee70cfa000c59a854c52a9569.dip0.t-ipconnect.de ([2003:de:e70c:fa00:c59:a854:c52a:9569]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1lwhgD-0005hC-55; Fri, 25 Jun 2021 10:59:17 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: <0d91a5c0-8dd5-cbe8-2ff9-c5b3fed3cbb2@gmail.com> Date: Fri, 25 Jun 2021 10:59:14 +0200 Cc: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Lars Eggert , rfced-future@iab.org, Joel Halpern Direct , Jay Daley , Eliot Lear Content-Transfer-Encoding: quoted-printable Message-Id: References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> <351774DB-C6DC-439F-9B5C-FB427EC9F6FE@ietf.org> <0a778f3b-c32e-abba-6e7f-305387adf3ad@it.aoyama.ac.jp> <0d91a5c0-8dd5-cbe8-2ff9-c5b3fed3cbb2@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1624611563;0f6a8d79; X-HE-SMSGID: 1lwhgD-0005hC-55 Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 08:59:28 -0000 The IAB doesn=E2=80=99t necessarily need to label all IAB documents as = IAB =E2=80=9Copinions=E2=80=9D but all IAB documents need IAB approval. = However, such things as workshop reports or also documents published by = the RSE are usually not seen as an outcome of the IAB and we often even = add a clause to the abstract that explicitly says that the document does = not reflect IAB opinions. For things that do reflect an IAB opinion when = usually even add the list of names of IAB members at the time of = approval, to make clear whose opinions are reflected given the IAB also = changes all the time (any thereby potentially also its opinions). Mirja P.S.: As a small side note an a statement that Jay made. The stream = mangers do discuss procedures with the RPC but usually the managers = would go back to their stream approval body and double-check, e.g. = that=E2=80=99s what is currently happening for the terminology guidance. = So for me, the stream manager is really just the dedicated contact = person here, while the stream =E2=80=9Cowner=E2=80=9D is the approval = body. > On 24. Jun 2021, at 22:35, Brian E Carpenter = wrote: >=20 > On 24-Jun-21 20:57, Martin J. D=C3=BCrst wrote: >> Hello Lars, others, >>=20 >> On 2021-06-24 17:46, Lars Eggert wrote: >>> Hi, >>>=20 >>> On 2021-6-24, at 7:57, Brian E Carpenter = =20 > wrote: >>>> As somebody else said, this stream by its very nature is going to = be special and even self-referential. The notion we have of a stream = being a=20 > client of the RFC Series just doesn't apply, so the normal notion of a = stream manager doesn't apply**. But surely we need someone to act as = progress chaser and nit resolver when a document has left the RSAB and = is inside the RPC? And who will that be if it's not the RSEA? >>>=20 >>> I still remain unconvinced that we even need a new stream. I may be = in=20 > the rough, but I would be OK with using the IAB stream and leaving the = IAB a role here. >>=20 >> What would that role be exactly? Giving the label "IAB stream" to = these=20 >=20 >> documents without actually being able to approve or decline any of = them? >=20 > I think that's exactly the problem. The IAB stream labels documents as > representing the IAB's opinion, and would imply that the IAB is > approving the RSAB's opinion, which is not the new model at all. >=20 > Brian >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Fri Jun 25 07:43:57 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E233A1ABF for ; Fri, 25 Jun 2021 07:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 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, NICE_REPLY_A=-0.338, 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=joelhalpern.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 Wvp2vN0NQZrp for ; Fri, 25 Jun 2021 07:43:51 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 655F63A1ABD for ; Fri, 25 Jun 2021 07:43:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4GBKWW16GSz6GDyJ; Fri, 25 Jun 2021 07:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1624632231; bh=36RcHbZFfJlLOzT7svlqF00GLy+FwoRrtrXvWCKVAiM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Bfu4kdZuMeK37ZGg0xXeX0+MCOpgRMm8SbdMvfhgP7p+4Jmaa9uaT0tcc0GhfoYm5 QLN1oCw4QmupnokcI9n0aH7muTiU2hxfJj1Wwqd9PBd82sg7HUqZvzD3J+odJ2p2Gs xnDiW6Pm8C/atvqh4KOv4CKAGijUfrg7kUhTkO1Q= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4GBKWV4CTFz6G9t2; Fri, 25 Jun 2021 07:43:50 -0700 (PDT) To: Mirja Kuehlewind Cc: rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> <351774DB-C6DC-439F-9B5C-FB427EC9F6FE@ietf.org> <0a778f3b-c32e-abba-6e7f-305387adf3ad@it.aoyama.ac.jp> <0d91a5c0-8dd5-cbe8-2ff9-c5b3fed3cbb2@gmail.com> From: "Joel M. Halpern" Message-ID: Date: Fri, 25 Jun 2021 10:43:49 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 14:43:56 -0000 There are a lot of nuances that matter here. I could probably live with declaring thatt RSWG / RSAB documents are on the IAB stream if the RFC that said that also said that the IAB could not make any substantive changes to the document and did not have the right to refuse to progress the document. All the other cases you cite are ones where the IAB chooses to not review. This is somewhat different. Yours, Joel On 6/25/2021 4:59 AM, Mirja Kuehlewind wrote: > The IAB doesn’t necessarily need to label all IAB documents as IAB “opinions” but all IAB documents need IAB approval. However, such things as workshop reports or also documents published by the RSE are usually not seen as an outcome of the IAB and we often even add a clause to the abstract that explicitly says that the document does not reflect IAB opinions. For things that do reflect an IAB opinion when usually even add the list of names of IAB members at the time of approval, to make clear whose opinions are reflected given the IAB also changes all the time (any thereby potentially also its opinions). > > Mirja > > P.S.: As a small side note an a statement that Jay made. The stream mangers do discuss procedures with the RPC but usually the managers would go back to their stream approval body and double-check, e.g. that’s what is currently happening for the terminology guidance. So for me, the stream manager is really just the dedicated contact person here, while the stream “owner” is the approval body. > > > > >> On 24. Jun 2021, at 22:35, Brian E Carpenter wrote: >> >> On 24-Jun-21 20:57, Martin J. Dürst wrote: >>> Hello Lars, others, >>> >>> On 2021-06-24 17:46, Lars Eggert wrote: >>>> Hi, >>>> >>>> On 2021-6-24, at 7:57, Brian E Carpenter >> wrote: >>>>> As somebody else said, this stream by its very nature is going to be special and even self-referential. The notion we have of a stream being a >> client of the RFC Series just doesn't apply, so the normal notion of a stream manager doesn't apply**. But surely we need someone to act as progress chaser and nit resolver when a document has left the RSAB and is inside the RPC? And who will that be if it's not the RSEA? >>>> >>>> I still remain unconvinced that we even need a new stream. I may be in >> the rough, but I would be OK with using the IAB stream and leaving the IAB a role here. >>> >>> What would that role be exactly? Giving the label "IAB stream" to these >> >>> documents without actually being able to approve or decline any of them? >> >> I think that's exactly the problem. The IAB stream labels documents as >> representing the IAB's opinion, and would imply that the IAB is >> approving the RSAB's opinion, which is not the new model at all. >> >> Brian >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > From nobody Fri Jun 25 09:12:43 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3416F3A0812 for ; Fri, 25 Jun 2021 09:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 0XJwPw9o91_o for ; Fri, 25 Jun 2021 09:12:35 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 92D0F3A07E2 for ; Fri, 25 Jun 2021 09:12:35 -0700 (PDT) Received: from p200300dee70cfa000c59a854c52a9569.dip0.t-ipconnect.de ([2003:de:e70c:fa00:c59:a854:c52a:9569]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1lwoRS-00069c-KS; Fri, 25 Jun 2021 18:12:30 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: Date: Fri, 25 Jun 2021 18:12:29 +0200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> <351774DB-C6DC-439F-9B5C-FB427EC9F6FE@ietf.org> <0a778f3b-c32e-abba-6e7f-305387adf3ad@it.aoyama.ac.jp> <0d91a5c0-8dd5-cbe8-2ff9-c5b3fed3cbb2@gmail.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1624637555;e2d5e645; X-HE-SMSGID: 1lwoRS-00069c-KS Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 16:12:41 -0000 If we would keep using the IAB stream (and I=E2=80=99m not stating any = opinion here; just trying to outline what that could mean process-wise), = I think we still need some kind of IAB approval, because I think the IAB = wants to retain some control about what happens on their stream. = However, I think we could easy define something like the IAB can only = not-approve based on formal procedural problems but cannot rejecting = based on the content that already has community consensus at that point. = Yes, it would be an additional process step but I think we can make that = very light-weight. However, these are only my personal initial thoughts = and it would probably be good to also check with the rest of the IAB if = that is considered an option. P.S.: The IAB reviews all IAB documents to some extend (workshop report = are usually written by IAB members) but during approval of those = documents everybody understands that we don=E2=80=99t need to have = consensus on the content of the document but are rather approving on the = basis that the document is considered appropriate and ready for = publication. > On 25. Jun 2021, at 16:43, Joel M. Halpern = wrote: >=20 > There are a lot of nuances that matter here. >=20 > I could probably live with declaring thatt RSWG / RSAB documents are = on the IAB stream if the RFC that said that also said that the IAB could = not make any substantive changes to the document and did not have the = right to refuse to progress the document. >=20 > All the other cases you cite are ones where the IAB chooses to not = review. This is somewhat different. >=20 > Yours, > Joel >=20 > On 6/25/2021 4:59 AM, Mirja Kuehlewind wrote: >> The IAB doesn=E2=80=99t necessarily need to label all IAB documents = as IAB =E2=80=9Copinions=E2=80=9D but all IAB documents need IAB = approval. However, such things as workshop reports or also documents = published by the RSE are usually not seen as an outcome of the IAB and = we often even add a clause to the abstract that explicitly says that the = document does not reflect IAB opinions. For things that do reflect an = IAB opinion when usually even add the list of names of IAB members at = the time of approval, to make clear whose opinions are reflected given = the IAB also changes all the time (any thereby potentially also its = opinions). >> Mirja >> P.S.: As a small side note an a statement that Jay made. The stream = mangers do discuss procedures with the RPC but usually the managers = would go back to their stream approval body and double-check, e.g. = that=E2=80=99s what is currently happening for the terminology guidance. = So for me, the stream manager is really just the dedicated contact = person here, while the stream =E2=80=9Cowner=E2=80=9D is the approval = body. >>> On 24. Jun 2021, at 22:35, Brian E Carpenter = wrote: >>>=20 >>> On 24-Jun-21 20:57, Martin J. D=C3=BCrst wrote: >>>> Hello Lars, others, >>>>=20 >>>> On 2021-06-24 17:46, Lars Eggert wrote: >>>>> Hi, >>>>>=20 >>>>> On 2021-6-24, at 7:57, Brian E Carpenter = >>> wrote: >>>>>> As somebody else said, this stream by its very nature is going to = be special and even self-referential. The notion we have of a stream = being a >>> client of the RFC Series just doesn't apply, so the normal notion of = a stream manager doesn't apply**. But surely we need someone to act as = progress chaser and nit resolver when a document has left the RSAB and = is inside the RPC? And who will that be if it's not the RSEA? >>>>>=20 >>>>> I still remain unconvinced that we even need a new stream. I may = be in >>> the rough, but I would be OK with using the IAB stream and leaving = the IAB a role here. >>>>=20 >>>> What would that role be exactly? Giving the label "IAB stream" to = these >>>=20 >>>> documents without actually being able to approve or decline any of = them? >>>=20 >>> I think that's exactly the problem. The IAB stream labels documents = as >>> representing the IAB's opinion, and would imply that the IAB is >>> approving the RSAB's opinion, which is not the new model at all. >>>=20 >>> Brian >>>=20 >>> --=20 >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >=20 From nobody Fri Jun 25 09:18:19 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB27C3A085E for ; Fri, 25 Jun 2021 09:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.338, 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 KcFygKX5dHgC for ; Fri, 25 Jun 2021 09:18:12 -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 751613A085A for ; Fri, 25 Jun 2021 09:18:12 -0700 (PDT) Received: from [IPv6:2001:420:c0c0:1011::3] ([IPv6:2001:420:c0c0:1011:0:0:0:3]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15PGI4uG495869 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 25 Jun 2021 18:18:09 +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=1624637890; bh=NpT4GjM5d57651/j5W480OM8fdD08Uvr6msIfWUip2w=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=QcAZPzrQWshKe9VlH1WEGsuC2RsN+9mH7w3SlWoO0QQWuvnVFIGDI03APNUXfHMBM VansWWn7KKkSg8+J7yDfosn1IGvFxQoasN/vU7urZkh4wo4NirnXjNSlhMLF9XPjc0 rathxzGiVHsPgHsHz9tztW9GrFMZ4hJTmeye5Mtw= To: Mirja Kuehlewind , "Joel M. Halpern" Cc: rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> <351774DB-C6DC-439F-9B5C-FB427EC9F6FE@ietf.org> <0a778f3b-c32e-abba-6e7f-305387adf3ad@it.aoyama.ac.jp> <0d91a5c0-8dd5-cbe8-2ff9-c5b3fed3cbb2@gmail.com> From: Eliot Lear Message-ID: <72d46ce5-f733-7cf2-b640-18bbef8709c4@lear.ch> Date: Fri, 25 Jun 2021 18:18:03 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="z20bjVXQRRMpjb9aspK62YUDhmbaRMdFN" Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 16:18:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --z20bjVXQRRMpjb9aspK62YUDhmbaRMdFN Content-Type: multipart/mixed; boundary="PXlD1cdDXjR0QUhOwaAYT0vjjy3Cms0x2"; protected-headers="v1" From: Eliot Lear To: Mirja Kuehlewind , "Joel M. Halpern" Cc: rfced-future@iab.org Message-ID: <72d46ce5-f733-7cf2-b640-18bbef8709c4@lear.ch> Subject: =?UTF-8?Q?Re=3a_=5bRfced-future=5d_Consensus_check=3a_Issue_22_?= =?UTF-8?Q?=e2=80=93_new_stream_for_RFC_Editor?= References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> <351774DB-C6DC-439F-9B5C-FB427EC9F6FE@ietf.org> <0a778f3b-c32e-abba-6e7f-305387adf3ad@it.aoyama.ac.jp> <0d91a5c0-8dd5-cbe8-2ff9-c5b3fed3cbb2@gmail.com> In-Reply-To: --PXlD1cdDXjR0QUhOwaAYT0vjjy3Cms0x2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Mirja, The implication in your note is that there is some great difficulty in=20 creating a new stream for this purpose.=C2=A0 Is that really the case?=C2= =A0 The=20 only real issues we have identified, so far as I understand it, is who=20 will represent the stream to the RPC when documents get pushed through,=20 and whether someone needs to represent the stream in the RSAB.=C2=A0 Are = there other issues? Eliot On 25.06.21 18:12, Mirja Kuehlewind wrote: > If we would keep using the IAB stream (and I=E2=80=99m not stating any = opinion here; just trying to outline what that could mean process-wise), = I think we still need some kind of IAB approval, because I think the IAB = wants to retain some control about what happens on their stream. However,= I think we could easy define something like the IAB can only not-approve= based on formal procedural problems but cannot rejecting based on the co= ntent that already has community consensus at that point. Yes, it would b= e an additional process step but I think we can make that very light-weig= ht. However, these are only my personal initial thoughts and it would pro= bably be good to also check with the rest of the IAB if that is considere= d an option. > > P.S.: The IAB reviews all IAB documents to some extend (workshop report= are usually written by IAB members) but during approval of those documen= ts everybody understands that we don=E2=80=99t need to have consensus on = the content of the document but are rather approving on the basis that th= e document is considered appropriate and ready for publication. > > >> On 25. Jun 2021, at 16:43, Joel M. Halpern wrote= : >> >> There are a lot of nuances that matter here. >> >> I could probably live with declaring thatt RSWG / RSAB documents are o= n the IAB stream if the RFC that said that also said that the IAB could n= ot make any substantive changes to the document and did not have the righ= t to refuse to progress the document. >> >> All the other cases you cite are ones where the IAB chooses to not rev= iew. This is somewhat different. >> >> Yours, >> Joel >> >> On 6/25/2021 4:59 AM, Mirja Kuehlewind wrote: >>> The IAB doesn=E2=80=99t necessarily need to label all IAB documents a= s IAB =E2=80=9Copinions=E2=80=9D but all IAB documents need IAB approval.= However, such things as workshop reports or also documents published by = the RSE are usually not seen as an outcome of the IAB and we often even a= dd a clause to the abstract that explicitly says that the document does n= ot reflect IAB opinions. For things that do reflect an IAB opinion when u= sually even add the list of names of IAB members at the time of approval,= to make clear whose opinions are reflected given the IAB also changes al= l the time (any thereby potentially also its opinions). >>> Mirja >>> P.S.: As a small side note an a statement that Jay made. The stream m= angers do discuss procedures with the RPC but usually the managers would = go back to their stream approval body and double-check, e.g. that=E2=80=99= s what is currently happening for the terminology guidance. So for me, th= e stream manager is really just the dedicated contact person here, while = the stream =E2=80=9Cowner=E2=80=9D is the approval body. >>>> On 24. Jun 2021, at 22:35, Brian E Carpenter wrote: >>>> >>>> On 24-Jun-21 20:57, Martin J. D=C3=BCrst wrote: >>>>> Hello Lars, others, >>>>> >>>>> On 2021-06-24 17:46, Lars Eggert wrote: >>>>>> Hi, >>>>>> >>>>>> On 2021-6-24, at 7:57, Brian E Carpenter >>>> wrote: >>>>>>> As somebody else said, this stream by its very nature is going to= be special and even self-referential. The notion we have of a stream bei= ng a >>>> client of the RFC Series just doesn't apply, so the normal notion of= a stream manager doesn't apply**. But surely we need someone to act as p= rogress chaser and nit resolver when a document has left the RSAB and is = inside the RPC? And who will that be if it's not the RSEA? >>>>>> I still remain unconvinced that we even need a new stream. I may b= e in >>>> the rough, but I would be OK with using the IAB stream and leaving t= he IAB a role here. >>>>> What would that role be exactly? Giving the label "IAB stream" to t= hese >>>>> documents without actually being able to approve or decline any of = them? >>>> I think that's exactly the problem. The IAB stream labels documents = as >>>> representing the IAB's opinion, and would imply that the IAB is >>>> approving the RSAB's opinion, which is not the new model at all. >>>> >>>> Brian >>>> >>>> --=20 >>>> Rfced-future mailing list >>>> Rfced-future@iab.org >>>> https://www.iab.org/mailman/listinfo/rfced-future --PXlD1cdDXjR0QUhOwaAYT0vjjy3Cms0x2-- --z20bjVXQRRMpjb9aspK62YUDhmbaRMdFN Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDWAbwFAwAAAAAACgkQh7ZrRtnSejOC vQgAsWnzJ8ulenvY0kOKbxbZ3HYvtABp6J8IaT3kwj1VvhuQmp/jzmQN0RhRaUTjbLt7kL4sVfZI fL+fZJc3UN/6mayTyNskpuwJQS6q8e/p36jshfJJ+MkeH7oi5dySUuFfHCf8OYypwIKluCWxTaAD GHvHQWp5uZGkHi6cSs9dTxlFnb1BOajVOnbcrPdux0JGgq/ahjQ2tvVypovvFfKDWABJ6oPrFb2g xPOkNH9aa04CBW3wR5FVOVOkOhAzEjLkRsSeGqFhe7BNMUvEWi3PwSxynQQjZDzqlyf6yemIaLZP gCHtL/Ur7nxTq+r68MbxG7uhYGsiurCU43A3zTNmDA== =6dUH -----END PGP SIGNATURE----- --z20bjVXQRRMpjb9aspK62YUDhmbaRMdFN-- From nobody Fri Jun 25 09:21:45 2021 Return-Path: X-Original-To: rfced-future@iab.org Delivered-To: rfced-future@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FA23A088A; Fri, 25 Jun 2021 09:21:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: The IAB , lflynn@amsl.com, rfced-future@iab.org, rfcefdp-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162463810393.1210.17522113620278059605@ietfa.amsl.com> Date: Fri, 25 Jun 2021 09:21:43 -0700 Archived-At: Subject: [Rfced-future] rfcefdp - Update to a Meeting Session Request for IETF 111 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 16:21:44 -0000 An update to a meeting session request has just been submitted by Liz Flynn, on behalf of the rfcefdp working group. --------------------------------------------------------- Working Group Name: RFC Editor Future Development Area Name: Internet Architecture Board Session Requester: Liz Flynn Number of Sessions: 2 Length of Session(s): 1 Hour, 1 Hour Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: rum dispatch stir sipcore emu opsawg anima Key Participant Conflict: spring tls secdispatch People who must be present: Eliot Lear Brian Rosen Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jun 25 10:16:28 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279343A0C1E for ; Fri, 25 Jun 2021 10:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.338, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] 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 EnFpN0bQrFKw for ; Fri, 25 Jun 2021 10:16:24 -0700 (PDT) Received: from mx36-out20.antispamcloud.com (mx36-out20.antispamcloud.com [209.126.121.68]) (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 5FEA93A0C18 for ; Fri, 25 Jun 2021 10:16:24 -0700 (PDT) Received: from xse142.mail2web.com ([66.113.196.142] helo=xse.mail2web.com) by mx136.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1lwpRC-000eFR-RQ for rfced-future@iab.org; Fri, 25 Jun 2021 19:16:20 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4GBNvP4z4DzLBB for ; Fri, 25 Jun 2021 10:16:17 -0700 (PDT) Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1lwpRB-00078Y-I6 for rfced-future@iab.org; Fri, 25 Jun 2021 10:16:17 -0700 Received: (qmail 6025 invoked from network); 25 Jun 2021 17:16:16 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.43.129]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Jun 2021 17:16:15 -0000 To: Lars Eggert , Brian E Carpenter Cc: rfced-future@iab.org, Joel Halpern Direct , Jay Daley , Eliot Lear References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> <351774DB-C6DC-439F-9B5C-FB427EC9F6FE@ietf.org> From: Christian Huitema Message-ID: Date: Fri, 25 Jun 2021 10:16:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 66.113.196.142 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yXEnUqtuiszqcStXlDoE9S53HEEk0VSrq03gtFxbC/KnPw 1rr53sqPgnfHyWXoRWZwGYjbvhzWX8Co+5c+eruaSxIRXVMlFuiz/acFNeeXtxN2fFxZWB9eYgpR BRu3UlDHMLIJYRi1cXH9Dbm+IxLV0XgtlP1veEWDxFjeo42e2HGFd932lfz+R/06O3Iy4akhy/LP m2rFgOGYwKKX1POmkVWClPVvbW5lVyQanRxw5hTHswbbB/ha+ZWrSAi8SkwqWAikMcSxTAWn8RCv ieGEqjG/gXZAaRh1X6LVetRf2ZYIiHqfCgG4wrA3w4/kQTYKxDHA9JN9J4k4XZq11JQkMemT4rxn nByU11Ftkqf3f/PF3GUV+KdBBqrnCX8j0Gi8Ksk+aedMfNWSnJswrtlNtZo3HPHi5Q+jjsF5dcBx ehWYzrkgsp4/Fysgb2cPV4IH0+lPwKr4i5mAANUcVraZYOaeuiH/yEdZH8S1+TgcJBOjh0vPxcQO jKKOrYIQYpwamUdylUIKhf3z2GAHxH7Iiihnln5nLwsYugixy853dgjI4WE+pjPnfrWRF8b8VMfH sJwWmPl681iOth9SifSFb3UQT3xbkHqpqmyCe4PiKWIgJ2XxgK7Je5b0uU+cZFhDVPQ6fMev1BMP vQ9qu4cW0z6bhalFEM/pjPCQA+BAlgw/CRu/wrwygqWNLx1IwWi3h1ESmlc3/lS5x7qxkdlaU/Pp xAhc6nC0ugI5tOt5hN7v62g7tRPzfrFjvwTWA5ZRXxKF5tPxTxfD0dMN+t5ZGb7Hq3E5aV3VWpIu YPuVVpHzWMmvk0UHbhiG5Vg3xxiN9/YGRrhMRGhIOTxMW00yF8F1u0YDQf8cLP9taeSLFY0fPBnF 89BphpBNlUg+TzHwBTL1+6vDOMemz/4I88NDcmnEJ4r7C+SwLRamrhQTd3PrpJpP5ewAjeqkzRNl ucyd+NO2McmveAr4ch9F7rE89jihx+Za/cV70jOJzN2r4A== X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 17:16:26 -0000 On 6/24/2021 1:46 AM, Lars Eggert wrote: > Hi, > > On 2021-6-24, at 7:57, Brian E Carpenter wrote: >> As somebody else said, this stream by its very nature is going to be special and even self-referential. The notion we have of a stream being a client of the RFC Series just doesn't apply, so the normal notion of a stream manager doesn't apply**. But surely we need someone to act as progress chaser and nit resolver when a document has left the RSAB and is inside the RPC? And who will that be if it's not the RSEA? > I still remain unconvinced that we even need a new stream. I may be in the rough, but I would be OK with using the IAB stream and leaving the IAB a role here. +1. That seems a much simpler solution than creating yet another rarely used structure. -- Christian Huitema From nobody Fri Jun 25 10:19:57 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1CA3A0C52 for ; Fri, 25 Jun 2021 10:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 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, NICE_REPLY_A=-0.338, 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=joelhalpern.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 himTwVQj-4pi for ; Fri, 25 Jun 2021 10:19:51 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 6CAD43A0C40 for ; Fri, 25 Jun 2021 10:19:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4GBNzV6mWSz6GKM1; Fri, 25 Jun 2021 10:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1624641590; bh=oAkN9Ibl3zY+M13MX73V6D3Pkd9Qxk9VX4PtwolxhrM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=pEPxLJS+KMzUFiZNH40KxrWBdS3vaptQkxJY+JPkDjDIGgKmKAE5uG1pa6kLBXQvl hjWvDfFdb4ArOChAyBDYnTr/Ex/UgUCAQzHfj/QZpYEn6lV4QoDnfnlBuInXTkKS5H 94TpMwJXRtohy7PR0bNdKR30Jf7P7KbZwJTuEYtI= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4GBNzV2mfCz6G98X; Fri, 25 Jun 2021 10:19:50 -0700 (PDT) To: Christian Huitema Cc: rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> <351774DB-C6DC-439F-9B5C-FB427EC9F6FE@ietf.org> From: "Joel M. Halpern" Message-ID: <476493c2-e434-0451-beaf-29a59be15aa3@joelhalpern.com> Date: Fri, 25 Jun 2021 13:19:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 17:19:56 -0000 If the IAB retains the right to rewrite or refuse the documents from this process, then I do not see what we have accomplished with this entire circus ??? Yours, Joel On 6/25/2021 1:16 PM, Christian Huitema wrote: > > On 6/24/2021 1:46 AM, Lars Eggert wrote: >> Hi, >> >> On 2021-6-24, at 7:57, Brian E Carpenter >> wrote: >>> As somebody else said, this stream by its very nature is going to be >>> special and even self-referential. The notion we have of a stream >>> being a client of the RFC Series just doesn't apply, so the normal >>> notion of a stream manager doesn't apply**. But surely we need >>> someone to act as progress chaser and nit resolver when a document >>> has left the RSAB and is inside the RPC? And who will that be if it's >>> not the RSEA? >> I still remain unconvinced that we even need a new stream. I may be in >> the rough, but I would be OK with using the IAB stream and leaving the >> IAB a role here. > > +1. That seems a much simpler solution than creating yet another rarely > used structure. > > -- Christian Huitema > From nobody Fri Jun 25 10:37:12 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87CF3A0D01 for ; Fri, 25 Jun 2021 10:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_NONE=-0.0001, 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=nthpermutation-com.20150623.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 oW4lQ1mK8s79 for ; Fri, 25 Jun 2021 10:37:06 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 A8F1D3A0D00 for ; Fri, 25 Jun 2021 10:37:06 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id o6so19981743qkh.4 for ; Fri, 25 Jun 2021 10:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=X33P/0pFrFB/Fntj1vLSVbvFBMG0PfYZvnCThYqbnKA=; b=BFMlRml50MEnV13mw0yrO3WVShkPRVt2lyvPn2T+jdfBvA+4P+pSPdvyf5NqRk2srZ acN19N534T7cMJBmBhNgeCpfOPobwMU/nS7b3x5UrRS+0yA+Pbant9gBka9PLGXBczpq MtPSnJUrGsbj8BwVsjLtP/NKCGCMRZgVsfW1nsGewm/nXatPidzvaZmjICAAe92HHR7m pEc3ahuT42/MR0A1hEALzZ3P1OThAC7p0KbOZzILAKUYu/s2AS7kFEMJFMGL6eovsQU6 WGDUtbNNOZmQTuMUGwMRVLx48xAeE5URGs/4sXlA5REl5YcsDFGkFwo9EWEcTrormwIY xbaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=X33P/0pFrFB/Fntj1vLSVbvFBMG0PfYZvnCThYqbnKA=; b=OF21NBxVPlX3OH7+ahyiDjbBNPE3xEFkjrwJ45qdAOSzwwza333XlCLFAp3kicTrqm Z0kRIPC8HptUO+Z/nAnFrmT7kE5U7n/yPolBylM8K8r7SifAIeYNsOjW037GuVcUc6vp G47QhWAR9QFepKeYiil//e5VywivzSvDzr54tD9/xFAjdRC+X1SHakzvEj9pw6o+K1q8 CXAtB+Sk9NZPnOhVDcFP1eem6kBgEB/eAWT5lS8c3Ja5VB2LD2JqOWg0SZmXbY3kSPH1 FB+xRHCxI564Gy5agyLvPbUj8zBHJd/B9DfPLLJkfTeYtl5WN/CG1cZyznfWSs3X5fgq b5gA== X-Gm-Message-State: AOAM533qc101lg8HHKUaNbRYXYywPhE3Bic0NqDVc9IIfyRyVMO2IRld d6xKr2Gekk023GwxIZqkZUPQU2U2CPF8zTkImaw= X-Google-Smtp-Source: ABdhPJyYoGBsDPdAp585ifD9bBj7xjk8BtUwcXM3CEadSkneaVYP4jqNqhfoBWAcFkEOBE17Di70Vg== X-Received: by 2002:a37:bb82:: with SMTP id l124mr12487363qkf.119.1624642624934; Fri, 25 Jun 2021 10:37:04 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id p14sm5267729qkh.128.2021.06.25.10.37.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Jun 2021 10:37:03 -0700 (PDT) To: rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> <351774DB-C6DC-439F-9B5C-FB427EC9F6FE@ietf.org> <476493c2-e434-0451-beaf-29a59be15aa3@joelhalpern.com> From: Michael StJohns Message-ID: Date: Fri, 25 Jun 2021 13:37:01 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <476493c2-e434-0451-beaf-29a59be15aa3@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 17:37:11 -0000 On 6/25/2021 1:19 PM, Joel M. Halpern wrote: > If the IAB retains the right to rewrite or refuse the documents from > this process, then I do not see what we have accomplished with this > entire circus ??? And to continue that thought, the IAB may change what it does with the IAB stream at any time for any reason. Effectively a veto. -1 - do not run publications of this type through the IAB process. Mike > > Yours, > Joel > > On 6/25/2021 1:16 PM, Christian Huitema wrote: >> >> On 6/24/2021 1:46 AM, Lars Eggert wrote: >>> Hi, >>> >>> On 2021-6-24, at 7:57, Brian E Carpenter >>> wrote: >>>> As somebody else said, this stream by its very nature is going to >>>> be special and even self-referential. The notion we have of a >>>> stream being a client of the RFC Series just doesn't apply, so the >>>> normal notion of a stream manager doesn't apply**. But surely we >>>> need someone to act as progress chaser and nit resolver when a >>>> document has left the RSAB and is inside the RPC? And who will that >>>> be if it's not the RSEA? >>> I still remain unconvinced that we even need a new stream. I may be >>> in the rough, but I would be OK with using the IAB stream and >>> leaving the IAB a role here. >> >> +1. That seems a much simpler solution than creating yet another >> rarely used structure. >> >> -- Christian Huitema >> > From nobody Fri Jun 25 10:37:46 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA693A0D03 for ; Fri, 25 Jun 2021 10:37:40 -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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 pL9-sETR4xRp for ; Fri, 25 Jun 2021 10:37:36 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 005EB3A0D01 for ; Fri, 25 Jun 2021 10:37:35 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id u5-20020a7bc0450000b02901480e40338bso6780299wmc.1 for ; Fri, 25 Jun 2021 10:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JzarHP8BMBrg1+ZfuSIWDyVfq5zrlb9nJrFfOYWkRVU=; b=ogaAE9ywD99XQobw4Avwwaye6rQFyPgrO38HZTtQhxnvGO9/tOO9uWYyNzklCUp4q6 sVuQeRAJu56MmnXi8UYFhXjuOeL0kcPULXCdzevEY3L3/Qli9ZpGfJrujanj2A/qpkg6 iRTm1ovLZX278YcGCi53FXlbn9R0s3n9wi8l6fkYPAdWVzqoPlZdkwpHIlhbXA+vlRC7 gWMlRgNKskCmWIXNlBVu964AjFjqMCzZigH9JUthgf4caeRJT9hNNX6hAqot+URYL0VL KsoUNpula7aHU//SUe8E+2b9hTHMCtkrIfiAaW+bm4q5hP1yXDJdmVV0BrYiK9eXQb97 tv4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JzarHP8BMBrg1+ZfuSIWDyVfq5zrlb9nJrFfOYWkRVU=; b=ETlUPlyN1d9tKaw9WP3i+sQiWCsfWlcIQ9qWz4GfBHxmrOm68CCA5Dip7o7Inahp1K ifpG1nUa1Tq3g4DjdSRXbjaEWkBpxY/EHcDvMAqhqN52mRJpKWbv62782oL3XoThxCaL KsEMGunwpdHMuXCyocTRGyfRH4493aqf61tAqYQVH2GSHdCr4v8LPyQuzi9sJE1DolMI o8B0MzjicB/u2Bdyy00rRM7PTLHinCCWrtl76q6ijOMegh4x9odjH7ylM3GkkRv+inZz H42Pkrc6+Jk1ZL8ObgvaBCiWN/NL24zicE7+rSnDmWuKU4SIwGRljD73lGNm10svUhDj Mh5w== X-Gm-Message-State: AOAM5312ShEA5/52ydtS01sKq4o3r+9bybTrxMGKM+Y+V/WgKAhk9qNE S4qxMFDt4y2o/Q74ZTYui7M= X-Google-Smtp-Source: ABdhPJyE0b/N1//AwzGfUpUVDwXudw9a2AM/0adSLN91NGVnpV3pFnXDpdlbpIGQLPX+vCR3wvSgMg== X-Received: by 2002:a05:600c:608:: with SMTP id o8mr11914445wmm.98.1624642652795; Fri, 25 Jun 2021 10:37:32 -0700 (PDT) Received: from [10.0.0.199] (c-24-5-53-184.hsd1.ca.comcast.net. [24.5.53.184]) by smtp.gmail.com with ESMTPSA id h15sm6570989wrq.88.2021.06.25.10.37.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Jun 2021 10:37:32 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1869BFA5-4381-41F7-8A4A-CE18928C3151"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Fri, 25 Jun 2021 10:37:29 -0700 In-Reply-To: <476493c2-e434-0451-beaf-29a59be15aa3@joelhalpern.com> Cc: Bob Hinden , rfced-future@iab.org To: "Joel M. Halpern" References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> <351774DB-C6DC-439F-9B5C-FB427EC9F6FE@ietf.org> <476493c2-e434-0451-beaf-29a59be15aa3@joelhalpern.com> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 17:37:41 -0000 --Apple-Mail=_1869BFA5-4381-41F7-8A4A-CE18928C3151 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 25, 2021, at 10:19 AM, Joel M. Halpern = wrote: >=20 > If the IAB retains the right to rewrite or refuse the documents from = this process, then I do not see what we have accomplished with this = entire circus ??? +1 Bob >=20 > Yours, > Joel >=20 > On 6/25/2021 1:16 PM, Christian Huitema wrote: >> On 6/24/2021 1:46 AM, Lars Eggert wrote: >>> Hi, >>>=20 >>> On 2021-6-24, at 7:57, Brian E Carpenter = wrote: >>>> As somebody else said, this stream by its very nature is going to = be special and even self-referential. The notion we have of a stream = being a client of the RFC Series just doesn't apply, so the normal = notion of a stream manager doesn't apply**. But surely we need someone = to act as progress chaser and nit resolver when a document has left the = RSAB and is inside the RPC? And who will that be if it's not the RSEA? >>> I still remain unconvinced that we even need a new stream. I may be = in the rough, but I would be OK with using the IAB stream and leaving = the IAB a role here. >> +1. That seems a much simpler solution than creating yet another = rarely used structure. >> -- Christian Huitema >=20 > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_1869BFA5-4381-41F7-8A4A-CE18928C3151 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAmDWFFkACgkQrut0EXfn u6hSPQf+J54WHAkgD9bmb/BNf1m/dwNzlsFvqwaPRDop2ja9NDHSoHZDpRO99epf ICvdujmgpzWTRRU/9oUwaytKxlB/kcEbkO3G3MDSTlh5YWlrbTMg5yj0C7Jxgxeh lPw0HCGSWh4dw2MP6RBn1acfsqefzrnFiZCyDBdBN2w4zgaiSoHkbTsJd8NcK74f bY5AaDktZuIyWxaUQkM9e7L5DOZpxFAp5s++OWcMCNp/dQT7FtCFTIyjDYfP+pxQ mJdDMJLBhwnk6fvrUXpGl4E02eCE7t2uBrUa346w4Dm5d/BzM5gM/PXvAuyWN5UI b8+i2YVhQUQyQ9Ny4CDbae9sOV4lBQ== =h2Mo -----END PGP SIGNATURE----- --Apple-Mail=_1869BFA5-4381-41F7-8A4A-CE18928C3151-- From nobody Fri Jun 25 12:00:53 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140173A09E4 for ; Fri, 25 Jun 2021 12:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 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, NICE_REPLY_A=-0.338, 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=mozilla.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 KSWP6xiczsTj for ; Fri, 25 Jun 2021 12:00:42 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 6C70A3A093D for ; Fri, 25 Jun 2021 12:00:37 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id s19so13688692ioc.3 for ; Fri, 25 Jun 2021 12:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=T69xhnqJjmcylLePxAq0gXn4io5X8SdOpF7Ejqc015g=; b=aTU2kTUG4cIbV9j7ApLeerPy1baD4EHXRWnarFWLKwRmC2o1+224mCZVPJkGib3l7/ BLc2NnvxXUlwhtt0BkNuejKzUxN05D6EFOijeEY/LIyEjEjXUAP3oqZf03CnJ8EUrgRu xsMjBJHBK30sHS687US2ttOn/exaO0XdBPTe4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=T69xhnqJjmcylLePxAq0gXn4io5X8SdOpF7Ejqc015g=; b=EcDwVmw9efN2PKV3gLPsHeDPFzTOpfD0iHrF1JyLClJ5haoTAjvixbtsQZ5yR13fCZ NwbLlYhQOgSot3eYy/Nyk5m5cxna4jXylOSiF+EtOAtFaU1MUQI2/WrQ0ndU1McQI5ci jx+9liBm+7uUdvR0nfX+yfmDVCeOA+E9/LXzn6tDS1td9jGmMcBXEY22rYZ9vz27zKFe cTWjSQzPO11ILqg5EcUISqDwuYJfdBZDQQPBbBQEgskxDgeZSZzI3VNRJNci/bDSI/4t a04u6++rtKMcKgwr32N2emGxID7Pu0Le85Qzq4Spb0oZ7FpGTVCms/nc4xGuWt00Joy/ 2Siw== X-Gm-Message-State: AOAM531eQjDgaTEnnlQVrSF3dgvGFlCGsHbwCDVUP9J/JbDMMkFgHa43 +Ll9gpbwHIa1W/qw3C3/Z/UJPA== X-Google-Smtp-Source: ABdhPJy1cDYBxgfZTbPLZ6S92lu0+Y1HnW+jDZo2gNEKGuXoihxWC+Aa+8kzhlXc/njqdD93ee0OWg== X-Received: by 2002:a5d:9d13:: with SMTP id j19mr1447210ioj.154.1624647635800; Fri, 25 Jun 2021 12:00:35 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id h12sm1613003ilj.6.2021.06.25.12.00.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Jun 2021 12:00:35 -0700 (PDT) To: adrian@olddog.co.uk, rfced-future@iab.org References: <6ed31a83-d686-59c3-ebdf-e914a0167022@lear.ch> <0a6401d7677a$137b07a0$3a7116e0$@olddog.co.uk> From: Peter Saint-Andre Message-ID: Date: Fri, 25 Jun 2021 13:00:33 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <0a6401d7677a$137b07a0$3a7116e0$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Consensus Check - Issue 20: Decider for hiring RSE/A X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 19:00:52 -0000 Hi Adrian, On 6/22/21 9:20 AM, Adrian Farrel wrote: > "and any detailed job description" tends to imply that if the LLC doesn't ask, they might not receive. Can the job description be forced upon them? Or s/any/the/ I suppose "any" leaves open the possibility that the search committee would do their work only based on the role definition and not also a detailed job description. However, the search committee might also take into account a much wider array of information, as such committees often do. Although I am not an expert on such matters, I am close to someone who is, and I'm aware that such information could include things like: * a competency model (knowledge, skills, abilities, and other characteristics needed for the role or within the organization), which in turn is typically created using a well-defined methodology * interviews with stakeholders (in our case that might be stream managers, LLC Executive Director, RPC leaders, etc.) * 360˚ feedback results * personality assessments * etc. I doubt we need to go into that level of detail, but here are two alternatives... Proposed text #1 (high level) The RSEA will be selected by a search committee formed by the Executive Director of the IETF LLC, taking into account the role definition [13] as well as other information that the committee deems necessary or helpful in making its decision. Proposed text #2 (detailed) The RSEA will be selected by a search committee formed by the Executive Director of the IETF LLC. To the extent possible, the committee will follow best practices for an executive search. The committee should take into account the role definition [13] as well as other information that the committee deems necessary or helpful in making its decision, such as an organizational competency model, consultations with relevant stakeholders (e.g., stream managers), formal assessments, and structured interviews. Peter From nobody Fri Jun 25 12:19:27 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C49F3A09D8 for ; Fri, 25 Jun 2021 12:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 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, NICE_REPLY_A=-0.338, 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 (1024-bit key) header.d=mozilla.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 YGpkSK1YOM-w for ; Fri, 25 Jun 2021 12:19:21 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 B021F3A09D1 for ; Fri, 25 Jun 2021 12:19:21 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id t12so1880274ile.13 for ; Fri, 25 Jun 2021 12:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rBiW+R//qOHc4DwiJfxwgBs0iS8ZXI75HopgkR5xuSs=; b=VPp0I8YrNeoEroh42sxT1Uafxl1QhS4toOY/55e6SghANMp3hqaIiq0Jq+GcYgdRSV KUyXTdqEuLu+Xgvb9pPC77uD6d6uZSvcTD/N1UpTd+Vz+ryl/218U/Qb8Af+Z4d/FapU nfb3CrSl6C8Wevj8xQCLIcmE1EQDpBSLe2rQM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=rBiW+R//qOHc4DwiJfxwgBs0iS8ZXI75HopgkR5xuSs=; b=OsPdcKYT3PNt/8fmJdyqpO6jv7g/ulVUkYJkQv69CtMKZJUdZ3II/3t1ukbeWapD/I fbzdzzaEwAkRbqleT8KPUSwLqG+kBQuYFnKSKKlrpoi4DjDaJyBwRkVVfArVogm351IG 8vJOTYXKWFFPfu7nABfYXArSK4VwdAlEGgnA09zIXruqOOd7+mMxjSFj3pvbLj2NOr2M UtIsqeed8Sc4vFJK7RE/2IlqtMRACiy3fU0LhuFtYt8M45snRBU9d2UboSgPzVabVgf+ LXH6mbwAYTD5pQXggpl2pOq1Xky/WrukcPSL3RHWaMXlm/iXF27YDXcZSwKL3Ip/JxFN XPKg== X-Gm-Message-State: AOAM531fjS02c/hk1af/gw4swME/Xq1d9sNWw6bVpoCMPlfJArIKyDWB 1M9EQ4pqGeC5T8yQ0Fy4p0blDA== X-Google-Smtp-Source: ABdhPJwAI4qmVVej0EOgux2lIqxfPVRdhpBhsmozJvUY/EoJ9it8sG3VWjvV9qibdb/z4JYn3UguHg== X-Received: by 2002:a05:6e02:dcc:: with SMTP id l12mr3833774ilj.80.1624648759996; Fri, 25 Jun 2021 12:19:19 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id e7sm3951207ili.10.2021.06.25.12.19.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Jun 2021 12:19:19 -0700 (PDT) To: Joel Halpern Direct Cc: rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> From: Peter Saint-Andre Message-ID: <2d926822-5c68-2279-b197-836534f3c030@mozilla.com> Date: Fri, 25 Jun 2021 13:19:18 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 19:19:26 -0000 On 6/23/21 3:06 AM, Joel Halpern Direct wrote: > I am wondering if we are mixing the concept of stream manager with > stream content owner.  The IESG is responsible for the content of the > IETF stream.  The IETF Chair or their delegate is the IETF stream > manager.  That role is making sure that there are no issues with the > practical publication of the stream, including interacting with the RPC. I'm not sure that we have a clear definition of the role of a stream manager. Bits and pieces are scattered around in RFCs 4844, 4845, 4846, 4714, etc. > Declaring the RSAB to be the stream manager hurts my head.  That is not > a person.  And will create confusion about the role of the RSAB.  WHile > the obvious analogy is to declare that the RSAB chair is the stream > manager for this new stream, it seems to me that creates confusion since > that person is (unless they are the RSE/A) the stream head for some > other stream. According to https://www.rfc-editor.org/faq/#streamman the stream managers are: For the IAB stream, the IAB Chair For the IETF stream, the IESG For the Independent Submissions stream, the ISE For the IRTF, the IRSG So we already have stream managers that are not natural persons. Peter From nobody Fri Jun 25 12:38:06 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292703A0AFD for ; Fri, 25 Jun 2021 12:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 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, NICE_REPLY_A=-0.338, 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=mozilla.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 lYI0S-bT3ZWO for ; Fri, 25 Jun 2021 12:38:02 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 BC60B3A0AF7 for ; Fri, 25 Jun 2021 12:38:02 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id k11so13849351ioa.5 for ; Fri, 25 Jun 2021 12:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=P6ssUX8kPmVfMVbUef0OKEXJrMb0pFiHhpM0raT0WGs=; b=JHbp/oz5H8BW+EGG2EH1N+FzYfUwmsyoraZmuYlxkde7HpOrR5eIgzU7+fmiNZxzzr cwOt5+/g8aem4rJjo0AeMYje/BjwVnWbNgXJW8xnqPp62DhygHM7ei2a4TN4zTjtAwo/ EofcylRabpzlsg+Xp4OH/sPsrYLIvIfRtIdMQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=P6ssUX8kPmVfMVbUef0OKEXJrMb0pFiHhpM0raT0WGs=; b=eKj8a3MbWR6CI4khMOhCWZkN3pNFxxT43LmFkPH1Wabwg7dGJw0/2sg6XQF3OFZql4 0lkO/UTCHF9Qx0I73WhySvJhy4Cy3ZmIyVn4PvWFAYq3CUbh7O87h+0wvPQTAXa6pwxT U3cxs2ALjzAgSEwWbtTbrJOhEs27YJjPfI+U5s9ZEbe0O2616KIkwEMzSL/20pxLle9P 5C75a1jO1iZy6xvyxTNxaz7WAMGan3M2Q7H3GuFvmwLOl3dv3i5PdWegj6HzyuHxwbYz T1PPOyR/jfjgQ/mGgSl+ZON+JfZ5VWLNSzU0sE7/jfmW+ZgXxawTxNZXXlxT+flyrkan yOtg== X-Gm-Message-State: AOAM5325vRcXmbMpQe5hI9VeNKuxMZr2hWUrCrs4m3RavZ84ry8oQ871 GL8p8UxQnMURSipg/TUM8iJblw== X-Google-Smtp-Source: ABdhPJz4fh5LGBZrrSCJF/uC2mrYRBv3fg+p2fC9owmqgZI7mGakSqNAWtUIOj/kKZMhLDhw5yINrg== X-Received: by 2002:a6b:c305:: with SMTP id t5mr10181367iof.202.1624649881194; Fri, 25 Jun 2021 12:38:01 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id f7sm4008434ilk.50.2021.06.25.12.38.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Jun 2021 12:38:00 -0700 (PDT) To: Eliot Lear , adrian@olddog.co.uk Cc: rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <0b9a01d76816$25690dd0$703b2970$@olddog.co.uk> From: Peter Saint-Andre Message-ID: <5113d732-2791-686a-3a46-66f81d5ea2a9@mozilla.com> Date: Fri, 25 Jun 2021 13:37:59 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 19:38:05 -0000 On 6/23/21 4:07 AM, Eliot Lear wrote: > Hi Adrian, > > On 23.06.21 11:57, Adrian Farrel wrote: >> Suppose a new stream published something that impeded in some way IETF >> work? I'm sure it is not our intent to open up a channel for end runs >> or subversion > > Assuming that the stream is exclusively for use for documents that are > approved via the process we are now defining, then the ultimate step is > for the RSAB to approve the document.  As part of that process, other > stream manager representatives get a shot at raising CONCERNs.  In a > sense, therefore, a check is built in. Indeed the document already says > the following: > >>    Notices will always be sent to the rfc-interest mailing list.  The >>    RSAB and RSWG should also send notices to other communities that may >>    be interested in or impacted by a proposal as they see fit, following >>    policies for those fora as appropriate. > > And so this allows each stream to apply whatever conflict resolution > process they would choose in order to determine whether a CONCERN should > be raised. Good point. That seems to cover it. Peter From nobody Fri Jun 25 13:02:47 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484053A0C50 for ; Fri, 25 Jun 2021 13:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 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, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_NONE=-0.0001, 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=mozilla.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 GFZmlJsaU32R for ; Fri, 25 Jun 2021 13:02:44 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 E01883A0C49 for ; Fri, 25 Jun 2021 13:02:43 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id h3so10743894ilc.9 for ; Fri, 25 Jun 2021 13:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Gt/zjTYV4CLDvKo7pdSkIhAV3LuLVp6wfs+worOkYf0=; b=Avpp/zf219wHFXzVswPCQRn75KvkkK40igfrNHfej34UP9BBRWuDFx/ckPixe6qWRF HUS2ZjRbTqeN8mQJX8FxxYNIf36d33HnHeDqX2w5fD0Lzchj2D0ORiFVw/uscIi+crWc USfV+4z6SzHWU47OOtucT5hNL9kVa0+omVsE4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=Gt/zjTYV4CLDvKo7pdSkIhAV3LuLVp6wfs+worOkYf0=; b=gWggWVwSKiJDM2cbyacf05j88EupQtR9hpQGrkQpT1SSoVXrdE/khbuL+f1SOxHyPJ osHJkR7ACOfJwY4lmZid0yIAMPEweTLt2QwMFsW2OrIaIfimPg6NjLsmKU2yWqwgL0Ov m1Yk/yLGHmW3WIfsKlFgNUnApq2MfJBGXgJYe87qgtS8X/JPIpc/k4mzG9FPyqoWrzcV 3+RF++HTtVjIH/LX0TX8klBHVaF8mgzaZiDriglquNtocWeyyDYKBOJcOZPBLZVXXcIO Li0CD5OaVFLvHUP4TyOWMIDEgbfU27SBPl9yVTbcuY1gW5M3rNpwjCJJ0rWQxYUw3dnK W/0g== X-Gm-Message-State: AOAM533wYDmksMK9mtLftHCC3lo2imcf0dfEeCcm8hU4veoNNnP4QuWq 4kvnaUfnhtZr2yAi8x4CDP8GXg== X-Google-Smtp-Source: ABdhPJx1mDlxahc7GMFbAwz1S2yS6S8d45CUAC7BRECtXP6+DGdbtRGvDK1fLSnpD46wmMt1pWhc4w== X-Received: by 2002:a05:6e02:8ee:: with SMTP id n14mr8377278ilt.205.1624651362564; Fri, 25 Jun 2021 13:02:42 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id g4sm4110858ilk.37.2021.06.25.13.02.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Jun 2021 13:02:42 -0700 (PDT) To: "Joel M. Halpern" , Christian Huitema Cc: rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> <351774DB-C6DC-439F-9B5C-FB427EC9F6FE@ietf.org> <476493c2-e434-0451-beaf-29a59be15aa3@joelhalpern.com> From: Peter Saint-Andre Message-ID: Date: Fri, 25 Jun 2021 14:02:40 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <476493c2-e434-0451-beaf-29a59be15aa3@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 20:02:46 -0000 On 6/25/21 11:19 AM, Joel M. Halpern wrote: > If the IAB retains the right to rewrite or refuse the documents from > this process, then I do not see what we have accomplished with this > entire circus ??? Circus? I take umbrage. ;-) But yes, separating this and related documents from the IAB stream seems best. Peter From nobody Fri Jun 25 13:08:31 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B422D3A0CDD for ; Fri, 25 Jun 2021 13:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 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, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=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=mozilla.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 sugn-A9j-Jpx for ; Fri, 25 Jun 2021 13:08:28 -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 384113A0CDC for ; Fri, 25 Jun 2021 13:08:28 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id g3so1897320ilj.7 for ; Fri, 25 Jun 2021 13:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=GY4YNMRn5qvSI1vE6RGNBRUeqoo6fhSsbJiym05L5vo=; b=aMllQVzW1eSB3J41jSc2fDmaxLX5wqb1nDPKeZTQz81FyEn/AWb6rNPRIyqGG6qp90 I+32P2xBndv0AgawCLXIlwfK2sfZsogGtsZw0ThtA7SLhbmKMMV94USOV+eBOaQpSUCO 3EOzmKbTqIkbuFlN9QVibGqxOsr/6PGzu6rDg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GY4YNMRn5qvSI1vE6RGNBRUeqoo6fhSsbJiym05L5vo=; b=mIPnlUSgPPCDrXdRS8FyRDcgMZ+W+wdxJA7lnS8VM9nqC6euvF/REAIem010BMz9DM M9ZxxEGl9mqLL9ghpiHlfcAm7S8ippc1OWCtvSyvLcM8qKD7RsU8d+odKPTLKAhfEfZD ac3pWB6TfcH9CEy4mB+ZpNe5WVkog3PQzoW4VIJC3Mx5lQhU/AUO4HyDhWpM1aTR2C+3 p2DLzxFVK0XBQz37QTTGXEmILO3Y5cqlqJDovx2MC2oKYUE86swRw9R9TlH7ValU/ozq OwtTKQScrm8XoI2H2fVbYIWzBHGyf0TY6TLOQ+IJcDjjT88S0hXwWV1FAocMFHji62VN YYag== X-Gm-Message-State: AOAM5322C+P88RrOELLtpJFxJDtlERhp4odtV1e9KnWIamIp8hksh7PC Akjjty8LeZMaKoB+lp5MbhlSO7EDGc+WpQ== X-Google-Smtp-Source: ABdhPJz0P5TRJnNm/FSBiWmZb8qc5BrNJEWexMXZYjq07XsQYKDxkeIIG3x1RIalvZ9ncCFM5GkulQ== X-Received: by 2002:a05:6e02:1288:: with SMTP id y8mr8461784ilq.86.1624651706848; Fri, 25 Jun 2021 13:08:26 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id n5sm1807361ilo.78.2021.06.25.13.08.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Jun 2021 13:08:26 -0700 (PDT) To: Martin Thomson , rfced-future@iab.org References: <7ef10df2-cb21-a95b-b977-286b6d8a8405@lear.ch> <0a8101d76788$0e1af5a0$2a50e0e0$@olddog.co.uk> <0ace01d767a5$39001350$ab0039f0$@olddog.co.uk> <7bda1df1-307b-4370-ad94-71af09af12c4@www.fastmail.com> From: Peter Saint-Andre Message-ID: <9eeb8fdb-73d2-5ee4-6021-7aa39e8a9333@mozilla.com> Date: Fri, 25 Jun 2021 14:08:24 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <7bda1df1-307b-4370-ad94-71af09af12c4@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 20:08:30 -0000 On 6/22/21 3:30 PM, Martin Thomson wrote: > On Wed, Jun 23, 2021, at 06:28, Adrian Farrel wrote: >> I think a stream exists because an organisation has requested to >> publish within the RFC Series. >> The owner of the Series surely decides whether to allow publication and >> whether a new stream is appropriate. >> >> I'm also interested in how a stream is shut down. Who makes that decision? > > My simple answer to both of these is: the RSWG proposes a change to the structure (add a stream, remove a stream) and the RSAB approves it. I think that both warrant publishing an RFC that documents the addition. That seems sensible. Naturally, an existing stream could shut itself down, too, but I suppose that could happen via the RSWG. Let's say the IRTF decides to close up shop - the act of closing the IRTF stream could be done through an RFC in the Editorial Stream. Peter From nobody Fri Jun 25 13:52:28 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBB33A0141 for ; Fri, 25 Jun 2021 13:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 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, NICE_REPLY_A=-0.338, 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=joelhalpern.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 WsXrH5fCaWPN for ; Fri, 25 Jun 2021 13:52:21 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 B87803A0143 for ; Fri, 25 Jun 2021 13:52:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4GBThj3SQfz6G98X; Fri, 25 Jun 2021 13:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1624654341; bh=vodiaC4H1rAaavFd9glSzea3CTZHb0G9TbwdvtgBIeU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=XeurZp4GG3bDRmINBTGICsdMazIvW7J/V6H6KMLJfasNOblN3dFqYMD+7iQW3Yb5S 29MGMYHMtQht7o/Et7R4PdjluEW6QH9hqc/Ev20ZkFmTPWCOmbwr6INIiEYDZFKaog lIv+j5IYhZCMzZtnHYHYl65+GvvvQfhDyZJIsIm8= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4GBThh6S1sz6GDyJ; Fri, 25 Jun 2021 13:52:20 -0700 (PDT) To: Peter Saint-Andre Cc: rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <2d926822-5c68-2279-b197-836534f3c030@mozilla.com> From: "Joel M. Halpern" Message-ID: Date: Fri, 25 Jun 2021 16:52:19 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <2d926822-5c68-2279-b197-836534f3c030@mozilla.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 20:52:26 -0000 Hmm. That does not seem to match reality. The IESG and IRSG do not attend the stream managers meetings. From everything I have ever been told about, the IRTF chair and the IETF chair have historically attended those meetings. And made practical decisions. (I am sure that for major items the IETF Chair checks with the IESG. The IRSG serves at the pleasure of the IRTF chair, so whether he (the IRTF Chair) checks with them is presumably up to him.) Yours, Joel On 6/25/2021 3:19 PM, Peter Saint-Andre wrote: > On 6/23/21 3:06 AM, Joel Halpern Direct wrote: >> I am wondering if we are mixing the concept of stream manager with >> stream content owner.  The IESG is responsible for the content of the >> IETF stream.  The IETF Chair or their delegate is the IETF stream >> manager.  That role is making sure that there are no issues with the >> practical publication of the stream, including interacting with the RPC. > > I'm not sure that we have a clear definition of the role of a stream > manager. Bits and pieces are scattered around in RFCs 4844, 4845, 4846, > 4714, etc. > >> Declaring the RSAB to be the stream manager hurts my head.  That is not >> a person.  And will create confusion about the role of the RSAB.  WHile >> the obvious analogy is to declare that the RSAB chair is the stream >> manager for this new stream, it seems to me that creates confusion since >> that person is (unless they are the RSE/A) the stream head for some >> other stream. > > According to https://www.rfc-editor.org/faq/#streamman the stream > managers are: > > For the IAB stream, the IAB Chair > For the IETF stream, the IESG > For the Independent Submissions stream, the ISE > For the IRTF, the IRSG > > So we already have stream managers that are not natural persons. > > Peter > From nobody Fri Jun 25 13:55:16 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF593A03FB for ; Fri, 25 Jun 2021 13:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 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, NICE_REPLY_A=-0.338, 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=mozilla.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 Z_UnbGyfcjuy for ; Fri, 25 Jun 2021 13:55:11 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 CFE093A0400 for ; Fri, 25 Jun 2021 13:55:11 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id h2so14062567iob.11 for ; Fri, 25 Jun 2021 13:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lC/WA7L5OXi9HarzqIGIY/mQZuMaOohcQ6jW9XOaGkY=; b=H0Dntzxm2ls0acqp0Lqvdl6jWnWiyNgGBJr0GXCRepIcjWSuYA3M0He4ueZXwjnHN2 5VnFAV0mOO8d5Nm0Pz+1+hcjtckuceX3va2dIOdTvuVEwCyavMjDZFu0OieHwIvtlZ1l gD7ZsYHXYJyQX/TDzH8nMBwe/MO80E3fDPbBk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=lC/WA7L5OXi9HarzqIGIY/mQZuMaOohcQ6jW9XOaGkY=; b=GcCRPZok7pDlRnDwfuMhem72gxk71ds/vXI2oOY0O3G+69g8OWN3srY+G0CqNzzR91 xyZ8WrVqX3N0qCVa5lsq/8kCv+kPK7WhgSqjuI/oAPAOhuA07Y7oyFMCPnj7WMqD4Hwx //wosKaOpeGg0Kr7wCZBrbDlF8kcN9veW/I5EOCerJ/TeuIlaMh2t1A4BF7NI+dvzjyr tLqTUDdWpLtuRyigUM0kc0NClSzHeknhLVlw7dW3MUXSRwVR0T5L64li+N0QVHsuTv6P gjResEMFa26js+F38n08sn9UMjXXJKZLJlpJvF4qBQtrfMP0r2joktTQqkYnW+1y2tzo UkDw== X-Gm-Message-State: AOAM532hBhA+3goIsAcuzbfWJx097oQikmKHo34QkAhUwh78CtQXe59v ssKQhiZbdOzoE9ms0E4NlaFUvQ== X-Google-Smtp-Source: ABdhPJwJTQcd17N6J+5CZldru4KM2x8FLtu8evnaoHSk0N3vRD7ThiB3O6oOdyZNIXsezNmJEbmoMg== X-Received: by 2002:a05:6638:13c3:: with SMTP id i3mr11111873jaj.140.1624654508823; Fri, 25 Jun 2021 13:55:08 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id e2sm3934240iot.50.2021.06.25.13.55.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Jun 2021 13:55:08 -0700 (PDT) To: "Joel M. Halpern" Cc: rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <2d926822-5c68-2279-b197-836534f3c030@mozilla.com> From: Peter Saint-Andre Message-ID: <55602726-93b9-d03c-447c-9d4b9ede5397@mozilla.com> Date: Fri, 25 Jun 2021 14:55:07 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 20:55:15 -0000 On 6/25/21 2:52 PM, Joel M. Halpern wrote: > Hmm.  That does not seem to match reality. Well, then we should align documentation with reality. ;-) > The IESG and IRSG do not > attend the stream managers meetings.  From everything I have ever been > told about, the IRTF chair and the IETF chair have historically attended > those meetings.  And made practical decisions.  (I am sure that for > major items the IETF Chair checks with the IESG.  The IRSG serves at the > pleasure of the IRTF chair, so whether he (the IRTF Chair) checks with > them is presumably up to him.) Right. Peter From nobody Fri Jun 25 14:23:37 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7110A3A098C for ; Fri, 25 Jun 2021 14:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 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.338, 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 MStvh1zWbReJ for ; Fri, 25 Jun 2021 14:23:34 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 BAB5F3A098A for ; Fri, 25 Jun 2021 14:23:34 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id h1so5380581plt.1 for ; Fri, 25 Jun 2021 14:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=+FJTMcd6CyiV3e8a5n5ldHCOg0UczF2cR7Lcfp9AM48=; b=cbmuJ3aitff7yl6igjruFSRpKHMzU5snLoNytgBfMJF36eCkw8WwlcFyEDf09fs0e9 FI7uyc8eaXmYYzqObB6foraFRX7M1C3F+/p6PC6M96Ciaw/GjLQKr0jbvRFVIo2mqGR4 QvaSkF1euMeAzIlGurqdkeb7uE3cbsWYLVTHTA9zxLfi6kFi0lpkZQJQc2YdnCu5Tbcb NCeCae8R1YGffVvg60d/qqc37NRBdfN7SdLbrWLZtO52iMIb04dIYCRCLDQ91D5wULrk uC5C4jz69KTbkn4GOPta1Z+SMie9v6l1xPhvUtfyKkL3OpaF2eZfhOzffYbYxSIYyhxb sy9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+FJTMcd6CyiV3e8a5n5ldHCOg0UczF2cR7Lcfp9AM48=; b=ET6P/ljlnWLVclcXJnhBwxQQGLty0Kw2D/QZjgOXL9sRqSMJNGoZdbtCiZKboVRJUH MMPoeOVJK/gxJtnjXrqcIGYrUr9J//GzHUc6HGqZKfCTf4VlHRydiM6dDu0Vqg+a2ngS 0C/iqSgCmp1xY3HOz0ZraHzz4wQ6YibllLcW49caqNjpXOmNaMzLResrkfLogTMJWLUX vbjG4iUffJ5cEo56vVmcfP8ve0rVOBaPH/E7/fAIikznqo4jibr0FlykWZ5v6WSeW2bp pXFDx2iYhqkeIDCkvBkSGaTUqdJOzZjjoojXvdKeNfMcu6Fh/9+ffgvPi3SmT8PxGq2H xUgA== X-Gm-Message-State: AOAM532tsptj94wJz3hTTzh/HEFwtZQlVObKsFUHCG+wAhG9x+7IYBKp Z5q+jZuV4k7m83nZ3cAyqt+xewHY1B4EoQ== X-Google-Smtp-Source: ABdhPJyabv1hlOUuPTeNvv/gjb+cjHjEe1RkoM5xzt5BBzwNgOtxlbjBERwUDxHd1TMf1ES7tbcRSw== X-Received: by 2002:a17:90b:3612:: with SMTP id ml18mr9084832pjb.209.1624656213157; Fri, 25 Jun 2021 14:23:33 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:db7:d041:a2d:ce65? ([2406:e003:100d:901:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id g17sm6399941pgh.61.2021.06.25.14.23.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Jun 2021 14:23:32 -0700 (PDT) To: Michael StJohns , rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> <351774DB-C6DC-439F-9B5C-FB427EC9F6FE@ietf.org> <476493c2-e434-0451-beaf-29a59be15aa3@joelhalpern.com> From: Brian E Carpenter Message-ID: <7ebda47b-990a-375c-0874-916ee359023a@gmail.com> Date: Sat, 26 Jun 2021 09:23:28 +1200 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: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 21:23:36 -0000 Exactly. Don't interpret this as an attack on the IAB. The idea is to *simplify* the overall structure and incidentally take all these concerns away from the IAB for ever, so that the IAB has more time to attend to the A in its name. (Whether the IAB even needs a liaison member from the RFC Editor in the new structure is for the IAB to think about.) Brian On 26-Jun-21 05:37, Michael StJohns wrote: > On 6/25/2021 1:19 PM, Joel M. Halpern wrote: >> If the IAB retains the right to rewrite or refuse the documents from >> this process, then I do not see what we have accomplished with this >> entire circus ??? > > And to continue that thought, the IAB may change what it does with the > IAB stream at any time for any reason. Effectively a veto. > > -1 - do not run publications of this type through the IAB process. > > > Mike > > >> >> Yours, >> Joel >> >> On 6/25/2021 1:16 PM, Christian Huitema wrote: >>> >>> On 6/24/2021 1:46 AM, Lars Eggert wrote: >>>> Hi, >>>> >>>> On 2021-6-24, at 7:57, Brian E Carpenter >>>> wrote: >>>>> As somebody else said, this stream by its very nature is going to >>>>> be special and even self-referential. The notion we have of a >>>>> stream being a client of the RFC Series just doesn't apply, so the >>>>> normal notion of a stream manager doesn't apply**. But surely we >>>>> need someone to act as progress chaser and nit resolver when a >>>>> document has left the RSAB and is inside the RPC? And who will that >>>>> be if it's not the RSEA? >>>> I still remain unconvinced that we even need a new stream. I may be >>>> in the rough, but I would be OK with using the IAB stream and >>>> leaving the IAB a role here. >>> >>> +1. That seems a much simpler solution than creating yet another >>> rarely used structure. >>> >>> -- Christian Huitema >>> >> > From nobody Fri Jun 25 14:26:44 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB81B3A09D5 for ; Fri, 25 Jun 2021 14:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 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.338, 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 YJjjOBDSRiEy for ; Fri, 25 Jun 2021 14:26:41 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 AF78E3A09D0 for ; Fri, 25 Jun 2021 14:26:41 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id d12so759713pfj.2 for ; Fri, 25 Jun 2021 14:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JD/MLIwAxAl2abDWZWwkr5pwELFNNt8CuaYQWXps+mI=; b=SvtHTcFBnvB69iR8p6ZKO18jpDODo/SaUwIkNkomp81uQROXf5XukxrwtNhpeyVTsw Io+EJ4vrLww5aIKiP+IHv6/CeyB05678Vr4TJ/MwxZy5hs3g1xdJnAIjNGTuWftVRo4F vnFg7/agujNWGtQTM08ABwA3K0YKayU+DoW/TQOrteNXziV9AXedVa0X1Fg1+m/6q69N Jd0dfQ7aeYHkMr+S5lz53DiKbhBcYHHO4bKsKc3CB9fsOVnkcwQSgNx8z9oiY2X6co75 BVfQze69hmGCeYpeH5SSuqlVXxKfuQyE/Y7bSme/6AdqJCFbBC6NHFRvjeun0iwHnZB3 drww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=JD/MLIwAxAl2abDWZWwkr5pwELFNNt8CuaYQWXps+mI=; b=cmv3vNM88xVVwJjaSQaNTVXbJKcfDJFxF63I+oOZaxGz94I2D3mIwZyczqIlwzSw2Z EdgZ0XMmddeiguqcOOcJi1JMhs3i1tP+lS4MKLGTHkN8JdHqJmqUPGdCZe+639tdyHR1 F0wbon+0Aa+GiwrmsgEMi1nm8WFK8MetuewociqCIc4sP6O8Nqwprxetkh3r22Rs3bz2 eMRbYTmtv0F0xv5lkWN6BEGAsL1H7vaDZ9ZMJDf9RBWcJy75ElO3tkA4zSj1V70KkYf9 qfE+rdeN+gulD95IcVyfw5Q60AeQjXu9tJk+hFwlsnUzrDHSGy2ThCXBkZmEMzSUFL+h BP3A== X-Gm-Message-State: AOAM5301I99VWeY/lI5pgfNRiIy/a5T+qBA0SH6tXYnfMG7xL58IerIy PXMxTwBCFEyazpyIJ1VpjKo4JDFkMtLTTQ== X-Google-Smtp-Source: ABdhPJzrbKTihgqoUs+f+4tSmc8Tks0eBCj9CfRcYq/Asq85BBAysp1Ap/0SXXwQUFE9GuiaqYtBAQ== X-Received: by 2002:a63:545a:: with SMTP id e26mr11431776pgm.282.1624656400581; Fri, 25 Jun 2021 14:26:40 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:db7:d041:a2d:ce65? ([2406:e003:100d:901:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id lb14sm11794431pjb.5.2021.06.25.14.26.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Jun 2021 14:26:40 -0700 (PDT) To: Peter Saint-Andre , "Joel M. Halpern" Cc: rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <2d926822-5c68-2279-b197-836534f3c030@mozilla.com> <55602726-93b9-d03c-447c-9d4b9ede5397@mozilla.com> From: Brian E Carpenter Message-ID: <34f4e8eb-3c81-6cb0-5cf1-ee3ab3b6cc5f@gmail.com> Date: Sat, 26 Jun 2021 09:26:35 +1200 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: <55602726-93b9-d03c-447c-9d4b9ede5397@mozilla.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 21:26:43 -0000 On 26-Jun-21 08:55, Peter Saint-Andre wrote: > On 6/25/21 2:52 PM, Joel M. Halpern wrote: >> Hmm.=C2=A0 That does not seem to match reality.=20 >=20 > Well, then we should align documentation with reality. ;-) How about=20 the IESG (represented by any AD) and the IRSG (normally represented by = the IRTF Chair) Brian >=20 >> The IESG and IRSG do not >> attend the stream managers meetings.=C2=A0 From everything I have ever=20 been >> told about, the IRTF chair and the IETF chair have historically attend= ed >> those meetings.=C2=A0 And made practical decisions.=C2=A0 (I am sure t= hat for >> major items the IETF Chair checks with the IESG.=C2=A0 The IRSG serves=20 at the >> pleasure of the IRTF chair, so whether he (the IRTF Chair) checks with= >> them is presumably up to him.) >=20 > Right. >=20 > Peter >=20 From nobody Fri Jun 25 14:29:21 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9546F3A09F9 for ; Fri, 25 Jun 2021 14:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 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, NICE_REPLY_A=-0.338, 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=joelhalpern.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 rnW23jilYIaw for ; Fri, 25 Jun 2021 14:29:15 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 4B15E3A09F5 for ; Fri, 25 Jun 2021 14:29:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4GBVWG61CYz6GHfH; Fri, 25 Jun 2021 14:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1624656554; bh=oFplPM/Up33NGp6QEsCAPDEyvuTkIzuBpusVWttn5SI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=S+6bwR1LQ8LP5tTuJ1+4SXirIoWG43lr30AjUMQv8274cFcbLNVeITLMH0lruMJfV mAUZNgHtCiLJkcAZDbhqVN1wO+sEOaodob4aJZvha+XJF2pnE/BVnCqBgBP69CLVnW 7Yr3/dip3v2ScldJ/3athbB00ljadxUDZ4SpIsW4= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4GBVWG0tpyz6GFQl; Fri, 25 Jun 2021 14:29:14 -0700 (PDT) To: Brian E Carpenter , Peter Saint-Andre Cc: rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <2d926822-5c68-2279-b197-836534f3c030@mozilla.com> <55602726-93b9-d03c-447c-9d4b9ede5397@mozilla.com> <34f4e8eb-3c81-6cb0-5cf1-ee3ab3b6cc5f@gmail.com> From: Joel Halpern Direct Message-ID: Date: Fri, 25 Jun 2021 17:29:12 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <34f4e8eb-3c81-6cb0-5cf1-ee3ab3b6cc5f@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 21:29:20 -0000 If those are the stream managers, then we need a different description for the makeup of the RSAB. It would be rather odd if the IESG sent different people at different times to the RSAB activities. Presumably we hope for some limited degree of continuity. Yours, Joel On 6/25/2021 5:26 PM, Brian E Carpenter wrote: > On 26-Jun-21 08:55, Peter Saint-Andre wrote: >> On 6/25/21 2:52 PM, Joel M. Halpern wrote: >>> Hmm.  That does not seem to match reality. >> >> Well, then we should align documentation with reality. ;-) > > How about > > the IESG (represented by any AD) and the IRSG (normally represented by the IRTF Chair) > > Brian > >> >>> The IESG and IRSG do not >>> attend the stream managers meetings.  From everything I have ever > been >>> told about, the IRTF chair and the IETF chair have historically attended >>> those meetings.  And made practical decisions.  (I am sure that for >>> major items the IETF Chair checks with the IESG.  The IRSG serves > at the >>> pleasure of the IRTF chair, so whether he (the IRTF Chair) checks with >>> them is presumably up to him.) >> >> Right. >> >> Peter >> > From nobody Fri Jun 25 14:42:57 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444843A0A4C for ; Fri, 25 Jun 2021 14:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 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.338, 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 XjjPrbm-3y2c for ; Fri, 25 Jun 2021 14:42:54 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 ECF4B3A0A20 for ; Fri, 25 Jun 2021 14:42:53 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id s14so7222649pfg.0 for ; Fri, 25 Jun 2021 14:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=R05TgeH9smraJuAd8zGdKL0QX6jgSY0DVTzMx8BrwqA=; b=sBKLQ9ySO5FDQXQRS0BFSP7N3WVWhR9g6qKHEZEQjNNyY3rebpAlaz+GUySKza4SOg rnD9r8ve0Px8HtG3UssJGwAH8QYCR6yZwYfCWI8+TeYTpYIKPkTEiJolJtUFed1j0ZI8 YJ4Pe9to/X4hPgmh2usUyV3ohP4xVHJNU4AN2rRVkfKRcMHNNA23o5PjYtEysShsOmrv 8ot3MHE2JG3+64ijCl19bxmfp8dG3EmTAfKAJSnYh55E3C3FfZBaNk0FA2XUaOX2JRQm gwA3bT3oBGZb6NIzJY/l8hcVs056UZsBpcU1mzvUMQyrWnDOyAQuRrTz8H9ZpgW4SyVa WGRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=R05TgeH9smraJuAd8zGdKL0QX6jgSY0DVTzMx8BrwqA=; b=Y1LFODganNWKAEafpMcWQ7VE6FV9Yg1kXtIKbe0iVHCXgPesGN4MkpkQSKOouSjmNh WWgwB3B4D4UWzVX0EyWqBAmuXjpZpd0EPa3wphfizTj1muUapyEvCvQvEJstMbtrqB2F fkfvUCAoGAxC2urct1nXWxMgiziFn/yFpIZmNsz1pStxaFSTkQFHYwZIq6A+2fGIgpKd ki564K1L651mFc+2QtKfkO3bk4n7t7K/AYwVW9FTJmsT+7E4aTCGZSiKL0M+GzEeJUey F+xLj4XI/J1b9eF5uAqiwPKocKrg3vI1IAY66+nSl3D+B9ZUNzY3sDlc9tV5oRPTK7D8 RIYw== X-Gm-Message-State: AOAM533W2/KgMtjhXBYcV4jD1w2TjHoAwIrnUZ8DmMg4IfLHujIv49vp wN15bma9bKJ9bCDFj4VF5361qOtIh62Keg== X-Google-Smtp-Source: ABdhPJyJAc1oPfynUvcEeIopSN2zCdCjIqY716gMrwgMmcNrWAQeGTUclKOBKjSzyr0UZiD9DEkwFA== X-Received: by 2002:a05:6a00:1742:b029:308:add4:e844 with SMTP id j2-20020a056a001742b0290308add4e844mr8509037pfc.18.1624657372578; Fri, 25 Jun 2021 14:42:52 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:db7:d041:a2d:ce65? ([2406:e003:100d:901:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id r134sm7135367pfc.68.2021.06.25.14.42.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Jun 2021 14:42:52 -0700 (PDT) To: Joel Halpern Direct , Peter Saint-Andre Cc: rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <2d926822-5c68-2279-b197-836534f3c030@mozilla.com> <55602726-93b9-d03c-447c-9d4b9ede5397@mozilla.com> <34f4e8eb-3c81-6cb0-5cf1-ee3ab3b6cc5f@gmail.com> From: Brian E Carpenter Message-ID: <708a0477-2df9-d36c-61ba-27c2e0d2f2b7@gmail.com> Date: Sat, 26 Jun 2021 09:42:47 +1200 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: quoted-printable Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Consensus_check=3A_Issue_22_=E2=80=93_n?= =?utf-8?q?ew_stream_for_RFC_Editor?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 21:42:56 -0000 Yes, you're correct; so the IESG and IRSG should each pick a regular participant, but presumably a deputy could attend if necessary.=20 Regards Brian On 26-Jun-21 09:29, Joel Halpern Direct wrote: > If those are the stream managers, then we need a different description = > for the makeup of the RSAB. It would be rather odd if the IESG sent=20 > different people at different times to the RSAB activities. Presumably=20 > we hope for some limited degree of continuity. >=20 > Yours, > Joel >=20 > On 6/25/2021 5:26 PM, Brian E Carpenter wrote: >> On 26-Jun-21 08:55, Peter Saint-Andre wrote: >>> On 6/25/21 2:52 PM, Joel M. Halpern wrote: >>>> Hmm.=C2=A0 That does not seem to match reality. >>> >>> Well, then we should align documentation with reality. ;-) >> >> How about >> >> the IESG (represented by any AD) and the IRSG (normally represented=20 by the IRTF Chair) >> >> Brian >> >>> >>>> The IESG and IRSG do not >>>> attend the stream managers meetings.=C2=A0 From everything I have ev= er >> been >>>> told about, the IRTF chair and the IETF chair have historically atte= nded >>>> those meetings.=C2=A0 And made practical decisions.=C2=A0 (I am sure=20 that for >>>> major items the IETF Chair checks with the IESG.=C2=A0 The IRSG serv= es >> at the >>>> pleasure of the IRTF chair, so whether he (the IRTF Chair) checks wi= th >>>> them is presumably up to him.) >>> >>> Right. >>> >>> Peter >>> >> From nobody Fri Jun 25 14:44:44 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFC73A0ADF for ; Fri, 25 Jun 2021 14:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 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.338, 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 xBtrqixGHLmQ for ; Fri, 25 Jun 2021 14:44:40 -0700 (PDT) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 7B69C3A0ADD for ; Fri, 25 Jun 2021 14:44:40 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id u2so5399739plf.3 for ; Fri, 25 Jun 2021 14:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=QmjaZY7THchi4T/wePyKI3GJYm+uByuDxe25qU9GxWM=; b=WF2jwyH/iyNYt05FoTxTAdudZyLMwvtGxpAH7qzfBwLX4jGeViozymHhZXnvsaO4tB HUoArbek8HkPUTOqE1Wa9VrH1Nei51dFdeyVHuLy6NCBrlAWd4fpe8J3b1uE3MfVrnvN C/hk9AEJpj2wt/smGP0XoB1E18pJc+l8C6Rr+yMQ9magjE+r/jB8w0woHZnVxDE3k01s W6u19rCDPwxbHjyKSbbQoYMTY5S5qRect6nzT8xkMx9wZ6z3fPZmx12sMMPQ49g4pQrR eOfErASkTKnPT4qoiVzHkhtuqaz3JwNGd+MfkwGb33O8C10/hx8fKZciGWX68+DSYKAk w7bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QmjaZY7THchi4T/wePyKI3GJYm+uByuDxe25qU9GxWM=; b=PI/9BRTKerWUt1S/5inxTn4BkWAdksktGnBWJt6PRucW1p1ng7v3Jzeg/voeJlgxSj jYn3VFQq41F13t1NkImhiFmkEOaQX3KQEqy1x0sEq6AV/Mhnc2SzDBsFqZNPdXxvThAy Whfv5PnZnmtwyBw4T0PocfgiOHjnaqe83CUdKOrvyuCmLhERZ7DhOHJM5D8EDJf2Q+qe LZPjEIoQ5R07D4ZlSo9lfpa8crWz5Z2yxcn5gulBbCRZTigiYsnI0zM+27pkVcgaMi5I qZkK1j041PWzYZD8c9Q3Ay3CcN49RQ/IUO74sPdcZalAT5SKe8TmCaI3/6P/BLZZJ8vU 2x9Q== X-Gm-Message-State: AOAM531AcVR6h5F6dkuFipgK7P2Vmin+BsIWNTDaI/hFbjdrKKngvHaS ZjPVwG0Q/IdxD3QWEzBYbJkpONuDEi7dqA== X-Google-Smtp-Source: ABdhPJxTBK+pa9Y/nypgy5Xcs4C42/mUapc8KlcjHQYfYzH1CZ4P4X/Vpn3SaA0Qt/AVKroDaibYGw== X-Received: by 2002:a17:90a:a797:: with SMTP id f23mr5277920pjq.190.1624657478666; Fri, 25 Jun 2021 14:44:38 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:db7:d041:a2d:ce65? ([2406:e003:100d:901:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id f17sm10097177pjj.21.2021.06.25.14.44.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Jun 2021 14:44:37 -0700 (PDT) To: rfced-future@iab.org References: <6ed31a83-d686-59c3-ebdf-e914a0167022@lear.ch> <0a6401d7677a$137b07a0$3a7116e0$@olddog.co.uk> From: Brian E Carpenter Message-ID: <5c1ae58e-c65b-e07e-b98c-378c3ed72878@gmail.com> Date: Sat, 26 Jun 2021 09:44:34 +1200 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: quoted-printable Archived-At: Subject: Re: [Rfced-future] Consensus Check - Issue 20: Decider for hiring RSE/A X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 21:44:43 -0000 I'd go for #1. Don't micromanage by RFC text. Regards Brian C On 26-Jun-21 07:00, Peter Saint-Andre wrote: > Hi Adrian, >=20 > On 6/22/21 9:20 AM, Adrian Farrel wrote: >> "and any detailed job description" tends to imply that if the LLC does= n't ask, they might not receive. Can the job description be forced upon t= hem? Or s/any/the/ >=20 > I suppose "any" leaves open the possibility that the search committee > would do their work only based on the role definition and not also a > detailed job description. >=20 > However, the search committee might also take into account a much wider= > array of information, as such committees often do. Although I am not an= > expert on such matters, I am close to someone who is, and I'm aware tha= t > such information could include things like: >=20 > * a competency model (knowledge, skills, abilities, and other > characteristics needed for the role or within the organization), which > in turn is typically created using a well-defined methodology >=20 > * interviews with stakeholders (in our case that might be stream > managers, LLC Executive Director, RPC leaders, etc.) >=20 > * 360=CB=9A feedback results >=20 > * personality assessments >=20 > * etc. >=20 > I doubt we need to go into that level of detail, but here are two > alternatives... >=20 > Proposed text #1 (high level) >=20 > The RSEA will be selected by a search committee formed by the > Executive Director of the IETF LLC, taking into account the role > definition [13] as well as other information that the committee > deems necessary or helpful in making its decision. >=20 > Proposed text #2 (detailed) >=20 > The RSEA will be selected by a search committee formed by the > Executive Director of the IETF LLC. To the extent possible, the > committee will follow best practices for an executive search. The > committee should take into account the role definition [13] as well > as other information that the committee deems necessary or helpful in= > making its decision, such as an organizational competency model, > consultations with relevant stakeholders (e.g., stream managers), > formal assessments, and structured interviews. >=20 > Peter >=20 From nobody Mon Jun 28 00:00:44 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28133A078F for ; Mon, 28 Jun 2021 00:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.888 X-Spam-Level: X-Spam-Status: No, score=-0.888 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, RCVD_IN_DNSWL_BLOCKED=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 hoorrpKmhQJ4 for ; Mon, 28 Jun 2021 00:00:38 -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 B4A833A2E40 for ; Mon, 28 Jun 2021 00:00:36 -0700 (PDT) Received: from [10.61.144.39] ([173.38.220.43]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15S70GCX034023 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 28 Jun 2021 09:00:21 +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=1624863630; bh=XQQolfpJBZn5PyXbW4tNvpIM911Ge4sM9etE+z/Jf0s=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=o4ZjiIpRlVfsu+aPYhUKZUn1ISTfJArhGgfKkhN+N29U1R4y+9QlHytN6kEBCOL4U KhJbwOq3xqjDsSht/UdvGhbw/XGqEu6u0hr0eHnFyuha539DqPqxpJDhpR14w2WZhI a4BGpzINnOL/pTSEQM7FU38DGibjAA7U2LJgGCJQ= To: Brian E Carpenter , Joel Halpern Direct , Peter Saint-Andre Cc: rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <2d926822-5c68-2279-b197-836534f3c030@mozilla.com> <55602726-93b9-d03c-447c-9d4b9ede5397@mozilla.com> <34f4e8eb-3c81-6cb0-5cf1-ee3ab3b6cc5f@gmail.com> <708a0477-2df9-d36c-61ba-27c2e0d2f2b7@gmail.com> From: Eliot Lear Message-ID: <84234113-6edd-e9fd-8196-c23a5517197e@lear.ch> Date: Mon, 28 Jun 2021 09:00:03 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <708a0477-2df9-d36c-61ba-27c2e0d2f2b7@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Qgf4l6mDcQujAHGsL7L4n0xITjJD55oH2" Archived-At: Subject: [Rfced-future] =?utf-8?q?RSAB_membership_=28was_Re=3A__Consensus?= =?utf-8?q?_check=3A_Issue_22_=E2=80=93_new_stream_for_RFC_Editor=29?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 07:00:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Qgf4l6mDcQujAHGsL7L4n0xITjJD55oH2 Content-Type: multipart/mixed; boundary="d3Xr3QjldG68SoU4T2BEUWyCzwHlLctYY"; protected-headers="v1" From: Eliot Lear To: Brian E Carpenter , Joel Halpern Direct , Peter Saint-Andre Cc: rfced-future@iab.org Message-ID: <84234113-6edd-e9fd-8196-c23a5517197e@lear.ch> Subject: =?UTF-8?Q?RSAB_membership_=28was_Re=3a_=5bRfced-future=5d_Consensus?= =?UTF-8?Q?_check=3a_Issue_22_=e2=80=93_new_stream_for_RFC_Editor=29?= References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <2d926822-5c68-2279-b197-836534f3c030@mozilla.com> <55602726-93b9-d03c-447c-9d4b9ede5397@mozilla.com> <34f4e8eb-3c81-6cb0-5cf1-ee3ab3b6cc5f@gmail.com> <708a0477-2df9-d36c-61ba-27c2e0d2f2b7@gmail.com> In-Reply-To: <708a0477-2df9-d36c-61ba-27c2e0d2f2b7@gmail.com> --d3Xr3QjldG68SoU4T2BEUWyCzwHlLctYY Content-Type: multipart/alternative; boundary="------------43E4A69FCFF372EBEA4593F7" Content-Language: en-US This is a multi-part message in MIME format. --------------43E4A69FCFF372EBEA4593F7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, On 25.06.21 23:42, Brian E Carpenter wrote: > Yes, you're correct; so the IESG and IRSG should each pick > a regular participant, but presumably a deputy could attend > if necessary. Here is what the text says: =C2=A0=C2=A0 The voting members of the RSAB shall be as follows: =C2=A0=C2=A0 o=C2=A0 One delegate representing the IETF stream, appointe= d by the IESG =C2=A0=C2=A0 o=C2=A0 One delegate representing the IAB stream, appointed= by the IAB =C2=A0=C2=A0 o=C2=A0 The IRTF Chair, representing the IRTF stream =C2=A0=C2=A0 o=C2=A0 The Independent Submissions Editor [RFC8730] =C2=A0=C2=A0 o=C2=A0 The RFC Series Editor/Advisor This means that the text in the draft is aligned with reality. My=20 suggestion is that we be explicit about term duration for the IESG and=20 IAB members, and whether they can be replaced mid term. The issue with=20 replacing someone mid term is that it takes a while for someone to learn = the job. So maybe something like this: NEW: "The IAB and IESG delegates shall serve for one year renewable terms.=C2=A0 Should a delegate become unavailable, the appointing bod= y MAY replace that individual to complete the term." This allows transitions to align with any membership changes within=20 those bodies. Eliot --------------43E4A69FCFF372EBEA4593F7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi,

On 25.06.21 23:42, Brian E Carpenter wrote:
Yes, you're correct; so the =
IESG and IRSG should each pick
a regular participant, but presumably a deputy could attend
if necessary.


Here is what the text says:

=C2=A0=C2=A0 The voting members of the RSAB shall be as follows:
=C2=A0=C2=A0 o=C2=A0 One delegate representing the IETF stream, app= ointed by the IESG

=C2=A0=C2=A0 o=C2=A0 One delegate representing the IAB stream, appo= inted by the IAB

=C2=A0=C2=A0 o=C2=A0 The IRTF Chair, representing the IRTF stream
=C2=A0=C2=A0 o=C2=A0 The Independent Submissions Editor [RFC8730]
=C2=A0=C2=A0 o=C2=A0 The RFC Series Editor/Advisor

This means that the text in the draft is aligned with reality.=C2=A0= My suggestion is that we be explicit about term duration for the IESG and IAB members, and whether they can be replaced mid term.=C2= =A0 The issue with replacing someone mid term is that it takes a while for someone to learn the job.

So maybe something like this:

NEW:

"The IAB and IESG delegates shall serve for one year renewable terms.=C2=A0 Should a delegate become unavailable, the appointing= body MAY replace that individual to complete the term."

This allows transitions to align with any membership changes within those bodies.

Eliot
--------------43E4A69FCFF372EBEA4593F7-- --d3Xr3QjldG68SoU4T2BEUWyCzwHlLctYY-- --Qgf4l6mDcQujAHGsL7L4n0xITjJD55oH2 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDZc3MFAwAAAAAACgkQh7ZrRtnSejMF WggA2JKKaWrum9X9MJyhFVRxBEgJqBb1CM1tDolICRXSLP0ZjH+lDE1heDfNMUrKuKai1SzoYCzH 7mI8WKNtTyHx1cVQy863yVS1jDbhcqBjGAM2IKO3ORClsqZKSAv1EVTxS5p3r9Ay/jK5KbWu8iFJ K8LVxXfDjl7S2q20csEL4laYdVEMe85Igw3fKOJmXtputQ7Zw+ET9EIGGcu7dH1MwW6nwth/2IsT 2POw/xgOkRobfZiqjMh2YSsJENKUr3qDe3GdHAuh5NQixF0vGjq0nuP1QiGwN6CjjNAjeyfQgUSM TOz2d9P8RmpwP9fvXRdCBlZYpBlx6yeKtKpuz27YwA== =SK2r -----END PGP SIGNATURE----- --Qgf4l6mDcQujAHGsL7L4n0xITjJD55oH2-- From nobody Mon Jun 28 00:33:23 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48873A2ED4 for ; Mon, 28 Jun 2021 00:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 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, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 bJJEj8K16iyP for ; Mon, 28 Jun 2021 00:33:16 -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 9AAB33A2E0D for ; Mon, 28 Jun 2021 00:33:16 -0700 (PDT) Received: from [10.61.144.39] ([173.38.220.43]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15S7X4Gb034272 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 28 Jun 2021 09:33:04 +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=1624865590; bh=/Yy3PzEz7GX99khY8rk+SgpEdhLHqEyl3XEM6KRQ40g=; h=To:References:From:Subject:Date:In-Reply-To:From; b=U7KQ+XMN9rdxHuhmIOZdvRtpIJTMRzfS/eou3y4287241u+WQjQ0n4E8xki1Nfn9r OPGO1QSao0iguBn6RmFKwuI/8JXRvA5uOHOIQ5GECWYWqGvM6eARXpiN+qRzH5e4GJ 2eFGUJtz0Q/3G7+G6i4F50txEeZxqDFZ4NsavAXY= To: adrian@olddog.co.uk, rfced-future@iab.org References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> From: Eliot Lear Message-ID: <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> Date: Mon, 28 Jun 2021 09:33:01 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hPKIO0WfsB0e61UywVJqAoqitfXJPflNn" Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 07:33:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hPKIO0WfsB0e61UywVJqAoqitfXJPflNn Content-Type: multipart/mixed; boundary="lAV0dAgKrzvGMKBzVxPo1S3Mnek1Bs5ii"; protected-headers="v1" From: Eliot Lear To: adrian@olddog.co.uk, rfced-future@iab.org Message-ID: <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> In-Reply-To: <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> --lAV0dAgKrzvGMKBzVxPo1S3Mnek1Bs5ii Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Adrian, On 22.06.21 17:10, Adrian Farrel wrote: > I completely agree with the sentiment, but I think the wording may have= issues. > > What the proposal does is say what can be done "if there are concerns a= bout the process followed by the RSWG." It does not say (but I think it i= s meant to imply) that the content of the decisions cannot be appealed. > > The "should" is also slightly ambiguous. > And "any action" presumably means the action being appealed. > > I would... > > Decisions of the RSWG can only be appealed on grounds of failure to fol= low the correct process. Such an appeal must be made to the RSAB within 3= 0 days of the action being appealed. The RSAB will then decide whether th= e process was followed correctly. One of the cases we were trying to cover was inaction of the chairs,=20 such as their refusal either to call a question or declare [lack of]=20 consensus.=C2=A0 Thus the wording as you saw it.=C2=A0 This leads to an=20 interesting question: when does the 30 day clock start? Also,=C2=A0 I thi= nk=20 the intent was to provide direction to the chairs in the case of an=20 appeal being upheld. With all of this in mind, I propose a bit of a merge: > Decisions of the RSWG can only be appealed on grounds of failure to=20 > follow the correct process. Appeals should be made within 30 days of=20 > any action, or in the case of failure to act, of notice having been=20 > given to the RSWG. The RSAB will then decide if the process was=20 > followed and will direct RSWG chairs as to what procedural actions are = > required. Does this make sense? Eliot > > Cheers, > Adrian > > -----Original Message----- > From: Rfced-future On Behalf Of Eliot Le= ar > Sent: 22 June 2021 15:38 > To: rfced-future@iab.org > Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) > > The following text was proposed to address appeals of the RSWG: > >> Appeals of RSWG decisions can be made to the RSAB if there are >> concerns about the process followed by the RSWG. Appeals should be >> made within 30 days of any action. The RSAB then decides if the >> process has been followed. > Please raise concerns by 6 July if you have any. > > Eliot > > > --lAV0dAgKrzvGMKBzVxPo1S3Mnek1Bs5ii-- --hPKIO0WfsB0e61UywVJqAoqitfXJPflNn Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDZey0FAwAAAAAACgkQh7ZrRtnSejPo hwgArwpm0RemiUyLgh0qKR6My7hg/TSlaEpEI6CZKcr5VwTRyHoLsrzWN0bXXk1CWeGkzyAePYD2 OpJBC3CIzTkHRGoT05LkNzFgTxKeLa+8TsQA/kbr3cM4LUJ0u/9fY7nNAT9ApwCX0msltl9gYbye sLAkzp8FJL7Nr29iO0PPxFmKnlQzhCRaP2+7nc7ynETMOc4C/LExPNVMyo6fvBltL3pKRrq6hXkZ YaA1DKonLTTmgQjAcw65R0HEddPF5MuciDqPOFt6/0G8MS5JdAp+IBcG2CAp7UODqodJl7j9G+h6 dDMzlEQf1GzFTt+uSDhWJjo1paChErMefnAi9oPpDw== =RcCq -----END PGP SIGNATURE----- --hPKIO0WfsB0e61UywVJqAoqitfXJPflNn-- From nobody Mon Jun 28 00:42:36 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF5B3A2F51 for ; Mon, 28 Jun 2021 00:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 X5bCb68CwyY3 for ; Mon, 28 Jun 2021 00:42:30 -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 D476A3A2F50 for ; Mon, 28 Jun 2021 00:42:29 -0700 (PDT) Received: from [10.61.144.39] ([173.38.220.43]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15S7gQwd034429 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Mon, 28 Jun 2021 09:42:27 +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=1624866147; bh=taS715FWP8PIGl+jNewckBvlYLbbHcA/fvyQFFYV+64=; h=To:From:Subject:Date:From; b=sMgvJy+OaQyWw9MmGxNXK17PuSSimZsFKueG785Ks+HzE/+WhMnKRodHHRIFsANq1 g6+KzcErb8LkLQkxQtdbz3LbEXLRQFpCS4jqt6h4TgEzJwawP3wdLO5BmjErMPC6Y+ /VlEy4C0Kh97GfppbDZIFqo9ULEnIfzeSAITs7uc= To: rfced-future@iab.org From: Eliot Lear Message-ID: <00714681-6efc-b775-7fd6-277c5ec296b9@lear.ch> Date: Mon, 28 Jun 2021 09:42:23 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FAFmonQQvJ51TYyA2E4z6Ca4Qq7aeuQRO" Archived-At: Subject: [Rfced-future] Consensus issues check status X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 07:42:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FAFmonQQvJ51TYyA2E4z6Ca4Qq7aeuQRO Content-Type: multipart/mixed; boundary="QPfxsxv7nEjt3iRedIzXGEWxTyQ15GNZf"; protected-headers="v1" From: Eliot Lear To: rfced-future@iab.org Message-ID: <00714681-6efc-b775-7fd6-277c5ec296b9@lear.ch> Subject: Consensus issues check status --QPfxsxv7nEjt3iRedIzXGEWxTyQ15GNZf Content-Type: multipart/alternative; boundary="------------EFEA42656C9E084360DB0ED4" Content-Language: en-US This is a multi-part message in MIME format. --------------EFEA42656C9E084360DB0ED4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi everyone, Given that we're checking consensus on a lot of issues, I thought I'd=20 put out an informal note in terms of where I think we are. The chairs=20 will provide a more formal summary after July 6th.=C2=A0 In the meantime,= =20 please keep those comments coming! Issue # Summary Status 11 =C2=A0Is there a figurehead (Propose to close) No objections thus far 14 Selection of RSWG chairs No objections thus far 16 Appeals In discussion 20 Decider for hiring Peter has offered two alternatives.=C2=A0 More discussion needed. 22 New Stream Lots of discussion- leaning toward somewhat rough consensus for the new = stream, but need to confirm 53 Defer Q of new RSAB members for new streams? Seemingly there is consensus 56,57,61,62 Various with RPC No consensus call.=C2=A0 Discussion continues Eliot --------------EFEA42656C9E084360DB0ED4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi everyone,

Given that we're checking consensus on a lot of issues, I thought I'd put out an informal note in terms of where I think we are.=C2=A0= The chairs will provide a more formal summary after July 6th.=C2=A0= In the meantime, please keep those comments coming!

Issue
#
 Summary
 Status
11
 =C2=A0Is there a figurehead (Propose to clos= e)
 No objections thus far
14
 Selection of RSWG chairs
 No objections thus far
16
 Appeals
 In discussion
20
 Decider for hiring
 Peter has offered two alternatives.=C2=A0 Mo= re discussion needed.
22
 New Stream
 Lots of discussion- leaning toward somewhat rough consensus for the new stream, but need to confirm
53
 Defer Q of new RSAB members for new streams?=
Seemingly there is consensus
56,57,61,62
 Various with RPC
 No consensus call.=C2=A0 Discussion continue= s


Eliot

--------------EFEA42656C9E084360DB0ED4-- --QPfxsxv7nEjt3iRedIzXGEWxTyQ15GNZf-- --FAFmonQQvJ51TYyA2E4z6Ca4Qq7aeuQRO Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDZfV8FAwAAAAAACgkQh7ZrRtnSejMX ugf+PVc69kDhnwR84eTp7DBj4TZhN7hOdfVypSIHJJhb34W7cBcn8wlRw1ShplQhHitYqvgPm3x7 kFqrmDYA/5P6KXFgWtKz8dIQzTu3yAJmTi864E5OE4wU2DSzNSk16xPwO6df46OrCC/yV9PESmLG T1+FU27bp2zhd4FA9f0PbUdP+PO2flxPzP4SjKWwFsWk9KmObTTSp0vCUurdmKPvLm9hrh+KRRLQ 0DlEhIvOflydB1iQUoXWMqOqdPTF3lIXaDqTGPcLEzYKT/FBqs4DVCI97Rdr5oxVDp65gS0X1jiT xI4HV7Zk9lnhSH16LwDV2qCyMP1I4ZaFYx3HNbv1yg== =PCDW -----END PGP SIGNATURE----- --FAFmonQQvJ51TYyA2E4z6Ca4Qq7aeuQRO-- From nobody Mon Jun 28 03:40:32 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E24D3A3499 for ; Mon, 28 Jun 2021 03:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 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, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 nPc__gRnVYqp for ; Mon, 28 Jun 2021 03:40:25 -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 AC2D63A3498 for ; Mon, 28 Jun 2021 03:40:24 -0700 (PDT) Received: from [10.61.144.45] ([173.38.220.46]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15SAe8m7036460 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 28 Jun 2021 12:40:09 +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=1624876820; bh=q8NnbP31XsMZuxfHM8tLx1DM+vA6s6uS7uwE6rxhujo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=mISZ1CuQNbhey7r5gTUBVT3Bul4ITKT/4dN/yOcnxohd82CJ93rFRXdl6aQQgoElP Q1ujRLF561dLPZO1xDweoolKchTe/deAuKvROIKij4DM04z/fiaiqCn2wER0+2Ibxn Z3Iewo5dO7qbTdfRpci+yHqJMdsSgc1aLlG9Uorw= To: Peter Saint-Andre , rfced-future@iab.org References: <6ed31a83-d686-59c3-ebdf-e914a0167022@lear.ch> <0a6401d7677a$137b07a0$3a7116e0$@olddog.co.uk> From: Eliot Lear Message-ID: Date: Mon, 28 Jun 2021 12:38:49 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5xvC97eaj9dwpzeWzBDD5DkH3lsPIJAiF" Archived-At: Subject: Re: [Rfced-future] Consensus Check - Issue 20: Decider for hiring RSE/A X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 10:40:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5xvC97eaj9dwpzeWzBDD5DkH3lsPIJAiF Content-Type: multipart/mixed; boundary="DlmzhUFfqfsblCD6ARkCTYrf2V8U3Dq0B"; protected-headers="v1" From: Eliot Lear To: Peter Saint-Andre , rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] Consensus Check - Issue 20: Decider for hiring RSE/A References: <6ed31a83-d686-59c3-ebdf-e914a0167022@lear.ch> <0a6401d7677a$137b07a0$3a7116e0$@olddog.co.uk> In-Reply-To: --DlmzhUFfqfsblCD6ARkCTYrf2V8U3Dq0B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Could people please share their views? On 25.06.21 21:00, Peter Saint-Andre wrote: > Proposed text #1 (high level) > > The RSEA will be selected by a search committee formed by the > Executive Director of the IETF LLC, taking into account the role > definition [13] as well as other information that the committee > deems necessary or helpful in making its decision. > > Proposed text #2 (detailed) > > The RSEA will be selected by a search committee formed by the > Executive Director of the IETF LLC. To the extent possible, the > committee will follow best practices for an executive search. The > committee should take into account the role definition [13] as well > as other information that the committee deems necessary or helpful i= n > making its decision, such as an organizational competency model, > consultations with relevant stakeholders (e.g., stream managers), > formal assessments, and structured interviews. --DlmzhUFfqfsblCD6ARkCTYrf2V8U3Dq0B-- --5xvC97eaj9dwpzeWzBDD5DkH3lsPIJAiF Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDZprkFAwAAAAAACgkQh7ZrRtnSejO4 FQf+KQt7e8qJOTlO5bt5IdDZajB8h8K0oS7/s90ctupAX9q1/K5V1fH75oq55VYVY3jSK1BfbWn/ InPkr2cSgSOFni6GKL2JI/RgbR8Q862+clpTmKBVqeAgLVNSe55ZyDM+Uws1e3jMxTNvmHX5Lern l4Vjlbv4WM0+tCIXwzLVcmcmz3frZgEytS/Y4jTDTVE10ynX1o2mz9ioq7s5iZDK6+AzVOcC0hh5 78a1PrtWNuErNqwHIUwwOLLpOv9T4HkZqeNP6VV0yjjys4UwNFs0xqdxMIhKJTqyCGa7PZENAljz qmjauW8Z43WsDpfZl665GjN0cMfgM3jtLzdIwxdzDQ== =5wYi -----END PGP SIGNATURE----- --5xvC97eaj9dwpzeWzBDD5DkH3lsPIJAiF-- From nobody Mon Jun 28 04:31:27 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B7B3A3616 for ; Mon, 28 Jun 2021 04:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 0kQN3HwkWR3o for ; Mon, 28 Jun 2021 04:31:22 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 9A9C03A3612 for ; Mon, 28 Jun 2021 04:31:21 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15SBVInU010360; Mon, 28 Jun 2021 12:31:18 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4E2214604B; Mon, 28 Jun 2021 12:31:18 +0100 (BST) Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 41D684603D; Mon, 28 Jun 2021 12:31:18 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS; Mon, 28 Jun 2021 12:31:18 +0100 (BST) Received: from LAPTOPK7AS653V ([195.166.134.8]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15SBVH32011025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Jun 2021 12:31:17 +0100 Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> In-Reply-To: <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> Date: Mon, 28 Jun 2021 12:31:17 +0100 Organization: Old Dog Consulting Message-ID: <112801d76c11$1c9d1760$55d74620$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQDwm4h/OuxJzo06clSw5zQRx8klMgKsDZSXAcJBaGes03U7IA== X-Originating-IP: 195.166.134.8 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1017-26244.007 X-TM-AS-Result: No--11.891-10.0-31-10 X-imss-scan-details: No--11.891-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1017-26244.007 X-TMASE-Result: 10--11.891100-10.000000 X-TMASE-MatchedRID: 0dFPYP4mu5S8rRvefcjeTb7u5vMMMVTtaMmm586o4gAUE18jzz932mG5 xHgwrq7piCilT76ynH2O14IwaXeTpLa2Vh2jQ2eESHCU59h5KrFbPuQHjNNdgmtEzrC9eANpIZR vYk3GLWrvRxhN4qdDLuF6spR+t5u70eczgee7i1MYkAMBsEcZTN1hWsVVuzNox9yTZd72QS7B3D S57bMZjQo+don4OUaJoV/DXcEgCX89d1nHWxkekElABXpquwdlDnVIBRSEqxSRM9Vk6by5HSPn0 SVYu0+T2sPhxG57msnQ3499m9WCV5kaeWCm57xMsTzXVHVB9VrYUDvAr2Y/121RcrL9l9kZfMrd D3NIUvvYh8hhwrkGAVvpPAaCtVR+EELLA9CKU2A5UYVNPDbxh90pE2POjYg4WcVk1+PpebZEvmP VFYOPw9InOZzevFRlWYlZIJWcltLlRxm3A2wKukY41YX/o/8Ki2QFaYS1v20qtq5d3cxkNQwWxr 7XDKH8xd94rmIJD5pqYquA9lCMfX522zPd3zuF3MMbXaj4KrVMwP1VAPtgPQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 11:31:27 -0000 Yeah, I can live with that. Failure to act is always a tricksy one. I think you have it covered. A -----Original Message----- From: Eliot Lear =20 Sent: 28 June 2021 08:33 To: adrian@olddog.co.uk; rfced-future@iab.org Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) Hi Adrian, On 22.06.21 17:10, Adrian Farrel wrote: > I completely agree with the sentiment, but I think the wording may = have issues. > > What the proposal does is say what can be done "if there are concerns = about the process followed by the RSWG." It does not say (but I think it = is meant to imply) that the content of the decisions cannot be appealed. > > The "should" is also slightly ambiguous. > And "any action" presumably means the action being appealed. > > I would... > > Decisions of the RSWG can only be appealed on grounds of failure to = follow the correct process. Such an appeal must be made to the RSAB = within 30 days of the action being appealed. The RSAB will then decide = whether the process was followed correctly. One of the cases we were trying to cover was inaction of the chairs,=20 such as their refusal either to call a question or declare [lack of]=20 consensus. Thus the wording as you saw it. This leads to an=20 interesting question: when does the 30 day clock start? Also, I think=20 the intent was to provide direction to the chairs in the case of an=20 appeal being upheld. With all of this in mind, I propose a bit of a merge: > Decisions of the RSWG can only be appealed on grounds of failure to=20 > follow the correct process. Appeals should be made within 30 days of=20 > any action, or in the case of failure to act, of notice having been=20 > given to the RSWG. The RSAB will then decide if the process was=20 > followed and will direct RSWG chairs as to what procedural actions are = > required. Does this make sense? Eliot > > Cheers, > Adrian > > -----Original Message----- > From: Rfced-future On Behalf Of Eliot = Lear > Sent: 22 June 2021 15:38 > To: rfced-future@iab.org > Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) > > The following text was proposed to address appeals of the RSWG: > >> Appeals of RSWG decisions can be made to the RSAB if there are >> concerns about the process followed by the RSWG. Appeals should be >> made within 30 days of any action. The RSAB then decides if the >> process has been followed. > Please raise concerns by 6 July if you have any. > > Eliot > > > From nobody Mon Jun 28 05:41:12 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B323A3803 for ; Mon, 28 Jun 2021 05:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=rtfm-com.20150623.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 471MfB2ajw3g for ; Mon, 28 Jun 2021 05:41:00 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 6DA0E3A37D9 for ; Mon, 28 Jun 2021 05:41:00 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id l5so5890901iok.7 for ; Mon, 28 Jun 2021 05:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5YjdTZE+GmCuLYqL94nJbWwx8+/OCJTV18r3PRCy9lQ=; b=gAEuSd9B1du3NDSRlI5hevIVcGk4feArlvlF3bsvWPNLS1VU0rnZurguKRX0936MtN nn5WbSRu6a/BY5FQ/pwVaNHFVLwg0iOvaXAkdgDLmEoUFjLbvBFE3dDXD5HZbyHrnFRO uv2glu8XPKYzyQbJ9gxISVJg3wWFdeEtX5T6lVo7nRPbeJ/PVJH46emYQ1FbrEgztNTM uLpCA2xZ+CqfTrSexW0Lb+cnWg27gp1gN9lBcU2jczOGVKx2s2Qm4dDEHt/7E4MY+lez nZXdY73FmoexMgN8b3D+EDTz13rIA4r9lV37ShX6somFHRZsv5Hfiy2+NVkLw+P/7UYl O0mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5YjdTZE+GmCuLYqL94nJbWwx8+/OCJTV18r3PRCy9lQ=; b=rbM64r0PJdShh5aq5iptc/o47llHuNNax1CIpksgJ5q3Dv9CyLsycUI8K7a0f66xTG G9MEKB0lK91d/PGEphf3h/HosgnUCf/zC3fac5tl5sF5iEntWzYFjVhHOGmejekgBOIq GuAfGkUgxrZ/N36NYYl0X3GJC9jvGz/aUcnw6PGogEmGsh3Noyoc6AFs7KP4lype0+eE pMROYEh9nsLYtVE5kxaUXFhIDc6fEMU+P6gdMNz3OpxMHb/A53ja2XRKxvgjSOwQ5KLg mX1izqnUHP6M+2zg+POlY9B7deV8jioCbCg8yjtNzI6mSZxt2o4of5Tk4Dnog8WLTEnO wjcQ== X-Gm-Message-State: AOAM533AOFySO+0zjg9x8lY9TczyyjbcnzjEWaB+IS8yoR36WHMltLI0 bhF6I2WV07pe+onzbL3EnaJiUHLrBazdR8e7yIG8pg== X-Google-Smtp-Source: ABdhPJxSsiy18Qf0GbfBhgRPqscR22rgKCMfaStDTm9WAuM7D6fpTvY0nhWJcoCWxh2Ye1O3ZeE0Am/fGoZhEXGk9Gg= X-Received: by 2002:a02:ba0a:: with SMTP id z10mr22947403jan.10.1624884058492; Mon, 28 Jun 2021 05:40:58 -0700 (PDT) MIME-Version: 1.0 References: <6ed31a83-d686-59c3-ebdf-e914a0167022@lear.ch> <0a6401d7677a$137b07a0$3a7116e0$@olddog.co.uk> <5c1ae58e-c65b-e07e-b98c-378c3ed72878@gmail.com> In-Reply-To: <5c1ae58e-c65b-e07e-b98c-378c3ed72878@gmail.com> From: Eric Rescorla Date: Mon, 28 Jun 2021 05:40:22 -0700 Message-ID: To: Brian E Carpenter Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000001ba5fb05c5d2cdbe" Archived-At: Subject: Re: [Rfced-future] Consensus Check - Issue 20: Decider for hiring RSE/A X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 12:41:12 -0000 --0000000000001ba5fb05c5d2cdbe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 -Ekr On Fri, Jun 25, 2021 at 2:44 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > I'd go for #1. Don't micromanage by RFC text. > > Regards > Brian C > > On 26-Jun-21 07:00, Peter Saint-Andre wrote: > > Hi Adrian, > > > > On 6/22/21 9:20 AM, Adrian Farrel wrote: > >> "and any detailed job description" tends to imply that if the LLC > doesn't ask, they might not receive. Can the job description be forced up= on > them? Or s/any/the/ > > > > I suppose "any" leaves open the possibility that the search committee > > would do their work only based on the role definition and not also a > > detailed job description. > > > > However, the search committee might also take into account a much wider > > array of information, as such committees often do. Although I am not an > > expert on such matters, I am close to someone who is, and I'm aware tha= t > > such information could include things like: > > > > * a competency model (knowledge, skills, abilities, and other > > characteristics needed for the role or within the organization), which > > in turn is typically created using a well-defined methodology > > > > * interviews with stakeholders (in our case that might be stream > > managers, LLC Executive Director, RPC leaders, etc.) > > > > * 360=CB=9A feedback results > > > > * personality assessments > > > > * etc. > > > > I doubt we need to go into that level of detail, but here are two > > alternatives... > > > > Proposed text #1 (high level) > > > > The RSEA will be selected by a search committee formed by the > > Executive Director of the IETF LLC, taking into account the role > > definition [13] as well as other information that the committee > > deems necessary or helpful in making its decision. > > > > Proposed text #2 (detailed) > > > > The RSEA will be selected by a search committee formed by the > > Executive Director of the IETF LLC. To the extent possible, the > > committee will follow best practices for an executive search. The > > committee should take into account the role definition [13] as well > > as other information that the committee deems necessary or helpful in > > making its decision, such as an organizational competency model, > > consultations with relevant stakeholders (e.g., stream managers), > > formal assessments, and structured interviews. > > > > Peter > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --0000000000001ba5fb05c5d2cdbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

-Ekr

=

= On Fri, Jun 25, 2021 at 2:44 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
I'd go for #1. Don= 't micromanage by RFC text.

Regards
=C2=A0 =C2=A0Brian C

On 26-Jun-21 07:00, Peter Saint-Andre wrote:
> Hi Adrian,
>
> On 6/22/21 9:20 AM, Adrian Farrel wrote:
>> "and any detailed job description" tends to imply that i= f the LLC doesn't ask, they might not receive. Can the job description = be forced upon them? Or s/any/the/
>
> I suppose "any" leaves open the possibility that the search = committee
> would do their work only based on the role definition and not also a > detailed job description.
>
> However, the search committee might also take into account a much wide= r
> array of information, as such committees often do. Although I am not a= n
> expert on such matters, I am close to someone who is, and I'm awar= e that
> such information could include things like:
>
> * a competency model (knowledge, skills, abilities, and other
> characteristics needed for the role or within the organization), which=
> in turn is typically created using a well-defined methodology
>
> * interviews with stakeholders (in our case that might be stream
> managers, LLC Executive Director, RPC leaders, etc.)
>
> * 360=CB=9A feedback results
>
> * personality assessments
>
> * etc.
>
> I doubt we need to go into that level of detail, but here are two
> alternatives...
>
> Proposed text #1 (high level)
>
>=C2=A0 =C2=A0The RSEA will be selected by a search committee formed by = the
>=C2=A0 =C2=A0Executive Director of the IETF LLC, taking into account th= e role
>=C2=A0 =C2=A0definition [13] as well as other information that the comm= ittee
>=C2=A0 =C2=A0deems necessary or helpful in making its decision.
>
> Proposed text #2 (detailed)
>
>=C2=A0 =C2=A0The RSEA will be selected by a search committee formed by = the
>=C2=A0 =C2=A0Executive Director of the IETF LLC.=C2=A0 To the extent po= ssible, the
>=C2=A0 =C2=A0committee will follow best practices for an executive sear= ch.=C2=A0 The
>=C2=A0 =C2=A0committee should take into account the role definition [13= ] as well
>=C2=A0 =C2=A0as other information that the committee deems necessary or= helpful in
>=C2=A0 =C2=A0making its decision, such as an organizational competency = model,
>=C2=A0 =C2=A0consultations with relevant stakeholders (e.g., stream man= agers),
>=C2=A0 =C2=A0formal assessments, and structured interviews.
>
> Peter
>

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--0000000000001ba5fb05c5d2cdbe-- From nobody Mon Jun 28 15:44:07 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404763A198F for ; Mon, 28 Jun 2021 15:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 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.338, RCVD_IN_DNSWL_BLOCKED=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 horoA2hdNSIW for ; Mon, 28 Jun 2021 15:44:04 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 C71773A198E for ; Mon, 28 Jun 2021 15:44:04 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id h1so9813533plt.1 for ; Mon, 28 Jun 2021 15:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ELpnGNqgzA7mY5AMndJ6rAKeRkyJUhiFyhEKflo43YM=; b=PIp2mcHEQoytxPBEnarJfq5WJv0sMeKdd6N8IiRw9XAwpfvLGSJLTBik/Z31IbxtGB Jt4JSg3AiUceBBNbOUHQgLvKNWejVyUdcolf8ySP3bMQtcVHm/aUMK+a9JSBja9Ln5ID ejeNMPJGABenYJngOU4sNJGHCHcRbhGYZbFaJHol5Hep4BwtW7S9a7bSZrbijIIFLF+H p1DGrLUz/y3knGm1Qx3etT6XVXPbrAFhYg0FoJz6JJT9MbPqJgzApkTmmjFLF1cvntPe nLcd7lKFL95QslAS4rYwHTRV2Cp5VfnVbEMMNb1KVyRAj8GfmknJAn1VCbzByGO8dFRL jY3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=ELpnGNqgzA7mY5AMndJ6rAKeRkyJUhiFyhEKflo43YM=; b=gse7g/5O0XrXlSkF9/JJcYN43SQad82XZZ/TU6phoW4Dtpij2CqXS9H5vAiiTO6ebl 6GNDjBMVLZi+F5EtMAvQ2qKW8j43jKrZVo2mx3xOF0Vm3L6r0/b2OqqoGaIuZrRyhc3O Hw0f+tJ69ghKHnsg5bCDJ2ecEH603fU4wbeCdE9NpLp7m+zUGCXU5S8npr4WN91ucLSv Ep1JF8Y3fLK0RszLLipmyxYXP0h6ePAPotXIRc8rKtceLpxkSD/C9OFRzFr1VD2fjhLu 2/nPtVETKkRf31ICbyrYfAeGLnviWzggDqeoa59mpWNLbqjGLEkwd+v4Kuc5GSHjkmfN AUWg== X-Gm-Message-State: AOAM531bmcwaMtbn353QJSdRW4xQOVgCJ5/6BQfnki4o1KGrq45U5com McuZLQ27RIp6cQcmpS+gy+RHzgoGJ+8jrw== X-Google-Smtp-Source: ABdhPJzHUJs8r6kkygK+23yN0SffZCM51LoSozPKGcETWQ+Rvjnu/WnwAXrjfCCECSlp02rk4aNIUA== X-Received: by 2002:a17:902:c3c6:b029:128:f061:889d with SMTP id j6-20020a170902c3c6b0290128f061889dmr2911054plj.50.1624920241830; Mon, 28 Jun 2021 15:44:01 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id q18sm15708019pfj.178.2021.06.28.15.43.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Jun 2021 15:44:01 -0700 (PDT) To: Eliot Lear , Joel Halpern Direct , Peter Saint-Andre Cc: rfced-future@iab.org References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <2d926822-5c68-2279-b197-836534f3c030@mozilla.com> <55602726-93b9-d03c-447c-9d4b9ede5397@mozilla.com> <34f4e8eb-3c81-6cb0-5cf1-ee3ab3b6cc5f@gmail.com> <708a0477-2df9-d36c-61ba-27c2e0d2f2b7@gmail.com> <84234113-6edd-e9fd-8196-c23a5517197e@lear.ch> From: Brian E Carpenter Message-ID: Date: Tue, 29 Jun 2021 10:43:56 +1200 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: <84234113-6edd-e9fd-8196-c23a5517197e@lear.ch> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?RSAB_membership_=28was_Re=3A__Consensus?= =?utf-8?q?_check=3A_Issue_22_=E2=80=93_new_stream_for_RFC_Editor=29?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 22:44:06 -0000 On 28-Jun-21 19:00, Eliot Lear wrote: > Hi, >=20 > On 25.06.21 23:42, Brian E Carpenter wrote: >> Yes, you're correct; so the IESG and IRSG should each pick >> a regular participant, but presumably a deputy could attend >> if necessary.=20 >=20 >=20 > Here is what the text says: >=20 > =C2=A0=C2=A0 The voting members of the RSAB shall be as follows: >=20 > =C2=A0=C2=A0 o=C2=A0 One delegate representing the IETF stream, appoint= ed by the IESG >=20 > =C2=A0=C2=A0 o=C2=A0 One delegate representing the IAB stream, appointe= d by the IAB >=20 > =C2=A0=C2=A0 o=C2=A0 The IRTF Chair, representing the IRTF stream >=20 > =C2=A0=C2=A0 o=C2=A0 The Independent Submissions Editor [RFC8730] >=20 > =C2=A0=C2=A0 o=C2=A0 The RFC Series Editor/Advisor >=20 > This means that the text in the draft is aligned with reality.=C2=A0 My=20 suggestion is that we be explicit about term duration for the IESG and IA= B members, and whether they can be replaced mid term.=C2=A0 The issue wit= h replacing someone mid term is that it takes a while for someone to lear= n the job. >=20 > So maybe something like this: >=20 > NEW: >=20 > "The IAB and IESG delegates shall serve for one year renewable term= s.=C2=A0 Should a delegate become unavailable, the appointing body MAY re= place that individual to complete the term." >=20 > This allows transitions to align with any membership changes within tho= se bodies. Yes, that works for me. I think the language should also allow for one-of= f replacements if someone is off sick or whatever. "Temporary replacements MAY be made in case of sickness etc." Brian Brian From nobody Mon Jun 28 15:47:38 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C953A19B6 for ; Mon, 28 Jun 2021 15:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 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.338, 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 XlLhhzjN7BoC for ; Mon, 28 Jun 2021 15:47:33 -0700 (PDT) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 06BD13A19BE for ; Mon, 28 Jun 2021 15:47:32 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id ce18-20020a17090aff12b0290170a3e3eb07so1126149pjb.1 for ; Mon, 28 Jun 2021 15:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=iqwvt19nW/lLLom40sX7sbZCyOh2LKV5v1DlX/aTf0c=; b=s6Aa3yPcGfKG6PUFyGsD5ol6SKxkd022e25weeVPv6AgplayR07qCu0NRsmvkyHj0X XJ76xZve9boEQOX0mDM2Bm7T2qkiA0bd+pWkHyRr/pIfKZxDfdUqElooP3q65GYMjBgK nO1YpzxminhLo+S0ecJmKcM6d74UqQSIaaltzhXB2O0ivBxnlRb+l0+dd7Wge90Sd6Di I94xE22Wkpxcc/UGPUxZPQMfO/OdSqItAE+bxVUjaKWxVZJ79PMEFbr3mD4ElZQLMIhY xj1HPlJ7b6Mnxr98oz0V9LoX0BuirLq/HgVi9bAFSMAyPJHQMfnSwaP+ojcfHd7OZ0xm cHjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=iqwvt19nW/lLLom40sX7sbZCyOh2LKV5v1DlX/aTf0c=; b=o7GUsAIoVAiGmSj2OiDJZ4rsWPPkcZ11kOrSd1tB7nriU6tl4XNzHWKfrA5h5KNzD8 rMYOFE4EV1U3nZ+jr+EMwo5rEvhSZX6okB1KTZJ+pGvHURHykU9HttXwILTHrbhbhbcO CRDCVcfKEd8fanTldpjJVjsVIJdbg+cBq6cgRqGV4fOK/phmFfkTHDm4to9lcyHd4qb1 70Qa0dZsRj3pxz2B8xc6oERwm2hL64sO0Om5zICZA1mt1qKC0wtj1ls1GXIsig53EK1l 4AHT2Im+ZS+yuMaGPcmvTLyGY6neABk00Wh9H0F4S/IrNgJIo43DrDXsIO7b/uMUPmbX 1dNQ== X-Gm-Message-State: AOAM532lc0wwzJyNH7t+m4AwKpdjFza4vHfwMMBbcInXuKYhhHbj3SPM ej4wHgRg2N+DynueVnSXwlZb4malHG8fFA== X-Google-Smtp-Source: ABdhPJzBgSEhm1bYmvDtv4XbVy5p0cb0/mCGHzZ5X71HgNwM7Odknbzvd06TbejDbYyky/QyimykMQ== X-Received: by 2002:a17:902:6902:b029:106:50e3:b2db with SMTP id j2-20020a1709026902b029010650e3b2dbmr24664664plk.35.1624920451565; Mon, 28 Jun 2021 15:47:31 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id ga1sm1195415pjb.43.2021.06.28.15.47.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Jun 2021 15:47:30 -0700 (PDT) To: adrian@olddog.co.uk, 'Eliot Lear' , rfced-future@iab.org References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk> From: Brian E Carpenter Message-ID: Date: Tue, 29 Jun 2021 10:47:26 +1200 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: <112801d76c11$1c9d1760$55d74620$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 22:47:38 -0000 On 28-Jun-21 23:31, Adrian Farrel wrote: > Yeah, I can live with that. Ditto. > Failure to act is always a tricksy one. I think you have it covered. Yes. Let us not forget that the first ever formal appeal in the IETF was an appeal against IESG inaction. Brian > > A > > -----Original Message----- > From: Eliot Lear > Sent: 28 June 2021 08:33 > To: adrian@olddog.co.uk; rfced-future@iab.org > Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) > > Hi Adrian, > > On 22.06.21 17:10, Adrian Farrel wrote: >> I completely agree with the sentiment, but I think the wording may have issues. >> >> What the proposal does is say what can be done "if there are concerns about the process followed by the RSWG." It does not say (but I think it is meant to imply) that the content of the decisions cannot be appealed. >> >> The "should" is also slightly ambiguous. >> And "any action" presumably means the action being appealed. >> >> I would... >> >> Decisions of the RSWG can only be appealed on grounds of failure to follow the correct process. Such an appeal must be made to the RSAB within 30 days of the action being appealed. The RSAB will then decide whether the process was followed correctly. > > One of the cases we were trying to cover was inaction of the chairs, > such as their refusal either to call a question or declare [lack of] > consensus. Thus the wording as you saw it. This leads to an > interesting question: when does the 30 day clock start? Also, I think > the intent was to provide direction to the chairs in the case of an > appeal being upheld. > > With all of this in mind, I propose a bit of a merge: > >> Decisions of the RSWG can only be appealed on grounds of failure to >> follow the correct process. Appeals should be made within 30 days of >> any action, or in the case of failure to act, of notice having been >> given to the RSWG. The RSAB will then decide if the process was >> followed and will direct RSWG chairs as to what procedural actions are >> required. > > Does this make sense? > > Eliot > >> >> Cheers, >> Adrian >> >> -----Original Message----- >> From: Rfced-future On Behalf Of Eliot Lear >> Sent: 22 June 2021 15:38 >> To: rfced-future@iab.org >> Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) >> >> The following text was proposed to address appeals of the RSWG: >> >>> Appeals of RSWG decisions can be made to the RSAB if there are >>> concerns about the process followed by the RSWG. Appeals should be >>> made within 30 days of any action. The RSAB then decides if the >>> process has been followed. >> Please raise concerns by 6 July if you have any. >> >> Eliot >> >> >> > > From nobody Mon Jun 28 21:33:50 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D5F3A244A for ; Mon, 28 Jun 2021 21:33:46 -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, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 gDGD47GLvkba for ; Mon, 28 Jun 2021 21:33:44 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 8E28D3A244D for ; Mon, 28 Jun 2021 21:33:44 -0700 (PDT) From: Jay Daley Content-Type: multipart/alternative; boundary="Apple-Mail=_9AF597BC-607D-46B7-84EB-74D27FBA6604" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Message-Id: <755F348B-79E0-46AF-950F-0EA1AC6CF043@ietf.org> References: To: rfced-future@iab.org Date: Tue, 29 Jun 2021 16:33:44 +1200 X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: [Rfced-future] Fwd: RFC Production Center contract extended until end of 2022 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 04:33:47 -0000 --Apple-Mail=_9AF597BC-607D-46B7-84EB-74D27FBA6604 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI > Begin forwarded message: >=20 > From: IETF Executive Director > Subject: RFC Production Center contract extended until end of 2022 > Date: 29 June 2021 at 2:00:11 PM NZST > To: IETF Announcement List > Reply-To: admin-discuss@ietf.org >=20 > The IETF Administration LLC has extended [1] the contract for the RFC = Production Center with Association Management Solutions for one year = until the end of 2022. This contract had previously been awarded and = twice extended to a total of six years, and would normally have been = re-tendered after that time. However, it is expected that major = changes will need to be made to the contract to implement the output of = the RFC Editor Future Program and this extra year provides for that = without additional disruption to the service. >=20 > Please feel free to contact me directly if you have any questions. >=20 > [1] = https://www.ietf.org/media/documents/ams-rpc-fourth-amendment-extension-ju= n-2021_REDACTED.pdf >=20 > --=20 > Jay Daley > IETF Executive Director > exec-director@ietf.org >=20 >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce >=20 --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_9AF597BC-607D-46B7-84EB-74D27FBA6604 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI

Begin forwarded message:

From: = IETF Executive Director <exec-director@ietf.org>
Subject: = RFC Production = Center contract extended until end of 2022
Date: = 29 June 2021 at 2:00:11 PM = NZST
To: = IETF Announcement List <ietf-announce@ietf.org>
Reply-To: = admin-discuss@ietf.org

The IETF Administration LLC = has extended [1] the contract for the RFC Production Center with = Association Management Solutions for one year until the end of 2022. =  This contract had previously been awarded and twice extended to a = total of six years, and would normally have been re-tendered after that = time.   However, it is expected that major changes will need = to be made to the contract to implement the output of the RFC Editor = Future Program and this extra year provides for that without additional = disruption to the service.

Please feel free = to contact me directly if you have any questions.

[1]  https://www.ietf.org/media/documents/ams-rpc-fourth-amendment-e= xtension-jun-2021_REDACTED.pdf

--
Jay Daley
IETF Executive Director
exec-director@ietf.org



_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


-- 
Jay Daley
IETF = Executive Director
jay@ietf.org

= --Apple-Mail=_9AF597BC-607D-46B7-84EB-74D27FBA6604-- From nobody Mon Jun 28 22:41:59 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2474B3A265C for ; Mon, 28 Jun 2021 22:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.227 X-Spam-Level: X-Spam-Status: No, score=-1.227 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, NICE_REPLY_A=-0.338, 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 8k6qWrPa3eFo for ; Mon, 28 Jun 2021 22:41:48 -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 3B4593A265A for ; Mon, 28 Jun 2021 22:41:47 -0700 (PDT) Received: from [10.61.144.46] ([173.38.220.44]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15T5fZ05048910 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 29 Jun 2021 07:41:36 +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=1624945300; bh=8zXzjWXSlOezD4tkBP+SD+DcboeoI63oyhU78UmZ5Sk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=dUZNNry/iDzDX3PDggNuZ8GOZAD49dt4HBJ+IryuJg1q6oJPjlOraYVaHt3/oztys 1jZsNoKoJY33XQSt21CZox5FSgO8vQrdJhhMlyJ6y9ocZTbF/D/OcOnHcJsZAC3DhM rhvP8pU9p/fSWHZZWoF+A9AywtSVks5NPv5JqwOI= To: Brian E Carpenter , adrian@olddog.co.uk, rfced-future@iab.org References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk> From: Eliot Lear Message-ID: <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch> Date: Tue, 29 Jun 2021 07:41:24 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fuYToCgVYxY6nqYM52gqEYNXXDf2WGBdk" Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 05:41:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fuYToCgVYxY6nqYM52gqEYNXXDf2WGBdk Content-Type: multipart/mixed; boundary="vCkAdxVaiFgdwE8hf3a0vGtQWAoqgejCg"; protected-headers="v1" From: Eliot Lear To: Brian E Carpenter , adrian@olddog.co.uk, rfced-future@iab.org Message-ID: <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch> Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk> In-Reply-To: --vCkAdxVaiFgdwE8hf3a0vGtQWAoqgejCg Content-Type: multipart/alternative; boundary="------------9A62398C38ECCA48D71E024F" Content-Language: en-US This is a multi-part message in MIME format. --------------9A62398C38ECCA48D71E024F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Ok.=C2=A0 Then the text as it stands is as follows: Decisions of the RSWG can only be appealed on grounds of failure to follow the correct process. Appeals should be made within 30 days of any action, or in the case of failure to act, of notice having been given to the RSWG. The RSAB will then decide if the process was followed and will direct RSWG chairs as to what procedural actions ar= e required. Any concerns?=C2=A0 Please respond by the 6th. Eliot On 29.06.21 00:47, Brian E Carpenter wrote: > On 28-Jun-21 23:31, Adrian Farrel wrote: >> Yeah, I can live with that. > Ditto. > >> Failure to act is always a tricksy one. I think you have it covered. > Yes. Let us not forget that the first ever formal appeal in the IETF > was an appeal against IESG inaction. > > Brian > >> A >> >> -----Original Message----- >> From: Eliot Lear >> Sent: 28 June 2021 08:33 >> To: adrian@olddog.co.uk; rfced-future@iab.org >> Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) >> >> Hi Adrian, >> >> On 22.06.21 17:10, Adrian Farrel wrote: >>> I completely agree with the sentiment, but I think the wording may ha= ve issues. >>> >>> What the proposal does is say what can be done "if there are concerns= about the process followed by the RSWG." It does not say (but I think it= is meant to imply) that the content of the decisions cannot be appealed.= >>> >>> The "should" is also slightly ambiguous. >>> And "any action" presumably means the action being appealed. >>> >>> I would... >>> >>> Decisions of the RSWG can only be appealed on grounds of failure to f= ollow the correct process. Such an appeal must be made to the RSAB within= 30 days of the action being appealed. The RSAB will then decide whether = the process was followed correctly. >> One of the cases we were trying to cover was inaction of the chairs, >> such as their refusal either to call a question or declare [lack of] >> consensus. Thus the wording as you saw it. This leads to an >> interesting question: when does the 30 day clock start? Also, I think= >> the intent was to provide direction to the chairs in the case of an >> appeal being upheld. >> >> With all of this in mind, I propose a bit of a merge: >> >>> Decisions of the RSWG can only be appealed on grounds of failure to >>> follow the correct process. Appeals should be made within 30 days of >>> any action, or in the case of failure to act, of notice having been >>> given to the RSWG. The RSAB will then decide if the process was >>> followed and will direct RSWG chairs as to what procedural actions ar= e >>> required. >> Does this make sense? >> >> Eliot >> >>> Cheers, >>> Adrian >>> >>> -----Original Message----- >>> From: Rfced-future On Behalf Of Eliot = Lear >>> Sent: 22 June 2021 15:38 >>> To: rfced-future@iab.org >>> Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG) >>> >>> The following text was proposed to address appeals of the RSWG: >>> >>>> Appeals of RSWG decisions can be made to the RSAB if there are >>>> concerns about the process followed by the RSWG. Appeals should be >>>> made within 30 days of any action. The RSAB then decides if the >>>> process has been followed. >>> Please raise concerns by 6 July if you have any. >>> >>> Eliot >>> >>> >>> >> --------------9A62398C38ECCA48D71E024F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Ok.=C2=A0 Then the text as it stands is as follows:

Decisions of the RSWG can on=
ly be appealed on grounds of failure to=20
follow the correct process. Appeals should be made within 30 days of=20
any action, or in the case of failure to act, of notice having been=20
given to the RSWG. The RSAB will then decide if the process was=20
followed and will direct RSWG chairs as to what procedural actions are=20
required.

Any concerns?=C2=A0 Please respond by the 6th.

Eliot

On 29.06.21 00:47, Brian E Carpenter wrote:
On 28-Jun-21 23:31, Adrian F=
arrel wrote:

Yeah, I can live with that=
=2E

Ditto.


Failure to act is always a=
 tricksy one. I think you have it covered.

Yes. Let us not forget that the first ever formal appeal in the IETF
was an appeal against IESG inaction.

   Brian


A

-----Original Message-----
From: Eliot Lear <lear@lear.ch>=20
Sent: 28 June 2021 08:33
To: adrian@olddog.co.uk; rfced-future@iab.org
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)

Hi Adrian,

On 22.06.21 17:10, Adrian Farrel wrote:

I completely agree with =
the sentiment, but I think the wording may have issues.

What the proposal does is say what can be done "if there are concerns abo=
ut the process followed by the RSWG." It does not say (but I think it is =
meant to imply) that the content of the decisions cannot be appealed.

The "should" is also slightly ambiguous.
And "any action" presumably means the action being appealed.

I would...

Decisions of the RSWG can only be appealed on grounds of failure to follo=
w the correct process. Such an appeal must be made to the RSAB within 30 =
days of the action being appealed. The RSAB will then decide whether the =
process was followed correctly.

One of the cases we were trying to cover was inaction of the chairs,=20
such as their refusal either to call a question or declare [lack of]=20
consensus.  Thus the wording as you saw it.  This leads to an=20
interesting question: when does the 30 day clock start? Also,  I think=20
the intent was to provide direction to the chairs in the case of an=20
appeal being upheld.

With all of this in mind, I propose a bit of a merge:


Decisions of the RSWG ca=
n only be appealed on grounds of failure to=20
follow the correct process. Appeals should be made within 30 days of=20
any action, or in the case of failure to act, of notice having been=20
given to the RSWG. The RSAB will then decide if the process was=20
followed and will direct RSWG chairs as to what procedural actions are=20
required.

Does this make sense?

Eliot


Cheers,
Adrian

-----Original Message-----
From: Rfced-future <rfced-future-bounces@iab.org> On Beh=
alf Of Eliot Lear
Sent: 22 June 2021 15:38
To: rfced-future@iab.org
Subject: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)

The following text was proposed to address appeals of the RSWG:


Appeals of RSWG decisi=
ons can be made to the RSAB if there are
concerns about the process followed by the RSWG. Appeals should be
made within 30 days of any action. The RSAB then decides if the
process has been followed.

Please raise concerns by=
 6 July if you have any.

Eliot







    

  


--------------9A62398C38ECCA48D71E024F--

--vCkAdxVaiFgdwE8hf3a0vGtQWAoqgejCg--

--fuYToCgVYxY6nqYM52gqEYNXXDf2WGBdk
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDasoUFAwAAAAAACgkQh7ZrRtnSejO5
tggApWzXVzSK+9i9yGJ9T8GYTa3cHpTiYKRLbjlUtsLOkl8r8X+4vfboyvuSAr0rey/2YZdwGvUu
SaqVKN19PJWPx9kMD+c9nWOKnzTzHEraQ8Z+TrsHl3ZLCu9IrZI+Pnp49A+obsLb3HRs6p/fGllw
hIpqZRGItDHzmXEol9O2/tW7521lXWHXFw10auSz3Bcpj6x01ng7M+Qik6qTA4rMFPHq1qOhjXKu
scB2Jom/jg2gDC9lTIUv02GwZIq9MGQTOsNTmGAUNZBG6FHcUQHMRfcqb4+XX1SNm7+RMpPm+EvK
1eeToBOwkpAW3gOv5q5md+0Ic8hv0oVgMDnzwVdOTw==
=en97
-----END PGP SIGNATURE-----

--fuYToCgVYxY6nqYM52gqEYNXXDf2WGBdk--


From nobody Mon Jun 28 22:54:43 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA5A3A26BC for ; Mon, 28 Jun 2021 22:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level: 
X-Spam-Status: No, score=-2.09 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_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 LfHXIAV6AfqG for ; Mon, 28 Jun 2021 22:54:32 -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 78E993A26BA for ; Mon, 28 Jun 2021 22:54:32 -0700 (PDT)
Received: from [10.61.144.46] ([173.38.220.44]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15T5sSn6048987 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 29 Jun 2021 07:54:29 +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=1624946069; bh=8ZUCoc4++KkGhwK4gZ5IrnLc9lNKGvw/7ZAg16cGMoQ=; h=To:From:Subject:Date:From; b=wRuULwXh47QHpLpMf0gfiyBAJnvyXN7I+nsHIok49S8y9BQwVVkFMallaobO5in5M 1C/hFcA2nHZ+/YpsD7ZLHCux4gh8kq56jgaw2Plu4AWJQoCx706PvTxMzJ8ecIAM2y D27ChC4u7F9FJsJUDNgqT1/4NUm5KCVwxIXomUs8=
To: rfced-future@iab.org
From: Eliot Lear 
Message-ID: 
Date: Tue, 29 Jun 2021 07:54:28 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qWz6IiiCUgPHWlMFmAU12nQaZBqozJRiZ"
Archived-At: 
Subject: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jun 2021 05:54:41 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--qWz6IiiCUgPHWlMFmAU12nQaZBqozJRiZ
Content-Type: multipart/mixed; boundary="9ZXlkySs6netyS4vhVEA6EvOpOB9KtUUf";
 protected-headers="v1"
From: Eliot Lear 
To: rfced-future@iab.org
Message-ID: 
Subject: Issue 38: Delegates for RSAB members

--9ZXlkySs6netyS4vhVEA6EvOpOB9KtUUf
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US


 =C2=A0Martin Thomson raised an issue that the delegates should come from=
 the=20
bodies themselves.=C2=A0 He wrote the following:

> The current document specifically names the chairs of the IETF, IAB,=20
> and IRTF as members of the board. This is unnecessary and goes against =

> efforts to distribute critical functions in these bodies, for the IESG =

> and IAB in particular. The board should instead be composed of a=20
> delegate from each stream, who is empowered to act for that stream.=20
> This might be the chair, but it does not need to be.
>
This part of the issue is resolved in current text (see below).
>
> However, it would be reasonable for the group to insist that the=20
> appointment is made from the IESG or IAB, excluding any ex officio=20
> positions in those bodies (which would rule out the IAB chair as=20
> representative from the IESG). That would be done on the basis that=20
> appointees to these roles are answerable to the community via the=20
> NomCom in addition to any accountability they have to their stream=20
> management. That would mean that the ISE and IRTF chair are stuck with =

> the RSAB position, having no pool to draw on.
>
The current text reads:

> =C2=A0=C2=A0 The voting members of the RSAB shall be as follows:
>
> =C2=A0=C2=A0 o=C2=A0 One delegate representing the IETF stream, appoint=
ed by the IESG
>
> =C2=A0=C2=A0 o=C2=A0 One delegate representing the IAB stream, appointe=
d by the IAB
>
> =C2=A0=C2=A0 o=C2=A0 The IRTF Chair, representing the IRTF stream
>
> =C2=A0=C2=A0 o=C2=A0 The Independent Submissions Editor [RFC8730]
>
> =C2=A0=C2=A0 o=C2=A0 The RFC Series Editor/Advisor

We seem to already like the following text as an addition:

> The IAB and IESG delegates shall serve for one year renewable terms.=C2=
=A0 Should a delegate become unavailable, the appointing body MAY replace=
 that individual to complete the term.

We could also add the following, to address Martin's point:

> The IAB and IESG delegates MUST themselves be appointed by the NOMCOM t=
o their respective bodies.  They shall bserve for one year renewable term=
s.=C2=A0 Should a delegate become unavailable, the appointing body MAY re=
place that individual to complete the term.

Comments?=C2=A0 For?=C2=A0 Against?=C2=A0 Wordsmith?

Eliot



--9ZXlkySs6netyS4vhVEA6EvOpOB9KtUUf--

--qWz6IiiCUgPHWlMFmAU12nQaZBqozJRiZ
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDatZQFAwAAAAAACgkQh7ZrRtnSejMz
aAgAh1CT18VWbq5D4ssDHt4/HRLcaFS7yZo2sXeIlkz5CV9k7PJgKfQ6HvLRj+MVyDqlc+O01fay
ENIghbaKtHMxpmKXHcfLS0KvBPqtqEDWTOpJaulpTTHjEmVApGkb2x1vYfTeg6DAu7/ye3rGcRFd
CTIeACGNvnmaNujyKJ7I4XBfaXClcvIZ3Sp+OSKWWz48q357Z7/ssxWKClt5H1fGl+dzLKyW7Z5a
MRGHDoc8hwoutyt5RFSqLfT5n/Grgub4/UPAKj+oZ+msSRtv/fn7Y9uVpyPj19SMA/KJ0CR4hFSo
h3g0883QQ11v/F+FaBtuMa5FaCYBo5Ac43JfXuNE+A==
=Jp+0
-----END PGP SIGNATURE-----

--qWz6IiiCUgPHWlMFmAU12nQaZBqozJRiZ--


From nobody Mon Jun 28 22:57:21 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A57A3A26CC for ; Mon, 28 Jun 2021 22:57:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.428
X-Spam-Level: 
X-Spam-Status: No, score=-2.428 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, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 5k1UULhcgwXH for ; Mon, 28 Jun 2021 22:57:14 -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 A4F713A26CB for ; Mon, 28 Jun 2021 22:57:14 -0700 (PDT)
Received: from [10.61.144.46] ([173.38.220.44]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15T5vBa0049009 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 29 Jun 2021 07:57:12 +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=1624946232; bh=JM5n2xPo4t5rye55w3ATpeTqQ7Uz95Hy9EvVE+r/qdw=; h=Subject:From:To:References:Date:In-Reply-To:From; b=sLa20qzg61yyuvu6pqn50U/o8KhO9ajfrsG/M2jVvr0G2saZVUOx3hJz/LkehM2M4 wHY75yZsSy51x9gj9ZpiNPnGYSm1TzgPbUpR/IT9RxmArvtW5OjokIZBPtNoDdAK7g pGhLMkjRaSLOQ41H8aACxcZEosKNemUGCohT1MT4=
From: Eliot Lear 
To: rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>
Message-ID: <16e2fc06-1f25-13d3-d99d-e0b3aaab2259@lear.ch>
Date: Tue, 29 Jun 2021 07:57:10 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cn3grnlSV4sZtcNftwFlWq3JtToiopHPF"
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jun 2021 05:57:19 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--cn3grnlSV4sZtcNftwFlWq3JtToiopHPF
Content-Type: multipart/mixed; boundary="7rSYvkZxZ2n87xww2OrqryB2b9AYrV0Jl";
 protected-headers="v1"
From: Eliot Lear 
To: rfced-future@iab.org
Message-ID: <16e2fc06-1f25-13d3-d99d-e0b3aaab2259@lear.ch>
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch>
 <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk>
 <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch>
 <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>
 
 <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>
In-Reply-To: <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch>

--7rSYvkZxZ2n87xww2OrqryB2b9AYrV0Jl
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

This text would cover not only issue 16, but also issue 70.

On 29.06.21 07:41, Eliot Lear wrote:
> Decisions of the RSWG can only be appealed on grounds of failure to
> follow the correct process. Appeals should be made within 30 days of
> any action, or in the case of failure to act, of notice having been
> given to the RSWG. The RSAB will then decide if the process was
> followed and will direct RSWG chairs as to what procedural actions are
> required.


--7rSYvkZxZ2n87xww2OrqryB2b9AYrV0Jl--

--cn3grnlSV4sZtcNftwFlWq3JtToiopHPF
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDatjYFAwAAAAAACgkQh7ZrRtnSejP7
3wgAmnltnf8GbnxVdeRpiBTmXaM3vUPCie4KeVcJ/+riNfjUkO/XZc6yIuR9DrJ921GWBk0ufhBt
rpPcgAtutkLe2jwSz/3NuK9bVk/b5LX8NPqJxoUyhkm0C/p1KB2vEba/utyPXakA95uAeApiwGCt
wfrQgOMGMv3G4fK1kanT7zs2uGpZM9L4PnuEMWA6ipfKDO24J9dmy1iXaymgERKu/DROXGIeL5EL
75PSLi2UBfTXnWSbn0qxG40wqeU8+u2LAl1g2T1YxgYsJXALfr7FwwdoI8tBbRZgGNjcV48Aosya
unrOUoSNZBahL4wyAhlOPc/C66GqvJozWhgo5E3TiA==
=r9la
-----END PGP SIGNATURE-----

--cn3grnlSV4sZtcNftwFlWq3JtToiopHPF--


From nobody Mon Jun 28 23:11:13 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CA93A2723 for ; Mon, 28 Jun 2021 23:11:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level: 
X-Spam-Status: No, score=-2.089 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_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 UOrp0HPlVp94 for ; Mon, 28 Jun 2021 23:11:07 -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 EED653A2721 for ; Mon, 28 Jun 2021 23:11:06 -0700 (PDT)
Received: from [10.61.144.46] ([173.38.220.44]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15T6B1Ur049186 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 29 Jun 2021 08:11:02 +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=1624947062; bh=h5hgM1cZvcOTF6UjyFfVaFKPrUlYAwHFkI5bqrdvPZU=; h=To:From:Subject:Date:From; b=GW2qaLBUZB+2GysLo29MCEe+OcL0tfsR8ogRhWrwtAv/5SDuYIIId6ATBzJNMrAAd lxtphZwag2pp0oGpfvGs1EYWzsAKj5SkSIibI6XZKcmBF4oMUgOZ0lv9Ok59i7OirE USeapBNGiPUth41Kox/zWghyubu0nVHMCjtcBM7k=
To: rfced-future@iab.org
From: Eliot Lear 
Message-ID: <4834a4a0-c3c9-1866-931b-d90ada0d0e7e@lear.ch>
Date: Tue, 29 Jun 2021 08:11:00 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vqFU2912fOuNhpsY36NB7aiKncggmOINY"
Archived-At: 
Subject: [Rfced-future] Issue 69: Who can adopt WG items?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jun 2021 06:11:12 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--vqFU2912fOuNhpsY36NB7aiKncggmOINY
Content-Type: multipart/mixed; boundary="oQWE8mAmlzile1ZHskgQPZAgMIC1bSTa9";
 protected-headers="v1"
From: Eliot Lear 
To: rfced-future@iab.org
Message-ID: <4834a4a0-c3c9-1866-931b-d90ada0d0e7e@lear.ch>
Subject: Issue 69: Who can adopt WG items?

--oQWE8mAmlzile1ZHskgQPZAgMIC1bSTa9
Content-Type: multipart/alternative;
 boundary="------------87B095011B81E5FDF826BDBB"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------87B095011B81E5FDF826BDBB
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

EKR raised the following question in Issue 69:

>  2. If there is sufficient interest in the proposal, RSWG may adopt
>     the proposal as a draft proposal of the RSWG, much the same way a
>     working group of the IETF or IRTF would.
>
> As has been pointed out previously, 2418 is a bit vague on how=20
> adoption happens. Do we want to be vague here?
>
2418 is *intentionally* vague about this because of the wide variety of=20
circumstances that can arise, and the need for chairs to have some=20
flexibility.=C2=A0 Also, that document was written 22 years ago, and we h=
ad=20
considerably less experience than we do now.=C2=A0 Still, that flexibilit=
y=20
might prove necessary =E2=80=93 or not.

In any event, for those who think we *should* be more specific, we need=20
proposed text.=C2=A0 Otherwise perhaps this is one can be deferred until =

there is some operational experience?=C2=A0 This also ties to the matter =
of=20
possibly appealing lack of action on the part of the chairs.=C2=A0 The RS=
AB=20
could certainly say to chairs that they were unreasonable either in=20
adopting or not adopting something.

Comments?

Eliot



--------------87B095011B81E5FDF826BDBB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  

    
  
  
    
EKR raised the following question in Issue 69:

    

      

        
    
          
  1. If there is sufficient interest in the proposal, RSWG may
            adopt
    
            the proposal as a draft proposal of the RSWG, much the same
            way a
    
            working group of the IETF or IRTF would.
    2. 
        

        
As has been pointed out previously, 2418 is a bit vague on
          how adoption happens. Do we want to be vague here?

      

    

    
2418 is intentionally vague about this because of the
      wide variety of circumstances that can arise, and the need for
      chairs to have some flexibility.=C2=A0 Also, that document was writ=
ten
      22 years ago, and we had considerably less experience than we do
      now.=C2=A0 Still, that flexibility might prove necessary =E2=80=93 =
or not.

    
In any event, for those who think we should be more
      specific, we need proposed text.=C2=A0 Otherwise perhaps this is on=
e
      can be deferred until there is some operational experience?=C2=A0 T=
his
      also ties to the matter of possibly appealing lack of action on
      the part of the chairs.=C2=A0 The RSAB could certainly say to chair=
s
      that they were unreasonable either in adopting or not adopting
      something.

    
Comments?

    
Eliot

    

    


    

  


--------------87B095011B81E5FDF826BDBB--

--oQWE8mAmlzile1ZHskgQPZAgMIC1bSTa9--

--vqFU2912fOuNhpsY36NB7aiKncggmOINY
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDauXQFAwAAAAAACgkQh7ZrRtnSejNc
JQgAnnx4jTyeoqC7FEQ5tsdZrRM/NOtNOxKfgNl/+RQijOAIcwjs+D9PxznGDiZ+Bz/lvQzEU0gI
mYUhKLhgpSlJ3N/Cd1Ke8IdFx8+XXC140I4nqP6wWRW353APH+XOsj7Euf2cNAHOfrVic7me6WtL
96/Fb6+lfSke60AfcfmrBho5rdWCBTG1RMyX0Nl9WadeQolTGA/TunQieWMiKoXS21nc84ziKTnF
UmJDA3qKh17Ct8qxkDtng40nKNNG44FyMcXiWR1revb1oOE49jz//yaKHu9Vi870vY4ITZeBZqnK
ApnSYsKH1fsfnTMqwTL33z7ZdYBqamzZMX7jCvJXIQ==
=JRRS
-----END PGP SIGNATURE-----

--vqFU2912fOuNhpsY36NB7aiKncggmOINY--


From nobody Mon Jun 28 23:35:54 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B663A27CE; Mon, 28 Jun 2021 23:35:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level: 
X-Spam-Status: No, score=-2.427 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, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 sXIObWd1uKiG; Mon, 28 Jun 2021 23:35:48 -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 C50DA3A27CD; Mon, 28 Jun 2021 23:35:47 -0700 (PDT)
Received: from [10.61.144.46] ([173.38.220.44]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15T6Zcfm049331 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 29 Jun 2021 08:35:40 +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=1624948542; bh=/DErF7zbR7rytdZf4Q+BtFN1NrJQ8UZ1nnNhVPNKC3E=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=FPI0RtbW/phET0JqO63UefH7IbdMs7YNVd22rXsVqOfJv3IkCU5yVv5OGfV4Qhgmw cgdDxe/JwXqRtIPrLndHERIK78csir9rnSZbbd8AKKbEb0ZuSivUlmEDyIzpfy6yx1 DbQqtQf2zEaz6NaZLMc7vEV1qDNLEc3wLE12GsRQ=
To: Jay Daley , Martin Thomson 
Cc: rfced-future@iab.org
References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> <09ba8d20-0793-4068-9857-04350b6e64ee@www.fastmail.com> <6E47DC4E-E798-4216-8C81-F80A38E1DD16@ietf.org>
From: Eliot Lear 
Message-ID: 
Date: Tue, 29 Jun 2021 08:35:35 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <6E47DC4E-E798-4216-8C81-F80A38E1DD16@ietf.org>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sTWh6FSFwuEdcbNNbqKIWwxaMB6W2K5J8"
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jun 2021 06:35:53 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--sTWh6FSFwuEdcbNNbqKIWwxaMB6W2K5J8
Content-Type: multipart/mixed; boundary="zIaM58NCr9jbIT9sqS47MmJhU99QEiJ4B";
 protected-headers="v1"
From: Eliot Lear 
To: Jay Daley , Martin Thomson 
Cc: rfced-future@iab.org
Message-ID: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org>
 <09ba8d20-0793-4068-9857-04350b6e64ee@www.fastmail.com>
 <6E47DC4E-E798-4216-8C81-F80A38E1DD16@ietf.org>
In-Reply-To: <6E47DC4E-E798-4216-8C81-F80A38E1DD16@ietf.org>

--zIaM58NCr9jbIT9sqS47MmJhU99QEiJ4B
Content-Type: multipart/alternative;
 boundary="------------C98DC19EB7F65B5A66B133C9"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------C98DC19EB7F65B5A66B133C9
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Jay, Martin,

Let's go through where we seem to agree first:

I am not hearing any argument about the reordering that Martin proposed, =

and so I think we stand as follows:

> All matters of budget, timetable and impact on its performance
> targets, are between the RPC and IETF LLC.
>
> The RPC shall report regularly to the RSAB, RSWG and broader
> community, on the contents and progress of its work program and any
> key risks or issues affecting it.
> In the event that the RPC is required to make a decision without
> consultation that would normally deserve consultation, or makes a
> decision against the advice of the RSAB then it must notify the
> RSAB.

Then there is the question of a non-voting liaison from the RPC. If=20
there is to be such a person, how does that person get appointed and by=20
whom?=C2=A0 The easiest answer is by the IETF Executive Director.=C2=A0 I=
s that=20
correct?=C2=A0 At some point we need to back up to how we relate all of t=
his=20
to the tooling team.=C2=A0 Is it represented by the same liaison?=C2=A0 I=
s it=20
governed in a similar fashion?

Then comes the trickier part:

> The RPC will develop this program using the strategic direction set by =
the community as input.  The RPC can consult with the RSAB directly, rath=
er than relying on public consultation.  As stream managers, the RSAB can=
 provide input on stream-specific policies or requirements.  The RSAB sho=
uld be able to advise on whether a decision might need to be made by the =
RSWG and what items are currently under discussion in the RSWG.  The RSAB=
 might be able to provide input on how work items on the program are prio=
ritized.
>
> However, I'm concerned that this last item gives considerable power to =
the RSAB.  Setting priority is a very good proxy for setting policy.  As =
stream managers, that is probably fine (hence my suggested tweak), as a b=
ody, that risks undermining the RSWG process: "the WG decided this, but i=
t's silly, so deprioritize its implementation".

This raises questions:

 1. Should there be a frequency by which the RPC reports?=C2=A0 If they'r=
e
    frequent enough, then there is no need to make massive shifts
    without consultation, and we are talking about a pretty focused
    function (i.e., not like an entire government ministry or
    department).=C2=A0=C2=A0 The only real question is whether the RPC sh=
ould seek
    approval/endorsement of its plan.=C2=A0 "Here's what we did, here's h=
ow
    it went, here's what we plan to do over the next XX months/year(s)".
 2. Are we are using the RSAB for regular consultations between stream
    managers and the RPC?=C2=A0 In this case, is the RSAB acting as a gro=
up
    or merely being gathered as stream managers?=C2=A0 If the latter, the=
n
    the RSAB has no formal role.=C2=A0 The RPC is always free to consult =
who
    they want to consult in order to get the job done or to identify
    issues.=C2=A0 Right?

Eliot


--------------C98DC19EB7F65B5A66B133C9
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Jay, Martin,

    
Let's go through where we seem to agree first:

    
I am not hearing any argument about the reordering that Martin
      proposed, and so I think we stand as follows:

    

      

        
All matters of budget, tim=
etable and impact on its performance=20
targets, are between the RPC and IETF LLC.

The RPC shall report regularly to the RSAB, RSWG and broader=20
community, on the contents and progress of its work program and any=20
key risks or issues affecting it. 

      

      

        
In the event that the RPC =
is required to make a decision without=20
consultation that would normally deserve consultation, or makes a=20
decision against the advice of the RSAB then it must notify the=20
RSAB.


      

    

    
Then there is the question of a non-voting liaison from the RPC.=C2=
=A0
      If there is to be such a person, how does that person get
      appointed and by whom?=C2=A0 The easiest answer is by the IETF
      Executive Director.=C2=A0 Is that correct?=C2=A0 At some point we n=
eed to
      back up to how we relate all of this to the tooling team.=C2=A0 Is =
it
      represented by the same liaison?=C2=A0 Is it governed in a similar
      fashion?

    
Then comes the trickier part:

    

      

        
The RPC will develop this =
program using the strategic direction set by the community as input.  The=
 RPC can consult with the RSAB directly, rather than relying on public co=
nsultation.  As stream managers, the RSAB can provide input on stream-spe=
cific policies or requirements.  The RSAB should be able to advise on whe=
ther a decision might need to be made by the RSWG and what items are curr=
ently under discussion in the RSWG.  The RSAB might be able to provide in=
put on how work items on the program are prioritized.

However, I'm concerned that this last item gives considerable power to th=
e RSAB.  Setting priority is a very good proxy for setting policy.  As st=
ream managers, that is probably fine (hence my suggested tweak), as a bod=
y, that risks undermining the RSWG process: "the WG decided this, but it'=
s silly, so deprioritize its implementation".

      

    

    
This raises questions:

    
    
      
  1. Should there be a frequency by which the RPC reports?=C2=A0 If
        they're frequent enough, then there is no need to make massive
        shifts without consultation, and we are talking about a pretty
        focused function (i.e., not like an entire government ministry
        or department).=C2=A0=C2=A0 The only real question is whether the=
 RPC
        should seek approval/endorsement of its plan.=C2=A0 "Here's what =
we
        did, here's how it went, here's what we plan to do over the next
        XX months/year(s)".
    
      
    2. 
      
  2. Are we are using the RSAB for regular consultations between
        stream managers and the RPC?=C2=A0 In this case, is the RSAB acti=
ng
        as a group or merely being gathered as stream managers?=C2=A0 If =
the
        latter, then the RSAB has no formal role.=C2=A0 The RPC is always=

        free to consult who they want to consult in order to get the job
        done or to identify issues.=C2=A0 Right?
    
      
    3. 
    

    
Eliot

    

  


--------------C98DC19EB7F65B5A66B133C9--

--zIaM58NCr9jbIT9sqS47MmJhU99QEiJ4B--

--sTWh6FSFwuEdcbNNbqKIWwxaMB6W2K5J8
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDavzcFAwAAAAAACgkQh7ZrRtnSejPM
RwgAmkUtonm2BsABz0qlrPAZCwL3bTLEut3SozgOjW63K3NrJr0sQc3Bmzb5Z75L7fV2eEw2crSg
6Wb2xCTmCFPDz9QMkuiSdf8eyNAUY00F3NhnT2qU1fCggremyfnknpYMzUK5D2LK17KVyqxIb6/5
cH1sHKb1GpTFJSdRJv5L8417yiPTwZz2LuixTjQ7aLf8mzL/sgml9joEEE3A8+b71oeJVEQMGL+A
fFCfECYA6jWLQg98NP0r71a9ZaRqQJEiFKDsdKZym/0PAfZH0P0dWoLQrnNP0qXgUuud++ZzN+F9
sp1jG0MADekNgk4IOfBwj3DvF8Xoohcqv+Kkr8Emgw==
=lxfc
-----END PGP SIGNATURE-----

--sTWh6FSFwuEdcbNNbqKIWwxaMB6W2K5J8--


From nobody Tue Jun 29 03:16:42 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7163A2E65 for ; Tue, 29 Jun 2021 03:16:39 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=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 xlVJkXBeOr3O; Tue, 29 Jun 2021 03:16:34 -0700 (PDT)
Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 720813A2E63; Tue, 29 Jun 2021 03:16:34 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-A54FFE89-9AF0-45C2-B1E1-3048945B4F7C
Content-Transfer-Encoding: 7bit
From: Jay Daley 
Mime-Version: 1.0 (1.0)
Date: Tue, 29 Jun 2021 22:16:31 +1200
Message-Id: <896D122F-C341-4B1F-9467-48040F691A42@ietf.org>
References: 
Cc: Martin Thomson , rfced-future@iab.org
In-Reply-To: 
To: Eliot Lear 
X-Mailer: iPad Mail (18F72)
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jun 2021 10:16:40 -0000

--Apple-Mail-A54FFE89-9AF0-45C2-B1E1-3048945B4F7C
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> On 29/06/2021, at 6:36 PM, Eliot Lear  wrote:
>=20
> =EF=BB=BF
> Jay, Martin,
>=20
> Let's go through where we seem to agree first:
>=20
> I am not hearing any argument about the reordering that Martin proposed, a=
nd so I think we stand as follows:
>=20
>> All matters of budget, timetable and impact on its performance=20
>> targets, are between the RPC and IETF LLC.
>>=20
>> The RPC shall report regularly to the RSAB, RSWG and broader=20
>> community, on the contents and progress of its work program and any=20
>> key risks or issues affecting it.=20
>> In the event that the RPC is required to make a decision without=20
>> consultation that would normally deserve consultation, or makes a=20
>> decision against the advice of the RSAB then it must notify the=20
>> RSAB.
> Then there is the question of a non-voting liaison from the RPC.  If there=
 is to be such a person, how does that person get appointed and by whom?  Th=
e easiest answer is by the IETF Executive Director.  Is that correct?=20
>=20
To me there are two separate needs here. The IETF Executive Director is a li=
aison to coordinate the overall operational response and ensure that perform=
ance targets and priorities are met - that includes RPC, tools, comms etc.=20=


The question of whether the RPC has a liaison depends on the nature of the R=
PC role that we are still discussing below so I=E2=80=99ll pick that up ther=
e. =20
> At some point we need to back up to how we relate all of this to the tooli=
ng team.  Is it represented by the same liaison?  Is it governed in a simila=
r fashion?
>=20
There=E2=80=99s no need for a specific tools liaison.  The RPC have tools re=
quirements that are discussed direct with the IETF Executive Director (fundi=
ng/contracting) and Tools Team PM (internal/community implementation).  The a=
uthors discuss their tools requirements directly on list.=20
> Then comes the trickier part:
>=20
>> The RPC will develop this program using the strategic direction set by th=
e community as input.  The RPC can consult with the RSAB directly, rather th=
an relying on public consultation.  As stream managers, the RSAB can provide=
 input on stream-specific policies or requirements.  The RSAB should be able=
 to advise on whether a decision might need to be made by the RSWG and what i=
tems are currently under discussion in the RSWG.  The RSAB might be able to p=
rovide input on how work items on the program are prioritized.
>>=20
>> However, I'm concerned that this last item gives considerable power to th=
e RSAB.  Setting priority is a very good proxy for setting policy.  As strea=
m managers, that is probably fine (hence my suggested tweak), as a body, tha=
t risks undermining the RSWG process: "the WG decided this, but it's silly, s=
o deprioritize its implementation".
> This raises questions:
>=20
> Should there be a frequency by which the RPC reports?  If they're frequent=
 enough, then there is no need to make massive shifts without consultation, a=
nd we are talking about a pretty focused function (i.e., not like an entire g=
overnment ministry or department).   The only real question is whether the R=
PC should seek approval/endorsement of its plan.  "Here's what we did, here'=
s how it went, here's what we plan to do over the next XX months/year(s)".
> Are we are using the RSAB for regular consultations between stream manager=
s and the RPC?  In this case, is the RSAB acting as a group or merely being g=
athered as stream managers?  If the latter, then the RSAB has no formal role=
.  The RPC is always free to consult who they want to consult in order to ge=
t the job done or to identify issues.  Right?
So this is where I think Martin and I have two very different visions of the=
 RPC and the answer to all of the above revolves around which vision we move=
 forward with.=20

The current structure has an RSE that collects community requirements, engag=
es with the community as needed, interprets those requirements and delivers a=
 prioritised list to the RPC.  The RSE also reports to the community. The RP=
C certainly picks up plenty of requirements from its engagement with authors=
 but those are fed into the RPC for them to work into their plans.  The chec=
ks and balances to this process are multiple - there is the RSOC overseeing t=
he RSE, the RSE overseeing the RPC and the LLC monitoring both contracts.  T=
he key check here is that the RSE cannot unilaterally decide who they consul=
t and what they consult on.=20

If we switch to a structure where the RPC is responsible to the full communi=
ty then two things happen. First, they take on all of the role of the RSE ab=
ove, which I am concerned is far too much of a change for the RPC.  Second, t=
he only check and balance becomes the LLC, which now monitors the contract, m=
anages performance, agrees the work program with the RPC, takes on the commu=
nity role of ensuring that the RPC consults with the right people and consul=
ts on the right things and the role of ensuring the reporting to the communi=
ty is adequate. I am concerned that is too large a role for the LLC and over=
steps the community line. (Of course there is an alternative that nobody doe=
s some parts of this, but that is significantly worse).=20

The structure I am suggesting inserts the RSAB into the mixture and by doing=
 so both softens the changes to the RPC and spreads the checks and balances.=
 The RSAB takes on the role of advising the RPC on community requirements, p=
riorities, what needs consulting on and who should be consulted. While the R=
PC still makes the final call, we now have some separation of roles. The req=
uirement for the RPC to inform the RSAB where it goes against its advice ens=
ures transparency and adds another check to the process.  The RSWG/RSAB also=
 take on the role of receiving the reports and are implicitly responsible fo=
r addressing the suitability of the reports. The role of the LLC is reduced t=
o contract monitoring and performance management. The LLC doesn=E2=80=99t ta=
ke on any community role but acts as an escalation point for the RSAB/RWSG.=20=


Each of these structures envisions a very different RPC.  If can agree which=
 vision of the RPC we prefer then the answers all fall out from that.=20

Jay

--=20
Jay Daley
IETF Executive Director

>=20
> Eliot

--Apple-Mail-A54FFE89-9AF0-45C2-B1E1-3048945B4F7C
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 29/06/2021, at 6:36 PM, Eliot Lear <lear@lear.ch> wrote:
=

=EF=BB=BF
 =20
    
 =20
 =20
    
Jay, Martin,

    
Let's go through where we seem to agree first:

    
I am not hearing any argument about the reordering that Martin
      proposed, and so I think we stand as follows:

    

      

        
All matters of budget, timeta=
ble and impact on its performance=20
targets, are between the RPC and IETF LLC.

The RPC shall report regularly to the RSAB, RSWG and broader=20
community, on the contents and progress of its work program and any=20
key risks or issues affecting it. 

      

      

        
In the event that the RPC is r=
equired to make a decision without=20
consultation that would normally deserve consultation, or makes a=20
decision against the advice of the RSAB then it must notify the=20
RSAB.


      

    

    
Then there is the question of a non-voting liaison from the RPC. =
;
      If there is to be such a person, how does that person get
      appointed and by whom?  The easiest answer is by the IETF
      Executive Director.  Is that correct?  
To me there are two separate needs here. The IETF Executive Director i=
s a liaison to coordinate the overall operational response and ensure that p=
erformance targets and priorities are met - that includes RPC, tools, comms e=
tc. 

The question of whether the RPC has a lia=
ison depends on the nature of the RPC role that we are still discussing belo=
w so I=E2=80=99ll pick that up there.  
=

At some point we need to
      back up to how we relate all of this to the tooling team.  Is it
      represented by the same liaison?  Is it governed in a similar
      fashion?
There=E2=80=99s no need for a spec=
ific tools liaison.  The RPC have tools requirements that are discussed=
 direct with the IETF Executive Director (funding/contracting) and Tools Tea=
m PM (internal/community implementation).  The authors discuss their to=
ols requirements directly on list. 

    
Then comes the trickier part:

    

      

        
The RPC will develop this pro=
gram using the strategic direction set by the community as input.  The RPC c=
an consult with the RSAB directly, rather than relying on public consultatio=
n.  As stream managers, the RSAB can provide input on stream-specific polici=
es or requirements.  The RSAB should be able to advise on whether a decision=
 might need to be made by the RSWG and what items are currently under discus=
sion in the RSWG.  The RSAB might be able to provide input on how work items=
 on the program are prioritized.

However, I'm concerned that this last item gives considerable power to the R=
SAB.  Setting priority is a very good proxy for setting policy.  As stream m=
anagers, that is probably fine (hence my suggested tweak), as a body, that r=
isks undermining the RSWG process: "the WG decided this, but it's silly, so d=
eprioritize its implementation".

      

    

    
This raises questions:

    
    
      
  1. Should there be a frequency by which the RPC reports?  If
        they're frequent enough, then there is no need to make massive
        shifts without consultation, and we are talking about a pretty
        focused function (i.e., not like an entire government ministry
        or department).   The only real question is whether the RP=
C
        should seek approval/endorsement of its plan.  "Here's what we
        did, here's how it went, here's what we plan to do over the next
        XX months/year(s)".
    
      
    2. 
      
  2. Are we are using the RSAB for regular consultations between
        stream managers and the RPC?  In this case, is the RSAB acting
        as a group or merely being gathered as stream managers?  If the=

        latter, then the RSAB has no formal role.  The RPC is always
        free to consult who they want to consult in order to get the job
        done or to identify issues.  Right?
So this is where I think Martin and I have two very different visi=
ons of the RPC and the answer to all of the above revolves around which visi=
on we move forward with. 

The current structur=
e has an RSE that collects community requirements, engages with the communit=
y as needed, interprets those requirements and delivers a prioritised list t=
o the RPC.  The RSE also reports to the community. The RPC certainly pi=
cks up plenty of requirements from its engagement with authors but those are=
 fed into the RPC for them to work into their plans.  The checks and ba=
lances to this process are multiple - there is the RSOC overseeing the RSE, t=
he RSE overseeing the RPC and the LLC monitoring both contracts.  The k=
ey check here is that the RSE cannot unilaterally decide who they consult an=
d what they consult on. 

If we switch to a str=
ucture where the RPC is responsible to the full community then two things ha=
ppen. First, they take on all of the role of the RSE above, which I am conce=
rned is far too much of a change for the RPC.  Second, the only check a=
nd balance becomes the LLC, which now monitors the contract, manages perform=
ance, agrees the work program with the RPC, takes on the community role of e=
nsuring that the RPC consults with the right people and consults on the righ=
t things and the role of ensuring the reporting to the community is adequate=
. I am concerned that is too large a role for the LLC and oversteps the comm=
unity line. (Of course there is an alternative that nobody does some parts o=
f this, but that is significantly worse). 

The=
 structure I am suggesting inserts the RSAB into the mixture and by doing so=
 both softens the changes to the RPC and spreads the checks and balances. Th=
e RSAB takes on the role of advising the RPC on community requirements, prio=
rities, what needs consulting on and who should be consulted. While the RPC s=
till makes the final call, we now have some separation of roles. The require=
ment for the RPC to inform the RSAB where it goes against its advice ensures=
 transparency and adds another check to the process.  The RSWG/RSAB als=
o take on the role of receiving the reports and are implicitly responsible f=
or addressing the suitability of the reports. The role of the LLC is reduced=
 to contract monitoring and performance management. The LLC doesn=E2=80=99t t=
ake on any community role but acts as an escalation point for the RSAB/RWSG.=
 

Each of these structures envisions a very di=
fferent RPC.  If can agree which vision of the RPC we prefer then the a=
nswers all fall out from that. 

Jay
=

-- 
Jay Daley
IETF Executive Director

  1. 
      
    2. 
    

    
Eliot

    

 =20


=

--Apple-Mail-A54FFE89-9AF0-45C2-B1E1-3048945B4F7C--


From nobody Tue Jun 29 06:04:00 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE3D3A33BE for ; Tue, 29 Jun 2021 06:03:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.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 dbSLWJOiwVsY for ; Tue, 29 Jun 2021 06:03:52 -0700 (PDT)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 BA8023A33BB for ; Tue, 29 Jun 2021 06:03:52 -0700 (PDT)
Received: by mail-il1-x12b.google.com with SMTP id a11so20781812ilf.2 for ; Tue, 29 Jun 2021 06:03:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B5VhFCI9lKykRVxBgjFO8colacgeywSizb5rA3XUs34=; b=IIg1g5ANK5djhRynnGbjZZZls0edGADSUPS0NOdnKn4w060uNL++RrPJR+X/gVEdO/ ewMSlyIibGbgC4/vMzUMF6sdvTSuet8+pndGN1TtAYNffR9fcDU0KAjP6tp1YU+/RXD1 u97WuQKhlmVu+Ol1Mf/aianZBCzag6lqRcFo6e5o4aY0U1JLaxwA3QhvgTtQDE0LnJSb hxpTygCxyhfYICn47bh985j+aD6hT2bDjpiN4ffv0PXx0+GMjQsNU4bQr6qQTWoxSdRo BX/2P5AH1eUAUmEZgstCvDVr8f4bW00WOt3lE018yTrbt6lZ/chTodo3ripZLw/TKqCl +DiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B5VhFCI9lKykRVxBgjFO8colacgeywSizb5rA3XUs34=; b=uRf5Yv7STD4rOhkzSjgx6s3pPvzKl+myyicUo6aqKlbdYFbFfoTh6SnmhN6AlUo/Jf vn+xu3lFy9Bxxe7psSrdVRLzQ/ftEuP6oIrAB53+qUsTKg4rEu/nQyVSkA2LiWt0mNJG C6F8gWoU0LU8wHYWJbzD9lIMuiNPRabAcId+SPQ8NeI279JQsM9vDcxu9cTPQXMTg2bw 4n5YNZiIXqa4kkJz3HABVkUcCjzUrtkr9vVgWOn/kSVu9G/NAw1qomYWdD5iJMN9A8H4 EKcpfWnEXn9Itf27BhDPUWZN7mdMpzZDKh/8AKaIJOjmTpuSDjGYsOg6hF9figiVF+Q1 dw6w==
X-Gm-Message-State: AOAM533+ADaXNRxgGDwF83t2Fm5v/B4NliZG/zlQLU22wX/8KFON6a56 40KnDCNJSANT1Rl5A0a7S4zdrXDrAvbqR0MlW5ZRcPK/LQ5QuQ==
X-Google-Smtp-Source: ABdhPJwpiEJVpyzK1+Q/OoZl56ru8Q9cY8Cpmsotd+OH1nDjSF5xxRdqashQrvBlsBmfVBs1Qb63WHWPyx4uBDW5h4k=
X-Received: by 2002:a92:9509:: with SMTP id y9mr22075261ilh.18.1624971831223;  Tue, 29 Jun 2021 06:03:51 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Eric Rescorla 
Date: Tue, 29 Jun 2021 06:03:14 -0700
Message-ID: 
To: Eliot Lear 
Cc: rfced-future@iab.org
Content-Type: multipart/alternative; boundary="000000000000c53e2505c5e73cb7"
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jun 2021 13:03:58 -0000

--000000000000c53e2505c5e73cb7
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 28, 2021 at 10:54 PM Eliot Lear  wrote:

>
>   Martin Thomson raised an issue that the delegates should come from the
> bodies themselves.  He wrote the following:
>
> > The current document specifically names the chairs of the IETF, IAB,
> > and IRTF as members of the board. This is unnecessary and goes against
> > efforts to distribute critical functions in these bodies, for the IESG
> > and IAB in particular. The board should instead be composed of a
> > delegate from each stream, who is empowered to act for that stream.
> > This might be the chair, but it does not need to be.
> >
> This part of the issue is resolved in current text (see below).
> >
> > However, it would be reasonable for the group to insist that the
> > appointment is made from the IESG or IAB, excluding any ex officio
> > positions in those bodies (which would rule out the IAB chair as
> > representative from the IESG). That would be done on the basis that
> > appointees to these roles are answerable to the community via the
> > NomCom in addition to any accountability they have to their stream
> > management. That would mean that the ISE and IRTF chair are stuck with
> > the RSAB position, having no pool to draw on.
> >
> The current text reads:
>
> >    The voting members of the RSAB shall be as follows:
> >
> >    o  One delegate representing the IETF stream, appointed by the IESG
> >
> >    o  One delegate representing the IAB stream, appointed by the IAB
> >
> >    o  The IRTF Chair, representing the IRTF stream
> >
> >    o  The Independent Submissions Editor [RFC8730]
> >
> >    o  The RFC Series Editor/Advisor
>
> We seem to already like the following text as an addition:
>
> > The IAB and IESG delegates shall serve for one year renewable terms.
> Should a delegate become unavailable, the appointing body MAY replace that
> individual to complete the term.
>
> We could also add the following, to address Martin's point:
>
> > The IAB and IESG delegates MUST themselves be appointed by the NOMCOM to
> their respective bodies.  They shall bserve for one year renewable terms.
> Should a delegate become unavailable, the appointing body MAY replace that
> individual to complete the term.
>
> Comments?  For?  Against?  Wordsmith?
>

This seems generally sound, but the appointing body should be able to
replace them for any reason, not just if they are unavailable.

-Ekr


> Eliot
>
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

--000000000000c53e2505c5e73cb7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Jun 28, 2021 at 10:54 PM Elio=
t Lear <lear@lear.ch> wrote:
<=
/div>


=C2=A0=C2=A0Martin Thomson raised an issue that the delegates should come f=
rom the 

bodies themselves.=C2=A0 He wrote the following:



> The current document specifically names the chairs of the IETF, IAB, <=
br>
> and IRTF as members of the board. This is unnecessary and goes against=
 

> efforts to distribute critical functions in these bodies, for the IESG=
 

> and IAB in particular. The board should instead be composed of a 

> delegate from each stream, who is empowered to act for that stream. 
> This might be the chair, but it does not need to be.

>

This part of the issue is resolved in current text (see below).

>

> However, it would be reasonable for the group to insist that the 

> appointment is made from the IESG or IAB, excluding any ex officio 
> positions in those bodies (which would rule out the IAB chair as 

> representative from the IESG). That would be done on the basis that 
> appointees to these roles are answerable to the community via the 

> NomCom in addition to any accountability they have to their stream 
> management. That would mean that the ISE and IRTF chair are stuck with=
 

> the RSAB position, having no pool to draw on.

>

The current text reads:



> =C2=A0=C2=A0 The voting members of the RSAB shall be as follows:

>

> =C2=A0=C2=A0 o=C2=A0 One delegate representing the IETF stream, appoin=
ted by the IESG

>

> =C2=A0=C2=A0 o=C2=A0 One delegate representing the IAB stream, appoint=
ed by the IAB

>

> =C2=A0=C2=A0 o=C2=A0 The IRTF Chair, representing the IRTF stream

>

> =C2=A0=C2=A0 o=C2=A0 The Independent Submissions Editor [RFC8730]

>

> =C2=A0=C2=A0 o=C2=A0 The RFC Series Editor/Advisor



We seem to already like the following text as an addition:



> The IAB and IESG delegates shall serve for one year renewable terms.=
=C2=A0 Should a delegate become unavailable, the appointing body MAY replac=
e that individual to complete the term.



We could also add the following, to address Martin's point:



> The IAB and IESG delegates MUST themselves be appointed by the NOMCOM =
to their respective bodies.=C2=A0 They shall bserve for one year renewable =
terms.=C2=A0 Should a delegate become unavailable, the appointing body MAY =
replace that individual to complete the term.



Comments?=C2=A0 For?=C2=A0 Against?=C2=A0 Wordsmith?
=
=C2=A0
This seems generally sound, but the appointing body should=
 be able to replace them for any reason, not just if they are unavailable.<=
br>

-Ekr




Eliot





-- 

Rfced-future mailing list

Rfced-future@iab.=
org

https://www.iab.org/mailman/listinfo/rfced-future




--000000000000c53e2505c5e73cb7--


From nobody Tue Jun 29 06:28:51 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A3D3A345B for ; Tue, 29 Jun 2021 06:28:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level: 
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 5rXxnSwr-ibF for ; Tue, 29 Jun 2021 06:28:43 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 B9E9E3A345A for ; Tue, 29 Jun 2021 06:28:41 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15TDSZWs015875; Tue, 29 Jun 2021 14:28:35 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D2D9246050; Tue, 29 Jun 2021 14:28:34 +0100 (BST)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A2A624604C; Tue, 29 Jun 2021 14:28:34 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS; Tue, 29 Jun 2021 14:28:34 +0100 (BST)
Received: from LAPTOPK7AS653V ([195.166.134.8]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15TDSX7Y024306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Jun 2021 14:28:34 +0100
Reply-To: 
From: "Adrian Farrel" 
To: "'Eric Rescorla'" , "'Eliot Lear'" 
Cc: 
References:  
In-Reply-To: 
Date: Tue, 29 Jun 2021 14:28:33 +0100
Organization: Old Dog Consulting
Message-ID: <128201d76cea$a9326c00$fb974400$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_1283_01D76CF3.0AF79750"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQJYLqiQ/XeTdq1mmedVrtykX7nyGwI9AqC2qheM0+A=
X-Originating-IP: 195.166.134.8
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1017-26248.005
X-TM-AS-Result: No--23.095-10.0-31-10
X-imss-scan-details: No--23.095-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1017-26248.005
X-TMASE-Result: 10--23.094800-10.000000
X-TMASE-MatchedRID: yebcs53SkkDkQwDXuLnCoXFPUrVDm6jtKyD9W9BY6Nbmo6V0TE8Joz/e IwK2t1v9HODVKmi6N/vs8T31M0qopp76e9GOpfQKg2tpowTD9Vo1wgjXWX56uIVu1taMFzoEaYp P/YTwcN12zpFTSDYa08AMamUub8UBGFmgT31DRscAjRSlC8RgmSYvaP2ceWuMpkmw1CcDKPOoBf Cx2HzmBv39Jkt00RkiXHBqzCLfY3HvrPAToiUKGGQ/BgUjr+YU+D+zbdY8Eins0dbsbINj9YP+Y Da/Dhu9XCi46XF/TvG1rv5o+aFbRJ4b0pDla751hQwmwdAU7bKrcyxAHgzswgvdKgmIWjypS2yx GRKp+k1wtfvAHpeQdenrwwvtGVhIPlYNs/F6jNYLwUwfdPoXvrNnwsbX4QeX6RxnahpAxWa3m5p vipjkgvUv8gMr6xtQpFYapP0PqDshYREeQEM9SVkxnoxnQfVSoae+ev6zOlKTclXtA9uJeF30wS BxChZcOQQpB9oD5lSlugrXm5IKcNIiC8HTcYSSx/Stmah0FpbfVqwz+CynaalVRHRK9i1KzEVDG nc+EfKahG/i8Ja1Yx++j1Rb0iZe/7PvFa8I/I9ZwLSBgxghaI5UafLmrvaGI9L0l0rdbj/NTgfZ zqBOOo0DuTXUKKLrnT2mBREOJhUGhPVGwmasBUcp08JfWWIeXccelkX/ubDG6KjwOvvPJD9KXKx TvhDDVZ4DbtT6Dl0jDoqvpyuBTGFNK8NkdpymHPYwOJi6PLmpr7RsZn6zmeCKzR2po8Q6C3uhS2 MBURJjavGVPY7N8iqFmu/h/tw7Gm6TX0QRAr6eAiCmPx4NwGgVPcrOkeoTU2Qzq85WfnCEFYiZR sDydVy8OHlq0+2gocUUS23BTVV6NMvsVHHJAUjCd1qWZDf4g3kw/dgbRug=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jun 2021 13:28:49 -0000

This is a multipart message in MIME format.

------=_NextPart_000_1283_01D76CF3.0AF79750
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I agree with Ekr about replacing for any reason.

=20

I don=E2=80=99t oppose any of these delegation rules, I just find them =
odd.

=20

The delegating body remains completely responsible for the actions of =
the delegate, so:

*	Why does it matter where the delegate is drawn from?
*	Why set specific term limits in this document (surely that is up to =
the delegating body)?
*	Why can the IRTF chair and ISE also delegate?

=20

I=E2=80=99d point out that the IESG continues to be under work-load =
pressure. Although this is only a small task (being a voting member of =
the RSAB), it is an additional task =E2=80=93 why wouldn=E2=80=99t the =
IES delegate externally and just receive reports back from the delegate? =


=20

It would presumably also be true that the delegate (voting member) is =
supposed to participate in the WG (although the delegating body/person) =
can also participate. This may be a large draw on time, and I assume =
that the IESG and IAB might be glad of the option to delegate that =
activity.

=20

Of course, in practice the IESG are not well known for letting go of the =
levers of power, but I don=E2=80=99t see why we should explicitly =
prevent them from doing that.

=20

Sorry if I missed this discussion already.

=20

Adrian

=20

From: Rfced-future  On Behalf Of Eric =
Rescorla
Sent: 29 June 2021 14:03
To: Eliot Lear 
Cc: rfced-future@iab.org
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members

=20

=20

=20

On Mon, Jun 28, 2021 at 10:54 PM Eliot Lear  > wrote:


  Martin Thomson raised an issue that the delegates should come from the =

bodies themselves.  He wrote the following:

> The current document specifically names the chairs of the IETF, IAB,=20
> and IRTF as members of the board. This is unnecessary and goes against =

> efforts to distribute critical functions in these bodies, for the IESG =

> and IAB in particular. The board should instead be composed of a=20
> delegate from each stream, who is empowered to act for that stream.=20
> This might be the chair, but it does not need to be.
>
This part of the issue is resolved in current text (see below).
>
> However, it would be reasonable for the group to insist that the=20
> appointment is made from the IESG or IAB, excluding any ex officio=20
> positions in those bodies (which would rule out the IAB chair as=20
> representative from the IESG). That would be done on the basis that=20
> appointees to these roles are answerable to the community via the=20
> NomCom in addition to any accountability they have to their stream=20
> management. That would mean that the ISE and IRTF chair are stuck with =

> the RSAB position, having no pool to draw on.
>
The current text reads:

>    The voting members of the RSAB shall be as follows:
>
>    o  One delegate representing the IETF stream, appointed by the IESG
>
>    o  One delegate representing the IAB stream, appointed by the IAB
>
>    o  The IRTF Chair, representing the IRTF stream
>
>    o  The Independent Submissions Editor [RFC8730]
>
>    o  The RFC Series Editor/Advisor

We seem to already like the following text as an addition:

> The IAB and IESG delegates shall serve for one year renewable terms.  =
Should a delegate become unavailable, the appointing body MAY replace =
that individual to complete the term.

We could also add the following, to address Martin's point:

> The IAB and IESG delegates MUST themselves be appointed by the NOMCOM =
to their respective bodies.  They shall bserve for one year renewable =
terms.  Should a delegate become unavailable, the appointing body MAY =
replace that individual to complete the term.

Comments?  For?  Against?  Wordsmith?

=20

This seems generally sound, but the appointing body should be able to =
replace them for any reason, not just if they are unavailable.

=20

-Ekr

=20


Eliot


--=20
Rfced-future mailing list
Rfced-future@iab.org =20
https://www.iab.org/mailman/listinfo/rfced-future


------=_NextPart_000_1283_01D76CF3.0AF79750
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I agree with Ekr about replacing =
for any reason.
 
I =
don=E2=80=99t oppose any of these delegation rules, I just find them =
odd.
 
The =
delegating body remains completely responsible for the actions of the =
delegate, so:
  • Why does it matter where the =
delegate is drawn from?
  • Why set specific term =
limits in this document (surely that is up to the delegating =
body)?
  • Why can the IRTF chair and ISE also =
delegate?
 
I=E2=80=99d =
point out that the IESG continues to be under work-load pressure. =
Although this is only a small task (being a voting member of the RSAB), =
it is an additional task =E2=80=93 why wouldn=E2=80=99t the IES delegate =
externally and just receive reports back from the delegate? =

 
It would =
presumably also be true that the delegate (voting member) is supposed to =
participate in the WG (although the delegating body/person) can also =
participate. This may be a large draw on time, and I assume that the =
IESG and IAB might be glad of the option to delegate that =
activity.
 
Of course, =
in practice the IESG are not well known for letting go of the levers of =
power, but I don=E2=80=99t see why we should explicitly prevent them =
from doing that.
 
Sorry if I =
missed this discussion already.
 
Adrian
 
From: Rfced-future =
<rfced-future-bounces@iab.org> On Behalf Of Eric =
Rescorla
Sent: 29 June 2021 14:03
To: Eliot Lear =
<lear@lear.ch>
Cc: =
rfced-future@iab.org
Subject: Re: [Rfced-future] Issue 38: =
Delegates for RSAB members
 
 
 

  Martin Thomson raised an issue that =
the delegates should come from the 
bodies themselves.  He wrote =
the following:

> The current document specifically names the =
chairs of the IETF, IAB, 
> and IRTF as members of the board. This =
is unnecessary and goes against 
> efforts to distribute critical =
functions in these bodies, for the IESG 
> and IAB in particular. =
The board should instead be composed of a 
> delegate from each =
stream, who is empowered to act for that stream. 
> This might be =
the chair, but it does not need to be.
>
This part of the issue =
is resolved in current text (see below).
>
> However, it =
would be reasonable for the group to insist that the 
> =
appointment is made from the IESG or IAB, excluding any ex officio =

> positions in those bodies (which would rule out the IAB chair =
as 
> representative from the IESG). That would be done on the =
basis that 
> appointees to these roles are answerable to the =
community via the 
> NomCom in addition to any accountability they =
have to their stream 
> management. That would mean that the ISE =
and IRTF chair are stuck with 
> the RSAB position, having no pool =
to draw on.
>
The current text reads:

>    =
The voting members of the RSAB shall be as follows:
>
> =
   o  One delegate representing the IETF stream, =
appointed by the IESG
>
>    o  One delegate =
representing the IAB stream, appointed by the IAB
>
> =
   o  The IRTF Chair, representing the IRTF =
stream
>
>    o  The Independent Submissions =
Editor [RFC8730]
>
>    o  The RFC Series =
Editor/Advisor

We seem to already like the following text as an =
addition:

> The IAB and IESG delegates shall serve for one =
year renewable terms.  Should a delegate become unavailable, the =
appointing body MAY replace that individual to complete the =
term.

We could also add the following, to address Martin's =
point:

> The IAB and IESG delegates MUST themselves be =
appointed by the NOMCOM to their respective bodies.  They shall =
bserve for one year renewable terms.  Should a delegate become =
unavailable, the appointing body MAY replace that individual to complete =
the term.

Comments?  For?  Against?  =
Wordsmith?
 
This seems generally sound, but the appointing body =
should be able to replace them for any reason, not just if they are =
unavailable.
 
-Ekr
 

Eliot


-- 
Rfced-future mailing =
list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

------=_NextPart_000_1283_01D76CF3.0AF79750--


From nobody Tue Jun 29 13:21:00 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914523A078F for ; Tue, 29 Jun 2021 13:20:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.236
X-Spam-Level: 
X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_NONE=-0.0001, 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=nthpermutation-com.20150623.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 tzb3l4U_h2_u for ; Tue, 29 Jun 2021 13:20:57 -0700 (PDT)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 27EB23A0799 for ; Tue, 29 Jun 2021 13:20:56 -0700 (PDT)
Received: by mail-qk1-x732.google.com with SMTP id g4so57196qkl.1 for ; Tue, 29 Jun 2021 13:20:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=sZ3RSwSwAY+1J9JVxuImeiyqD6vQuLOm5gdGBbiEEg4=; b=fYJEFJohrIDxYTTVeUf2Dx2r3fD6yZSVVmTX9FwRlXazcFXFVX3xcF1sbgJDTQuBQ2 6xEVsSt+83W2y8al33qC4sDb/q7/QUkOqbTc1qEwKGECfRq0HJ425+iKZbBztG/SpE8s lMEr39HIDOnvcHMmlU8mbgyJhhODquBRo4MxqNrlHPYHyPt5AeUsl4h4TFhdFQFLvdzh 0SCkVPImTo5gbNRDM4CdiOsgzNAA1fDJoPxXG0900ACFCIzAkxaUJYAnJok1Wq9yVtH3 W5tFBz1Li/TI1JOXYOTG42dnVuCW259tWN/t/1muVpdPwDZ6KV6MsslZm5lDf6ZoL2yf 8jyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=sZ3RSwSwAY+1J9JVxuImeiyqD6vQuLOm5gdGBbiEEg4=; b=AR7L091EdxXlclUEJJgvDzVQMTpr0GGDY9sSCjS7G/x74prsM2ec+MLF2fK0l7xKMq AjQPAmDqS02LrOqyxgQ1Kyqa2eDV+z+dMjD6OGN5n0QxOpJVU6n7iUxeR9BKtTKPDEaD 55YAQWOlOjTVbkLG/kcK0EIXB78cKQAtBP8cMSRPmvrGi40GwNNboBhQSYBcQJy29I/W jnjAMwZthVmqUdDguza3/foSBV1Bf/i6/HzzKxEn1HV62RZkkOkZtELArM65XYAh97eX /28DY2+rTBRZ7dE+ztJ+YbqzBC1NZrMqP5EMt1jC/fle5aKT4QNBRVU1UEQGdLDIIKUa CmsQ==
X-Gm-Message-State: AOAM530UJvPnfIjWIXUqjcjXSgL/ExTUxqCA3G1idmthFyg77pHWOsC9 iUm0GOajRxqX++sJbNelggr+BIpdnS4kaTiiQwU=
X-Google-Smtp-Source: ABdhPJzoeKEwAmlhXkdcN1oFzE5Z0at5YgvAPD7N742hRWcwyrYVyZagyVXDisaK2NIV7pYF5ubD1A==
X-Received: by 2002:a37:4388:: with SMTP id q130mr31982594qka.460.1624998054459;  Tue, 29 Jun 2021 13:20:54 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id e26sm3924801qka.38.2021.06.29.13.20.53 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Jun 2021 13:20:53 -0700 (PDT)
To: rfced-future@iab.org
References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> <09ba8d20-0793-4068-9857-04350b6e64ee@www.fastmail.com> <6E47DC4E-E798-4216-8C81-F80A38E1DD16@ietf.org> 
From: Michael StJohns 
Message-ID: <6f3fb134-efe5-a645-77ca-7f0c36221fe8@nthpermutation.com>
Date: Tue, 29 Jun 2021 16:20:51 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jun 2021 20:20:59 -0000

On 6/29/2021 2:35 AM, Eliot Lear wrote:
> Then there is the question of a non-voting liaison from the RPC.  If 
> there is to be such a person, how does that person get appointed and 
> by whom?  The easiest answer is by the IETF Executive Director.  Is 
> that correct? 


If there is a liaison (and I think there probably should be regardless 
of the model), then the appropriate person/entity to select the RPC 
representative is the manager on the RPC side, not the ED.   This goes 
back to the general (US at least) rules for contracts vs employment.  
The ED can tell the RPC what to do (within the bounds of what's written 
in the contract), but mostly not how to do it.  That usually means also 
not directing who does it with exceptions existing such as "key man" 
clauses.  The RPC manager is going to have the best view of who of the 
set of RPC employees should represent the interests of the RPC to the RSAB.

Or to put it a slightly different way, the ED manages the contract not 
the RPC. (And yes we can quibble about what manage means here).

This isn't going to be an appointment, it's going to be an assignment, 
and the RPC management IMHO will/should make that assignment.

Mike


ps - some food for thought on Jay's comment:   The RSE is a selected 
individual with specific qualifications; the RPC is a contracted service 
with a defined SLA.  These are not fungible entities.  That needs to be 
taken into account when attempting to assign duties currently the 
purview of the RSE to the RPC.


From nobody Tue Jun 29 16:17:07 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0752A3A18CD for ; Tue, 29 Jun 2021 16:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 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.338, 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 fTGHaEy-b5HH for ; Tue, 29 Jun 2021 16:17:01 -0700 (PDT)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 653823A18CC for ; Tue, 29 Jun 2021 16:17:01 -0700 (PDT)
Received: by mail-pj1-x1033.google.com with SMTP id p4-20020a17090a9304b029016f3020d867so114078pjo.3 for ; Tue, 29 Jun 2021 16:17:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=mxXOU09fbsRfP4jE0aCntA+Xd3BL0qJ56Fepgy8lp1Y=; b=rlw2WGkZNb5juIFJyEtNM53yZihvo5K3/+HSuaFlOlY/QQfreeoI69bW2oMHTtaInU WXN+ygdiJmjy3g3BTEPmeKqj8p4WZbrlLu3ShV742731BSzYsXXNZquZHDH0NldSECi7 eIKyGphE+1s2FP1QNl33zRbz+M7DDOtHcndc9eTKK38veWC50tBYoEG6nPzRrvtG8Ykb 7dfcq9WtIXM4h67UuuV291AZG/5Ip5Oo4PzLQzrW7+BeyzSeF55F9OAzjUquPwMPgq4z 9L4N6phhTXr7+zA7Y/KYfUcsouPty8tLw9riA5vU/7zL3/55NDavzBl1YxDXxrco1sch ZV1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=mxXOU09fbsRfP4jE0aCntA+Xd3BL0qJ56Fepgy8lp1Y=; b=b9rlSk6SIkqOm/JXtSm7wEW2WFTlGId3uKh0BXr4hL++RSW1+VJIXo93HtGVmKSWO1 MVimHxhLRmxIm25cebgvvjUJSlY5wioG6xdl4zQhHD9lmpTN7/4o19Hn1UOZ/ZjaqD6R z1/RrUbj+XKKJK8s2neWW15CAXVtngSaodyYKp9tdM8b3i/cVnqktlP9M8NSc8/74JGi w+4W+A7bbXerVZxhmmYfJNGd5Vz9qCWjU7ONmlLDT7nHBY2sroqXw1yTfy+nfB0L1bsT X2quAD6blOiGjQISYp9c/S6ZWSix0OQarC5tkGLBE8dJQ1tiBEodWg9pvV8wnS5Mhemt POfA==
X-Gm-Message-State: AOAM531/UpcHG/6PDecHMTuzY6KeY4UtIub97mF8XiwnHUf2PrjluhFK Dq8crQujFu22cGS7+Mp8y36ZfdKkVeYPmQ==
X-Google-Smtp-Source: ABdhPJznVoB+H18KugokS7vIRizIMvW6se5MGsE6fPGLebKKTSQn+llHKbIvsx6q3Xk6EvUWeGWB+Q==
X-Received: by 2002:a17:902:7087:b029:104:6133:6d2d with SMTP id z7-20020a1709027087b029010461336d2dmr29711506plk.39.1625008619269;  Tue, 29 Jun 2021 16:16:59 -0700 (PDT)
Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id k13sm18357146pfu.57.2021.06.29.16.16.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Jun 2021 16:16:58 -0700 (PDT)
To: adrian@olddog.co.uk, 'Eric Rescorla' , 'Eliot Lear' 
Cc: rfced-future@iab.org
References:   <128201d76cea$a9326c00$fb974400$@olddog.co.uk>
From: Brian E Carpenter 
Message-ID: <7bcb4fee-4aec-6223-427c-6c0a4d7d1b91@gmail.com>
Date: Wed, 30 Jun 2021 11:16:55 +1200
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: <128201d76cea$a9326c00$fb974400$@olddog.co.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jun 2021 23:17:06 -0000

On 30-Jun-21 01:28, Adrian Farrel wrote:
> I agree with Ekr about replacing for any reason.

And also doing so *temporarily* e.g. due to sickness.

   Brian
>=20
> =C2=A0
>=20
> I don=E2=80=99t oppose any of these delegation rules, I just find them =
odd.
>=20
> =C2=A0
>=20
> The delegating body remains completely responsible for the actions of t=
he delegate, so:
>=20
>   * Why does it matter where the delegate is drawn from?
>   * Why set specific term limits in this document (surely that is up to=20
the delegating body)?
>   * Why can the IRTF chair and ISE also delegate?
>=20
> =C2=A0
>=20
> I=E2=80=99d point out that the IESG continues to be under work-load pre=
ssure. Although this is only a small task (being a voting member of the R=
SAB), it is an additional task =E2=80=93 why wouldn=E2=80=99t the IES del=
egate externally and just receive reports back from the delegate?
>=20
> =C2=A0
>=20
> It would presumably also be true that the delegate (voting member) is s=
upposed to participate in the WG (although the delegating body/person) ca=
n also participate. This may be a large draw on time, and I assume that t=
he IESG and IAB might be glad of the option to delegate that activity.
>=20
> =C2=A0
>=20
> Of course, in practice the IESG are not well known for letting go of th=
e levers of power, but I don=E2=80=99t see why we should explicitly preve=
nt them from doing that.
>=20
> =C2=A0
>=20
> Sorry if I missed this discussion already.
>=20
> =C2=A0
>=20
> Adrian
>=20
> =C2=A0
>=20
> *From:*Rfced-future  *On Behalf Of *Eric =
Rescorla
> *Sent:* 29 June 2021 14:03
> *To:* Eliot Lear 
> *Cc:* rfced-future@iab.org
> *Subject:* Re: [Rfced-future] Issue 38: Delegates for RSAB members
>=20
> =C2=A0
>=20
> =C2=A0
>=20
> =C2=A0
>=20
> On Mon, Jun 28, 2021 at 10:54 PM Eliot Lear > wrote:
>=20
>=20
>     =C2=A0=C2=A0Martin Thomson raised an issue that the delegates shoul=
d come from the
>     bodies themselves.=C2=A0 He wrote the following:
>=20
>     > The current document specifically names the chairs of the IETF, I=
AB,
>     > and IRTF as members of the board. This is unnecessary and goes ag=
ainst
>     > efforts to distribute critical functions in these bodies, for the=20
IESG
>     > and IAB in particular. The board should instead be composed of a
>     > delegate from each stream, who is empowered to act for that strea=
m.
>     > This might be the chair, but it does not need to be.
>     >
>     This part of the issue is resolved in current text (see below).
>     >
>     > However, it would be reasonable for the group to insist that the
>     > appointment is made from the IESG or IAB, excluding any ex offici=
o
>     > positions in those bodies (which would rule out the IAB chair as
>     > representative from the IESG). That would be done on the basis th=
at
>     > appointees to these roles are answerable to the community via the=

>     > NomCom in addition to any accountability they have to their strea=
m
>     > management. That would mean that the ISE and IRTF chair are stuck=20
with
>     > the RSAB position, having no pool to draw on.
>     >
>     The current text reads:
>=20
>     > =C2=A0=C2=A0 The voting members of the RSAB shall be as follows:
>     >
>     > =C2=A0=C2=A0 o=C2=A0 One delegate representing the IETF stream, a=
ppointed by the IESG
>     >
>     > =C2=A0=C2=A0 o=C2=A0 One delegate representing the IAB stream, ap=
pointed by the IAB
>     >
>     > =C2=A0=C2=A0 o=C2=A0 The IRTF Chair, representing the IRTF stream=

>     >
>     > =C2=A0=C2=A0 o=C2=A0 The Independent Submissions Editor [RFC8730]=

>     >
>     > =C2=A0=C2=A0 o=C2=A0 The RFC Series Editor/Advisor
>=20
>     We seem to already like the following text as an addition:
>=20
>     > The IAB and IESG delegates shall serve for one year renewable ter=
ms.=C2=A0 Should a delegate become unavailable, the appointing body MAY r=
eplace that individual to complete the term.
>=20
>     We could also add the following, to address Martin's point:
>=20
>     > The IAB and IESG delegates MUST themselves be appointed by the NO=
MCOM to their respective bodies.=C2=A0 They shall bserve for one year ren=
ewable terms.=C2=A0 Should a delegate become unavailable, the appointing =
body MAY replace that individual to complete the term.
>=20
>     Comments?=C2=A0 For?=C2=A0 Against?=C2=A0 Wordsmith?
>=20
> =C2=A0
>=20
> This seems generally sound, but the appointing body should be able to r=
eplace them for any reason, not just if they are unavailable.
>=20
> =C2=A0
>=20
> -Ekr
>=20
> =C2=A0
>=20
>=20
>     Eliot
>=20
>=20
>     --=20
>     Rfced-future mailing list
>     Rfced-future@iab.org 
>     https://www.iab.org/mailman/listinfo/rfced-future 
>=20
>=20


From nobody Tue Jun 29 16:21:53 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4033A18E1 for ; Tue, 29 Jun 2021 16:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 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.338, 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 yTtYuE3QWN9q for ; Tue, 29 Jun 2021 16:21:47 -0700 (PDT)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 602873A18DE for ; Tue, 29 Jun 2021 16:21:47 -0700 (PDT)
Received: by mail-pl1-x635.google.com with SMTP id a14so202254pls.4 for ; Tue, 29 Jun 2021 16:21:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=1WlMu1QZtM6r/3QcI1UwN5y7LyMPjVhHxp3dHGq/pnQ=; b=KGE8ihZ/xumPWcLATAUplC7+z8sU98H4T0tY9dvBra9mVxO1S+vt17dnfrB+6X1Nun 4yUerPhabNLioR8DNcFYKdl07A/Nqa6be6F30IaUlW0V/HTfopykZv0msaPwlMtdJgTU N9ZA4JOYTADqk9I5DUJUPmYj83mbNtGSN9gGGe9ShweEh3bbxersA92tVEddeV7yEabY Fhh8EmuhImm7trtQ7KB0bmJmHI4dj2fRjlq3fDlVqTuQCWgxFJBwoQTCDdEX5gW4iAa5 R4PHkBCyTo9j8IcKA28grhwtEuwCr2lg/G6xauf2r9pU1LOgaocUII4Qcvcxefgq0+Fw 6Lmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1WlMu1QZtM6r/3QcI1UwN5y7LyMPjVhHxp3dHGq/pnQ=; b=rm5RBbdUyMsDCnNWxQpOFe5LMmlbIb5JZWKHD37jnHmukryw9o9TGpte0EJxOSFv5b iddxU8DaAGQaAEASlvbJbpEgV8zcWyBB1QU2Gvek+dg5xN0EguskyDPFngVHBk3f7pe4 kOryXS9zQpAjcLqQUjKqfZBRULpnNxtO5SrrYLFpAAlvs/tIUkl6XmDwPs6+8LmjIckr oErUlGvoQHadzDnsTGPn5tTxmhc35pQnEW+yjf28YlnG4RmvSklcHmQFuNPqAA8GTo1d kTVVQ8SyAhKW49rN1vRsndXJ2yiLTvbdGBnpH8PEJ7RZZ622zO6RtCdrcROtNGxtZil+ ONBA==
X-Gm-Message-State: AOAM5305wESlr7SENAEO6kZP5N+tQzvTCNwH2sm5zY6iQ2QxHDnVQ4lC SVX1UsUqJ8kKOyOOmpeHygD07zIEQgLYyg==
X-Google-Smtp-Source: ABdhPJySYcUQMGdiHbv+0X5R8a2jEi5Lj1m7Pk7Q7BKgvpqlVkWe39JpqTcdHu7tN9OEzkFp6Zvf6A==
X-Received: by 2002:a17:90b:3842:: with SMTP id nl2mr2915135pjb.189.1625008905545;  Tue, 29 Jun 2021 16:21:45 -0700 (PDT)
Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id k6sm5801905pgt.15.2021.06.29.16.21.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Jun 2021 16:21:44 -0700 (PDT)
To: Eliot Lear , rfced-future@iab.org
References: <4834a4a0-c3c9-1866-931b-d90ada0d0e7e@lear.ch>
From: Brian E Carpenter 
Message-ID: <671e3081-440d-c03b-1fe7-884bf8f4046c@gmail.com>
Date: Wed, 30 Jun 2021 11:21:41 +1200
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: <4834a4a0-c3c9-1866-931b-d90ada0d0e7e@lear.ch>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Issue 69: Who can adopt WG items?
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jun 2021 23:21:52 -0000

On 29-Jun-21 18:11, Eliot Lear wrote:
> EKR raised the following question in Issue 69:
>=20
>>  2. If there is sufficient interest in the proposal, RSWG may adopt
>>     the proposal as a draft proposal of the RSWG, much the same way a
>>     working group of the IETF or IRTF would.
>>
>> As has been pointed out previously, 2418 is a bit vague on how adoptio=
n happens. Do we want to be vague here?
>>
> 2418 is *intentionally* vague about this because of the wide variety of=20
circumstances that can arise, and the need for chairs to have some flexib=
ility.=C2=A0 Also, that document was written 22 years ago, and we had con=
siderably less experience than we do now.=C2=A0 Still, that flexibility m=
ight prove necessary =E2=80=93 or not.
>=20
> In any event, for those who think we *should* be more specific, we need=20
proposed text.=C2=A0 Otherwise perhaps this is one can be deferred until =
there is some operational experience?=C2=A0 This also ties to the matter =
of possibly appealing lack of action on the part of the chairs.=C2=A0 The=20
RSAB could certainly say to chairs that they were unreasonable either in =
adopting or not adopting something.
>=20
> Comments?

The problem is that even RFC7221 is contentious and https://datatracker.i=
etf.org/doc/html/draft-carpenter-gendispatch-rfc7221bis-01 proved to be e=
ven more so.

If the IETF can't sort this out, can we?

Regards
   Brian C


From nobody Tue Jun 29 16:23:40 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361973A1569 for ; Tue, 29 Jun 2021 16:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 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.338, 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 JKcI57HFPJCd for ; Tue, 29 Jun 2021 16:23:36 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 5E38B3A2E06 for ; Tue, 29 Jun 2021 16:23:36 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id d1so403786plg.6 for ; Tue, 29 Jun 2021 16:23:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=3JuH3y7t/WV+hXnr8byJ3R7I3nHnAK48hFD9gN/ynPQ=; b=notCkCo9hOm/eOU1v1IgfZ/g/S8iQ40gA8NOTXo70HCGxJmlZuZ7sHxKMbz4nJKbRT gX3qmqTdLdtRH7rMM9IeFiWAl7Rs4vVSh2vPiGthzY2+0Px1puisKF9wtkDd/GJ4lPge Ry5d0MMw+7E/k9Qz/GSdD97zBAleGBtJ89GL1xs7X/rsJJye/4p00+v/B6IK6QCubvXS 0sdfXCgq5u2X7l5iLB+u50unuaCa6R2f+x10FHqot4YrFokVPMQ7F/zclZ9yvnUfaTQk AXD2zSsLPq1aEtSXh+oeu2d/nEIZMDPpNRrdqgHyH1lF6ZZzm1esQ8wAlN2ayI4YgyHe gcXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3JuH3y7t/WV+hXnr8byJ3R7I3nHnAK48hFD9gN/ynPQ=; b=giTCelrhOAduXOPQJsTqbcfSC58dsndE3vUXOQmOTWmjRc6YliM7zx82sgh1VCSkjj bIgQd1q8UO2tdt+IhK4z9XTKGubZeHZroZHsxx0k73LtmE/TjxVdhT8HvUCT1tR8Xbbr G1aFi9yixFasUCm0rCcQqeSZQaNdLFP84JcHUSPOyTYaNYm7rZ1uSnsiDeRQ/1aonyBE hEHMkArWRNPhu44xDEQxXpu2202p1AEcJQDhOdaq7opriTppNOu1g7i+/0QKl0UkseuN oilpFxKJDyqze9XDp+lSAnJ8OG/4EU1sIaZEc2Lx+Zmw7UfkFrymNhpr1YvU4fewpuDp MeEA==
X-Gm-Message-State: AOAM5330L+r/fY6w/Y3cE7PmpfqoRlbklHT5YIkMK9pKDPL04hNnqsgv eHsvzllLpQ20rQ02xAfjyR+B90B7y0qX3Q==
X-Google-Smtp-Source: ABdhPJzZn8ELvUJrjJn8AolvwGpADBgabORqK8aGlbqnqcCUV4Mi/LqvRhX9Ks6NTZfAgLk0IyYgwg==
X-Received: by 2002:a17:902:eccb:b029:127:9520:ac96 with SMTP id a11-20020a170902eccbb02901279520ac96mr29291758plh.70.1625009015183;  Tue, 29 Jun 2021 16:23:35 -0700 (PDT)
Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id n63sm19006543pfn.140.2021.06.29.16.23.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Jun 2021 16:23:34 -0700 (PDT)
To: Eliot Lear , rfced-future@iab.org
References: <2629ac02-5373-7762-a862-fb1240273fa4@lear.ch> <0a5e01d76778$ad98aec0$08ca0c40$@olddog.co.uk> <970e8906-2676-e040-03de-19116f5e9fcf@lear.ch> <112801d76c11$1c9d1760$55d74620$@olddog.co.uk>  <61db5ca4-764d-8b11-0bb4-2849b99156f2@lear.ch> <16e2fc06-1f25-13d3-d99d-e0b3aaab2259@lear.ch>
From: Brian E Carpenter 
Message-ID: 
Date: Wed, 30 Jun 2021 11:23:32 +1200
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: <16e2fc06-1f25-13d3-d99d-e0b3aaab2259@lear.ch>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Rfced-future] Consensus check: Issue 16: Appeals (RSWG)
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jun 2021 23:23:39 -0000

wfm

   Brian
On 29-Jun-21 17:57, Eliot Lear wrote:
> This text would cover not only issue 16, but also issue 70.
> 
> On 29.06.21 07:41, Eliot Lear wrote:
>> Decisions of the RSWG can only be appealed on grounds of failure to
>> follow the correct process. Appeals should be made within 30 days of
>> any action, or in the case of failure to act, of notice having been
>> given to the RSWG. The RSAB will then decide if the process was
>> followed and will direct RSWG chairs as to what procedural actions are
>> required.
> 
> 


From nobody Tue Jun 29 16:28:57 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFF13A3F3E for ; Tue, 29 Jun 2021 16:28:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 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.338, 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 1Sq8z7u60w_y for ; Tue, 29 Jun 2021 16:28:51 -0700 (PDT)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 51CAC3A3965 for ; Tue, 29 Jun 2021 16:28:51 -0700 (PDT)
Received: by mail-pf1-x42d.google.com with SMTP id a127so676600pfa.10 for ; Tue, 29 Jun 2021 16:28:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ba+VlL0mRCq+NbIy/esuF7V8BSVebXmFDNs+MO/k3MM=; b=aQNIxUR0Gh7Ab8hrl8+3QT6Pjz03K9olxCsZ4I/AkH2hnZZeysQPKeG8zpRrL2lhhW GVP0n0U0OYuetunHwbLTjQcQ7pnJ5jM2+ejeEEF403NF2rcrcwFbuBdGWJ6ARyZHTuZX Kx5gnct3RrdVcfm9jF+2v248Gq5dmVkHXKlHOBBB4ZlVelwFk4ZLJoji4EyIcPG7j3j5 PbSpK6r+pNh0uSGYokPs47nf+ULJJQim4XFZNj3WEuJ7VCerhpYsCxmHhcB9heskrwPQ zuzbqDcfWh7Dp7Lu3ajEsN1xvDIWVw+W9dmm6Utxk8LgZ5md1FwFHdugObgPxr1xGXQh 8/+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=ba+VlL0mRCq+NbIy/esuF7V8BSVebXmFDNs+MO/k3MM=; b=lMolty3vU9qBg4WKslX8SinGjg88TDqajp6eNZ2jeMUwn67eUFAsQY07euIPJKGfov 6HcsZbHRuCgaMIxIxmLbjqU+bm52O5zjSb8YONg9ursoSv8vglMTZsEK9boHGvVb9AuN KJB15qh+A8fN9xglJzPotY0bXlR5uvya6Gdr/fjEchn9yYTq0JSEvE+5OdVSjYuc/IiA NHN5jIFk+03WQmq5EU7ZX9+GX5rPd+ItmjQhR8e/CuupEmp15cEzYacKQdOOBks6qY8v 2fudS0y77+NEaqJD2AfNbekTk5A6e1xcmmypWFi0G0h08wcT36j/PLwY0LBYuUuFHkRV X9PQ==
X-Gm-Message-State: AOAM530eoKmtlU8AZMVgCaWRaisdTn2bf2ShwV66kdlTuBk782OucKjZ fg9l39FFslOVUjCLDz6wmd8=
X-Google-Smtp-Source: ABdhPJy1dj9heSZL/1q0S4pAyIMGoVJDmJIBzPX/uUwjl32S56dzJzJEDrg0C1ngkGDTVOyPMxCYXw==
X-Received: by 2002:a63:5b02:: with SMTP id p2mr12253945pgb.161.1625009330269;  Tue, 29 Jun 2021 16:28:50 -0700 (PDT)
Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id z26sm15440231pfk.112.2021.06.29.16.28.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Jun 2021 16:28:49 -0700 (PDT)
To: Jay Daley , Eliot Lear 
Cc: rfced-future@iab.org, Martin Thomson 
References:  <896D122F-C341-4B1F-9467-48040F691A42@ietf.org>
From: Brian E Carpenter 
Message-ID: <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com>
Date: Wed, 30 Jun 2021 11:28:46 +1200
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: <896D122F-C341-4B1F-9467-48040F691A42@ietf.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jun 2021 23:28:56 -0000

Jay,

> The structure I am suggesting inserts the RSAB into the mixture and by =
doing so both softens the changes to the RPC and spreads the checks and b=
alances. The RSAB takes on the role of advising the RPC on community requ=
irements, priorities, what needs consulting on and who should be consulte=
d

I think this is reasonable as a high level statement. However, I remain w=
orried that a committee as a whole can't advise an operational unit as a =
whole. That's a small version of a football crowd advising another footba=
ll crowd.

So I continue to see a role here for the RSEA as a communicator.

Regards
   Brian Carpenter

On 29-Jun-21 22:16, Jay Daley wrote:
>=20
>=20
>> On 29/06/2021, at 6:36 PM, Eliot Lear  wrote:
>>
>> =EF=BB=BF
>>
>> Jay, Martin,
>>
>> Let's go through where we seem to agree first:
>>
>> I am not hearing any argument about the reordering that Martin propose=
d, and so I think we stand as follows:
>>
>>> All matters of budget, timetable and impact on its performance=20
>>> targets, are between the RPC and IETF LLC.
>>>
>>> The RPC shall report regularly to the RSAB, RSWG and broader=20
>>> community, on the contents and progress of its work program and any=20
>>> key risks or issues affecting it.=20
>>> In the event that the RPC is required to make a decision without=20
>>> consultation that would normally deserve consultation, or makes a=20
>>> decision against the advice of the RSAB then it must notify the=20
>>> RSAB.
>>
>> Then there is the question of a non-voting liaison from the RPC.=C2=A0=20
If there is to be such a person, how does that person get appointed and b=
y whom?=C2=A0 The easiest answer is by the IETF Executive Director.=C2=A0=20
Is that correct?=C2=A0
>>
> To me there are two separate needs here. The IETF Executive Director is=20
a liaison to coordinate the overall operational response and ensure that =
performance targets and priorities are met - that includes RPC, tools, co=
mms etc.=C2=A0
>=20
> The question of whether the RPC has a liaison depends on the nature of =
the RPC role that we are still discussing below so I=E2=80=99ll pick that=20
up there. =C2=A0
>>
>> At some point we need to back up to how we relate all of this to the t=
ooling team.=C2=A0 Is it represented by the same liaison?=C2=A0 Is it gov=
erned in a similar fashion?
>>
> There=E2=80=99s no need for a specific tools liaison. =C2=A0The RPC hav=
e tools requirements that are discussed direct with the IETF Executive Di=
rector (funding/contracting) and Tools Team PM (internal/community implem=
entation). =C2=A0The authors discuss their tools requirements directly on=20
list.=C2=A0
>>
>> Then comes the trickier part:
>>
>>> The RPC will develop this program using the strategic direction set b=
y the community as input.  The RPC can consult with the RSAB directly, ra=
ther than relying on public consultation.  As stream managers, the RSAB c=
an provide input on stream-specific policies or requirements.  The RSAB s=
hould be able to advise on whether a decision might need to be made by th=
e RSWG and what items are currently under discussion in the RSWG.  The RS=
AB might be able to provide input on how work items on the program are pr=
ioritized.
>>>
>>> However, I'm concerned that this last item gives considerable power t=
o the RSAB.  Setting priority is a very good proxy for setting policy.  A=
s stream managers, that is probably fine (hence my suggested tweak), as a=20
body, that risks undermining the RSWG process: "the WG decided this, but =
it's silly, so deprioritize its implementation".
>>
>> This raises questions:
>>
>>  1. Should there be a frequency by which the RPC reports?=C2=A0 If the=
y're frequent enough, then there is no need to make massive shifts withou=
t consultation, and we are talking about a pretty focused function (i.e.,=20
not like an entire government ministry or department).=C2=A0=C2=A0 The on=
ly real question is whether the RPC should seek approval/endorsement of i=
ts plan.=C2=A0 "Here's what we did, here's how it went, here's what we pl=
an to do over the next XX months/year(s)".
>>  2. Are we are using the RSAB for regular consultations between stream=20
managers and the RPC?=C2=A0 In this case, is the RSAB acting as a group o=
r merely being gathered as stream managers?=C2=A0 If the latter, then the=20
RSAB has no formal role.=C2=A0 The RPC is always free to consult who they=20
want to consult in order to get the job done or to identify issues.=C2=A0=20
Right?
> So this is where I think Martin and I have two very different visions o=
f the RPC and the answer to all of the above revolves around which vision=20
we move forward with.=C2=A0
>=20
> The current structure has an RSE that collects community requirements, =
engages with the community as needed, interprets those requirements and d=
elivers a prioritised list to the RPC. =C2=A0The RSE also reports to the =
community. The RPC certainly picks up plenty of requirements from its eng=
agement with authors but those are fed into the RPC for them to work into=20
their plans. =C2=A0The checks and balances to this process are multiple -=20
there is the RSOC overseeing the RSE, the RSE overseeing the RPC and the =
LLC monitoring both contracts. =C2=A0The key check here is that the RSE c=
annot unilaterally decide who they consult and what they consult on.=C2=A0=

>=20
> If we switch to a structure where the RPC is responsible to the full co=
mmunity then two things happen. First, they take on all of the role of th=
e RSE above, which I am concerned is far too much of a change for the RPC=
=2E =C2=A0Second, the only check and balance becomes the LLC, which now m=
onitors the contract, manages performance, agrees the work program with t=
he RPC, takes on the community role of ensuring that the RPC consults wit=
h the right people and consults on the right things and the role of ensur=
ing the reporting to the community is adequate. I am concerned that is to=
o large a role for the LLC and oversteps the community line. (Of course t=
here is an alternative that nobody does some parts of this, but that is s=
ignificantly worse).=C2=A0
>=20
> The structure I am suggesting inserts the RSAB into the mixture and by =
doing so both softens the changes to the RPC and spreads the checks and b=
alances. The RSAB takes on the role of advising the RPC on community requ=
irements, priorities, what needs consulting on and who should be consulte=
d. While the RPC still makes the final call, we now have some separation =
of roles. The requirement for the RPC to inform the RSAB where it goes ag=
ainst its advice ensures transparency and adds another check to the proce=
ss. =C2=A0The RSWG/RSAB also take on the role of receiving the reports an=
d are implicitly responsible for addressing the suitability of the report=
s. The role of the LLC is reduced to contract monitoring and performance =
management. The LLC doesn=E2=80=99t take on any community role but acts a=
s an escalation point for the RSAB/RWSG.=C2=A0
>=20
> Each of these structures envisions a very different RPC. =C2=A0If can a=
gree which vision of the RPC we prefer then the answers all fall out from=20
that.=C2=A0
>=20
> Jay
>=20
> --=C2=A0
> Jay Daley
> IETF Executive Director
>=20
>> 2.
>>
>> Eliot
>>
>=20


From nobody Tue Jun 29 16:34:52 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA193A3F6A for ; Tue, 29 Jun 2021 16:34:51 -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, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 sQ1Kc_ln-BLE; Tue, 29 Jun 2021 16:34:45 -0700 (PDT)
Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 78A203A3F68; Tue, 29 Jun 2021 16:34:44 -0700 (PDT)
From: Jay Daley 
Message-Id: <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_94632A90-5ADD-43D3-A6D3-22043DDA7E5E"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Wed, 30 Jun 2021 11:34:41 +1200
In-Reply-To: <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com>
Cc: Eliot Lear , rfced-future@iab.org, Martin Thomson 
To: Brian E Carpenter 
References:  <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jun 2021 23:34:51 -0000

--Apple-Mail=_94632A90-5ADD-43D3-A6D3-22043DDA7E5E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 30/06/2021, at 11:28 AM, Brian E Carpenter =
 wrote:
>=20
> Jay,
>=20
>> The structure I am suggesting inserts the RSAB into the mixture and =
by doing so both softens the changes to the RPC and spreads the checks =
and balances. The RSAB takes on the role of advising the RPC on =
community requirements, priorities, what needs consulting on and who =
should be consulted
>=20
> I think this is reasonable as a high level statement. However, I =
remain worried that a committee as a whole can't advise an operational =
unit as a whole. That's a small version of a football crowd advising =
another football crowd.

I was not expecting all 11 members of the RPC to be present for this =
exchange, just the manager and possibly her deputy.

> So I continue to see a role here for the RSEA as a communicator.

That replaces=20

	RSAB -> RPC Manager   with   RSAB -> RSEA -> RPC Manager

I don=E2=80=99t see how that helps anything.  Don=E2=80=99t forget the =
RSAB includes the RSAB so it is actually  RSAB/RSEA -> RPC Manager.

Jay

>=20
> Regards
>   Brian Carpenter
>=20
> On 29-Jun-21 22:16, Jay Daley wrote:
>>=20
>>=20
>>> On 29/06/2021, at 6:36 PM, Eliot Lear  wrote:
>>>=20
>>> =EF=BB=BF
>>>=20
>>> Jay, Martin,
>>>=20
>>> Let's go through where we seem to agree first:
>>>=20
>>> I am not hearing any argument about the reordering that Martin =
proposed, and so I think we stand as follows:
>>>=20
>>>> All matters of budget, timetable and impact on its performance=20
>>>> targets, are between the RPC and IETF LLC.
>>>>=20
>>>> The RPC shall report regularly to the RSAB, RSWG and broader=20
>>>> community, on the contents and progress of its work program and any=20=

>>>> key risks or issues affecting it.=20
>>>> In the event that the RPC is required to make a decision without=20
>>>> consultation that would normally deserve consultation, or makes a=20=

>>>> decision against the advice of the RSAB then it must notify the=20
>>>> RSAB.
>>>=20
>>> Then there is the question of a non-voting liaison from the RPC. =20
> If there is to be such a person, how does that person get appointed =
and by whom?  The easiest answer is by the IETF Executive Director. =20
> Is that correct?=20
>>>=20
>> To me there are two separate needs here. The IETF Executive Director =
is=20
> a liaison to coordinate the overall operational response and ensure =
that performance targets and priorities are met - that includes RPC, =
tools, comms etc.=20
>>=20
>> The question of whether the RPC has a liaison depends on the nature =
of the RPC role that we are still discussing below so I=E2=80=99ll pick =
that=20
> up there. =20
>>>=20
>>> At some point we need to back up to how we relate all of this to the =
tooling team.  Is it represented by the same liaison?  Is it governed in =
a similar fashion?
>>>=20
>> There=E2=80=99s no need for a specific tools liaison.  The RPC have =
tools requirements that are discussed direct with the IETF Executive =
Director (funding/contracting) and Tools Team PM (internal/community =
implementation).  The authors discuss their tools requirements directly =
on=20
> list.=20
>>>=20
>>> Then comes the trickier part:
>>>=20
>>>> The RPC will develop this program using the strategic direction set =
by the community as input.  The RPC can consult with the RSAB directly, =
rather than relying on public consultation.  As stream managers, the =
RSAB can provide input on stream-specific policies or requirements.  The =
RSAB should be able to advise on whether a decision might need to be =
made by the RSWG and what items are currently under discussion in the =
RSWG.  The RSAB might be able to provide input on how work items on the =
program are prioritized.
>>>>=20
>>>> However, I'm concerned that this last item gives considerable power =
to the RSAB.  Setting priority is a very good proxy for setting policy.  =
As stream managers, that is probably fine (hence my suggested tweak), as =
a=20
> body, that risks undermining the RSWG process: "the WG decided this, =
but it's silly, so deprioritize its implementation".
>>>=20
>>> This raises questions:
>>>=20
>>> 1. Should there be a frequency by which the RPC reports?  If they're =
frequent enough, then there is no need to make massive shifts without =
consultation, and we are talking about a pretty focused function (i.e.,=20=

> not like an entire government ministry or department).   The only real =
question is whether the RPC should seek approval/endorsement of its =
plan.  "Here's what we did, here's how it went, here's what we plan to =
do over the next XX months/year(s)".
>>> 2. Are we are using the RSAB for regular consultations between =
stream=20
> managers and the RPC?  In this case, is the RSAB acting as a group or =
merely being gathered as stream managers?  If the latter, then the=20
> RSAB has no formal role.  The RPC is always free to consult who they=20=

> want to consult in order to get the job done or to identify issues. =20=

> Right?
>> So this is where I think Martin and I have two very different visions =
of the RPC and the answer to all of the above revolves around which =
vision=20
> we move forward with.=20
>>=20
>> The current structure has an RSE that collects community =
requirements, engages with the community as needed, interprets those =
requirements and delivers a prioritised list to the RPC.  The RSE also =
reports to the community. The RPC certainly picks up plenty of =
requirements from its engagement with authors but those are fed into the =
RPC for them to work into=20
> their plans.  The checks and balances to this process are multiple -=20=

> there is the RSOC overseeing the RSE, the RSE overseeing the RPC and =
the LLC monitoring both contracts.  The key check here is that the RSE =
cannot unilaterally decide who they consult and what they consult on.=20
>>=20
>> If we switch to a structure where the RPC is responsible to the full =
community then two things happen. First, they take on all of the role of =
the RSE above, which I am concerned is far too much of a change for the =
RPC.  Second, the only check and balance becomes the LLC, which now =
monitors the contract, manages performance, agrees the work program with =
the RPC, takes on the community role of ensuring that the RPC consults =
with the right people and consults on the right things and the role of =
ensuring the reporting to the community is adequate. I am concerned that =
is too large a role for the LLC and oversteps the community line. (Of =
course there is an alternative that nobody does some parts of this, but =
that is significantly worse).=20
>>=20
>> The structure I am suggesting inserts the RSAB into the mixture and =
by doing so both softens the changes to the RPC and spreads the checks =
and balances. The RSAB takes on the role of advising the RPC on =
community requirements, priorities, what needs consulting on and who =
should be consulted. While the RPC still makes the final call, we now =
have some separation of roles. The requirement for the RPC to inform the =
RSAB where it goes against its advice ensures transparency and adds =
another check to the process.  The RSWG/RSAB also take on the role of =
receiving the reports and are implicitly responsible for addressing the =
suitability of the reports. The role of the LLC is reduced to contract =
monitoring and performance management. The LLC doesn=E2=80=99t take on =
any community role but acts as an escalation point for the RSAB/RWSG.=20
>>=20
>> Each of these structures envisions a very different RPC.  If can =
agree which vision of the RPC we prefer then the answers all fall out =
from=20
> that.=20
>>=20
>> Jay
>>=20
>> --=20
>> Jay Daley
>> IETF Executive Director
>>=20
>>> 2.
>>>=20
>>> Eliot
>>>=20
>>=20
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org 
> https://www.iab.org/mailman/listinfo/rfced-future =

--=20
Jay Daley
IETF Executive Director
jay@ietf.org


--Apple-Mail=_94632A90-5ADD-43D3-A6D3-22043DDA7E5E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 30/06/2021, at 11:28 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Jay,

The structure I am suggesting inserts =
the RSAB into the mixture and by doing so both softens the changes to =
the RPC and spreads the checks and balances. The RSAB takes on the role =
of advising the RPC on community requirements, priorities, what needs =
consulting on and who should be consulted

I think this is reasonable as a =
high level statement. However, I remain worried that a committee as a =
whole can't advise an operational unit as a whole. That's a small =
version of a football crowd advising another football crowd.

I was not =
expecting all 11 members of the RPC to be present for this exchange, =
just the manager and possibly her deputy.

So I continue to see a role here for the RSEA as a =
communicator.

That =
replaces 

	RSAB =
-> RPC Manager   with   RSAB -> RSEA -> RPC =
Manager

I don=E2=80=99t see how that =
helps anything.  Don=E2=80=99t forget the RSAB includes the RSAB so =
it is actually  RSAB/RSEA -> RPC Manager.

Jay


Regards
  Brian Carpenter

On 29-Jun-21 22:16, Jay Daley wrote:


On =
29/06/2021, at 6:36 PM, Eliot Lear <lear@lear.ch> wrote:

=EF=BB=
=BF

Jay, Martin,

Let's go through where we seem to agree first:

I am not hearing any argument about the =
reordering that Martin proposed, and so I think we stand as follows:

All =
matters of budget, timetable and impact on its performance 
targets, are =
between the RPC and IETF LLC.

The RPC shall =
report regularly to the RSAB, RSWG and broader 
community, =
on the contents and progress of its work program and any 
key risks or =
issues affecting it. In the event that the RPC is required to make a decision =
without 
consultation that would normally deserve consultation, or =
makes a 
decision against the advice of the RSAB then it must notify =
the 
RSAB.

Then there is =
the question of a non-voting liaison from the RPC.  
If there is to be such a person, how does that person get =
appointed and by whom?  The easiest answer is by the IETF Executive =
Director.  
Is that correct? 

To me there are two separate needs here. The =
IETF Executive Director is 
a liaison to coordinate the overall operational response and =
ensure that performance targets and priorities are met - that includes =
RPC, tools, comms etc. 

The question of =
whether the RPC has a liaison depends on the nature of the RPC role that =
we are still discussing below so I=E2=80=99ll pick that 
up there.  

At some point we need to back up to how we =
relate all of this to the tooling team.  Is it represented by the =
same liaison?  Is it governed in a similar fashion?
There=E2=80=99s no need for a specific tools =
liaison.  The RPC have tools requirements that are discussed direct =
with the IETF Executive Director (funding/contracting) and Tools Team PM =
(internal/community implementation).  The authors discuss their =
tools requirements directly on 
list. 

Then comes the trickier part:

The RPC will develop =
this program using the strategic direction set by the community as =
input.  The RPC can consult with the RSAB directly, rather than =
relying on public consultation.  As stream managers, the RSAB can =
provide input on stream-specific policies or requirements.  The =
RSAB should be able to advise on whether a decision might need to be =
made by the RSWG and what items are currently under discussion in the =
RSWG.  The RSAB might be able to provide input on how work items on =
the program are prioritized.

However, I'm =
concerned that this last item gives considerable power to the RSAB. =
 Setting priority is a very good proxy for setting policy.  As =
stream managers, that is probably fine (hence my suggested tweak), as =
a 
body, that risks undermining the =
RSWG process: "the WG decided this, but it's silly, so deprioritize its =
implementation".

This raises questions:

1. Should there be a frequency by which the RPC =
reports?  If they're frequent enough, then there is no need to make =
massive shifts without consultation, and we are talking about a pretty =
focused function (i.e., 
not like an entire government ministry or =
department).   The only real question is whether the RPC =
should seek approval/endorsement of its plan.  "Here's what we did, =
here's how it went, here's what we plan to do over the next XX =
months/year(s)".
2.=
 Are we are using the RSAB for regular consultations between stream 
managers and the RPC?  In this case, is the RSAB acting =
as a group or merely being gathered as stream managers?  If the =
latter, then the 
RSAB has no formal role.  =
The RPC is always free to consult who they 
want to consult in order to get =
the job done or to identify issues.  
Right?
So =
this is where I think Martin and I have two very different visions of =
the RPC and the answer to all of the above revolves around which =
vision 
we move forward with. 

The current structure =
has an RSE that collects community requirements, engages with the =
community as needed, interprets those requirements and delivers a =
prioritised list to the RPC.  The RSE also reports to the =
community. The RPC certainly picks up plenty of requirements from its =
engagement with authors but those are fed into the RPC for them to work =
into 
their plans.  The checks and balances to this process =
are multiple - 
there is the RSOC overseeing the =
RSE, the RSE overseeing the RPC and the LLC monitoring both contracts. =
 The key check here is that the RSE cannot unilaterally decide who =
they consult and what they consult on. 

If we switch to a structure where the RPC is responsible to =
the full community then two things happen. First, they take on all of =
the role of the RSE above, which I am concerned is far too much of a =
change for the RPC.  Second, the only check and balance becomes the =
LLC, which now monitors the contract, manages performance, agrees the =
work program with the RPC, takes on the community role of ensuring that =
the RPC consults with the right people and consults on the right things =
and the role of ensuring the reporting to the community is adequate. I =
am concerned that is too large a role for the LLC and oversteps the =
community line. (Of course there is an alternative that nobody does some =
parts of this, but that is significantly worse). 

The structure I am suggesting inserts the RSAB into the =
mixture and by doing so both softens the changes to the RPC and spreads =
the checks and balances. The RSAB takes on the role of advising the RPC =
on community requirements, priorities, what needs consulting on and who =
should be consulted. While the RPC still makes the final call, we now =
have some separation of roles. The requirement for the RPC to inform the =
RSAB where it goes against its advice ensures transparency and adds =
another check to the process.  The RSWG/RSAB also take on the role =
of receiving the reports and are implicitly responsible for addressing =
the suitability of the reports. The role of the LLC is reduced to =
contract monitoring and performance management. The LLC doesn=E2=80=99t =
take on any community role but acts as an escalation point for the =
RSAB/RWSG. 

Each of these structures =
envisions a very different RPC.  If can agree which vision of the =
RPC we prefer then the answers all fall out from 
that. 

Jay

-- 
Jay Daley
IETF Executive =
Director

2.

Eliot



-- 
Rfced-future mailing =
list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future



-- 
Jay Daley
IETF =
Executive Director
jay@ietf.org




=

--Apple-Mail=_94632A90-5ADD-43D3-A6D3-22043DDA7E5E--


From nobody Tue Jun 29 17:19:20 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0BB3A409D for ; Tue, 29 Jun 2021 17:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.234
X-Spam-Level: 
X-Spam-Status: No, score=-2.234 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.338, RCVD_IN_DNSWL_BLOCKED=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=nthpermutation-com.20150623.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 fGspLmah5Bxe for ; Tue, 29 Jun 2021 17:19:16 -0700 (PDT)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 626643A409C for ; Tue, 29 Jun 2021 17:19:16 -0700 (PDT)
Received: by mail-qk1-x72a.google.com with SMTP id 19so617771qky.13 for ; Tue, 29 Jun 2021 17:19:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=180G6U75Lspvglb7DtANl/gVfsQaGP8czf1Ftcne4L8=; b=c5fuLOwESwYBSCqSy4na2LLWPtvdKEjHLETtjUXOeYEFyQkPFqr69ZiFE0mxxNuipJ c7U9eO2iOxgXO6zpDdB00F6jc52r8qGoIiV4vsMWEx23nf/FMzZFgByL36v6hzjMZy9P YFeTPB/vPBFForFpvBy8PQgsnmfQjolopjc88RZmhylg8sYCyMYEtSVssD7guJmVChiM 8lwvkX/fE7WkJsuUrjRdCjTodAfRx4OLyaSdwWvOLzDyr1T8cT5YdsxxL32nDgV2lXZm x+OD4yo5lJDncvZPyktzNpJ7lnqz/GFOZXYWDj/RTOvQonq12teo1Tw/qhu/0wUgEHCI T3Jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=180G6U75Lspvglb7DtANl/gVfsQaGP8czf1Ftcne4L8=; b=XJzAwdczdSS3uyx0UbkQ+hVSJtdi+ukFX5U69WSSoH8QAM6fInbOpZbywjsmC+69yw df/WfbKipU3wz4VbAb6Iz4vF2Ib/AsVLbg0bfQWnRu9oCve7zwT/c4YlTKIpQE30jWNe AVIPw1+jtOwy6TH1vRwyZII4V5wQpEoh/LgKuvDkKT4Y0Yyt+wY5914vWunshWEZQ4nm +0BiNsYuspQtuXlcLmAIB4sfZC+FsCI1fGuhoVj5Vas5oTobjwTfZosd5AraTWUdlxAE pLdDKhNBi+Ln4XFIjcxyPUFW8UVyqHRzqHj1PvqpWJwo/vpxNxoO7O8newbjFJ5J83s+ 2mrw==
X-Gm-Message-State: AOAM533Onjk7oZKLt/QraQ4fgkoI3t53DLzWpPT2XQasiI17apZqbQCn ptCBBAaQOzAk3ktxlaoiEd5PR1M6WizH5odAIng=
X-Google-Smtp-Source: ABdhPJyPJhVeVnNDlowQ4ZuGmyXnAizoabIPRVXc8QqJzjNGzRRdf+pkNZOfymfCd0RvLXfkTbObfA==
X-Received: by 2002:a37:a78d:: with SMTP id q135mr24955896qke.297.1625012354273;  Tue, 29 Jun 2021 17:19:14 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id x5sm12941724qke.92.2021.06.29.17.19.13 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Jun 2021 17:19:13 -0700 (PDT)
To: rfced-future@iab.org
References:  <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org>
From: Michael StJohns 
Message-ID: <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>
Date: Tue, 29 Jun 2021 20:19:11 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org>
Content-Type: multipart/alternative; boundary="------------5EDB05E8F2163AB9EC56FF5F"
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jun 2021 00:19:18 -0000

This is a multi-part message in MIME format.
--------------5EDB05E8F2163AB9EC56FF5F
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 6/29/2021 7:34 PM, Jay Daley wrote:
>> So I continue to see a role here for the RSEA as a communicator.
>
> That replaces
>
> RSAB -> RPC Manager   with   RSAB -> RSEA -> RPC Manager
>
> I don’t see how that helps anything.  Don’t forget the RSAB includes 
> the RSAB so it is actually  RSAB/RSEA -> RPC Manager.
>
> Jay


Hi Jay -

I think you're missing the point that the RSEA will be "on" much more 
than the RSAB.   The RSAB operates when convened, but, with the 
exception of the RSEA, consists of people stuck with "other duties as 
assigned" - e.g. additional duties mostly not related to their day job 
and probably not going to want to spend a lot of time doing things they 
may not be paid for.

Having the RSEA (*sigh* can we pick one name please?)  be the point 
person for day to day things and bring those things back to the RSAB 
when it convenes to have a discussion seems to me to make a lot more 
sense than direct and persistent management by committee.   I expect the 
RSAB to interpret the strategic direction model as proposed by the RSWG, 
but I would be very surprised if that gives rise to the RSAB meeting 
with the RPC or its representatives as frequently as might be needed by 
the RPC to resolve tactical issues.

Just my $.02. Mike



--------------5EDB05E8F2163AB9EC56FF5F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 6/29/2021 7:34 PM, Jay Daley wrote:

    

    

      

        
So I
            continue to see a role here for the RSEA as a communicator.

        

      

      


      

      
That replaces 

      


      

      
	RSAB
        -> RPC Manager   with   RSAB -> RSEA -> RPC Manager

      


      

      
I don’t see how that helps anything.  Don’t forget the RSAB
        includes the RSAB so it is actually  RSAB/RSEA -> RPC
        Manager.

      


      

      
Jay

    

    


    

    
Hi Jay - 

    

    
I think you're missing the point that the RSEA will be "on" much
      more than the RSAB.   The RSAB operates when convened, but, with
      the exception of the RSEA, consists of people stuck with "other
      duties as assigned" - e.g. additional duties mostly not related to
      their day job and probably not going to want to spend a lot of
      time doing things they may not be paid for.  

    

    
 Having the RSEA (*sigh* can we pick one name please?)  be the
      point person for day to day things and bring those things back to
      the RSAB when it convenes to have a discussion seems to me to make
      a lot more sense than direct and persistent management by
      committee.   I expect the RSAB to interpret the strategic
      direction model as proposed by the RSWG, but I would be very
      surprised if that gives rise to the RSAB meeting with the RPC or
      its representatives as frequently as might be needed by the RPC to
      resolve tactical issues.

    
Just my $.02. Mike

    


    

  


--------------5EDB05E8F2163AB9EC56FF5F--


From nobody Tue Jun 29 17:35:55 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D3B3A0DFC for ; Tue, 29 Jun 2021 17:35:53 -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, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 NsleIFS5ndJC; Tue, 29 Jun 2021 17:35:49 -0700 (PDT)
Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 7689A3A0DF9; Tue, 29 Jun 2021 17:35:48 -0700 (PDT)
From: Jay Daley 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_FFC99545-CCA4-4ADA-A9FE-459DD451522E"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Wed, 30 Jun 2021 12:35:45 +1200
In-Reply-To: <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>
Cc: rfced-future@iab.org
To: Michael StJohns 
References:  <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jun 2021 00:35:54 -0000

--Apple-Mail=_FFC99545-CCA4-4ADA-A9FE-459DD451522E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 30/06/2021, at 12:19 PM, Michael StJohns  =
wrote:
>=20
> On 6/29/2021 7:34 PM, Jay Daley wrote:
>>> So I continue to see a role here for the RSEA as a communicator.
>>=20
>> That replaces=20
>>=20
>> 	RSAB -> RPC Manager   with   RSAB -> RSEA -> RPC Manager
>>=20
>> I don=E2=80=99t see how that helps anything.  Don=E2=80=99t forget =
the RSAB includes the RSAB so it is actually  RSAB/RSEA -> RPC Manager.
>>=20
>> Jay
>=20
> Hi Jay -=20
>=20
> I think you're missing the point that the RSEA will be "on" much more =
than the RSAB.   The RSAB operates when convened, but, with the =
exception of the RSEA, consists of people stuck with "other duties as =
assigned" - e.g. additional duties mostly not related to their day job =
and probably not going to want to spend a lot of time doing things they =
may not be paid for. =20
>=20
> Having the RSEA (*sigh* can we pick one name please?)  be the point =
person for day to day things and bring those things back to the RSAB =
when it convenes to have a discussion seems to me to make a lot more =
sense than direct and persistent management by committee.   I expect the =
RSAB to interpret the strategic direction model as proposed by the RSWG, =
but I would be very surprised if that gives rise to the RSAB meeting =
with the RPC or its representatives as frequently as might be needed by =
the RPC to resolve tactical issues.
>=20
> Just my $.02. Mike
>=20
Point taken.  That seems to me to be a good reason to make the RSEA -> =
RPC Manager another required source of advice etc in addition to other =
sources (RSAB -> RPC Manager and RSWG -> RPC Manager) but not to replace =
them as proposed.  Your earlier point about the fungibility of roles =
however, does lead to a structure more like RSWG -> RSAB -> RSEA - RPC, =
which we should explore properly.

Whatever we choose, we have to be careful that whatever role we create =
for the RSEA doesn=E2=80=99t have a distant centre of gravity such that =
the role is under pressure to change right from the outset.  Some of =
these proposed changes concern me that is how we are setting it up.

Jay
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future

--=20
Jay Daley
IETF Executive Director
jay@ietf.org


--Apple-Mail=_FFC99545-CCA4-4ADA-A9FE-459DD451522E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 30/06/2021, at 12:19 PM, Michael StJohns <msj@nthpermutation.com> wrote:


 =20
    
 =20
  

    
On 6/29/2021 7:34 PM, Jay Daley =
wrote:

    

    

      

        
So I
            continue to see a role here for the RSEA as a =
communicator.

        

      

      


      

      
That replaces 

      


      

      
	RSAB
        -> RPC Manager   with   RSAB -> RSEA -> RPC =
Manager

      


      

      
I don=E2=80=99t see how that helps anything. =
 Don=E2=80=99t forget the RSAB
        includes the RSAB so it is actually  RSAB/RSEA -> RPC
        Manager.

      


      

      
Jay

    


    
Hi Jay - 

    
I think you're missing the point that the RSEA =
will be "on" much
      more than the RSAB.   The RSAB operates when convened, =
but, with
      the exception of the RSEA, consists of people stuck with "other
      duties as assigned" - e.g. additional duties mostly not related to
      their day job and probably not going to want to spend a lot of
      time doing things they may not be paid for.  

    
 Having the RSEA (*sigh* can we pick one name =
please?)  be the
      point person for day to day things and bring those things back to
      the RSAB when it convenes to have a discussion seems to me to make
      a lot more sense than direct and persistent management by
      committee.   I expect the RSAB to interpret the =
strategic
      direction model as proposed by the RSWG, but I would be very
      surprised if that gives rise to the RSAB meeting with the RPC or
      its representatives as frequently as might be needed by the RPC to
      resolve tactical issues.
Just my $.02. =
Mike
Point taken.  That seems to me to be a good reason to =
make the RSEA -> RPC Manager another required source of advice etc in =
addition to other sources (RSAB -> RPC Manager and RSWG -> RPC =
Manager) but not to replace them as proposed.  Your earlier point =
about the fungibility of roles however, does lead to a structure more =
like RSWG -> RSAB -> RSEA - RPC, which we should explore =
properly.

Whatever we choose, we have to be careful that whatever role =
we create for the RSEA doesn=E2=80=99t have a distant centre of gravity =
such that the role is under pressure to change right from the outset. =
 Some of these proposed changes concern me that is how we are =
setting it up.

Jay


    

  


-- 
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future



-- 
Jay Daley
IETF =
Executive Director
jay@ietf.org




=

--Apple-Mail=_FFC99545-CCA4-4ADA-A9FE-459DD451522E--


From nobody Tue Jun 29 18:38:44 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6DA3A1154 for ; Tue, 29 Jun 2021 18:38:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.235
X-Spam-Level: 
X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.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 tNs92PwijIrN for ; Tue, 29 Jun 2021 18:38:37 -0700 (PDT)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 7FB063A1152 for ; Tue, 29 Jun 2021 18:38:37 -0700 (PDT)
Received: by mail-qk1-x72c.google.com with SMTP id j13so825780qka.8 for ; Tue, 29 Jun 2021 18:38:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=UrBF/Txq1P93mU753WS4bafkDrE7HWXa59kRbGHh/xY=; b=a1tzWP/Vmj1Fw+jk26zQ9TSZcCjU/IrjInY+BHuHvj7QUZRRdW2LWdWkiWr4o/YIM0 sEM4LgCSHHUXbBc+HAm64RB+GA8+fIhdi1iFIzphIzVECRsShM2oMobMBRzaHnpOmpF3 nnYcTpOjW21hsfXs0kYCA6pJ+T0oFOVgaq43SCIW38RMjPOzC4trqyESVhqMVGUeU66o /w9vqp0LDorsnENZWbi6R/NJlbza7JK+LzQo7PJ5Prae2pZf0TLdHW1NUC//3ceEs4Hp Mwx9dzBTdMcoethLXr1tPd/ZW01ksK9yDVY7Dr0VSekqhSW32GKvKn23xuuacaKUy+9H ORDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=UrBF/Txq1P93mU753WS4bafkDrE7HWXa59kRbGHh/xY=; b=PFjsv5pO/Ti72oegWVj3suJuNywBwq/FWNSxX0g+Qszx8/QTBNU2jZAwOHPFLvKiT8 uVWUBiT4qq0UM/c1gcSdUTJ3ny4vIcVT9Nje8HEiBLoe0ZWGxBjMdOqvJOsBCqCwL+yb j1erAMxgfYlrv+ZiUdX4H1YdjwJB+Si55kRXOLWvFuoIRO6327v7MlxPFzwG7uC6kRCj pmQXcQlwon1/JREvlVMrpd3p47JHZhmjJs2H646O89r0S+YC1SY802T8+kJeGDNgxVTH PPSoYjBT0uqaH/EFMX76hBta5Hb4uKaLbxiSBj2rUGxLboFTi78FAG3HJI8flteYe6Ij 7arA==
X-Gm-Message-State: AOAM533tvvMmpSUV+mdb0+yJdMHHghu7RSfGNpW18TdGq2/9uMxBdn28 S6DAeMp4grW3x2rH1qZXYN0V9HXxweYRhBfW5+w=
X-Google-Smtp-Source: ABdhPJz1W3N6mDfVcoha0uv2GSakyu9ckl5ASj0CCYuNK74iSFyTk2MONhrJf5hKTwwThxu3vfByCw==
X-Received: by 2002:a05:620a:14b7:: with SMTP id x23mr5347789qkj.451.1625017115105;  Tue, 29 Jun 2021 18:38:35 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id p187sm12728360qkd.57.2021.06.29.18.38.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Jun 2021 18:38:34 -0700 (PDT)
To: Jay Daley 
Cc: rfced-future@iab.org
References:  <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com> 
From: Michael StJohns 
Message-ID: <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com>
Date: Tue, 29 Jun 2021 21:38:32 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jun 2021 01:38:43 -0000

Hi Jay -

On 6/29/2021 8:35 PM, Jay Daley wrote:
> Point taken.  That seems to me to be a good reason to make the RSEA -> 
> RPC Manager another required source of advice etc in addition to other 
> sources (RSAB -> RPC Manager and RSWG -> RPC Manager) but not to 
> replace them as proposed.  Your earlier point about the fungibility of 
> roles however, does lead to a structure more like RSWG -> RSAB -> RSEA 
> - RPC, which we should explore properly.
>
> Whatever we choose, we have to be careful that whatever role we create 
> for the RSEA doesn’t have a distant centre of gravity such that the 
> role is under pressure to change right from the outset.  Some of these 
> proposed changes concern me that is how we are setting it up.

Actually there shouldn't be  RSWG -> RSAB nor RSWG -> RPC.   The RSWG is 
solely a strategic body writing documents that describe the policy of 
the RFC series.  The RSWG's sole and only form of interaction with the 
RPC here should be at the document level.    The interaction with the 
RSAB is more nuanced: the arrow above implies some level of oversight or 
direction that isn't in the model - there's interaction between the two, 
but no directive actions from one to the other:

RSWG --- Doc submission --- > RSAB --- Doc approval  ---> RFC Editorial 
Series Document

RFC Editorial Series --- Policy ---- > RSAB   <--> RPC
                             ^            ^          ^
                             |_____> |_> RSEA <_|

There are both  RSAB -> RPC and RSEA -> RPC relationships, but their 
forms of interaction will be a bit different.  Month to month or quarter 
to quarter vs day to day would be one way to scope it.

If the documents don't answer the policy questions, the RSAB may ask for 
input from the RSWG in forming its advice to the RPC, or could suggest 
the RSWG write a new document, but having the RSWG with a direct path to 
the RPC seems a likely failure mode.


With respect to the RSAB/RSEA and their roles vis a vis the RPC, I'd 
take a look at https://ballotpedia.org/Council-manager_government as I 
think it sort of describes the model I'm thinking of.  It's not exact 
since the RSEA is a full member of the RSAB, but the division of labor 
seems to be more correct than not.

Mike



From nobody Tue Jun 29 19:27:52 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357273A1326 for ; Tue, 29 Jun 2021 19:27:49 -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, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 Q4DuDlG8cP-7; Tue, 29 Jun 2021 19:27:44 -0700 (PDT)
Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id EBE3F3A1321; Tue, 29 Jun 2021 19:27:43 -0700 (PDT)
From: Jay Daley 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_A1921055-210C-4B27-BAAE-40BF9AE4D10A"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Wed, 30 Jun 2021 14:27:41 +1200
In-Reply-To: <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com>
Cc: rfced-future@iab.org
To: Michael StJohns 
References:  <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>  <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jun 2021 02:27:49 -0000

--Apple-Mail=_A1921055-210C-4B27-BAAE-40BF9AE4D10A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thanks Mike

> On 30/06/2021, at 1:38 PM, Michael StJohns  =
wrote:
>=20
> Hi Jay -
>=20
> On 6/29/2021 8:35 PM, Jay Daley wrote:
>> Point taken.  That seems to me to be a good reason to make the RSEA =
-> RPC Manager another required source of advice etc in addition to =
other sources (RSAB -> RPC Manager and RSWG -> RPC Manager) but not to =
replace them as proposed.  Your earlier point about the fungibility of =
roles however, does lead to a structure more like RSWG -> RSAB -> RSEA - =
RPC, which we should explore properly.
>>=20
>> Whatever we choose, we have to be careful that whatever role we =
create for the RSEA doesn=E2=80=99t have a distant centre of gravity =
such that the role is under pressure to change right from the outset.  =
Some of these proposed changes concern me that is how we are setting it =
up.
>=20
> Actually there shouldn't be  RSWG -> RSAB nor RSWG -> RPC.   The RSWG =
is solely a strategic body writing documents that describe the policy of =
the RFC series.  The RSWG's sole and only form of interaction with the =
RPC here should be at the document level.    The interaction with the =
RSAB is more nuanced: the arrow above implies some level of oversight or =
direction that isn't in the model - there's interaction between the two, =
but no directive actions from one to the other:

My arrows were only meant to show the flow of requirements and =
priorities (and advice on those) that the RPC builds its workplan from, =
not any form of oversight or direction. =20

>=20
> RSWG --- Doc submission --- > RSAB --- Doc approval  ---> RFC =
Editorial Series Document
>=20
> RFC Editorial Series --- Policy ---- > RSAB   <--> RPC
>                             ^            ^          ^
>                             |____________+_> RSEA <_|
>=20
> There are both  RSAB -> RPC and RSEA -> RPC relationships, but their =
forms of interaction will be a bit different.  Month to month or quarter =
to quarter vs day to day would be one way to scope it.

I concur.

>=20
> If the documents don't answer the policy questions, the RSAB may ask =
for input from the RSWG in forming its advice to the RPC, or could =
suggest the RSWG write a new document, but having the RSWG with a direct =
path to the RPC seems a likely failure mode.

Fine by me.  I am very comfortable with your second diagram above (which =
I=E2=80=99ve fixed up slightly).

> With respect to the RSAB/RSEA and their roles vis a vis the RPC, I'd =
take a look at https://ballotpedia.org/Council-manager_government as I =
think it sort of describes the model I'm thinking of.  It's not exact =
since the RSEA is a full member of the RSAB, but the division of labor =
seems to be more correct than not.

That seems to me to describe the current IAB/RSOC/RSE/RPC model rather =
than the new one being proposed. =20

My mental image of the new RSEA as defined so far is a floating, =
independent publishing expert who gets involved in everything related to =
RFC series policy and policy implementation, reads the lists, talks to =
people, researches the issues, provides advice widely, produces drafts =
to stimulate thinking and potentially initiate policy discussions, and =
communicates what they see/hear/think to the RSWG, RSAB and RPC alike.  =
This fits closely with your diagram and with the title of RSA.

Crucially though, in the structure proposed so far they have no =
responsibility.  If they are to be given responsibility, such as a =
stream manager role or the main communication point for the RPC, then we =
need to make sure they have the authority to deliver that and there is =
appropriate accountability in place.  The proposals I=E2=80=99ve seen so =
far do neither.

Jay

>=20
> Mike
>=20
>=20

--=20
Jay Daley
IETF Executive Director
jay@ietf.org


--Apple-Mail=_A1921055-210C-4B27-BAAE-40BF9AE4D10A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Thanks Mike

On 30/06/2021, at 1:38 =
PM, Michael StJohns <msj@nthpermutation.com> wrote:

Hi Jay -

On 6/29/2021 8:35 PM, =
Jay Daley wrote:
Point =
taken.  That seems to me to be a good reason to make the RSEA -> =
RPC Manager another required source of advice etc in addition to other =
sources (RSAB -> RPC Manager and RSWG -> RPC Manager) but not =
to replace them as proposed.  Your earlier point about the =
fungibility of roles however, does lead to a structure more like RSWG =
-> RSAB -> RSEA - RPC, which we should explore properly.

Whatever we choose, we have to be careful that =
whatever role we create for the RSEA doesn=E2=80=99t have a distant =
centre of gravity such that the role is under pressure to change right =
from the outset.  Some of these proposed changes concern me =
that is how we are setting it up.

Actually there shouldn't be  RSWG -> RSAB nor RSWG =
-> RPC.   The RSWG is solely a strategic body writing documents =
that describe the policy of the RFC series.  The RSWG's sole =
and only form of interaction with the RPC here should be at the =
document level.    The interaction with the RSAB is more =
nuanced: the arrow above implies some level of oversight or =
direction that isn't in the model - there's interaction between the =
two, but no directive actions from one to the other:

My arrows were only meant to show =
the flow of requirements and priorities (and advice on those) that the =
RPC builds its workplan from, not any form of oversight or =
direction.  


RSWG --- Doc submission --- > =
RSAB --- Doc approval  ---> RFC Editorial Series Document

RFC =
Editorial Series --- Policy ---- > RSAB   <--> RPC
                =
            ^         =
   ^          ^
  =
                    =
      |____________+_> RSEA <_|

There are both  RSAB -> RPC and RSEA =
-> RPC relationships, but their forms of interaction will be a bit =
different.  Month to month or quarter to quarter vs day to day =
would be one way to scope it.

I concur.


If the documents don't answer =
the policy questions, the RSAB may ask for input from the RSWG in =
forming its advice to the RPC, or could suggest the RSWG write a new =
document, but having the RSWG with a direct path to the RPC seems a =
likely failure mode.

Fine by =
me.  I am very comfortable with your second diagram above (which =
I=E2=80=99ve fixed up slightly).

With respect to =
the RSAB/RSEA and their roles vis a vis the RPC, I'd take a look at https://ballotpedia.org/Council-manager_government as I =
think it sort of describes the model I'm thinking of.  It's =
not exact since the RSEA is a full member of the RSAB, but the division =
of labor seems to be more correct than not.
That seems to me to describe the current IAB/RSOC/RSE/RPC =
model rather than the new one being proposed.  

My mental image of the =
new RSEA as defined so far is a floating, independent publishing expert =
who gets involved in everything related to RFC series policy and policy =
implementation, reads the lists, talks to people, researches the issues, =
provides advice widely, produces drafts to stimulate thinking and =
potentially initiate policy discussions, and communicates what they =
see/hear/think to the RSWG, RSAB and RPC alike.  This fits closely =
with your diagram and with the title of RSA.

Crucially though, in the structure =
proposed so far they have no responsibility.  If they are to be =
given responsibility, such as a stream manager role or the main =
communication point for the RPC, then we need to make sure they have the =
authority to deliver that and there is appropriate accountability in =
place.  The proposals I=E2=80=99ve seen so far do neither.

Jay


Mike



-- 
Jay Daley
IETF Executive =
Director
jay@ietf.org

=

--Apple-Mail=_A1921055-210C-4B27-BAAE-40BF9AE4D10A--


From nobody Tue Jun 29 22:56:25 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0257F3A098D for ; Tue, 29 Jun 2021 22:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level: 
X-Spam-Status: No, score=-2.089 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_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 jGkUjqOBBKDm for ; Tue, 29 Jun 2021 22:56:17 -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 F21D43A098B for ; Tue, 29 Jun 2021 22:56:16 -0700 (PDT)
Received: from [10.61.144.51] ([173.38.220.45]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15U5u2O2065591 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 30 Jun 2021 07:56:03 +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=1625032573; bh=xEYYMIQnf+q+8NpLXRecED2VOXilyxfqXOkNGOMi/Us=; h=To:Cc:From:Subject:Date:From; b=D5pojoNL2AQR7y89GLTXkOxxx4tG63K5rL/zK3GNt6TrdHsuzqf95hVYRbGqYckww F03b+tVzfJFDCBEkTE0X5AI77IAmB4e43yE79Q70TfaUWD6XGWXRXMj0JhyptYMnVT sbA6BbipgsXT2IxIdeu0969Su5Us41Gf+4ifFsCE=
To: rfced-future@iab.org
Cc: EKR 
From: Eliot Lear 
Message-ID: <612bacba-0bdb-32bb-5369-19486742a111@lear.ch>
Date: Wed, 30 Jun 2021 07:55:52 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zTIs0yMJuLD7ajGakqSXHkUVsk9KAulVN"
Archived-At: 
Subject: [Rfced-future] Issue 68: we prohibited in person meetings and design teams
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jun 2021 05:56:23 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--zTIs0yMJuLD7ajGakqSXHkUVsk9KAulVN
Content-Type: multipart/mixed; boundary="YI5jkeMY9v4MaSAIuS4hRaKMYAuFNl2Mn";
 protected-headers="v1"
From: Eliot Lear 
To: rfced-future@iab.org
Cc: EKR 
Message-ID: <612bacba-0bdb-32bb-5369-19486742a111@lear.ch>
Subject: Issue 68: we prohibited in person meetings and design teams

--YI5jkeMY9v4MaSAIuS4hRaKMYAuFNl2Mn
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

EKR pointed out that our wording might go a bit too far when we say:

> When the RSWG is formed, all
> discussions shall take place on an open email discussion list.
> Subsequently, the RSWG may decide by rough consensus to use
> additional tooling or forms of communication (e.g., GitHub as
> specified in [RFC8874]) as long as they are consistent with
> [RFC2418].

How about this:

> When the RSWG is formed, all discussions shall take place on an open=20
> email discussion list or through in person meetings. Subsequently, the =

> RSWG may decide by rough consensus to use working methods(e.g., GitHub =

> as specified in [RFC8874] or design teams) as long as they are=20
> consistent with [RFC2418].

Eliot



--YI5jkeMY9v4MaSAIuS4hRaKMYAuFNl2Mn--

--zTIs0yMJuLD7ajGakqSXHkUVsk9KAulVN
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDcB2gFAwAAAAAACgkQh7ZrRtnSejNU
gQgAoIUn19Tky0nSLxF0RwHGc859+FRLUrcnzGFL/BDnyKIH3CpLjIE4GVR+s4gbr8GRakIeqTyi
fMIiGYG4DqS+08WZmi3bV3uHiWtQkgrQblc2z8Y3EAx1JT0pGULsD0l5C98wYgZuciSvLka4Be4X
v6mUn2bzVL2H+P2Tx8TD8AHUyNSkFzFLwErd+X96vZ8U+scFqMNXfAxNfVaW/T+k1Oy9J5tc/r+n
lCjGDZXJF5Z6wIam3fCXFiC3sa2mW4stbd9bOUTOFDDCI1Mph5T0PBUj1VZvFjj10YfiaGOCkFGx
oScEQjZdpPWGVCzzhsgX/Iq5oR7ZiXsz6iZX203ZEg==
=jvsG
-----END PGP SIGNATURE-----

--zTIs0yMJuLD7ajGakqSXHkUVsk9KAulVN--


From nobody Tue Jun 29 23:18:36 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15083A0AB7; Tue, 29 Jun 2021 23:18:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level: 
X-Spam-Status: No, score=-2.427 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, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 vobDFtBOYOlr; Tue, 29 Jun 2021 23:18:30 -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 B37863A0AB4; Tue, 29 Jun 2021 23:18:29 -0700 (PDT)
Received: from [10.61.144.51] ([173.38.220.45]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15U6IJSL065850 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 30 Jun 2021 08:18:19 +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=1625033906; bh=Sl3ed2Gv7sznHKn+ih+NBvOli4So+s/l6Bmhg/g/SEU=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=HRpECnvs6hW5KGmn1+NtRiVZ9Bec+jt42/9Ab5QFbUCcdcEBR7AOhcvy8ETDTfyjH iiiytmOmI7fFtZZ0Z6HVUL/sWkn0/llub8gUBJUTf03Qs9qB/9rj0lm7RGQkRfl+7J AJcxDFTkdwNSSMm0k5Tvk3GTCRBn5oL/KjXpUBl4=
To: Jay Daley , Michael StJohns 
Cc: rfced-future@iab.org
References:  <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>  <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com> 
From: Eliot Lear 
Message-ID: <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch>
Date: Wed, 30 Jun 2021 08:18:18 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2xCMEZKToB6X22C8SOJ9IyP4OkjhmR4Fy"
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jun 2021 06:18:35 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--2xCMEZKToB6X22C8SOJ9IyP4OkjhmR4Fy
Content-Type: multipart/mixed; boundary="UTGA6nYzuWkdDXyyYAMSFNHeXHn7gJzWN";
 protected-headers="v1"
From: Eliot Lear 
To: Jay Daley , Michael StJohns 
Cc: rfced-future@iab.org
Message-ID: <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch>
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
References: 
 <896D122F-C341-4B1F-9467-48040F691A42@ietf.org>
 <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com>
 <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org>
 <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>
 
 <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com>
 
In-Reply-To: 

--UTGA6nYzuWkdDXyyYAMSFNHeXHn7gJzWN
Content-Type: multipart/alternative;
 boundary="------------48B5C3C2ECE791F07B2589A2"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------48B5C3C2ECE791F07B2589A2
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Sooo....

On 30.06.21 04:27, Jay Daley wrote:
>> RFC Editorial Series --- Policy ---- > RSAB =C2=A0 <--> RPC
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ^ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^ =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 |____________+_> RSEA <_|
>>
>> There are both =C2=A0RSAB -> RPC and RSEA -> RPC relationships, but th=
eir=20
>> forms of interaction will be a bit different. =C2=A0Month to month or =

>> quarter to quarter vs day to day would be one way to=C2=A0scope it.
>
> I concur.

I *think* this is where we're at:

  * The RSWG establishes policy, with input from the community, the
    RSAB, and the RSEA.
  * The RSAB approves that policy.
  * The RPC periodically reports to the RSAB on how it is implementing
    that policy.
  * The RSEA provides expertise to the RPC and RSAB on how to implement
    the policy on an ongoing and operational basis, perhaps raising
    issues along the way for both the RSAB and community to consider.

If issues arise with particular policies, the RPC still brings them to=20
the RSAB who interprets the policy, and provides interim guidance to the =

RPC, informing the RSWG of those interpretations. This is roughly in=20
line with what we said re Issue 60 (Resolution of disputes between the=20
RPC and authors with cross-stream implications).

This provides the RPC expert advise on an ongoing basis, and direct=20
communications to the RSAB.=C2=A0 It does not provide direct commuication=
s=20
between the RPC and the RSWG, but reports to the RSAB would be public.

Is this what people want?

Eliot


--------------48B5C3C2ECE791F07B2589A2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Sooo....

    

    
On 30.06.21 04:27, Jay Daley wrote:
    

    

      
RFC
          Editorial Series --- Policy ---- > RSAB =C2=A0 <--> RP=
C

          =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0^ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^

          =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |____________+_> RSEA <_|=


        

        There are both =C2=A0RSAB -> RPC and RSEA -> RPC relationsh=
ips,
        but their forms of interaction will be a bit different. =C2=A0Mon=
th
        to month or quarter to quarter vs day to day would be one way
        to=C2=A0scope it.

      

      

      I concur.

    

    
I think this is where we're at:

    
    
      
  • The RSWG establishes policy, with input from the community,
        the RSAB, and the RSEA.
    • 
      
  • The RSAB approves that policy.
    • 
      
  • The RPC periodically reports to the RSAB on how it is
        implementing that policy.
    • 
      
  • The RSEA provides expertise to the RPC and RSAB on how to
        implement the policy on an ongoing and operational basis,
        perhaps raising issues along the way for both the RSAB and
        community to consider.
    • 
    

    
If issues arise with particular policies, the RPC still brings
      them to the RSAB who interprets the policy, and provides interim
      guidance to the RPC, informing the RSWG of those interpretations.=C2=
=A0
      This is roughly in line with what we said re Issue 60 (Resolution
      of disputes between the RPC and authors with cross-stream
      implications).

    
This provides the RPC expert advise on an ongoing basis, and
      direct communications to the RSAB.=C2=A0 It does not provide direct=

      commuications between the RPC and the RSWG, but reports to the
      RSAB would be public.

    
Is this what people want?

    
Eliot

    

  


--------------48B5C3C2ECE791F07B2589A2--

--UTGA6nYzuWkdDXyyYAMSFNHeXHn7gJzWN--

--2xCMEZKToB6X22C8SOJ9IyP4OkjhmR4Fy
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDcDKoFAwAAAAAACgkQh7ZrRtnSejP9
fQf+PJXa3AD7RQLmGTNCPcJJvmiMdAxpih6FWTb1qxZJUjfbZIVWu3hM0izJpBMdozo/bii+fGvP
DFTYn5776sZGKMkuBnj0yquQYboxl/LYv9UzKwGi78mMBBtayhnLOrfE0BL/+nJplnE3iV8rZC1t
KwkSMlB3v23jJGsL8QfIchziOTXTL9YUHptCRMoRs+aViIbMAYIV2OJUZHnAjyAKvxYxXpMVJ+EW
DJ7prtNt42MHjlW8+813DyzmcQNv/NKSwXI7pqcSxiUrlqWKOKQtBqXkWoGbfGLkCPsFDamcjH2S
iiDEJ9g+BT56ITfIsVpDBLbTFqxbTu4M10sn7qO35A==
=V/SE
-----END PGP SIGNATURE-----

--2xCMEZKToB6X22C8SOJ9IyP4OkjhmR4Fy--


From nobody Tue Jun 29 23:21:12 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69303A0AD1 for ; Tue, 29 Jun 2021 23:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.237
X-Spam-Level: 
X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=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 (1024-bit key) header.d=itaoyama.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 HAuOlh9ipTKS for ; Tue, 29 Jun 2021 23:21:05 -0700 (PDT)
Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400137.outbound.protection.outlook.com [40.107.140.137]) (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 9A4773A0AC6 for ; Tue, 29 Jun 2021 23:21:05 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YsBTwTmH9JpQtHqlNOJHcU629JoSjYlsH2CqN6XQ1njTfdJGqdz6/4YNC87jhZb2e/eWAM54HuHY+1kA7qcwpV9hGL6qLRxTRdFGfvlhXYwI3/nLVf2VJA3dfzod4QkjB+YafGe6lj72BxENu4n8vCE1C3gM7uJIrkLUXkQTux2jBErD+LocLoN7udekn6O7d+6cLf+H15lDMOj+eqCLvdeooticwnnECZl0715qXb/UdhaFQwDooOuV30DGSk+WvaPVXOccaRI/+zPDRv1H+0S0XwMBaBPKyvCDLyJCCQ//aUB88F3gzfTfkJGX/LPUouv7w6FWDmichc9RkoPsQg==
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-SenderADCheck; bh=XBUxMnp8XnW55qcvDirWN3pl6LV+VJouIUDAqMPHgSQ=; b=d9v25O3JmjL9Bjm+cbbZkLU87hzFnoLl+uAqOV47Ip7ua+K8vhlGg589u9pIFWci0T93cZ9qZUHa2N2j9iv2M4fwAbwY0XbozKWKgpvVMQC7RFk7wes6CsXaTwZzG/NCFfGfGetxmnEge2TGUYfIjci3ELXl5ObudmLJSDrKAgIiUIFXU17I1fmCA2j74Pm1sioOCUhKLhwFmf0Pds51vshm+HZaOnZY8gPzIQoP2WD+Ldrlp/Wdu9bYmFIm5sX/CNlrXPVGUXgUYT2ugfJYwGbyov6YwoihQtgW7cofM+u86N8z7pzRo0sTcpLd9ct0xFj2qrNUaawwoG8DGBT2Hw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XBUxMnp8XnW55qcvDirWN3pl6LV+VJouIUDAqMPHgSQ=; b=Yzz66orX32Wu46CmE+WLkhAqQt+VJwkQ9W5MStdeyw1oKgmG/pRoTBvJMZYPiYMdwRGVY2/yykTk55RHLsU4989tc6BJK4X1NNlAKNkzATbn6vyZmNu1nL+avxpzu4JuNC7rZf31Ut5CWeom5UOnJuB4r0vFZ5JNlaviqbDtuUg=
Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=it.aoyama.ac.jp;
Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYYPR01MB6683.jpnprd01.prod.outlook.com (2603:1096:400:c8::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.19; Wed, 30 Jun 2021 06:21:02 +0000
Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::4c2b:a1b2:2e7f:358]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::4c2b:a1b2:2e7f:358%8]) with mapi id 15.20.4264.026; Wed, 30 Jun 2021 06:21:02 +0000
To: adrian@olddog.co.uk, 'Eric Rescorla' , 'Eliot Lear' 
Cc: rfced-future@iab.org
References:   <128201d76cea$a9326c00$fb974400$@olddog.co.uk>
From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= 
Organization: Aoyama Gakuin University
Message-ID: <86cb89b4-d227-0ecd-fb0a-99d0369750c9@it.aoyama.ac.jp>
Date: Wed, 30 Jun 2021 15:20:58 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
In-Reply-To: <128201d76cea$a9326c00$fb974400$@olddog.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [133.2.210.39]
X-ClientProxiedBy: TY2PR01CA0015.jpnprd01.prod.outlook.com (2603:1096:404:a::27) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [133.2.210.39] (133.2.210.39) by TY2PR01CA0015.jpnprd01.prod.outlook.com (2603:1096:404:a::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.22 via Frontend Transport; Wed, 30 Jun 2021 06:21:02 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: eb927edf-db64-4cf8-92d8-08d93b8f3c1d
X-MS-TrafficTypeDiagnostic: TYYPR01MB6683:
X-Microsoft-Antispam-PRVS: 
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: Yssxow3fq0btn/gQB9kUAFzOywhQwcCtmlNcIkJJIas65Vs1g/wGz0yLzB6W7P+c0DdjXIqxYALUkDDrG9BqzXsjTUucG/SN00W/8gAQUjx+DrxyscjshJmq19BBqoLpJ3G8jtU3aZqX3LGMK80FKj6EIYR736CXuCVj7Z8x2I+nMpDyIhWCav/uSR0LEZOdhjILjN1Y35P7jxf+65ZApmC8VU3iZ5R/+jyDCmrwpVsqYQN3stIDy+aREpvyHvCDuKOLG82TP6AMLXrA839dXUERSTSEd8OJv2NpWYKoc2dlWck/1FZlZn0N1QbenFL1W4oXnC/EKVdr3F1cvtsT7TqKYImZMDI0CNYa06hWItTKKp7pH7vHrf9NFBeh6jlzvjdXfxfvvz1ii84VrEVm5mv+BDBdRKb+EPAfpmWd1h/Eez5hMCQ5UkceZw0cvQYh0xXYUx80goRmVgLZTX6gQc3DPwteA7+QsCe2QT+xhYsveS24QMXgzGYfcGRa1u+aqUcMDDF1gJLhYUhs1q9ZeLaxx3X81PC8/R/8d6Sc5v5SSvIoXfxQQgNI9WoNvPmiBTo+90po2MoG4+2JAfIMp4/iN0DWuPAfDF9Uvee/N12O0ghADs+ajkL+AceKGU7Jo+Ejc96F+Z42VVTWC3xPVcnPvazmzRWGvzCd26l5/NpeahsObX08ntln1LITm4B3AxkrKJ9mD6KwciEqErrsHJRql00iojzA11BN/FqSHP6J0fbgY/uSgPWf6wI74YIDO/CZsqzt+MFUlI8R19pstPCP9L0pqia9IjjdKAwF1Wk=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE;  SFS:(136003)(366004)(346002)(396003)(39830400003)(376002)(186003)(31696002)(16526019)(86362001)(478600001)(26005)(38100700002)(38350700002)(5660300002)(786003)(2616005)(956004)(53546011)(6486002)(110136005)(36916002)(316002)(52116002)(16576012)(83380400001)(66476007)(66556008)(8936002)(6706004)(6666004)(2906002)(66574015)(4326008)(66946007)(31686004)(8676002)(3940600001)(45980500001)(43740500002); DIR:OUT; SFP:1102; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NWdGTzIrWFRJV2NjUkJxQWw0TkdqSHBLOHRDbndqMlYrVXlHRmhDRmVJbzNJ?= =?utf-8?B?Ukx1d2F3bnF1WE5qbFJlanFla3hZekFpTTNXcVBWUEp6aDFEU09KeWxKRno2?= =?utf-8?B?WVVUYzZ6MGU1Q050QnpQSVlqR2txMWtidzVJOU9mb1BueDIzd2lGVDFDM005?= =?utf-8?B?dlM3V005TU10aE9JUDBnWllMYXpaaGNLOW5rTmN3VDVtbDZOSDdVOVBPa09G?= =?utf-8?B?VCs1OEJySW1wMGN0Z052RXZseDRHNkNPR1pTSStZdEMzSkoxRmhIckZONFNN?= =?utf-8?B?L3p4MHlZb054RE80M1A2bVZuMnFjNml1SjVjcWI0dHpoTHpCM0daL3BQVWRu?= =?utf-8?B?NzM4SDZnVmJYTDlaMWhGbnFZN2tYR3BER0VCbEhQMDRVMVNuTlZrV3VkWGZh?= =?utf-8?B?V29YQnhRdjRoTTJrWUpWeU42dUpxRlNzUmNQYWkvRjZlM0x5ZzVCYi82U1lQ?= =?utf-8?B?NkYwWDZrdENLTVNZeEozNFZYbzdBMjdocXBjNFZJVTc3YzJYZ2pXTytwZ1Uy?= =?utf-8?B?M2hPbXA3YW02MGVJQzN4d1N6K2Nva2VCbVp0OFU3eTdMZkIwR3Q1c29Tck5V?= =?utf-8?B?ZHhNbWtacGU2bG5DME5xTCtTc2ZtSkdScTFyNzVvbFpyaWdTYVl4UStoYlpt?= =?utf-8?B?N0liNE8wTmxrRTQxa2Jtb3Q4SnhqdExtMkR6ek85VnNQL2RNUmU3ZWZXY3pR?= =?utf-8?B?SXpKOFA2bnpnaTllemZBYjJXd1Z1TENSdUd4dThBM1VycDhGMzlPaUg3VnNL?= =?utf-8?B?SWFXSWdpWnhiaTZmTkQ4cU4weXpIUUdha0pHMVU3Z0NXQ1dRUGx3MG9oQmQ0?= =?utf-8?B?d3o1MkNmQ0F2N1VVZ2tXNkhLWGpOcFg5aGRUdjB0bDZFT1F3QmdIZTc4NzUy?= =?utf-8?B?eXB6YytaWW9nWVc2MGJFNE9saTRWMlFhT0VocGZwWDk4akQ3S3haZDVUQlZE?= =?utf-8?B?ZzNvZkxCNStkRm9UZUJZaFllQlZ2UHYxU1FjZU85ZTIxaWtWTmRqMDBiL3Q5?= =?utf-8?B?d3h5Z0x1S0JiK0VHOFNlUEdIa3NORTh1ajFBWXBUMGkrYndmaHU3V2xsdVp1?= =?utf-8?B?Zzd1d1NJUjNoVm9CVktBM2VCNlp2MjRvNnJIZ0Z0UWo1YVY4Y3pEcUwwaUh4?= =?utf-8?B?Z1JzdU8xWG9CM1J6b3NveDRYOUlZc0FodDN5RVpJNGdET2ZnTGw3MURxSDRp?= =?utf-8?B?a1U5NzgycjBvN2RHWWpoa0gvN1ZvMkFGZE9YMXNXd1ZxZERrWkpWdW41aUFG?= =?utf-8?B?aG1kdzRpeGRaYmJZUmNNQ1Naa2YrbmVVOElpVVFNTWp0VlF4Q0hUS1BEN0pv?= =?utf-8?B?RWRlcGVtMVZiM2ZIWG52ZkJRME9iTElQTldGK1J3aFUxYk9Jem80dUhlMjRK?= =?utf-8?B?cUMxZng5ZjFmcXNEc015ck9Ra1h3OERDcExEMEh0T1lZWGR2cnpqRmRML2ta?= =?utf-8?B?dk44YXlyQVdQMlVKUEh0NFN4bmU5NEtnVk1EZzE1aWxienV3c3IrYy9KcHR2?= =?utf-8?B?WEhKNndaSVpScTR0VFlaNnlmVTVvZDBpd09kd2hKVmxra2NjTit1VkVod05i?= =?utf-8?B?MHZNR0QxRmo4RlZIZUZiMHFCdUxyOVNPaUJtY3ZOVUR2ZU90UTZSdkhpNmNV?= =?utf-8?B?ZHJCT0pIL2lBT0p1L3lDQmtGV3g4TEtBWDZ5K1ZmeS9TZmpmUXQwQ2dNZ3Zj?= =?utf-8?B?cTRJMUR3UmRGMHdINFdjRm5vNzhlcno4UVdHMlFoMVo3UUZGSEJZR2V2ZHhG?= =?utf-8?Q?EIYxxEtsxKME6YjgraPM40Onpj8EoqqJtk8qBNo?=
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: eb927edf-db64-4cf8-92d8-08d93b8f3c1d
X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jun 2021 06:21:02.5634 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: N6VcSY/YNj/3ST55SZoFGDAPTK0hmK0KnaEWe9ozNbFVJQP7vKjaSEqPx502vEyTM+hdj8umv30NGM8UgubInw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYPR01MB6683
Archived-At: 
Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jun 2021 06:21:11 -0000

On 2021-06-29 22:28, Adrian Farrel wrote:
> I agree with Ekr about replacing for any reason.

I generally agree, too, also with what is said below. However, I think 
we should keep something about continuity in the text. The idea, as far 
as I understand, is clearly NOT to have a different delegate every other 
meeting.

Regards,   Martin.


>   
> 
> I don’t oppose any of these delegation rules, I just find them odd.
> 
>   
> 
> The delegating body remains completely responsible for the actions of the delegate, so:
> 
> *	Why does it matter where the delegate is drawn from?
> *	Why set specific term limits in this document (surely that is up to the delegating body)?
> *	Why can the IRTF chair and ISE also delegate?
> 
>   
> 
> I’d point out that the IESG continues to be under work-load pressure. Although this is only a small task (being a voting member of the RSAB), it is an additional task – why wouldn’t the IES delegate externally and just receive reports back from the delegate?
> 
>   
> 
> It would presumably also be true that the delegate (voting member) is supposed to participate in the WG (although the delegating body/person) can also participate. This may be a large draw on time, and I assume that the IESG and IAB might be glad of the option to delegate that activity.
> 
>   
> 
> Of course, in practice the IESG are not well known for letting go of the levers of power, but I don’t see why we should explicitly prevent them from doing that.
> 
>   
> 
> Sorry if I missed this discussion already.
> 
>   
> 
> Adrian
> 
>   
> 
> From: Rfced-future  On Behalf Of Eric Rescorla
> Sent: 29 June 2021 14:03
> To: Eliot Lear 
> Cc: rfced-future@iab.org
> Subject: Re: [Rfced-future] Issue 38: Delegates for RSAB members
> 
>   
> 
>   
> 
>   
> 
> On Mon, Jun 28, 2021 at 10:54 PM Eliot Lear  > wrote:
> 
> 
>    Martin Thomson raised an issue that the delegates should come from the
> bodies themselves.  He wrote the following:
> 
>> The current document specifically names the chairs of the IETF, IAB,
>> and IRTF as members of the board. This is unnecessary and goes against
>> efforts to distribute critical functions in these bodies, for the IESG
>> and IAB in particular. The board should instead be composed of a
>> delegate from each stream, who is empowered to act for that stream.
>> This might be the chair, but it does not need to be.
>>
> This part of the issue is resolved in current text (see below).
>>
>> However, it would be reasonable for the group to insist that the
>> appointment is made from the IESG or IAB, excluding any ex officio
>> positions in those bodies (which would rule out the IAB chair as
>> representative from the IESG). That would be done on the basis that
>> appointees to these roles are answerable to the community via the
>> NomCom in addition to any accountability they have to their stream
>> management. That would mean that the ISE and IRTF chair are stuck with
>> the RSAB position, having no pool to draw on.
>>
> The current text reads:
> 
>>     The voting members of the RSAB shall be as follows:
>>
>>     o  One delegate representing the IETF stream, appointed by the IESG
>>
>>     o  One delegate representing the IAB stream, appointed by the IAB
>>
>>     o  The IRTF Chair, representing the IRTF stream
>>
>>     o  The Independent Submissions Editor [RFC8730]
>>
>>     o  The RFC Series Editor/Advisor
> 
> We seem to already like the following text as an addition:
> 
>> The IAB and IESG delegates shall serve for one year renewable terms.  Should a delegate become unavailable, the appointing body MAY replace that individual to complete the term.
> 
> We could also add the following, to address Martin's point:
> 
>> The IAB and IESG delegates MUST themselves be appointed by the NOMCOM to their respective bodies.  They shall bserve for one year renewable terms.  Should a delegate become unavailable, the appointing body MAY replace that individual to complete the term.
> 
> Comments?  For?  Against?  Wordsmith?
> 
>   
> 
> This seems generally sound, but the appointing body should be able to replace them for any reason, not just if they are unavailable.
> 
>   
> 
> -Ekr
> 
>   
> 
> 
> Eliot
> 
> 
> 

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan


From nobody Wed Jun 30 03:14:17 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4935D3A16B7 for ; Wed, 30 Jun 2021 03:14:16 -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, 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 1nEMKNXSgk15 for ; Wed, 30 Jun 2021 03:14:12 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 05FF53A16B5 for ; Wed, 30 Jun 2021 03:14:11 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id q18so4096029lfc.7 for ; Wed, 30 Jun 2021 03:14:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aHS9zgsQxRfrxst8xSTdLmm2XxBxiaH0wgt2SdDLg0Q=; b=Z7L/YkbFcfaUIjQWl3TqvTX7HIhCQxBOvj91Qu8NkY8PkOyxfU16jovcNRwZiMgQOL ToARQJ1ss5wKNmxfZXhy9Dn0CyfWFXQJaR76aASgeyjMUPLQXrCKaNqCuz50RsCO2NlK FmM179oRLI6/wSaVL+EXpsNzv21GO9xzhC6coFIXQqhxSbSiLzcsRDoHG2yl0tcjLOAK JFYPZjaBRgrE8sKB7R89bcO9PZ9PGdd+oA+L+j4ph6fGbX/ljgPZgBsgAfGl7BNg8o9D qtaUR2Fwog5BVIfv/0Vx9lFB3CihIEajxnVFZvLzkCotMekmMAmqFnIYxm8+Xp9Tameq xwDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aHS9zgsQxRfrxst8xSTdLmm2XxBxiaH0wgt2SdDLg0Q=; b=IaMMFhwVWaKjU6adLKcj89FExmb3qiig8rY6uWvzWd3/2Z2gdx65khlbcCbqD087kf ThpyyJFIicvD7nROQXgcoGro2eu9WhFhc89+pltCcwNRm3oC8i0nUhNZKSxuYvZ4dTKM 6iB9+Quk07f8YvfJTC0RneE2rDI6qTnhhwszevNvNGMz2s/ariuks1iyOY7ouej/g3Sg 6DRz/SGEuSDN7SAoZSQXhJdDXEp8155iCYptCsHnYiwCDRmW+hKgtMKqj7hLk+xbXEUs 2QTMPgUZqDWAfvQyIsH2z6qsd1AEUrsDvy6oSI5H4CJ1MR1Ll6Xa02Ikl+0RI6VsnB0C B04w==
X-Gm-Message-State: AOAM530P+TKqOxrmLNUnjmsoQMR6Im1T7eGIwe8qaNYGHwiJznDNzviJ VSGDe2gz6uDYzdXyk81cdUOZYpxtyi+YYacbWlY=
X-Google-Smtp-Source: ABdhPJyIe2kFUbeenXaCAFFxPWJwnJxvgrac3cqE9UMFRCAfZGkps5XH6E0zXqHUHaHOZ3ahnb/2y1w1sIeUUGaIo3Q=
X-Received: by 2002:ac2:5236:: with SMTP id i22mr26370277lfl.637.1625048048228;  Wed, 30 Jun 2021 03:14:08 -0700 (PDT)
MIME-Version: 1.0
References: <612bacba-0bdb-32bb-5369-19486742a111@lear.ch>
In-Reply-To: <612bacba-0bdb-32bb-5369-19486742a111@lear.ch>
From: Brian Carpenter 
Date: Wed, 30 Jun 2021 22:13:54 +1200
Message-ID: 
To: Eliot Lear 
Cc: rfced-future@iab.org, EKR 
Content-Type: multipart/alternative; boundary="000000000000a85aab05c5f8fbf7"
Archived-At: 
Subject: Re: [Rfced-future] Issue 68: we prohibited in person meetings and design teams
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jun 2021 10:14:16 -0000

--000000000000a85aab05c5f8fbf7
Content-Type: text/plain; charset="UTF-8"

*In-person* meetings? That is so 2019.

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

On Wed, 30 Jun 2021, 17:56 Eliot Lear,  wrote:

> EKR pointed out that our wording might go a bit too far when we say:
>
> > When the RSWG is formed, all
> > discussions shall take place on an open email discussion list.
> > Subsequently, the RSWG may decide by rough consensus to use
> > additional tooling or forms of communication (e.g., GitHub as
> > specified in [RFC8874]) as long as they are consistent with
> > [RFC2418].
>
> How about this:
>
> > When the RSWG is formed, all discussions shall take place on an open
> > email discussion list or through in person meetings. Subsequently, the
> > RSWG may decide by rough consensus to use working methods(e.g., GitHub
> > as specified in [RFC8874] or design teams) as long as they are
> > consistent with [RFC2418].
>
> Eliot
>
>
> --
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>

--000000000000a85aab05c5f8fbf7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


*In-person* meetings? That is so 2019.

Regards,
=C2=A0=C2=A0=C2=A0 Brian Carpenter=

=C2=A0=C2=A0=C2=A0 (via tiny screen & keyboard)

On Wed, 30 Jun=
 2021, 17:56 Eliot Lear, <lear@lear.ch> wrote:
EKR pointed out that =
our wording might go a bit too far when we say:



> When the RSWG is formed, all

> discussions shall take place on an open email discussion list.

> Subsequently, the RSWG may decide by rough consensus to use

> additional tooling or forms of communication (e.g., GitHub as

> specified in [RFC8874]) as long as they are consistent with

> [RFC2418].



How about this:



> When the RSWG is formed, all discussions shall take place on an open <=
br>
> email discussion list or through in person meetings. Subsequently, the=
 

> RSWG may decide by rough consensus to use working methods(e.g., GitHub=
 

> as specified in [RFC8874] or design teams) as long as they are 

> consistent with [RFC2418].



Eliot





-- 

Rfced-future mailing list

Rfced-future@iab.org

https://www.iab.org/mailman/listinfo/rfc=
ed-future




--000000000000a85aab05c5f8fbf7--


From nobody Wed Jun 30 09:15:43 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94D33A21A1 for ; Wed, 30 Jun 2021 09:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.235
X-Spam-Level: 
X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=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=nthpermutation-com.20150623.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 RADK4rM6PVSF for ; Wed, 30 Jun 2021 09:15:37 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 D30563A21A3 for ; Wed, 30 Jun 2021 09:15:36 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id f13so1844832qtb.6 for ; Wed, 30 Jun 2021 09:15:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=SDq5j7J6PYrHeBV0f75XZvIOSFB5EkpP+ESNIx4ZVqI=; b=n9KaRWHcytfDDilVTVBCpwEJwJwC4ejLaNmv69RZQSE5WlnfxHd8wGoXM3s4D3rRyo fIKEvyifGm6QyGdC9cjggkrJLJdaTv6kiV3Xk4NVmkQox2yUNv7VCZUoVWN55GwOVdkI ioKAuX6LgENmaCVbQRmz6Ivj6DsJLGJiKYykZRVzYelwtyGr7D5llDiFAFaCMOT/Mu9K naJMbxRWQ1Kmsurln1SRlHVR7QBFtSvff0S0SPR1IlS5E84SbUVPb9qwh1wk0Ci8XjjJ BNYhH7+gY8emWvLfaB5TJJBoiLMqp8GHR1dp5fSXgcFRIATq9r0xDkzBAdPbJPM0y/as EC1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=SDq5j7J6PYrHeBV0f75XZvIOSFB5EkpP+ESNIx4ZVqI=; b=Vrr918kbwu1H8V5NVAjNNuEczHI6yPGLKs64Y3fCvWfThXuw1Bcl05yccuOopkrg9u FhE0dH+6Qr1nM0GYfo11IhsQ+AmgPpgXDNOVW7lnkYQ3EyYFTK9QC9ElcIEH5lyWaHiU zJXx9nY0mU3xw9saonUYdBm9HkaVtuKNpKWwE5qD0gdpNo/e6h09pBqnmwuwE/7BFyyN hQJAlUQF/Jfmv+doRXWKSH2dnupGsLEL9Z0bA7J8msqbp+yQtQA/n822ffgd4L1VxnFL 5m/3vNaIJMgTxu4pQF3SMSa1nbNp9YufFb2F5MKOU+wNtF3Tm9gmGCKjeS3CLRXxyvi9 BhVw==
X-Gm-Message-State: AOAM532d2pXmyywcqt/gSFe5h82D9tqTazlB27XiIUAjG2i2ypdgCHXo BgmnYNOLW1l40VeS9E84Nqs+SpxDSNRxahaHAHY=
X-Google-Smtp-Source: ABdhPJzn3sdIFpzmXalnBadpeK68Xz20imJqaEWy3oVghQ+h40s2agmpYdK27D6+W73PJ6wvRN4N4g==
X-Received: by 2002:a05:622a:1049:: with SMTP id f9mr14410545qte.30.1625069734484;  Wed, 30 Jun 2021 09:15:34 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id p64sm7247939qka.114.2021.06.30.09.15.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Jun 2021 09:15:30 -0700 (PDT)
To: Eliot Lear , Jay Daley 
Cc: rfced-future@iab.org
References:  <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>  <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com>  <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch>
From: Michael StJohns 
Message-ID: <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com>
Date: Wed, 30 Jun 2021 12:15:25 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jun 2021 16:15:42 -0000

On 6/30/2021 2:18 AM, Eliot Lear wrote:
> The RSWG establishes policy, with input from the community, the RSAB, 
> and the RSEA.

s/establishes/proposes/ please.


From nobody Wed Jun 30 09:20:07 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBED83A21C5 for ; Wed, 30 Jun 2021 09:20:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.236
X-Spam-Level: 
X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_NONE=-0.0001, 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=nthpermutation-com.20150623.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 mVc7jcBTGX9S for ; Wed, 30 Jun 2021 09:20:00 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 E674B3A21C1 for ; Wed, 30 Jun 2021 09:19:59 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id n9so1848790qtk.7 for ; Wed, 30 Jun 2021 09:19:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=o7180i2z9gkYPXXX6IwoiJ/cz4sQnlFSIbI0lLywBOo=; b=coeq80l8g7pH6ALlSO+rPWu0lJQ0gG/4M2aQm81rDuH2TRjwWbw3xaAwP3RG/2HHz+ jx/LJrm7bCdlJVyxbyavxuCig7337p8bJDN7fukDdJmg6apqOJQkTPvOAb5SeW5PGxwN ZHmkuHUfzmplRuyjx0xl3xNI73IGgypwLcIPbB0O+f/DydAVoIFQQ/GD1dJY/ZsMEClR I3g/P1AjLeSwE71a+pK7E+jgrfMkYxpMJOhGdKQbvMXHL4j/U8joo74kKyPR5/qlNFU6 ctBoGV708oVN98iS+n6jTD4R+W2Zse7DtpPoplt8bVtnaH7KkQhg+FvdO65N+vuT8Qdk xbog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=o7180i2z9gkYPXXX6IwoiJ/cz4sQnlFSIbI0lLywBOo=; b=LKGa3jkQF2YBqz+8JAsTb4psojFCcsorvL2V3MifXN15pJK7Fsacc7f5U2QQAFMXob 9ViNLGBk+EZXlO6Z6GS0OJb0vn8BlBoTTNmcjRIFOPRkxqJNtXNraUp9EpccXPzfExMm Nh960t6GmjNNRQszLUyw6vD5aPkWlTGQ8tQG+cxAGrhJ/ZLP7eGi7zD5lx8Z7CadDBkx /4yzFZJXE2MoVJJIjqc+JEHygq8u/rksA4Rz1cgmSqYLvuDhqhqNBQmwYO7H3F1+8Wd4 W6p3Dqs7xYrk+HxTkXxjLNqvItbh7lZelN57aUu5L7UKB3ZBZyDRzt5+2SrUuR62hSMT KnwQ==
X-Gm-Message-State: AOAM531neL0v4lTk7pWvxG1PwA+aL/wthQ//kv6CCTY8QVGr8ETGdaQn CnyRsvMRKD6IkMhIR22BCrD71vx3V9VcGBnIS5c=
X-Google-Smtp-Source: ABdhPJw0LuTpTka1t3hQPfe0kptHCx8yVe4E3hPF1ik2JYq0lvr/0j91tjeveVKslwTXNu5YgxlIOg==
X-Received: by 2002:a05:622a:104b:: with SMTP id f11mr29926691qte.240.1625069997488;  Wed, 30 Jun 2021 09:19:57 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id j8sm9406137qti.20.2021.06.30.09.19.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Jun 2021 09:19:56 -0700 (PDT)
From: Michael StJohns 
To: Eliot Lear , Jay Daley 
Cc: rfced-future@iab.org
References:  <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>  <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com>  <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com>
Message-ID: 
Date: Wed, 30 Jun 2021 12:19:54 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jun 2021 16:20:05 -0000

On 6/30/2021 12:15 PM, Michael StJohns wrote:
> On 6/30/2021 2:18 AM, Eliot Lear wrote:
>> The RSWG establishes policy, with input from the community, the RSAB, 
>> and the RSEA.
>
> s/establishes/proposes/ please.
>
Or maybe even:

The RSWG drafts policy documentation, with input from the community, the 
RSAB and the RSEA.

The RSAB considers and decides whether to approve such documentation for 
publication in the editorial series.


This makes it clear that the RSAB is not a rubber stamp for the RSWGs 
proposals.

Mike



From nobody Wed Jun 30 11:51:53 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B7E3A2685 for ; Wed, 30 Jun 2021 11:51:52 -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, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 V1yhdUAffuzx; Wed, 30 Jun 2021 11:51:47 -0700 (PDT)
Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 81AB63A267F; Wed, 30 Jun 2021 11:51:46 -0700 (PDT)
From: Jay Daley 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_F931B6FC-794B-4A22-AAB9-7B458FAF9DA0"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Thu, 1 Jul 2021 06:51:43 +1200
In-Reply-To: 
Cc: Eliot Lear , rfced-future@iab.org
To: Michael StJohns 
References:  <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>  <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com>  <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com> 
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jun 2021 18:51:52 -0000

--Apple-Mail=_F931B6FC-794B-4A22-AAB9-7B458FAF9DA0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

wfm

> On 1/07/2021, at 4:19 AM, Michael StJohns  =
wrote:
>=20
> On 6/30/2021 12:15 PM, Michael StJohns wrote:
>> On 6/30/2021 2:18 AM, Eliot Lear wrote:
>>> The RSWG establishes policy, with input from the community, the =
RSAB, and the RSEA.
>>=20
>> s/establishes/proposes/ please.
>>=20
> Or maybe even:
>=20
> The RSWG drafts policy documentation, with input from the community, =
the RSAB and the RSEA.
>=20
> The RSAB considers and decides whether to approve such documentation =
for publication in the editorial series.
>=20
>=20
> This makes it clear that the RSAB is not a rubber stamp for the RSWGs =
proposals.
>=20
> Mike
>=20
>=20
> --=20
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future
>=20

--=20
Jay Daley
IETF Executive Director
jay@ietf.org


--Apple-Mail=_F931B6FC-794B-4A22-AAB9-7B458FAF9DA0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

wfm

On 1/07/2021, at 4:19 AM, Michael StJohns =
<msj@nthpermutation.com> wrote:

On =
6/30/2021 12:15 PM, Michael StJohns wrote:
On 6/30/2021 2:18 AM, Eliot Lear wrote:
The RSWG establishes =
policy, with input from the community, the RSAB, and the RSEA.

s/establishes/proposes/ =
please.

Or maybe even:

The RSWG drafts policy documentation, with =
input from the community, the RSAB and the RSEA.

The RSAB considers and decides whether to approve such =
documentation for publication in the editorial series.


This makes it clear that the RSAB is not a =
rubber stamp for the RSWGs proposals.

Mike

-- 
Rfced-future =
mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future




-- 
Jay Daley
IETF =
Executive Director
jay@ietf.org




=

--Apple-Mail=_F931B6FC-794B-4A22-AAB9-7B458FAF9DA0--


From nobody Wed Jun 30 12:40:27 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D79E3A27F3; Wed, 30 Jun 2021 12:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level: 
X-Spam-Status: No, score=-2.427 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, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 9BJUCTLno--6; Wed, 30 Jun 2021 12:40:19 -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 D45B03A27F1; Wed, 30 Jun 2021 12:40:18 -0700 (PDT)
Received: from [10.61.144.50] ([173.38.220.59]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15UJe7rd093847 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 30 Jun 2021 21:40:08 +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=1625082013; bh=29iMxmQzSrYS4LTRLP21COAe0RhLiPhx3Lg2Tz4urCg=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=b5VvmlqMA5NAqb9Lab+EE3uACidcgJorXJmdzc3L2GlvNwpLPekljKr0KqmIchCWH gQ4RpEAu7JyjikCEqEJJLKkV9EmEr4GP9IK3wVMjB1x1ex/XuP3wxAhLdNzMh2MXhI Gvny6t4wWWy8YN+56s5M9MoE2aSLnmf+RlBjuGtE=
To: Jay Daley , Michael StJohns 
Cc: rfced-future@iab.org
References:  <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>  <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com>  <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com>  
From: Eliot Lear 
Message-ID: 
Date: Wed, 30 Jun 2021 21:40:06 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lktFufP4L8pccPSikHL9D3QU8iHde5EWD"
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jun 2021 19:40:26 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--lktFufP4L8pccPSikHL9D3QU8iHde5EWD
Content-Type: multipart/mixed; boundary="G49PNCV0NIiYyQMoIGFUFjTOZ7nvy4Fu0";
 protected-headers="v1"
From: Eliot Lear 
To: Jay Daley , Michael StJohns 
Cc: rfced-future@iab.org
Message-ID: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
References: 
 <896D122F-C341-4B1F-9467-48040F691A42@ietf.org>
 <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com>
 <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org>
 <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>
 
 <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com>
 
 <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch>
 <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com>
 
 
In-Reply-To: 

--G49PNCV0NIiYyQMoIGFUFjTOZ7nvy4Fu0
Content-Type: multipart/alternative;
 boundary="------------37C64D146725D99BE9FE5E87"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------37C64D146725D99BE9FE5E87
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable


Here's the model, slightly tweaked, but the goal is not to wordsmith=20
this model, but rather to explain the relationships with the RPC in=20
particular (e.g., the first two bullets are really just there for=20
completeness; we've covered that ground).=C2=A0 I don't think this text g=
oes=20
into the draft.=C2=A0 We need something that is a bit more elaborated.=C2=
=A0 But=20
if people are comfortable with the general approach, then we have a good =

starting point to develop appropriate text.

>   * The RSWG establishes policy, with input from the community, the
>     RSAB, and the RSEA.
>   * The RSAB considers those proposals and approves or returns as
>     appropriate.
>   * The RPC periodically reports to the RSAB on how it is implementing
>     that policy.
>   * The RSEA provides expertise to the RPC and RSAB on how to
>     implement the policy on an ongoing and operational basis, perhaps
>     raising issues along the way for both the RSAB and community to
>     consider.
>
> If issues arise with particular policies, the RPC still brings them to =

> the RSAB who interprets the policy, and provides interim guidance to=20
> the RPC, informing the RSWG of those interpretations.
>
Are there people who are generally uncomfortable with the overall=20
approach?=C2=A0 Please discuss.

Eliot


--------------37C64D146725D99BE9FE5E87
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    

    
Here's the model, slightly tweaked, but the goal is not to
      wordsmith this model, but rather to explain the relationships with
      the RPC in particular (e.g., the first two bullets are really just
      there for completeness; we've covered that ground).=C2=A0 I don't t=
hink
      this text goes into the draft.=C2=A0 We need something that is a bi=
t
      more elaborated.=C2=A0 But if people are comfortable with the gener=
al
      approach, then we have a good starting point to develop
      appropriate text.

    

    

      
    
        
  • The RSWG establishes policy, with input from the community,
          the RSAB, and the RSEA.
    • 
        
  • The RSAB considers those proposals and approves or returns
          as appropriate.
    • 
        
  • The RPC periodically reports to the RSAB on how it is
          implementing that policy.
    • 
        
  • The RSEA provides expertise to the RPC and RSAB on how to
          implement the policy on an ongoing and operational basis,
          perhaps raising issues along the way for both the RSAB and
          community to consider.
    • 
      

      
If issues arise with particular policies, the RPC still brings
        them to the RSAB who interprets the policy, and provides interim
        guidance to the RPC, informing the RSWG of those
        interpretations.=C2=A0
      

    

    
Are there people who are generally uncomfortable with the overall
      approach?=C2=A0 Please discuss.

    

    
Eliot

    

  


--------------37C64D146725D99BE9FE5E87--

--G49PNCV0NIiYyQMoIGFUFjTOZ7nvy4Fu0--

--lktFufP4L8pccPSikHL9D3QU8iHde5EWD
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmDcyJYFAwAAAAAACgkQh7ZrRtnSejMQ
WQf6A4mkd18XxS/Cm/XlUvWnN+6JbEuPQczCgwoZP6hCHd9BKrpt25KnF+yVrD47lB0Fl+XRwNx1
we2WePKpNnFS4OQHfVgWJNWF9mOqMcpJ9GBmgxArKWqUFsWCz0WkUOYeIfuWHSMbxCKr9wntM8N2
s3tNhesE2VeeqNyqPa0NlPLgI75Rj4TTG0yNU8q6DHY6AhYL9Ve6gliGznrd+sdfkefJfb5ryz3u
D1xJsWOlUjbpvJvK8ye0w7RRaxPGPAEDJo0PZq+yOUNKqHUfwsUpirK//UGjllw2pWXJqh1Et8m3
BsJ2mJYF+piBA0fJHnpAhaZyf/u88ppWhsk2l6b2Pg==
=BpSC
-----END PGP SIGNATURE-----

--lktFufP4L8pccPSikHL9D3QU8iHde5EWD--


From nobody Wed Jun 30 13:57:34 2021
Return-Path: 
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B593A3A2A72 for ; Wed, 30 Jun 2021 13:57:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 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.338, RCVD_IN_DNSWL_NONE=-0.0001, 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 3fneW-JwRJEU for ; Wed, 30 Jun 2021 13:57:29 -0700 (PDT)
Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 EBDB43A2A6F for ; Wed, 30 Jun 2021 13:57:28 -0700 (PDT)
Received: by mail-pj1-x1031.google.com with SMTP id mn20-20020a17090b1894b02901707fc074e8so4565361pjb.0 for ; Wed, 30 Jun 2021 13:57:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=q/k/ZfN9guLYOFknhNVQ3QlaI2o2uaJF9ke101KKH9A=; b=Hut7jgcN76AahsR+qaqx90ABLX0jei13exf/tjqTKlATLptf4QsFiOJ17gjVx/mBxu a1oh7tvwYrlKapaEmHb7b9KyHIY7+sFDzHEgyMO8+xb0tL14RhfclVhTYAdFLKQ9NUDK hi59f6+8iVCJq/JtceeF8s7WvT0YBymj4np1apcI9haKkBCEsfpVaMkhmc5osOJFGnmd LbGrg4iTTIp2ml70qYaDJFejZn6kh5fdyvmdHEOa30BxXBNtUiCr9C/uXjCMJfEu+qW+ AeFH1FX+4hWTb9VxRFgkrxJGXukunu8s0NZaizcJKlXmp93kHmMniq3CDbjpDxoL8XOs BiqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=q/k/ZfN9guLYOFknhNVQ3QlaI2o2uaJF9ke101KKH9A=; b=k7CukVPdsaftbsvcIhNrhDx9cwWKLf8mmthJuqpJUqJb6QuLhoYkgwGDrkULGlDzjM EaPEVR2wjlmP4OMTHsuDhPKjFwwlbw/f42MKQN8f1+B5sXM9WIdUzXnYT3fSMm5YEOIP QR5/hNtzEZ4ZFLTRGdy6qIMToDUuSyw1iZt6Fp31eynkW5n6IWB0VI3kEbMRh/kn2ffJ WlTmA3NQwfFEQSQeRc84gRWCcP20T6dHTMyuQZHIZ5kq1oRGbzfUkvfIF349q2IZ+Nd4 ZsuFjWswwpTW5O5XsCQDY5B9mvGD16fL/tGHbncnoZdSAzuosk6HwDonM12NfFJY0EM5 fM5Q==
X-Gm-Message-State: AOAM5322Cofolu/fjIUplf8drthbQ5aOQ961XUphVZe4v4bn3yu/QvS0 ZwtcOHucqFiv/NAQABybDhRBVXhppNVnBg==
X-Google-Smtp-Source: ABdhPJxsBQdfJzV5zw3VFx+p5k0mI3mRqoD8HbBVx3Zj0oSltTJRHdIc2qF0hJbmLdYUKshZ96g2WQ==
X-Received: by 2002:a17:90a:c8b:: with SMTP id v11mr6058930pja.114.1625086647506;  Wed, 30 Jun 2021 13:57:27 -0700 (PDT)
Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id v9sm25097789pgq.54.2021.06.30.13.57.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Jun 2021 13:57:26 -0700 (PDT)
To: Eliot Lear , Jay Daley , Michael StJohns 
Cc: rfced-future@iab.org
References:  <896D122F-C341-4B1F-9467-48040F691A42@ietf.org> <096215b8-ba95-7406-fbe5-fcf145417fc3@gmail.com> <9114EB06-AB70-4E6A-A72B-0D7D5867C74A@ietf.org> <538d1ce7-6e4b-fea0-f04b-36669c43dec1@nthpermutation.com>  <996b71fc-6ebd-06a1-9a0a-2695a6044381@nthpermutation.com>  <4ad09680-b067-4475-9232-e8f69101e7c0@lear.ch> <3295300e-d396-36fc-2137-6452de7f5296@nthpermutation.com>   
From: Brian E Carpenter 
Message-ID: <848d287a-d2e5-7e61-90c4-e3718c010906@gmail.com>
Date: Thu, 1 Jul 2021 08:57:22 +1200
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: quoted-printable
Archived-At: 
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jun 2021 20:57:33 -0000

On 01-Jul-21 07:40, Eliot Lear wrote:
>=20
> Here's the model, slightly tweaked, but the goal is not to wordsmith th=
is model, but rather to explain the relationships with the RPC in particu=
lar (e.g., the first two bullets are really just there for completeness; =
we've covered that ground).=C2=A0 I don't think this text goes into the d=
raft.=C2=A0 We need something that is a bit more elaborated.=C2=A0 But if=20
people are comfortable with the general approach, then we have a good sta=
rting point to develop appropriate text.
>=20
>>   * The RSWG establishes policy, with input from the community, the RS=
AB, and the RSEA.
>>   * The RSAB considers those proposals and approves or returns as appr=
opriate.
>>   * The RPC periodically reports to the RSAB on how it is implementing=20
that policy.
>>   * The RSEA provides expertise to the RPC and RSAB on how to implemen=
t the policy on an ongoing and operational basis, perhaps raising issues =
along the way for both the RSAB and community to consider.

Yes, I think that position's the RSEA's role nicely (and to my mind, fixe=
s the name as RSA because the RSEA is clearly *not* in authority).

   Brian

>>
>> If issues arise with particular policies, the RPC still brings them to=20
the RSAB who interprets the policy, and provides interim guidance to the =
RPC, informing the RSWG of those interpretations.=C2=A0
>>
> Are there people who are generally uncomfortable with the overall appro=
ach?=C2=A0 Please discuss.
>=20
> Eliot
>=20
>=20