From nobody Tue Nov 3 02:22:32 2020 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 5C60B3A1601 for ; Tue, 3 Nov 2020 02:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 azJVvAHQi-LP for ; Tue, 3 Nov 2020 02:22:28 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3A03A15F6 for ; Tue, 3 Nov 2020 02:22:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1118; q=dns/txt; s=iport; t=1604398948; x=1605608548; h=from:content-transfer-encoding:mime-version:subject: message-id:date:to; bh=NNFD8Tz6yLPliAEnr6TefGzU/43734MwR6QOJ778+BM=; b=Uywlp3XB9O0IzJvOkvul680kPXFjK0Pntty77KpkOgaEmkltq6eplEyr VXLxH9Mcz11IclCxIpVSY6zAIbLFENpWj6VNXQtZPKbFm5gBNvSztewmT xwZ2bkofP1DM4HGameUoUelcOqF2HTufhE7mDIr2c5hzc+29SIgMjp4g7 M=; X-IPAS-Result: =?us-ascii?q?A0BWBABqLqFf/xbLJq1iHgEBCxIMQIFEC4NvATKEa4kFp?= =?us-ascii?q?EELAQEBDQEBLwQBAYZWJjcGDgIDAQEBAwIDAQEBAQUBAQECAQYEcYVthhxIQ?= =?us-ascii?q?wImAoQYgn2gUI4ZdoEyhVeFD4EOKo1VggCBOByDDYULgkozgiwEuCCCd4MZl?= =?us-ascii?q?3ADH6FssDCDYQIEBgUCFYFqJIFXMxoIGxVlAYI/PRIZDZxpQANoAgYBCQEBA?= =?us-ascii?q?wmOSAEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,447,1596499200"; d="scan'208";a="28388842" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Nov 2020 10:22:24 +0000 Received: from ams3-vpn-dhcp87.cisco.com (ams3-vpn-dhcp87.cisco.com [10.61.64.87]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A3AMNN4027187 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 3 Nov 2020 10:22:24 GMT From: Eliot Lear Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <9183499C-0A42-494E-900C-DF17774DE1FE@cisco.com> Date: Tue, 3 Nov 2020 11:22:23 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.64.87, ams3-vpn-dhcp87.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: [Rfced-future] Issue 12: Is the expert an advisor (RSA) vs an executive editor (RSE) 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, 03 Nov 2020 10:22:30 -0000 As we get ready for our IETF meting, I was wondering if I could solicit = more conversation on this topic. This is from my summary: There is a split within the group over this topic. Some people have = made clear that they prefer an advisor, and others believe the role = should be that of an executive editor, where the latter makes decisions. = We=E2=80=99ve had a bit of a discussion about what decisions would be = made. What, for instance, could the RPC management reasonably decide? = What authority and expertise might they lack? Here we had a = contribution from the RPC that described some of their activities. One possible resolution is that the expert exercises moral authority =E2=80= =93 as experts do =E2=80=93 and provides guidance when asked by the RPC = within the existing framework. If the existing framework is found to be = wanting, the advisor might point this out to strategy body. It is then = up to them to resolve through whatever processes they have. They might = seek guidance from the advisor to resolve issues. Tell me if you think this is unacceptable.= From nobody Tue Nov 3 10:49:18 2020 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 5F50A3A10DA for ; Tue, 3 Nov 2020 10:49:16 -0800 (PST) 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 SeOgeXToC_lK for ; Tue, 3 Nov 2020 10:49:14 -0800 (PST) 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 A99D63A0E48 for ; Tue, 3 Nov 2020 10:49:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 49C47300B63 for ; Tue, 3 Nov 2020 13:49:12 -0500 (EST) 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 RnujlOUk9BMC for ; Tue, 3 Nov 2020 13:49:11 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id E559430066E; Tue, 3 Nov 2020 13:49:10 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: <9183499C-0A42-494E-900C-DF17774DE1FE@cisco.com> Date: Tue, 3 Nov 2020 13:49:12 -0500 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <9183499C-0A42-494E-900C-DF17774DE1FE@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Rfced-future] Issue 12: Is the expert an advisor (RSA) vs an executive editor (RSE) 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, 03 Nov 2020 18:49:16 -0000 Eliot: = https://datatracker.ietf.org/doc/draft-levkowetz-xml2rfc-v3-implementation= -notes/ This I-D is essentially the as-designed vs. the as-built discussion of = the tools. It includes "Heather's indication" regarding each of the = many schema. That would be the final word in one of these model, but = the place to start the community discussion in the other. It is still = very unclear to me who calls consensus after the community discussion in = the advisory model. Russ > On Nov 3, 2020, at 5:22 AM, Eliot Lear = wrote: >=20 > As we get ready for our IETF meting, I was wondering if I could = solicit more conversation on this topic. This is from my summary: >=20 >=20 > There is a split within the group over this topic. Some people have = made clear that they prefer an advisor, and others believe the role = should be that of an executive editor, where the latter makes decisions. = We=E2=80=99ve had a bit of a discussion about what decisions would be = made. What, for instance, could the RPC management reasonably decide? = What authority and expertise might they lack? Here we had a = contribution from the RPC that described some of their activities. >=20 > One possible resolution is that the expert exercises moral authority = =E2=80=93 as experts do =E2=80=93 and provides guidance when asked by = the RPC within the existing framework. If the existing framework is = found to be wanting, the advisor might point this out to strategy body. = It is then up to them to resolve through whatever processes they have. = They might seek guidance from the advisor to resolve issues. >=20 > Tell me if you think this is unacceptable. > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Tue Nov 3 11:16:23 2020 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 07DA83A0DD4 for ; Tue, 3 Nov 2020 11:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 lL22-YoHSInA for ; Tue, 3 Nov 2020 11:16:19 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6D93A0DCB for ; Tue, 3 Nov 2020 11:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2264; q=dns/txt; s=iport; t=1604430979; x=1605640579; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=UsNI9cMCCOknFlH/KZ6R2Nhp0DFjro9+QD9m40lvxqk=; b=RXzc1irwet1n0x+17FoTQN0PRuJpBcBfYt5a1IvlpEyxe1OUfFxUX2G8 E4fJnP6898goePb9Qrf3JmC5oLFtgnDNc0UT5Qc2MsDpv8OLkWLacZW4a 8nW6NtDe4Yy8uFHLvNbiXzWtZzy7FQbP5uwQWdV2oYCGOdoLyA1csEi1m 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DRAgDnq6Ff/xbLJq1iHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+DGlUBMi6EPYkFiBacKQsBAQENAQEYDQoEAQGESgKCCyY?= =?us-ascii?q?4EwIDAQELAQEFAQEBAgEGBHGFYQyFcgEBAQECAQEBIUgDCwULCxgCAiYCAic?= =?us-ascii?q?wBhMUgxIBglwgD69UdoEyhFJBRIRiBoEOKo1VggCBOByCTz6CXQEBAgEBgVu?= =?us-ascii?q?DFzOCLAS4IIJ3gxmFcZF/Ax+STY8fnkWRa4NhAgQGBQIVgWsjgVczGggbFTs?= =?us-ascii?q?qAYI+PhIZDY5WiE6FRUADMAI2AgYBCQEBAwmOSAEB?= X-IronPort-AV: E=Sophos;i="5.77,448,1596499200"; d="scan'208";a="30833782" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Nov 2020 19:16:14 +0000 Received: from [10.61.227.83] ([10.61.227.83]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A3JGD10001360 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Nov 2020 19:16:14 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Eliot Lear In-Reply-To: Date: Tue, 3 Nov 2020 20:16:13 +0100 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <422D0794-C941-41E8-A6A7-28EB2C0A37CE@cisco.com> References: <9183499C-0A42-494E-900C-DF17774DE1FE@cisco.com> To: Russ Housley X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.227.83, [10.61.227.83] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] Issue 12: Is the expert an advisor (RSA) vs an executive editor (RSE) 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, 03 Nov 2020 19:16:21 -0000 Hi Russ, > On 3 Nov 2020, at 19:49, Russ Housley wrote: >=20 > Eliot: >=20 > = https://datatracker.ietf.org/doc/draft-levkowetz-xml2rfc-v3-implementation= -notes/ >=20 > This I-D is essentially the as-designed vs. the as-built discussion of = the tools. It includes "Heather's indication" regarding each of the = many schema. That would be the final word in one of these model, but = the place to start the community discussion in the other. It is still = very unclear to me who calls consensus after the community discussion in = the advisory model. Others might see things differently, but I think it is at least assumed = in the community model that the chairs call consensus. Of course if = there are two of them and they disagree, perhaps there=E2=80=99s less = consensus than one thought ;-). Eliot >=20 > Russ >=20 >=20 >=20 >> On Nov 3, 2020, at 5:22 AM, Eliot Lear = wrote: >>=20 >> As we get ready for our IETF meting, I was wondering if I could = solicit more conversation on this topic. This is from my summary: >>=20 >>=20 >> There is a split within the group over this topic. Some people have = made clear that they prefer an advisor, and others believe the role = should be that of an executive editor, where the latter makes decisions. = We=E2=80=99ve had a bit of a discussion about what decisions would be = made. What, for instance, could the RPC management reasonably decide? = What authority and expertise might they lack? Here we had a = contribution from the RPC that described some of their activities. >>=20 >> One possible resolution is that the expert exercises moral authority = =E2=80=93 as experts do =E2=80=93 and provides guidance when asked by = the RPC within the existing framework. If the existing framework is = found to be wanting, the advisor might point this out to strategy body. = It is then up to them to resolve through whatever processes they have. = They might seek guidance from the advisor to resolve issues. >>=20 >> Tell me if you think this is unacceptable. >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 From nobody Tue Nov 3 11:58:22 2020 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 EAAA43A110E for ; Tue, 3 Nov 2020 11:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.247, 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=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 Q0mv1eY1bpb3 for ; Tue, 3 Nov 2020 11:58:19 -0800 (PST) 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 608463A1101 for ; Tue, 3 Nov 2020 11:58:19 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id 12so12355306qkl.8 for ; Tue, 03 Nov 2020 11:58:19 -0800 (PST) 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=UaCUrVa/rnEojUiaeJ+2jkU1+VM/WUBkX3Z75UZWGvQ=; b=ujAUdpj4rcftrTfMjbxnODJXjbHYOY7bLkjpUuISmbaj9JUNcr+i8rZ8Ji2Cbhevgs EEEefY5gidGuODtADjsk/vHVM9Kx1yoz73pyfh24yPjV/Uz1jCAieMKRXQXez+sCxdRf GhKhgoN+16p+cTXdu9J3Sa1N5YuN/8/TL+2htxtV+qnX4VxEFARHfVWsJKagWb/eiHdQ /DpcsIVXmFonjValmQsDMS3dh8DZLclHfHg788p5SO6w6CCYRNsjM6lOr+Mcyp4BJkRv ugG370VKhxaVVGC67HqMIyOw83ahd/RHveRDBwyQMhXCud8mJRL0FCL9YQaDNV929Ol7 uc0w== 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=UaCUrVa/rnEojUiaeJ+2jkU1+VM/WUBkX3Z75UZWGvQ=; b=GlcyNU6ZkIZN7MY9+JHBs/ItVCw3tCUixqQl4ALIsmZpd90k9X4yBt39gJveyXSTxx P64ovBH/s+ko2UHyEgl/zfqh8Zp3upt7NbzBtUsxHycLft5o2QuDETaWU7IbWT0pQsD6 8rIMbFB6o8DT5d3L7kvDxI5FhJpxNKS69w/vvXC/Br5cT1IsDjZ9ryYIIPWIW3FV9Lmd bvdrWUjDA3gsZ3PWazcqJ4OA5eJZTjN+wqKoRsf2MAO7SOZAP/S8L6uYkIaC7OQXSQVG 2hDYBSzWjhADlVbkWPcABzl714kFlxLAybmMNjwWXwYuCfsBPkuJAhI9js3mOTAmQrMI WPuA== X-Gm-Message-State: AOAM532P1YGex4MgO8tcFkHMJNMku0CG5bgJubsYjw+LDV0HehRfolLl j2HSh6d3IQK2rQ6Xkh0/WSfYQzt1w/S4u07xYX0= X-Google-Smtp-Source: ABdhPJyAwCoems1ZGXUcfCrVzg0wbdFytYuCdcZP+Wh3Dy37NPVZp+CtOclgGFjjbROWgxHofhzltg== X-Received: by 2002:a37:4e57:: with SMTP id c84mr21434770qkb.394.1604433497756; Tue, 03 Nov 2020 11:58:17 -0800 (PST) Received: from [192.168.1.22] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id 129sm11579450qkf.62.2020.11.03.11.58.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Nov 2020 11:58:16 -0800 (PST) To: rfced-future@iab.org References: <9183499C-0A42-494E-900C-DF17774DE1FE@cisco.com> <422D0794-C941-41E8-A6A7-28EB2C0A37CE@cisco.com> From: Michael StJohns Message-ID: <1fdef0e9-e371-ee47-ce3e-b4a7b85fa24e@nthpermutation.com> Date: Tue, 3 Nov 2020 14:58:15 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <422D0794-C941-41E8-A6A7-28EB2C0A37CE@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Issue 12: Is the expert an advisor (RSA) vs an executive editor (RSE) 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, 03 Nov 2020 19:58:21 -0000 Hi Eliot - On 11/3/2020 2:16 PM, Eliot Lear wrote: > Hi Russ, > >> On 3 Nov 2020, at 19:49, Russ Housley wrote: >> >> Eliot: >> >> https://datatracker.ietf.org/doc/draft-levkowetz-xml2rfc-v3-implementation-notes/ >> >> This I-D is essentially the as-designed vs. the as-built discussion of the tools. It includes "Heather's indication" regarding each of the many schema. That would be the final word in one of these model, but the place to start the community discussion in the other. It is still very unclear to me who calls consensus after the community discussion in the advisory model. > Others might see things differently, but I think it is at least assumed in the community model that the chairs call consensus. Of course if there are two of them and they disagree, perhaps there’s less consensus than one thought ;-). But then we get into the question of who chooses the chairs or what to do if a chair (or chairs) gets overtaken by their day job in preference to making progress on the RFC issues. Turtles all the way down... Later, Mike > > Eliot > > >> Russ >> >> >> >>> On Nov 3, 2020, at 5:22 AM, Eliot Lear wrote: >>> >>> As we get ready for our IETF meting, I was wondering if I could solicit more conversation on this topic. This is from my summary: >>> >>> >>> There is a split within the group over this topic. Some people have made clear that they prefer an advisor, and others believe the role should be that of an executive editor, where the latter makes decisions. We’ve had a bit of a discussion about what decisions would be made. What, for instance, could the RPC management reasonably decide? What authority and expertise might they lack? Here we had a contribution from the RPC that described some of their activities. >>> >>> One possible resolution is that the expert exercises moral authority – as experts do – and provides guidance when asked by the RPC within the existing framework. If the existing framework is found to be wanting, the advisor might point this out to strategy body. It is then up to them to resolve through whatever processes they have. They might seek guidance from the advisor to resolve issues. >>> >>> Tell me if you think this is unacceptable. >>> -- >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future From nobody Tue Nov 3 12:36:36 2020 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 0E22E3A113A for ; Tue, 3 Nov 2020 12:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 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.247, 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 5tPKxG586HMo for ; Tue, 3 Nov 2020 12:36:31 -0800 (PST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 3AB3C3A113C for ; Tue, 3 Nov 2020 12:36:31 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id x23so9145330plr.6 for ; Tue, 03 Nov 2020 12:36:31 -0800 (PST) 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=O+4iI3ijjRjlQKEqRCxBGAR9dtx+le+XAljHlESZwBc=; b=DMmg7wu7qcsq3EITeQxboOF3BcxSolmhWnmTv1kp3yjMgvnX4iDT9My14GTnSI+XvR Q4ghH+u+U20NFNjsG1T3tVRywJOYH4VY4NCeYKWxgc07FuHiX4i1ir4KktBOhlt32UYA yEyAvtQ2OJ4Eho/z86V2ycMP0sns2TgJRKAhBDFZ2UcgDDXJVPGCHGeytpuAUPqIEbBd Ykm1DZqmYQlEqrJytKdEnrK0+rJUX1gZesosZrb0cy1cZStW3b7ddAjaNKbqfMDw74Md Yepl6a7OlsYrZSK2KUU5uX/zvEwixAY4mnGC1Hukm51157J6KzC+f7krNdTqrwqXIJKi t89w== 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=O+4iI3ijjRjlQKEqRCxBGAR9dtx+le+XAljHlESZwBc=; b=Gdp3vfdxiK9CfNFgLC62IyrVCPGRH0YCGlNgQOlMTLJ3/iv6FTRyE9QE6zWWbUkhkR 4+WjJ71zGd9TPK286rOkCUqqmqzXceSEMW3es0lSv7i+o0eVttU17GNd3t4Or0kkmnvN uaqbJIshH9snfB2RG7ol+Oa6qbQ4gt8AyiN5+oLzP3/C4QUOyKc4XgWKpA3oxzMWy756 hqlA6brcndxP4tL6Sjb2VuesKgdXN05ccbeviIc61I3ZWAQmtiNa5o/PqR+6jU267PO4 RVgCkuJ4bswJtljf0LJ5CL2NLTYE/KUygJw+HjWrIgRDaCDY3aYkyaMFpWpuPIZYAVjh NMlA== X-Gm-Message-State: AOAM530yvdbBHdAiF0skb6Pe/oUeMq7C4uGrrtGVQPjSsBwk4qq9/Hir jY1SsG3NznnweRjBL941C+WIaOjRjpBhgQ== X-Google-Smtp-Source: ABdhPJynjzm/bwes7q4Onb3C03XrCtG2sfz51F8m8od41C2P5MHmBoMXI8627BkF5C8FVjwUwPzd8w== X-Received: by 2002:a17:902:b714:b029:d6:de05:4b06 with SMTP id d20-20020a170902b714b02900d6de054b06mr6189322pls.79.1604435789984; Tue, 03 Nov 2020 12:36:29 -0800 (PST) Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id e22sm12574pjh.45.2020.11.03.12.36.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2020 12:36:29 -0800 (PST) To: Michael StJohns , rfced-future@iab.org References: <9183499C-0A42-494E-900C-DF17774DE1FE@cisco.com> <422D0794-C941-41E8-A6A7-28EB2C0A37CE@cisco.com> <1fdef0e9-e371-ee47-ce3e-b4a7b85fa24e@nthpermutation.com> From: Brian E Carpenter Message-ID: <336b0743-e4d5-a45c-e06a-702bd7068c8a@gmail.com> Date: Wed, 4 Nov 2020 09:36:25 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <1fdef0e9-e371-ee47-ce3e-b4a7b85fa24e@nthpermutation.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Issue 12: Is the expert an advisor (RSA) vs an executive editor (RSE) 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, 03 Nov 2020 20:36:35 -0000 On 04-Nov-20 08:58, Michael StJohns wrote: > Hi Eliot - >=20 > On 11/3/2020 2:16 PM, Eliot Lear wrote: >> Hi Russ, >> >>> On 3 Nov 2020, at 19:49, Russ Housley wrote: >>> >>> Eliot: >>> >>> https://datatracker.ietf.org/doc/draft-levkowetz-xml2rfc-v3-implement= ation-notes/ >>> >>> This I-D is essentially the as-designed vs. the as-built discussion o= f the tools. It includes "Heather's indication" regarding each of the ma= ny schema. That would be the final word in one of these model, but the p= lace to start the community discussion in the other. It is still very un= clear to me who calls consensus after the community discussion in the adv= isory model. >> Others might see things differently, but I think it is at least assume= d in the community model that the chairs call consensus. Of course if th= ere are two of them and they disagree, perhaps there=E2=80=99s less conse= nsus than one thought ;-). fwiw I think Eliot is correct: the chairs call consensus. > But then we get into the question of who chooses the chairs or what to = > do if a chair (or chairs) gets overtaken by their day job in preference= =20 > to making progress on the RFC issues. We have that problem throughout the I*, by which I mean the IETF, IAB, IRTF, Independent Series, and even the IETF LLC Board. True, we still have to write down some rules about how the chairs are appointed. That's clearly soluble, but it hasn't been solved. What's the worst that could happen? A dispute between an author and the RPC could be held up until the chairs can take enough time from their day= jobs to extract a consensus. So the RFC concerned would be delayed. That's unlikely to be the end of the world. > Turtles all the way down... We're computer scientists, we can handle recursion. Regards Brian >=20 > Later, Mike >=20 >=20 >=20 >> >> Eliot >> >> >>> Russ >>> >>> >>> >>>> On Nov 3, 2020, at 5:22 AM, Eliot Lear wrote: >>>> >>>> As we get ready for our IETF meting, I was wondering if I could soli= cit more conversation on this topic. This is from my summary: >>>> >>>> >>>> There is a split within the group over this topic. Some people have= made clear that they prefer an advisor, and others believe the role shou= ld be that of an executive editor, where the latter makes decisions. We=E2= =80=99ve had a bit of a discussion about what decisions would be made. W= hat, for instance, could the RPC management reasonably decide? What auth= ority and expertise might they lack? Here we had a contribution from the= RPC that described some of their activities. >>>> >>>> One possible resolution is that the expert exercises moral authority= =E2=80=93 as experts do =E2=80=93 and provides guidance when asked by th= e RPC within the existing framework. If the existing framework is found = to be wanting, the advisor might point this out to strategy body. It is = then up to them to resolve through whatever processes they have. They mi= ght seek guidance from the advisor to resolve issues. >>>> >>>> Tell me if you think this is unacceptable. >>>> --=20 >>>> Rfced-future mailing list >>>> Rfced-future@iab.org >>>> https://www.iab.org/mailman/listinfo/rfced-future >=20 >=20 From nobody Tue Nov 3 18:54:23 2020 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 74AE33A1342 for ; Tue, 3 Nov 2020 18:54:21 -0800 (PST) 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=i/WKHXO1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gkxlMq86 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 q4eVsFrLPSaT for ; Tue, 3 Nov 2020 18:54:20 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B8C3A1110 for ; Tue, 3 Nov 2020 18:54:20 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 58ED4E46 for ; Tue, 3 Nov 2020 21:54:19 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Tue, 03 Nov 2020 21:54:19 -0500 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=fm3; bh=/CREN9KKBuBUby5YW9zGnUaKftCfJik TdH9b00VJCNo=; b=i/WKHXO1f4JAtEYq9uw8wDZhoN/EtXvviPAyArUpUqswIpQ 1IZXpKD/pRaf3+v9UvHS+LmNiV7+c9gNRddkgg+GrJhxk0EbkuDVbZb5X7mUo6bG N+y5t0jyj9L00z4DFpbCddnNMUnAdR03Za85ieZtamYaDCNeVrtY6OzxxtQ5LaIm ZN3Qm1ygflqIeP+LyeX75iLUVXG0sroVD70l7pkobbkGIPmmEqKXHF5Qi0SNrX6O HkZ83j4bjpxxkqw8Sr+D0i9si34Ki7HnnVxo+sx2c4nqDUcFJeFIQzXIxlZgTdne lo3/okvOKesFUbE/g6aN9XTaH6ynXMmlN/uhoUg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=/CREN9 KKBuBUby5YW9zGnUaKftCfJikTdH9b00VJCNo=; b=gkxlMq86iE/nmZnZpxX3JM eIcEI8wRghTGYfgHqEUr99qz+qFbD7CUhWRt9amsXfimC+1P/hFrDw+YzXcQ/uAX Dra4Dvc7o7hfgctfevDZThhjbh5rfC0ubnv8hkiVWrowCOM/ZbRqzvkci4bUmy0c CzEvzO8e2/Q+FmN4Y0NCxnSyW0MgyvVS1aq62wCPg1ztzwARB/U/A1O7g6dv+RR7 T84wgt+09ZWwBCd4HWrPwqezRBIgAkoKLy6I4jevo9H3hJ4x2RVOwxe+dyfpxI6x d1GBdY2SRtQ2mAhLDauzqiBPYcEjmYl7tFgz/FMYUaxnx1xRP97Lpg1o/ZOMVuKQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddtgedghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeehfeetudduudehtdekhf dvhfetleffudejgeejffehffevkeduiefgueevkeefleenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9B929200DB; Tue, 3 Nov 2020 21:54:18 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-530-g8da6958-fm-20201021.003-g69105b13-v35 Mime-Version: 1.0 Message-Id: In-Reply-To: <336b0743-e4d5-a45c-e06a-702bd7068c8a@gmail.com> References: <9183499C-0A42-494E-900C-DF17774DE1FE@cisco.com> <422D0794-C941-41E8-A6A7-28EB2C0A37CE@cisco.com> <1fdef0e9-e371-ee47-ce3e-b4a7b85fa24e@nthpermutation.com> <336b0743-e4d5-a45c-e06a-702bd7068c8a@gmail.com> Date: Wed, 04 Nov 2020 13:53:58 +1100 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Issue_12=3A_Is_the_expert_an_advisor_?= =?utf-8?q?=28RSA=29_vs_an_executive_editor_=28RSE=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, 04 Nov 2020 02:54:21 -0000 On Wed, Nov 4, 2020, at 07:36, Brian E Carpenter wrote: > What's the worst that could happen? A dispute between an author and the > RPC could be held up until the chairs can take enough time from their day > jobs to extract a consensus. So the RFC concerned would be delayed. > That's unlikely to be the end of the world. I think that I proposed something slightly different: we let the RPC proceed with a decision grounded in their own best judgment (which I would hope, but not insist, would involve some attempt at consultation). Then we live with the consequences of mistakes if the eventual community position differs when consensus is reached. In other words, let the community provide input at the strategic level. That means strategic timescales for resolution, and no need for high availability or rapid response on the part of chairs. If there is a permanent advisor, then I would expect them to take a more active role in the preliminary decision-making. Such a person could be well-suited to making a recommendation. However, like Brian, I don't share Mike's apparent complete lack of faith in the ability of our consensus process to produce results. From nobody Tue Nov 3 19:09:08 2020 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 57C873A1350 for ; Tue, 3 Nov 2020 19:09:06 -0800 (PST) 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 L0_OpIvdHGk6 for ; Tue, 3 Nov 2020 19:09:03 -0800 (PST) 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 31B0F3A1349 for ; Tue, 3 Nov 2020 19:09:03 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id b1so25100468lfp.11 for ; Tue, 03 Nov 2020 19:09:03 -0800 (PST) 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=UxYG2Zd1Mny7MOxg9AhieDa8Iw0y1CTKJnqZZBJsw/Q=; b=RxJlyuKUjdWOX+9OGCmjP+mFPjRdGWSHceFsMapaiyEgQVbsCm+WgWh7fr36uKLY/h pdgU8L048E2RhO2Btqe20X1f8oMvp5mAsVwDqIaC+w4MfehRIDJP6AJ+yZCwB9hOHkKi e3zqSG2vPnBJt36eyPNsYeGFVT+Vw0O/tjepBED7trXsG95hlmKM7WPXv4Yl9+Al0pGi FsvgFwj1He2eulcsRqGdkSC/QCiMjnYNZVAE0je14EaB4O09e2WuZZkuc6GY+YdOR9gr 0dfqWTUFDB6EEsCBfdMdvuGr3fhdKS05ixhRfivWyW7PYVb+Woq3CXuPQIoJzcuRu0n0 oNlA== 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=UxYG2Zd1Mny7MOxg9AhieDa8Iw0y1CTKJnqZZBJsw/Q=; b=X/8c+Z8N/9wTewL9HJGq5dxwCecMEaVFWnp0zwDNSKcihYqwmVnI7KWC3MsTbGfsHi DnFx7BATCkYoXmrqSOmQEyhh1a2S8xxfLJ1dYhaUO3eWx8JHRq2Vy0u5UOlQJdBuGCel kFu+Kq4kO/whRcrvIcSgMB7hbyW40BBzojEZyD43bCp9BRxrKRp0AlmXNtDja7UvgnpR 2yNqiqR6sIq/6vU3Kvt0iFfoQE8vUTCDFS+pNNPRH9DPDW4szqxJ+V8UhYfI0b4vcqHe CRxkFiqA4JCbOXG6ayFKCkLa6dltiQ98ToQil/Qsn9OU+BZwlJvZ1QqdOtSXP1Y6K2bb UKNQ== X-Gm-Message-State: AOAM532rJ37F2QrqaJPX0H1laptaXgq+pBhR71aghUusiz7VEWqfkwPH lzqyKGFxbCqDkehMuGLfvc4TN+zd95K+e4Kk8/vx0A== X-Google-Smtp-Source: ABdhPJzIfGypaj65Sqs2BVduSrBr6ErshGKrzbTgILlvA3GyjwGl/lJIggBQrg73AKZwqB1OMVHHqx3sCUH4x0isOY8= X-Received: by 2002:a05:6512:110b:: with SMTP id l11mr7340554lfg.234.1604459341195; Tue, 03 Nov 2020 19:09:01 -0800 (PST) MIME-Version: 1.0 References: <9183499C-0A42-494E-900C-DF17774DE1FE@cisco.com> <422D0794-C941-41E8-A6A7-28EB2C0A37CE@cisco.com> <1fdef0e9-e371-ee47-ce3e-b4a7b85fa24e@nthpermutation.com> <336b0743-e4d5-a45c-e06a-702bd7068c8a@gmail.com> In-Reply-To: From: Eric Rescorla Date: Tue, 3 Nov 2020 19:08:25 -0800 Message-ID: To: Martin Thomson Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000016c4c405b33f4d8b" Archived-At: Subject: Re: [Rfced-future] Issue 12: Is the expert an advisor (RSA) vs an executive editor (RSE) 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, 04 Nov 2020 03:09:06 -0000 --00000000000016c4c405b33f4d8b Content-Type: text/plain; charset="UTF-8" On Tue, Nov 3, 2020 at 6:54 PM Martin Thomson wrote: > On Wed, Nov 4, 2020, at 07:36, Brian E Carpenter wrote: > > What's the worst that could happen? A dispute between an author and the > > RPC could be held up until the chairs can take enough time from their day > > jobs to extract a consensus. So the RFC concerned would be delayed. > > That's unlikely to be the end of the world. > > I think that I proposed something slightly different: we let the RPC > proceed with a decision grounded in their own best judgment (which I would > hope, but not insist, would involve some attempt at consultation). Then we > live with the consequences of mistakes if the eventual community position > differs when consensus is reached. > It's worth noting that in our current practice, the RPC doesn't publish the RFC without author (or in extremis, AD) signoff, so it takes a lot for a dispute to become irreparable as opposed to delaying the publication of the RFC. In other words, let the community provide input at the strategic level. > That means strategic timescales for resolution, and no need for high > availability or rapid response on the part of chairs. > True, though given the time scales we are operating on here in general, it doesn't seem like a crisis if we have to get the RFC WG to take a few months to resolve some contentious issue. -Ekr > If there is a permanent advisor, then I would expect them to take a more > active role in the preliminary decision-making. Such a person could be > well-suited to making a recommendation. > > However, like Brian, I don't share Mike's apparent complete lack of faith > in the ability of our consensus process to produce results. > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --00000000000016c4c405b33f4d8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 3, 2020 at 6:54 PM Martin= Thomson <mt@lowentropy.net>= wrote:
On Wed, = Nov 4, 2020, at 07:36, Brian E Carpenter wrote:
> What's the worst that could happen? A dispute between an author an= d the
> RPC could be held up until the chairs can take enough time from their = day
> jobs to extract a consensus. So the RFC concerned would be delayed. > That's unlikely to be the end of the world.

I think that I proposed something slightly different: we let the RPC procee= d with a decision grounded in their own best judgment (which I would hope, = but not insist, would involve some attempt at consultation).=C2=A0 Then we = live with the consequences of mistakes if the eventual community position d= iffers when consensus is reached.

It= 9;s worth noting that in our current practice, the RPC doesn't publish = the RFC without author (or in extremis, AD) signoff, so it takes a lot for = a dispute to become irreparable as opposed to delaying the publication of t= he RFC.


In other words, let the community provide input at the strategic level.=C2= =A0 That means strategic timescales for resolution, and no need for high av= ailability or rapid response on the part of chairs.
True, though given the time scales we are operating on here in= general, it doesn't seem like a crisis if we have to get the RFC WG to= take a few months to resolve some contentious issue.

<= div>-Ekr


If there is a permanent advisor, then I would expect them to take a more ac= tive role in the preliminary decision-making.=C2=A0 Such a person could be = well-suited to making a recommendation.

However, like Brian, I don't share Mike's apparent complete lack of= faith in the ability of our consensus process to produce results.

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--00000000000016c4c405b33f4d8b-- From nobody Wed Nov 4 01:28:34 2020 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 BE14E3A0E1B for ; Wed, 4 Nov 2020 01:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 B9xH1RLPyisF for ; Wed, 4 Nov 2020 01:28:30 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D067B3A0E13 for ; Wed, 4 Nov 2020 01:28:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6914; q=dns/txt; s=iport; t=1604482103; x=1605691703; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=v4IljYWsCJi46WzGkZm2zussKy++5YHbmmHE+oL5mfY=; b=fh6XHHIeSbL/jurPCKiZmgXCd+FAsP2WEdC0WnwF9LYjjpt7Lreqd8pj SMDeIhgYM0R8Vw2ONFYEw51ko5YKcEEuq2TYVKvhMG+xf+rktRAqQ5rBK +428ERex6kh+MfRnzbNltucGgug93MzWC+3vgHXWLekdPRYonDuV2fsWR k=; X-IPAS-Result: =?us-ascii?q?A0D5AAAQc6Jf/xbLJq1iHQEBAQEJARIBBQUBgX4FAQsBg?= =?us-ascii?q?SKCTAEyLoQ9iQWIF5QQiBkLAQEBDQEBLwQBAYRKAoINJjcGDgIDAQEBAwIDA?= =?us-ascii?q?QEBAQUBAQECAQYEcYVthXIBAQEBAgEjSA4FCwsOCioCAlcGExSDEoJdIK8Bd?= =?us-ascii?q?oEyhVeEaYE4AY1UggCBOByCTz6HVTOCLASQNadsgneDGZdwAx+STY8gsDCDY?= =?us-ascii?q?QIEBgUCFYFqJIFXMxoIGxVlAYI+PhIZDY4rFxSOE0ADMDgCBgEJAQEDCY5IA?= =?us-ascii?q?QE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos; i="5.77,450,1596499200"; d="scan'208,217"; a="28415564" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Nov 2020 09:28:18 +0000 Received: from [10.61.192.90] ([10.61.192.90]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A49SH4A010676 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Nov 2020 09:28:18 GMT From: Eliot Lear Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_709D31A6-CE6A-46A5-9CF4-E3A4505E311A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 4 Nov 2020 10:28:16 +0100 In-Reply-To: Cc: Martin Thomson , rfced-future@iab.org To: Eric Rescorla References: <9183499C-0A42-494E-900C-DF17774DE1FE@cisco.com> <422D0794-C941-41E8-A6A7-28EB2C0A37CE@cisco.com> <1fdef0e9-e371-ee47-ce3e-b4a7b85fa24e@nthpermutation.com> <336b0743-e4d5-a45c-e06a-702bd7068c8a@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.192.90, [10.61.192.90] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Issue 12: Is the expert an advisor (RSA) vs an executive editor (RSE) 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, 04 Nov 2020 09:28:32 -0000 --Apple-Mail=_709D31A6-CE6A-46A5-9CF4-E3A4505E311A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, > On 4 Nov 2020, at 04:08, Eric Rescorla wrote: >=20 > It's worth noting that in our current practice, the RPC doesn't = publish the RFC without author (or in extremis, AD) signoff, so it takes = a lot for a dispute to become irreparable as opposed to delaying the = publication of the RFC. Yes. There are two situations: There is a dispute with an author There is a question within the RPC itself about how to proceed. You are describing the former case. We have said that as things stand, = we were going to leave it in the hands of the stream managers (in the = case of the IETF it would be the AD) to make the final call, and not the = RPC, presumably within the limits of the current approved format (e.g, = one shouldn=E2=80=99t expect a stream manager to override the RPC in = publishing an RFC in EBCDIC). In the second case, as an author, I leave many editorial decisions to = the RPC. But they themselves might find decision points that need to be = addressed. In this case, I think where Martin is angling is that the = RPC makes the call, and then perhaps informs the community of an = ambiguity and how they handled it. It=E2=80=99s then up to the = community to address in the future. That is- work doesn=E2=80=99t stop = over whether a comma is used or not with a single adverb phrase, or the = flowing of a particular diagram. Bringing this back to the issue at hand, quoting Martin: > If there is a permanent advisor, then I would expect them to take a = more active role in the preliminary decision-making. Such a person = could be well-suited to making a recommendation. And that brings us back to whether we are discussing a decision maker or = an advisor, and whether the text I put forth represents something that = might be in some way acceptable, assuming the advisor is present. As a = reminder, here it is: > One possible resolution is that the expert exercises moral authority = =E2=80=93 as experts do =E2=80=93 and provides guidance when asked by = the RPC within the existing framework. If the existing framework is = found to be wanting, the advisor might point this out to strategy body. = It is then up to them to resolve through whatever processes they have. = They might seek guidance from the advisor to resolve issues. Assuming there is such a person would this text be acceptable? And if = not, what would be? Eliot= --Apple-Mail=_709D31A6-CE6A-46A5-9CF4-E3A4505E311A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric,

On 4 Nov 2020, at 04:08, Eric Rescorla <ekr@rtfm.com> = wrote:

It's worth noting that in our = current practice, the RPC doesn't publish the RFC without author (or in = extremis, AD) signoff, so it takes a lot for a dispute to become = irreparable as opposed to delaying the publication of the = RFC.

Yes. =  There are two situations:

  • There is a dispute with an author
  • There is = a question within the RPC itself about how to proceed.

You are describing = the former case.  We have said that as things stand, we were going = to leave it in the hands of the stream managers (in the case of the IETF = it would be the AD) to make the final call, and not the RPC, presumably within the limits of the = current approved format (e.g, one shouldn=E2=80=99t expect a stream = manager to override the RPC in publishing an RFC in EBCDIC).

In the second case, as = an author, I leave many editorial decisions to the RPC.  But they = themselves might find decision points that need to be addressed. =  In this case, I think where Martin is angling is that the RPC = makes the call, and then perhaps informs the community of an ambiguity = and how they handled it.  It=E2=80=99s then up to the community to = address in the future.  That is- work doesn=E2=80=99t stop over = whether a comma is used or not with a single adverb phrase, or the = flowing of a particular diagram.

Bringing this back to the issue at = hand, quoting Martin:

If there is a permanent = advisor, then I would expect them to take a more active role in the = preliminary decision-making.  Such a person could be well-suited to = making a recommendation.

And that brings us back to whether we = are discussing a decision maker or an advisor, and whether the text I = put forth represents something that might be in some way acceptable, = assuming the advisor is present.  As a reminder, here it = is:

One possible resolution is that the expert = exercises moral authority =E2=80=93 as experts do =E2=80=93 and provides = guidance when asked by the RPC within the existing framework.  If = the existing framework is found to be wanting, the advisor might point = this out to strategy body.  It is then up to them to resolve = through whatever processes they have.  They might seek guidance = from the advisor to resolve issues.

Assuming there is such a person would this text be = acceptable?  And if not, what would be?

Eliot
= --Apple-Mail=_709D31A6-CE6A-46A5-9CF4-E3A4505E311A-- From nobody Wed Nov 4 01:31:40 2020 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 292E93A0E22 for ; Wed, 4 Nov 2020 01:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 EfRTWpRge7Eo for ; Wed, 4 Nov 2020 01:31:37 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5143A0E13 for ; Wed, 4 Nov 2020 01:31:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9959; q=dns/txt; s=iport; t=1604482297; x=1605691897; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=/r6Bu1frejUFLABSyNz0e+9nVq8gQndUZKRli19LU5I=; b=RhP/31PHPI0m9fWluTAV1zaMagm1iADRGhkoahFJ/WIrQYlOCPty0JmN MSqB3MEXqf2vU43a89KzUAgYJAvFDsyuUP+wrELWDJ0XCRZTIpY9vZ66S Na5Q33j8oD3yv+S5lI1RiQ8IOZQdE1mRf+mfe/TWTaA4ZBO+hQOF63a9W I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALBAADdKJf/xbLJq1iHQEBAQEJARI?= =?us-ascii?q?BBQUBgg+BI4JMATIuhD2JBYgWlBCIGQsBAQENAQEvBAEBhEoCgg0mOBMCAwE?= =?us-ascii?q?BCwEBBQEBAQIBBgRxhW2FcgEBAQECASNWBQsLGCoCAlcZgyaCXSCvAXaBMoV?= =?us-ascii?q?XhGmBOI1VggCBOByCTz6EIIM1M4IsBKcGkRuCd4MZl3ADH4MYihKFI48gsDC?= =?us-ascii?q?DYQIEBgUCFYFrI4FXMxoIGxU7KgGCPj4SGQ2OKxeOJ0ADMDgCBgEJAQEDCY5?= =?us-ascii?q?IAQE?= X-IronPort-AV: E=Sophos; i="5.77,450,1596499200"; d="scan'208,217"; a="30791970" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Nov 2020 09:31:33 +0000 Received: from [10.61.192.90] ([10.61.192.90]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A49VWr5009298 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Nov 2020 09:31:33 GMT From: Eliot Lear Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2B0F87D8-5A1F-4149-9D8E-2D78F8FC21BF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 4 Nov 2020 10:31:32 +0100 In-Reply-To: <08ff01d6aef5$dc784b60$9568e220$@olddog.co.uk> Cc: rfced-future@iab.org To: adrian@olddog.co.uk References: <08ff01d6aef5$dc784b60$9568e220$@olddog.co.uk> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.192.90, [10.61.192.90] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] Status of our discussions 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, 04 Nov 2020 09:31:39 -0000 --Apple-Mail=_2B0F87D8-5A1F-4149-9D8E-2D78F8FC21BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Adrian, Thanks for your comments. Just several points. > On 30 Oct 2020, at 20:50, Adrian Farrel wrote: >=20 > Hi Eliot, > =20 > Thanks for this summary. It=E2=80=99s helpful and prompts me to some = work. > =20 > The list of issues is =E2=80=9Csomewhat busy=E2=80=9D and so it has = been hard to engage except dipping in and out. > =20 > If I=E2=80=99m picky, #7 uses the word =E2=80=9Cdebate=E2=80=9D. Well, = you know, anyone can debate anything :-Z Is the intention: > Debates of strategy will be directed to a separate body > A separate body will resolve issues of strategy I believe the answer is (b) but others might care to chime in. > There are a lot of issues =E2=80=9CIn Discussion=E2=80=9D. Would it be = sensible to try not to discuss them all at once? Mark > some as =E2=80=9CIn Discussion=E2=80=9D and some as =E2=80=9CPending = Discussion=E2=80=9D? Yes that probably makes sense. > =20 > #10 You have captured my feelings on this. Can we please not use = =E2=80=9Cthought leader=E2=80=9D: notwithstanding dictionary = definitions, there is too much baggage associated. If someone who is = inspired by this term would like to write out what they mean, then we = can get meaningful debate on what we actually want.=20 > =20 > #10 and #11 > TBH, I also don=E2=80=99t like =E2=80=9Cfigurehead=E2=80=9D for its = connotations of =E2=80=9Csomeone who actually has no power, but is put = up to deliver a message=E2=80=9D: again, let=E2=80=99s stop using = buzzwords and say what we mean. Are we hiding from saying =E2=80=9Cperson = in authority=E2=80=9D or =E2=80=9Cleader=E2=80=9D or =E2=80=9Cspokesperson= =E2=80=9D or =E2=80=9Cchairperson=E2=80=9D? I think these names will become clearer as their roles become clearer, = as we have said. Eliot --Apple-Mail=_2B0F87D8-5A1F-4149-9D8E-2D78F8FC21BF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Adrian,

Thanks for your = comments.  Just several points.

On 30 Oct 2020, at 20:50, = Adrian Farrel <adrian@olddog.co.uk> wrote:

Hi = Eliot,
 
Thanks for this summary. It=E2=80=99s helpful and prompts me = to some work.
 
The list of issues is =E2=80=9Csomewhat busy=E2=80=9D and so = it has been hard to engage except dipping in and out.
 
If I=E2=80=99m picky, #7 uses the word =E2=80=9Cdebate=E2=80=9D= . Well, you know, anyone can debate anything :-Z Is the intention:
  1. Debates of strategy = will be directed to a separate body
  2. A separate body will = resolve issues of = strategy

I believe the answer is (b) but others might care to = chime in.



There are a lot of issues =E2=80=9C= In Discussion=E2=80=9D. Would it be sensible to try not to discuss them = all at once? Mark
some as =E2=80=9CIn = Discussion=E2=80=9D and some as =E2=80=9CPending = Discussion=E2=80=9D?

Yes that probably makes sense.

 
#10 You have captured my feelings on this. Can we please not = use =E2=80=9Cthought leader=E2=80=9D: notwithstanding dictionary = definitions, there is too much baggage associated. If someone who is = inspired by this term would like to write out what they mean, then we = can get meaningful debate on what we actually want. 
 
#10 and #11
TBH, I also don=E2=80=99t like = =E2=80=9Cfigurehead=E2=80=9D for its connotations of =E2=80=9Csomeone = who actually has no power, but is put up to deliver a message=E2=80=9D: = again, let=E2=80=99s stop using buzzwords and say what we mean. Are we = hiding from saying =E2=80=9Cperson in authority=E2=80=9D or =E2=80=9Cleade= r=E2=80=9D or =E2=80=9Cspokesperson=E2=80=9D or = =E2=80=9Cchairperson=E2=80=9D?
<= br class=3D"">
I think these names will become clearer as their = roles become clearer, as we have said.

Eliot

= --Apple-Mail=_2B0F87D8-5A1F-4149-9D8E-2D78F8FC21BF-- From nobody Wed Nov 4 07:54:34 2020 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 425B83A0DDE for ; Wed, 4 Nov 2020 07:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 3k63OzJEcK-f for ; Wed, 4 Nov 2020 07:54:32 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 243A33A0D58 for ; Wed, 4 Nov 2020 07:54:32 -0800 (PST) Received: from xse469.mail2web.com ([66.113.197.215] helo=xse.mail2web.com) by mx169.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kaL78-000Oux-4G for rfced-future@iab.org; Wed, 04 Nov 2020 16:54:29 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4CRB6K1KgLz1tbW for ; Wed, 4 Nov 2020 07:54:17 -0800 (PST) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kaL73-0007bn-2f for rfced-future@iab.org; Wed, 04 Nov 2020 07:54:17 -0800 Received: (qmail 1199 invoked from network); 4 Nov 2020 15:54:16 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.139]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 4 Nov 2020 15:54:16 -0000 To: Eliot Lear , Eric Rescorla Cc: rfced-future@iab.org, Martin Thomson References: <9183499C-0A42-494E-900C-DF17774DE1FE@cisco.com> <422D0794-C941-41E8-A6A7-28EB2C0A37CE@cisco.com> <1fdef0e9-e371-ee47-ce3e-b4a7b85fa24e@nthpermutation.com> <336b0743-e4d5-a45c-e06a-702bd7068c8a@gmail.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <36c2515e-f687-d7c9-6913-795c921a9e9f@huitema.net> Date: Wed, 4 Nov 2020 07:54:16 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: 66.113.197.215 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0XvADx2zSFwG+3csxFBPBHmpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjRzgyua+oKUgQGcbmeu+KPhY RkpFG1KU35iPF8F1Y4gKJfUIJnB2MsGW6V2XVPmQQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEUE6zyPc6aUCdl00F/tjba+42Vki7412dpbhrD2d47zbC3VvU djSCswikK/licfX+oIF6uBSWByrPG2Vxuo/vVPllrFEbCkMryfcYCsgMUJObfBQoU3roWy2GH1DY sAiH3gousbgNfxi2R3uFLvZP/HBXvrLBlKCVRjjdPbjQ4HnBNho1Lszw5OO01yYoll8q2UgzFF+j HNSbIoW1Q++Wvj3dKxLhoxcmaInYbR5vlqFg3eKzPG9E5MikC2dVXWcpK172i/E5sOgbaCtBiSIx 1XwCY8vmv+JqOVJamBHfOGVwjn7Xut/lXagsodd5qqODTFiwcpU4fyz75jxpU98RPGiH1Wgh6RAe nBR+licROGb39x3Pp0qQsqDkbqmcZOiQ00yoa+Dg6Nzs0x/RbDKRZxpUYVS5zo6JDHUw5BuNBHsr cuyeNztZhTczEttfN8GcQie12lTu81QucaD9n7tPrXuXCC1A5Cukky0WFo38JXT3Y80OmAux3oN1 3+ztUzneRALDqCLViTWGWWL3n/NLm783o7TP54FLJfg9sR3SxHLd/m2NTtFPj9naxCkXZ5qQannU M7ViGDlYq6j+z7TmD4W+axx2DzNv8BNlsyaVn+UqcgvK/XTFXOcD79N9Rs1n3UVkhX78ZcdZtWJt ri4lXS4599fEDT1GENo62d+DqD+gavEa4Cf1ILpAKBLSDHQENgjpXL2y/ONOC04/YEfTu1ss+n2f fnQxt6aJ7klZab8CvOT2YjlrAxveXsTwUzCTkiX4qyX2d5a1xbDejUjyqRVeiJQ5XjnH4gzAuCMQ 8aUxL7hrJSk60SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] Issue 12: Is the expert an advisor (RSA) vs an executive editor (RSE) 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, 04 Nov 2020 15:54:33 -0000 On 11/4/2020 1:28 AM, Eliot Lear wrote: > Bringing this back to the issue at hand, quoting Martin: > >> If there is a permanent advisor, then I would expect them to take a >> more active role in the preliminary decision-making.  Such a person >> could be well-suited to making a recommendation. > > And that brings us back to whether we are discussing a decision maker > or an advisor, and whether the text I put forth represents something > that might be in some way acceptable, assuming the advisor is present. >  As a reminder, here it is: > >> One possible resolution is that the expert exercises moral authority >> – as experts do – and provides guidance when asked by the RPC within >> the existing framework.  If the existing framework is found to be >> wanting, the advisor might point this out to strategy body.  It is >> then up to them to resolve through whatever processes they have. >>  They might seek guidance from the advisor to resolve issues. > > Assuming there is such a person would this text be acceptable?  And if > not, what would be? I would avoid "moral authority". Martin considers that given their technical expertise, experts are well suited to making recommendations. But these recommendations shall be grounded in technical expertise, not a vague "moral authority". -- ChristianHuitema From nobody Wed Nov 4 09:04:22 2020 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 2BE7B3A135D for ; Wed, 4 Nov 2020 09:04:21 -0800 (PST) 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 (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 vPfrjlUnnvCD for ; Wed, 4 Nov 2020 09:04:20 -0800 (PST) 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 286153A0D40 for ; Wed, 4 Nov 2020 09:04:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4CRCg76jVQz1pCQd for ; Wed, 4 Nov 2020 09:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1604509459; bh=IUOj3rzCLcVc6dw7dM/bAgvOGJ28iMCB/2qll6YcNyM=; h=To:From:Subject:Date:From; b=B052gFiRCjxL6oRCW/WuW2/P4a6hTQI8Saw4Wa/FN3MibdVYEC8IRl5jZZOCUCp1u EnVTfRV4h4WOKQuFS7hnDsUGtTHsbl8TvC7FcjOUdV36T+m1FafbhsEewehHHbJcoQ 3YQP5p35M5fZRrk50cpdEool3qsOrkh+BTTnhSk4= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4CRCg73htdz1ntWW for ; Wed, 4 Nov 2020 09:04:19 -0800 (PST) To: rfced-future@iab.org From: "Joel M. Halpern" Message-ID: <7b7de94f-8b0f-14c6-6e0e-aab547572d1c@joelhalpern.com> Date: Wed, 4 Nov 2020 12:04:18 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfced-future] Qualifications for series leader / advisor / subject matter expert 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, 04 Nov 2020 17:04:21 -0000 In trying to articulate to someone my (admittedly rather amorphous) concerns with current proposed text, I realized that I make some assumptions that may not be shared. Maybe articulating these will help us find our clear differences and then resolutions for them. I assume that we want a significantly skilled subject matter (technical publishing) expert. I also assume that we the odds are that if we can find such a person they will not have a deep understanding of our processes, expectations, habits, ... Thus, we are asking someone to come in and spend significant time and energy to learn to work with us. And learn what we need. This has multiple implications. It implies a significant degree of early engagement so they can actually learn our reality. It also suggests that we will not want to have to invest in that too often. As a corollary, I assume we want someone who learns to engage effectively with the community, in listening, advising, and to whatever degree we select directing / selecting / pointing... The closest I can come to articulating my overall concern is that some of the descriptions either will not be such that we will be unable to find a sufficiently skilled person to take the job. Or, even worse, we could find someone with apparent sufficient skills whose is a master of producing consultant reports that get thrown in a drawer and ignore. Yours, Joel From nobody Wed Nov 4 10:37:39 2020 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 8A3383A15FA for ; Wed, 4 Nov 2020 10:37:36 -0800 (PST) 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 8VyxpAIrBkKm for ; Wed, 4 Nov 2020 10:37:35 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450: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 E34BE3A15F2 for ; Wed, 4 Nov 2020 10:37:34 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id a7so28465286lfk.9 for ; Wed, 04 Nov 2020 10:37:34 -0800 (PST) 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=hSoj7Vk854BbX5KgjfDbJGsoQv7HYlCC3fMA1OAZjF8=; b=ec3KJiykl6GAixsYwL23WN4ZNIC44pSrkFqhSveVqB95jRl4aradZaFdjBaxHa4ALm newKdBEw97dkJeTDOGXIxISYbMB+lMKHv700GclSTF7H9oQWIe+Qlal9QNEgSZeHOBGp cRWld2O8ZPHUzYAIeMg5GKBD2E2UtPJFnt7MfpUP5gOZvywupH3hbqcGUkexy0+L3s9V zpjRAPZRT5jVQerdYQnSr6BbQFsvaQHjtxqUUvUuarVKfeuRxQ/47psgDPrrXdIzCfrM FSHo6EmpCZZhv+p0ubXOIG4h4kWcJc9J6ElarLMgrvRAvMFlQl0A0SAS4eVZHu4g/LjX ySIg== 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=hSoj7Vk854BbX5KgjfDbJGsoQv7HYlCC3fMA1OAZjF8=; b=MMBMUVmN3RbGZdxqqKYkTaf+0sWA1wtNLxsRxlWdLtkycWWi9gynczYH+1T1bwjDSM c9MPqo1jJgVF7Z/vTs1WtZco1wOAzPhwqUEyApW+8l+6l60jHVHe5zgqIW/qFInXbtqZ xkhyr28j0BinxuJhkFJeniv7gmRbWs2uLCXPZg8D5HQ5q22Kvsx3i2ZMmTt/Uk6TVvLk 9ZOIWP//8ud+9K/hzr643sFJEbnTr77P2NSDT0Rvjvl6sbP83b+CCHs1HowxD4UCLmBd Hqs302HTRlr8QCXkGcPa6THyf4q4to9oNADSJ8kZutDefDzHPxeDEP5bipHXmiqcYO3r DLIA== X-Gm-Message-State: AOAM533k4syEEBIJZAdR/zEG39OkkqI7XZ0F9uFkKvb/1Mwpmxl4Gjhr zP93jgNBvPobqN9D6YEuAAHio3eoiGCCw/GHtFbCpw== X-Google-Smtp-Source: ABdhPJx9MUVn59ywXtAUdUS+pn1ogtjWpsdkZY1Gs2p2CyzbOqeRLal7aKsh5SiB8Lv9dBQgU14484nIlIUe4PRdxkM= X-Received: by 2002:ac2:48bb:: with SMTP id u27mr9270345lfg.516.1604515053017; Wed, 04 Nov 2020 10:37:33 -0800 (PST) MIME-Version: 1.0 References: <9183499C-0A42-494E-900C-DF17774DE1FE@cisco.com> <422D0794-C941-41E8-A6A7-28EB2C0A37CE@cisco.com> <1fdef0e9-e371-ee47-ce3e-b4a7b85fa24e@nthpermutation.com> <336b0743-e4d5-a45c-e06a-702bd7068c8a@gmail.com> In-Reply-To: From: Eric Rescorla Date: Wed, 4 Nov 2020 10:36:57 -0800 Message-ID: To: Eliot Lear Cc: Martin Thomson , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000c5b24705b34c4545" Archived-At: Subject: Re: [Rfced-future] Issue 12: Is the expert an advisor (RSA) vs an executive editor (RSE) 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, 04 Nov 2020 18:37:37 -0000 --000000000000c5b24705b34c4545 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 4, 2020 at 1:28 AM Eliot Lear wrote: > Hi Eric, > > On 4 Nov 2020, at 04:08, Eric Rescorla wrote: > > It's worth noting that in our current practice, the RPC doesn't publish > the RFC without author (or in extremis, AD) signoff, so it takes a lot fo= r > a dispute to become irreparable as opposed to delaying the publication of > the RFC. > > > Yes. There are two situations: > > > - There is a dispute with an author > - There is a question within the RPC itself about how to proceed. > > > You are describing the former case. We have said that as things stand, w= e > were going to leave it in the hands of the stream managers (in the case o= f > the IETF it would be the AD) to make the final call, and *not* the RPC, > presumably within the limits of the current approved format (e.g, one > shouldn=E2=80=99t expect a stream manager to override the RPC in publishi= ng an RFC > in EBCDIC). > > In the second case, as an author, I leave many editorial decisions to the > RPC. But they themselves might find decision points that need to be > addressed. In this case, I think where Martin is angling is that the RPC > makes the call, and then perhaps informs the community of an ambiguity an= d > how they handled it. > Yes. i think they make the call using some mechanism of their choice. Given that this is ultimately only a suggestion. > One possible resolution is that the expert exercises moral authority =E2= =80=93 as > experts do =E2=80=93 and provides guidance when asked by the RPC within t= he > existing framework. If the existing framework is found to be wanting, th= e > advisor might point this out to strategy body. It is then up to them to > resolve through whatever processes they have. They might seek guidance > from the advisor to resolve issues. > > > Assuming there is such a person would this text be acceptable? And if > not, what would be? > Well, i don't think "moral authority" makes any sense. They're advising in the form of expertise. The right model here is effectively the situation we have with the LLC, counsel where the LLC can consult counsel and take decisions based on that but also that counsel is available to inform community decisions. -Ekr > Eliot > --000000000000c5b24705b34c4545 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 4, 2020 at 1:28 AM Eliot = Lear <lear@cisco.com> wrote:
Hi Eric,

On 4 Nov 2020, at 04:08, Eric Rescorla <ekr@rtfm.com> wrote:

It's worth noting that in our current= practice, the RPC doesn't publish the RFC without author (or in extrem= is, AD) signoff, so it takes a lot for a dispute to become irreparable as o= pposed to delaying the publication of the RFC.

Yes.=C2=A0 There are two situations:

<= ul>
  • There is a dispute with an author
  • There is a question within= the RPC itself about how to proceed.

    • Yo= u are describing the former case.=C2=A0 We have said that as things stand, = we were going to leave it in the hands of the stream managers (in the case = of the IETF it would be the AD) to make the final call, and not=C2= =A0the RPC, presumably within the limits of the current approved format (e.= g, one shouldn=E2=80=99t expect a stream manager to override the RPC in pub= lishing an RFC in EBCDIC).

    In the second case, as = an author, I leave many editorial decisions to the RPC.=C2=A0 But they them= selves might find decision points that need to be addressed.=C2=A0 In this = case, I think where Martin is angling is that the RPC makes the call, and t= hen perhaps informs the community of an ambiguity and how they handled it. = =C2=A0

    Yes. i think they make t= he call using some mechanism of their choice. Given that this is ultimately= only a suggestion.
    =C2=A0
    =
    One possible resolution is that the expert exerci= ses moral authority =E2=80=93 as experts do =E2=80=93 and provides guidance= when asked by the RPC within the existing framework.=C2=A0 If the existing= framework is found to be wanting, the advisor might point this out to stra= tegy body.=C2=A0 It is then up to them to resolve through whatever processe= s they have.=C2=A0 They might seek guidance from the advisor to resolve iss= ues.

    Assuming there is such a person would this = text be acceptable?=C2=A0 And if not, what would be?

    Well, i don't think "moral authority" m= akes any sense. They're advising in the form of expertise.
    The right model here is effectively the situation we have with= the LLC, counsel where the LLC can consult counsel and take decisions base= d on that but also that counsel is available to inform community decisions.=


    -Ekr


    Eliot
    --000000000000c5b24705b34c4545-- From nobody Wed Nov 4 11:18:08 2020 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 C1B533A0F47; Wed, 4 Nov 2020 11:18:07 -0800 (PST) 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 923RaegOjYhh; Wed, 4 Nov 2020 11:18:06 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEFA23A0EE0; Wed, 4 Nov 2020 11:18:05 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kaOIG-000OGB-8N; Wed, 04 Nov 2020 14:18:04 -0500 Date: Wed, 04 Nov 2020 14:17:57 -0500 From: John C Klensin To: Brian E Carpenter cc: 'Eliot Lear' , rfced-future@iab.org Message-ID: <6F079FF1650F9655DF70E086@PSB> In-Reply-To: References: <011601d698f3$4e1237e0$ea36a7a0$@olddog.co.uk> 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] Issue 12: Is the expert an advisor (RSA) vs an executive editor (RSE) 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, 04 Nov 2020 19:18:08 -0000 --On Saturday, October 3, 2020 09:25 +1300 Brian E Carpenter wrote: > I think that the root cause of the problems we experienced in > 2018 and 2019 was split responsibility about the line > management of both RFC production and tools implementation. > This was built into the old model, with the IAD, the RSOC, and > the RSE all believing they were supposed to be in charge. The > arrival of the LLC sharpened up this problem, but also makes > it clear that the LLC -- and *only* the LLC -- should be > responsible for line management. Brian, While I might have said the same thing a few months ago, after reading the subsequent thread (although I'm going back to the above to reply), thinking about some other correspondence (in and out of the IETF) and other situations, reflecting on "the RFC Editor function long ago", the "moral authority" and "provides guidance when asked by the RPC" characterizations, and the implications of what seem to me to be frightening similarities between Henrik's (and Leif's) description of his situation and Heather's description of what caused her to leave, I partially disagree. In that old model, the IAD (and IAOC), the RSOC (and IAB), the RSE (and predecessors), and (by the way) the IESG all thought (and acted as if) they were part of a team effort, working together for the best results for the IETF community and the Internet... with perhaps-surprisingly little attention paid on a regular basis to who was "in charge". Now, that has clearly changed and the "who is in charge" question has become fundamental. Perhaps the cause(s) [1] of that are inevitable or unavoidable at there is no going back to more collaborative and cooperative times. However, if the LLC and its ExecDir are "in charge" and they see their role as running things like a good company with responsible management controls over employees and contractors -- and it is easy to understand the LLC agreement and several of the IASA2 documents that way so they are not to blame for going down that path -- then, unless we can figure out how to erect some very strong boundaries (and get them to agree because it is not clear the community can dictate to them), the difference between "responsible for line management" and "it is part of our job to lay out contractual language and, even more important, rules about how contractors behave" [2] is strictly up to the LLC and its interpretation(s). For this particular case, where this is leading is that, as long as the LLC has the ability to say "you cannot give that advice or issue those instructions" or "you are not allowed to say anything to the IETF public without our approval", the "advisor versus executive editor" question is ultimately meaningless -- they are just contractors subject to the LLC's rules. Now, I wouldn't expect any of the current actors in the LLC to impose restrictions that broad or draconian, but that doesn't mean they or their successors couldn't (they might even feel obligated to do so if acceptance of particular advice would, e.g., increase costs. I'm coning to realize that another pair of issues I've tried to raise are relevant to this. Whether as advisor, executive editor, or some other characterization of the role, there are knowledge and skills involved that are rarely taught in, e.g., network engineering school. This list keeps coming back to variations on "the community makes the ultimate decisions about strategic issues". Unless we are willing to write into the job description for this position (with either of these titles or another one) "willing and with the needed skills to educate the IETF community about publications and publication strategy issues" and then write into the job description of IETF participants "willing to either be educated about publications and publication strategy issues or to know what they don't know and stay out of the discussions" (and figure of a way to enforce the IETF community requirement without suppressing dissent) then we are going to have terrible difficulty recruiting someone of the caliber I assume you want for the position and retaining them once recruited... even if the LLC is not the ultimate arbiter of strategic decisions. back to lurking... john [1] These are perhaps caricatures, not quotes, but I see "need to watch out for the welfare and best interests of the company", "I'm going to be perceived of as 'in charge' and blamed if things go wrong, so I'd best assert control", or fundamental changes in the characteristics of the people who volunteer for various leadership roles and who, from them, are selected as likely parts of the puzzle. [2] The recent consultation about contractor conflicts of interest is an interesting example of this. I'm pleased that the Jay (and the LLC) have been responsive to community concerns about accidentally cutting off valuable substantive input, but nothing actually obligates them to do that -- we advise and they do what they think best (perhaps even first for the company and second for the IETF). From nobody Wed Nov 4 11:31:50 2020 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 8B8963A0FCC for ; Wed, 4 Nov 2020 11:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 w8eeyBYZKtcb for ; Wed, 4 Nov 2020 11:31:47 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA06C3A0FC2 for ; Wed, 4 Nov 2020 11:31:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=597; q=dns/txt; s=iport; t=1604518307; x=1605727907; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=mIN8Dij2pUuJ49UbtWgy1EudkZ/cRqegf11wK8irpXw=; b=jD+rscLP6xp3OG6FVrqOb+jcC3b70imYEPYaedLlqaDquJGRiJ015BS9 CeQ/+xTEU5TN7dE42fu7JYoseW0jrfacm+MPoyqoLtpIylPQnfhNgbznS GezIU/I0WZH9QSbfRi83gcZJP5vZCVPk1MenuOc31aZc7qmmpFRClqSY1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvAAASAaNf/xbLJq1iHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgT4EAQELAYMZVQEgEi6EPYkFiBacKQsBAQENAQEYCwwEAQG?= =?us-ascii?q?ESgKCDSY3Bg4CAwEBCwEBBQEBAQIBBgRxhWEMhXMBAQMBAQEhSAMLBQsLGgI?= =?us-ascii?q?mAgInMAYTgyYBglwgD69tdoEyij0GgQ4qAY1UggCBOByCTz6CXQGBYIMXM4I?= =?us-ascii?q?sBJAUqA2Cd4MZl3ADH4MGj0ePILAwg2ECBAYFAhWBaiSBVzMaCBsVOyoBgj4?= =?us-ascii?q?+EhkNjlaIToVFQAMwOAIGAQkBAQMJjkgBAQ?= X-IronPort-AV: E=Sophos;i="5.77,451,1596499200"; d="scan'208";a="30805104" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Nov 2020 19:31:42 +0000 Received: from [10.61.194.70] ([10.61.194.70]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A4JVgs4030262 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Nov 2020 19:31:42 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Eliot Lear In-Reply-To: <36c2515e-f687-d7c9-6913-795c921a9e9f@huitema.net> Date: Wed, 4 Nov 2020 20:31:41 +0100 Cc: Eliot Lear , Eric Rescorla , rfced-future@iab.org, Martin Thomson Content-Transfer-Encoding: quoted-printable Message-Id: References: <9183499C-0A42-494E-900C-DF17774DE1FE@cisco.com> <422D0794-C941-41E8-A6A7-28EB2C0A37CE@cisco.com> <1fdef0e9-e371-ee47-ce3e-b4a7b85fa24e@nthpermutation.com> <336b0743-e4d5-a45c-e06a-702bd7068c8a@gmail.com> <36c2515e-f687-d7c9-6913-795c921a9e9f@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.194.70, [10.61.194.70] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Rfced-future] Issue 12: Is the expert an advisor (RSA) vs an executive editor (RSE) 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, 04 Nov 2020 19:31:49 -0000 Eric, Christian, >=20 >=20 > I would avoid "moral authority=E2=80=9D. Fair points, both of you. I only meant the term in that they have an = expert basis for their views. No need to use the term, tho. Eliot > Martin considers that given their > technical expertise, experts are well suited to making = recommendations. > But these recommendations shall be grounded in technical expertise, = not > a vague "moral authority". >=20 > -- ChristianHuitema >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Wed Nov 4 13:43:58 2020 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 AA15E3A102E; Wed, 4 Nov 2020 13:43:57 -0800 (PST) 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 zsz8uexKP9Zz; Wed, 4 Nov 2020 13:43:56 -0800 (PST) Received: from jays-mbp.localdomain (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 0EE3E3A1022; Wed, 4 Nov 2020 13:43:54 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Jay Daley In-Reply-To: <6F079FF1650F9655DF70E086@PSB> Date: Thu, 5 Nov 2020 10:43:52 +1300 Cc: Brian E Carpenter , rfced-future@iab.org, Eliot Lear Content-Transfer-Encoding: quoted-printable Message-Id: <544E808D-026A-4AE6-80E0-4D4EA39C9BFB@ietf.org> References: <011601d698f3$4e1237e0$ea36a7a0$@olddog.co.uk> <6F079FF1650F9655DF70E086@PSB> To: John C Klensin X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rfced-future] Issue 12: Is the expert an advisor (RSA) vs an executive editor (RSE) 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, 04 Nov 2020 21:43:58 -0000 John > On 5/11/2020, at 8:17 AM, John C Klensin wrote: >=20 >=20 >=20 > --On Saturday, October 3, 2020 09:25 +1300 Brian E Carpenter > wrote: >=20 >> I think that the root cause of the problems we experienced in >> 2018 and 2019 was split responsibility about the line >> management of both RFC production and tools implementation. >> This was built into the old model, with the IAD, the RSOC, and >> the RSE all believing they were supposed to be in charge. The >> arrival of the LLC sharpened up this problem, but also makes >> it clear that the LLC -- and *only* the LLC -- should be >> responsible for line management. >=20 > Brian, >=20 > While I might have said the same thing a few months ago, after > reading the subsequent thread (although I'm going back to the > above to reply), thinking about some other correspondence (in > and out of the IETF) and other situations, reflecting on "the > RFC Editor function long ago", the "moral authority" and > "provides guidance when asked by the RPC" characterizations, and > the implications of what seem to me to be frightening > similarities between Henrik's (and Leif's) description of his > situation and Heather's description of what caused her to leave, > I partially disagree. >=20 > In that old model, the IAD (and IAOC), the RSOC (and IAB), the > RSE (and predecessors), and (by the way) the IESG all thought > (and acted as if) they were part of a team effort, working > together for the best results for the IETF community and the > Internet... with perhaps-surprisingly little attention paid on a > regular basis to who was "in charge". Now, that has clearly > changed and the "who is in charge" question has become > fundamental. Perhaps the cause(s) [1] of that are inevitable or > unavoidable at there is no going back to more collaborative and > cooperative times. =20 >=20 > However, if the LLC and its ExecDir are "in charge" and they see > their role as running things like a good company with > responsible management controls over employees and contractors > -- and it is easy to understand the LLC agreement and several of > the IASA2 documents that way so they are not to blame for going > down that path -- then, unless we can figure out how to erect > some very strong boundaries (and get them to agree because it is > not clear the community can dictate to them), the difference > between "responsible for line management" and "it is part of our > job to lay out contractual language and, even more important, > rules about how contractors behave" [2] is strictly up to the > LLC and its interpretation(s). =20 You are mistakenly interpreting Henrik=E2=80=99s message to mean that he = was over managed by me, when the complaint about me is actually about = under management. =20 > For this particular case, where this is leading is that, as long > as the LLC has the ability to say "you cannot give that advice > or issue those instructions" or "you are not allowed to say > anything to the IETF public without our approval", the "advisor > versus executive editor" question is ultimately meaningless -- > they are just contractors subject to the LLC's rules. Now, I > wouldn't expect any of the current actors in the LLC to impose > restrictions that broad or draconian, but that doesn't mean they > or their successors couldn't (they might even feel obligated to > do so if acceptance of particular advice would, e.g., increase > costs. I agree that this is a risk, but I think it=E2=80=99s a much bigger risk = than can be mitigated against here as it applies to all contractual = relationships. I have on my work plan a consultation about contractual = terms and I think that would be a good place to raise this - i.e. to = introduce a "safe harbour" clause for a contractor providing their = honest opinion to the IETF community. >=20 > I'm coning to realize that another pair of issues I've tried to > raise are relevant to this. Whether as advisor, executive > editor, or some other characterization of the role, there are > knowledge and skills involved that are rarely taught in, e.g., > network engineering school. This list keeps coming back to > variations on "the community makes the ultimate decisions about > strategic issues". Unless we are willing to write into the job > description for this position (with either of these titles or > another one) "willing and with the needed skills to educate the > IETF community about publications and publication strategy > issues" and then write into the job description of IETF > participants "willing to either be educated about publications > and publication strategy issues or to know what they don't know > and stay out of the discussions" (and figure of a way to enforce > the IETF community requirement without suppressing dissent) then > we are going to have terrible difficulty recruiting someone of > the caliber I assume you want for the position and retaining > them once recruited... even if the LLC is not the ultimate > arbiter of strategic decisions. >=20 > back to lurking... > john >=20 >=20 >=20 > [1] These are perhaps caricatures, not quotes, but I see "need > to watch out for the welfare and best interests of the company", > "I'm going to be perceived of as 'in charge' and blamed if > things go wrong, so I'd best assert control", or fundamental > changes in the characteristics of the people who volunteer for > various leadership roles and who, from them, are selected as > likely parts of the puzzle. >=20 > [2] The recent consultation about contractor conflicts of > interest is an interesting example of this. I'm pleased that > the Jay (and the LLC) have been responsive to community concerns > about accidentally cutting off valuable substantive input, but > nothing actually obligates them to do that -- we advise and they > do what they think best (perhaps even first for the company and > second for the IETF). I disagree. RFC 8711 is explicit: Responsiveness to the community. The IETF LLC is expected to act consistently with the documented consensus of the IETF community, to be responsive to the community's needs, and to adapt its decisions in response to consensus-based community feedback. If your response to that is that the LLC could choose to ignore that = then we=E2=80=99re again into a much bigger set of issues. 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 From nobody Wed Nov 4 14:47:08 2020 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 196AC3A10C3 for ; Wed, 4 Nov 2020 14:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 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.247, 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 rcgwwZv5Yorq for ; Wed, 4 Nov 2020 14:47:05 -0800 (PST) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 692793A10BD for ; Wed, 4 Nov 2020 14:47:05 -0800 (PST) Received: by mail-pl1-x62c.google.com with SMTP id k7so29849plk.3 for ; Wed, 04 Nov 2020 14:47:05 -0800 (PST) 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=A8ks94KTcVbaX0OfjO5NQXdxdFiLtIvvzR/IlUpluXs=; b=GyT3A1tb69vJ36uJmckEYjbtCkKGu84uL0N3DFPHxCd8tYg0yepktWrmSSkh8R1ioA HSkX85ZZDf32kGERl/aJb89AlrTSHW1+ohWQyPyqsRoEHYzBNCXy5YCVTfK6PGFUN7Qm Z0QFgGEKZcxUcsCUXBFnVBlGzbeXLUSgT7aAQCVAN25sHUmFZF4Fb4ugEu9eOpDJkfAC X06QpoK8170HXCBC37lcL/NxFzlPbpfKfRYMKkwuVzgxMSQvCZgUPVVu/pZgHVpIRLds pb7qscVS9gmSItIxXFhTzVzlPSibf8tQ65fiVVjZyuMNkssSbEf8JSOvAp8kveEqnEoQ MlWA== 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=A8ks94KTcVbaX0OfjO5NQXdxdFiLtIvvzR/IlUpluXs=; b=XCSLEA0d6iwB4BkQsS6UdPRurzKdnbqshjRDhXZbE7RUuYVuKDiO4lX7FWXNWNyu11 Cjr7CTULgZL+KNgw3jJRWBuwnZHN2IUGZFGDqNtYwl18CtxYcYksxVt0j3YJ5LRYnIBC 0KEhcuRY3TLxiZhhNBjOr9zPRfdbPD/CH5ROYi2UOVKWGtsZXWB9RpEKNvSrRQt4v4Cq mGeLkb8dKPobCD5/Xze0xG/cWYsZmocnFhNgXqHts3yo1TOuVkp/lQNPvkurc19hzhp+ fuBQwUtsnz3lTBpLG1xCP86XB6JVv8aqCxhS1NOOQWqjQdxNWaNvFzMGr+soKwXTJCZf jXlw== X-Gm-Message-State: AOAM533uOFY/ykw8x3FY3njSBoUpptGNaiXh4ZiKzFamvkp4IH8JFB11 f2t1vkWPm2THo9eRDJfsOJvnEq9jeShWBA== X-Google-Smtp-Source: ABdhPJwl1aNCpG/oONuNB3uS9ydS9CbBOXKusQCX5ujdgMYhYlSEVPPIYmPwf7jihPG316tHh7uZwA== X-Received: by 2002:a17:902:a3c9:b029:d5:df0c:f217 with SMTP id q9-20020a170902a3c9b02900d5df0cf217mr12298plb.59.1604530024397; Wed, 04 Nov 2020 14:47:04 -0800 (PST) Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id v126sm3537196pfb.137.2020.11.04.14.47.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2020 14:47:03 -0800 (PST) To: "Joel M. Halpern" , rfced-future@iab.org References: <7b7de94f-8b0f-14c6-6e0e-aab547572d1c@joelhalpern.com> From: Brian E Carpenter Message-ID: Date: Thu, 5 Nov 2020 11:46:59 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <7b7de94f-8b0f-14c6-6e0e-aab547572d1c@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Qualifications for series leader / advisor / subject matter expert 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, 04 Nov 2020 22:47:07 -0000 Joel, On 05-Nov-20 06:04, Joel M. Halpern wrote: > In trying to articulate to someone my (admittedly rather amorphous) > concerns with current proposed text, I realized that I make some > assumptions that may not be shared. Maybe articulating these will help > us find our clear differences and then resolutions for them. > > I assume that we want a significantly skilled subject matter (technical > publishing) expert. I also assume that we the odds are that if we can > find such a person they will not have a deep understanding of our > processes, expectations, habits, ... > > Thus, we are asking someone to come in and spend significant time and > energy to learn to work with us. And learn what we need. > > This has multiple implications. It implies a significant degree of > early engagement so they can actually learn our reality. It also > suggests that we will not want to have to invest in that too often. > > As a corollary, I assume we want someone who learns to engage > effectively with the community, in listening, advising, and to whatever > degree we select directing / selecting / pointing... Yes. That is of the essence, whether the person is Editor or Advisor. > The closest I can come to articulating my overall concern is that some > of the descriptions either will not be such that we will be unable to > find a sufficiently skilled person to take the job. > Or, even worse, we could find someone with apparent sufficient skills > whose is a master of producing consultant reports that get thrown in a > drawer and ignore. Agreed, that is a horrible danger that is built into the "contractization" of previously community-volunteer roles. We've all seen it in other contexts, and we don't want to see it in the RFC sphere. (That's not to say that contracts are automatically evil. But contractors are part of our community too.) Brian From nobody Wed Nov 4 14:53:39 2020 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 B94AA3A10E8 for ; Wed, 4 Nov 2020 14:53:37 -0800 (PST) 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 6BodXb4gUAR1 for ; Wed, 4 Nov 2020 14:53:36 -0800 (PST) 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 093DD3A10E7 for ; Wed, 4 Nov 2020 14:53:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A8DB8300B49 for ; Wed, 4 Nov 2020 17:53:33 -0500 (EST) 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 85zTQzH5GPFJ for ; Wed, 4 Nov 2020 17:53:32 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 27FF2300AB0 for ; Wed, 4 Nov 2020 17:53:32 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Wed, 4 Nov 2020 17:53:33 -0500 References: <7b7de94f-8b0f-14c6-6e0e-aab547572d1c@joelhalpern.com> To: rfced-future@iab.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Rfced-future] Qualifications for series leader / advisor / subject matter expert 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, 04 Nov 2020 22:53:38 -0000 >> In trying to articulate to someone my (admittedly rather amorphous) >> concerns with current proposed text, I realized that I make some >> assumptions that may not be shared. Maybe articulating these will help >> us find our clear differences and then resolutions for them. >> >> I assume that we want a significantly skilled subject matter (technical >> publishing) expert. I also assume that we the odds are that if we can >> find such a person they will not have a deep understanding of our >> processes, expectations, habits, ... >> >> Thus, we are asking someone to come in and spend significant time and >> energy to learn to work with us. And learn what we need. >> >> This has multiple implications. It implies a significant degree of >> early engagement so they can actually learn our reality. It also >> suggests that we will not want to have to invest in that too often. >> >> As a corollary, I assume we want someone who learns to engage >> effectively with the community, in listening, advising, and to whatever >> degree we select directing / selecting / pointing... > > Yes. That is of the essence, whether the person is Editor or Advisor. > >> The closest I can come to articulating my overall concern is that some >> of the descriptions either will not be such that we will be unable to >> find a sufficiently skilled person to take the job. >> Or, even worse, we could find someone with apparent sufficient skills >> whose is a master of producing consultant reports that get thrown in a >> drawer and ignore. > > Agreed, that is a horrible danger that is built into the "contractization" > of previously community-volunteer roles. We've all seen it in other > contexts, and we don't want to see it in the RFC sphere. > > (That's not to say that contracts are automatically evil. But contractors > are part of our community too.) We are all more successful when contractions are partners in the journey! Russ From nobody Thu Nov 5 02:06:44 2020 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 210D53A1732 for ; Thu, 5 Nov 2020 02:06:42 -0800 (PST) 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 64w3pGoZg-kT for ; Thu, 5 Nov 2020 02:06:36 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 915063A172B for ; Thu, 5 Nov 2020 02:06:26 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.153.104]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 0A5A68AR002766 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2020 02:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1604570781; x=1604657181; i=@elandsys.com; bh=npuMzgdPBguHnpagcLU8//W5vAw15p5qDGb2i3kvV1c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=flzht9O63Mn06mSwPds9o19zogrXBN/183qrKVr2q6ZJXG1DAqvNX1vJ7AjLqa9hV cAbQ/J1PR1b/nd0J2VIHmyqLYJ48QgF5nVgKCXrYUiyBdIrWTpoGTlyWSwxc3hqFPO Pp82kh0Qbcs8SPvVHPdp4kE/cgcB4Cn6acsoktl0= Message-Id: <6.2.5.6.2.20201105005945.149795a0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 05 Nov 2020 02:03:18 -0800 To: John C Klensin , rfced-future@iab.org From: S Moonesamy In-Reply-To: <6F079FF1650F9655DF70E086@PSB> References: <011601d698f3$4e1237e0$ea36a7a0$@olddog.co.uk> <6F079FF1650F9655DF70E086@PSB> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Rfced-future] Issue 12: Is the expert an advisor (RSA) vs an executive editor (RSE) 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, 05 Nov 2020 10:06:42 -0000 Hi John, At 11:17 AM 04-11-2020, John C Klensin wrote: >--On Saturday, October 3, 2020 09:25 +1300 Brian E Carpenter > wrote: > > > I think that the root cause of the problems we experienced in > > 2018 and 2019 was split responsibility about the line > > management of both RFC production and tools implementation. > > This was built into the old model, with the IAD, the RSOC, and > > the RSE all believing they were supposed to be in charge. The > > arrival of the LLC sharpened up this problem, but also makes > > it clear that the LLC -- and *only* the LLC -- should be > > responsible for line management. In general, there is more than one root cause to problems. >Brian, > >While I might have said the same thing a few months ago, after >reading the subsequent thread (although I'm going back to the >above to reply), thinking about some other correspondence (in >and out of the IETF) and other situations, reflecting on "the >RFC Editor function long ago", the "moral authority" and >"provides guidance when asked by the RPC" characterizations, and >the implications of what seem to me to be frightening >similarities between Henrik's (and Leif's) description of his >situation and Heather's description of what caused her to leave, >I partially disagree. > >In that old model, the IAD (and IAOC), the RSOC (and IAB), the >RSE (and predecessors), and (by the way) the IESG all thought >(and acted as if) they were part of a team effort, working >together for the best results for the IETF community and the >Internet... with perhaps-surprisingly little attention paid on a >regular basis to who was "in charge". Now, that has clearly >changed and the "who is in charge" question has become >fundamental. Perhaps the cause(s) [1] of that are inevitable or >unavoidable at there is no going back to more collaborative and >cooperative times. There was a time when the RFC Editor had the final say. If I am not mistaken, that was based on the person's experience instead of the job description. That worked well as long as someone out there was writing the check without asking too many questions. The structure (after the transition) created contractual relationships together with the accountability which comes with that. There were also several "governance" entities in the structure which made accountability more complex. A structure does not work well if there isn't some cooperation, At the same time, people from the outside expect someone to be in charge of daily operations. The discussion looks one about the title of that person. Another angle to the discussion is the "governance" entities. The strategy over the years was to put the IETF Chair on most of the committees. The person automatically became the one in charge of everything. Is that a sustainable approach? One of the issues identified by IETF Administration was that there isn't any contract performance framework. Would copying and pasting a framework from somewhere else would work well? Regards, S. Moonesamy From nobody Mon Nov 9 02:58:22 2020 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 67DFF3A0E87 for ; Mon, 9 Nov 2020 02:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 nZrGgQkWHPVs for ; Mon, 9 Nov 2020 02:58:20 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA313A0E83 for ; Mon, 9 Nov 2020 02:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5864; q=dns/txt; s=iport; t=1604919499; x=1606129099; h=from:mime-version:subject:message-id:date:to; bh=KgQ8qnvuOlN+jxlGf+gAqsqOu9P4HgajE+weO5Exb7w=; b=e1soKktoS9rJIEyXlRBjqG0HLzEYTsjsE1zFy9yPM28HoS/bdbKsxom1 BOFZ9iW8r2oAH8d3G+YR6IcAklLp/515uyM+KYiemPc0WQZmBR+FpznTF PFRSMeZa7YdahwpHtJK0WspuSbAdfKkWB+A4sEF2yQLMDzYUfZEys5EEA E=; X-IPAS-Result: =?us-ascii?q?A0ArBQBbIKlf/xbLJq1iHgEBCxIMhDmBSQEyhGuJBYd1l?= =?us-ascii?q?DiIGQsBAQENAQEvBAEBhl8mOBMCAwEBAQMCAwEBAQEFAQEBAgEGBHGFbYV0B?= =?us-ascii?q?CRIE1gCgQaDEoJnIJ4yjhl2gTKFV4RpgTiNWoIAgTgMEIIhbIdVM4IsBLgmg?= =?us-ascii?q?ncEgxaRagiGAQMfoXCwMoNiAgQGBQIVgWsjgVczGggbFRpLAYI/PRIZDZxpQ?= =?us-ascii?q?ANoAgYBCQEBAwmOSAEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos; i="5.77,463,1596499200"; d="scan'208,217"; a="30913821" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Nov 2020 10:57:58 +0000 Received: from dhcp-10-61-100-129.cisco.com (dhcp-10-61-100-129.cisco.com [10.61.100.129]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A9AvuP0011429 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 9 Nov 2020 10:57:57 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_B7DC536C-0227-4CEE-924C-651EA982046D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <948AEA96-BF3F-4159-8666-5268D27B726B@cisco.com> Date: Mon, 9 Nov 2020 11:57:56 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.100.129, dhcp-10-61-100-129.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Continuing on Issue 12: Is there an Executive Editor or an Advisor? 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, 09 Nov 2020 10:58:21 -0000 --Apple-Mail=_B7DC536C-0227-4CEE-924C-651EA982046D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you to those who have commented on this issue. What was proposed: One possible resolution is that the expert exercises moral authority =E2=80= =93 as experts do =E2=80=93 and provides guidance when asked by the RPC = within the existing framework. If the existing framework is found to be = wanting, the advisor might point this out to strategy body. It is then = up to them to resolve through whatever processes they have. They might = seek guidance from the advisor to resolve issues. There was quite a bit of objection to the term =E2=80=9Cmoral = authority=E2=80=9D. To remedy this, we can do something along these lines, recognizing that = a bit of wordsmithing will still be necessary if this hits a draft: > One possible resolution is that the expert provides guidance when = asked by the RPC within the existing framework. If the existing = framework is found to be wanting, the advisor might point this out to = strategy body. It is then up to them to resolve through whatever = processes they have. They might seek guidance from the advisor to = resolve issues. This leaves several stated concerns open. As I see it, it takes three = forms: Could we write a job description for the role such that it could be = filled? What is the title of the individual? What is the contract period / how is this person treated? Another way to look at this would be to view this person as a senior = member of the RPC - with a slightly different function. In that case, = Martin=E2=80=99s text fits quite neatly: > I think that I proposed something slightly different: we let the RPC = proceed with a decision grounded in their own best judgment (which I = would hope, but not insist, would involve some attempt at consultation). = Then we live with the consequences of mistakes if the eventual = community position differs when consensus is reached. That would simply leave open how this person takes on strategic work. = On their own initiative? At the behest of the community? Both? Should = I hope an issue on this? Maybe we can start discussion here though? Eliot --Apple-Mail=_B7DC536C-0227-4CEE-924C-651EA982046D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thank= you to those who have commented on this issue.

    What was proposed:


    One possible resolution is that the expert = exercises moral authority =E2=80=93 as experts do =E2=80=93 and provides = guidance when asked by the RPC within the existing framework.  If = the existing framework is found to be wanting, the advisor might point = this out to strategy body.  It is then up to them to resolve = through whatever processes they have.  They might seek guidance = from the advisor to resolve issues.

    There was quite a bit of = objection to the term =E2=80=9Cmoral authority=E2=80=9D.

    To remedy this, we can = do something along these lines, recognizing that a bit of wordsmithing = will still be necessary if this hits a draft:

    One possible resolution is that the expert provides guidance = when asked by the RPC within the existing framework.  If the = existing framework is found to be wanting, the advisor might point this = out to strategy body.  It is then up to them to resolve through = whatever processes they have.  They might seek guidance from the = advisor to resolve issues.

    This leaves several = stated concerns open.  As I see it, it takes three forms:
    • Could we write a job = description for the role such that it could be filled?
    • What is the title of the individual?
    • What = is the contract period / how is this person treated?

    Another way to = look at this would be to view this person as a senior member of the RPC = - with a slightly different function.  In that case, Martin=E2=80=99s= text fits quite neatly:

    I think that I proposed = something slightly different: we let the RPC proceed with a decision = grounded in their own best judgment (which I would hope, but not insist, = would involve some attempt at consultation).  Then we live with the = consequences of mistakes if the eventual community position differs when = consensus is reached.

    That would simply leave open how this person takes on = strategic work.  On their own initiative?  At the behest of = the community?  Both?  Should I hope an issue on this? =  Maybe we can start discussion here though?

    Eliot

    = --Apple-Mail=_B7DC536C-0227-4CEE-924C-651EA982046D-- From nobody Mon Nov 9 07:27:49 2020 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 C16ED3A113A for ; Mon, 9 Nov 2020 07:27:46 -0800 (PST) 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_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 eeCducl8fO5a for ; Mon, 9 Nov 2020 07:27:45 -0800 (PST) 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 A2EE03A1139 for ; Mon, 9 Nov 2020 07:27:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4CVFHP3QGZz1nsT9; Mon, 9 Nov 2020 07:27:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1604935665; bh=EIK/116XAvxa8w90U5WaEWja1J1imICtMv59Qbwnj60=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Q5P6H5F0i28spA+PdhWx5+JcG1ssfaIK/iHDnavAZkEX3wYNWhtUgBP/fADbufToY K97KBp1kq0ly8fG5s19B3MQiwmujL0tY2qsC9E8MsACrPrHGukKBRMpWNq6OR1suW/ UQBg+xQRTP2VTLe0RDHlqzOZmJorluo5+T0YO7IY= X-Quarantine-ID: <1lGRc19ylV-h> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4CVFHN4X32z1nsT0; Mon, 9 Nov 2020 07:27:44 -0800 (PST) To: Eliot Lear , rfced-future@iab.org References: <948AEA96-BF3F-4159-8666-5268D27B726B@cisco.com> From: "Joel M. Halpern" Message-ID: <173fafb6-bd51-ce1a-73f1-d01c1f874471@joelhalpern.com> Date: Mon, 9 Nov 2020 10:27:43 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.1 MIME-Version: 1.0 In-Reply-To: <948AEA96-BF3F-4159-8666-5268D27B726B@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Continuing on Issue 12: Is there an Executive Editor or an Advisor? 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, 09 Nov 2020 15:27:47 -0000 This seems to assume that in almost all cases the stragic body knows what the issues are and what the reasonable paths are. And that it can tell when it needs to ask for advice. From my time on the RSOC, what struck me early on was the number of things Heather was bringing up that would not have occurred to me. I am concerned that the formulations proposed ignore the need for active participation in the strategy work by a respected expert in the domain. Yours, Joel On 11/9/2020 5:57 AM, Eliot Lear wrote: > Thank you to those who have commented on this issue. > > What was proposed: > > > One possible resolution is that the expert exercises moral authority – > as experts do – and provides guidance when asked by the RPC within the > existing framework.  If the existing framework is found to be wanting, > the advisor might point this out to strategy body.  It is then up to > them to resolve through whatever processes they have.  They might seek > guidance from the advisor to resolve issues. > > There was quite a bit of objection to the term “moral authority”. > > To remedy this, we can do something along these lines, recognizing that > a bit of wordsmithing will still be necessary if this hits a draft: > >> One possible resolution is that the expert provides guidance when >> asked by the RPC within the existing framework.  If the existing >> framework is found to be wanting, the advisor might point this out to >> strategy body.  It is then up to them to resolve through whatever >> processes they have.  They might seek guidance from the advisor to >> resolve issues. > > This leaves several stated concerns open.  As I see it, it takes three > forms: > > * Could we write a job description for the role such that it could be > filled? > * What is the title of the individual? > * What is the contract period / how is this person treated? > > > Another way to look at this would be to view this person as a senior > member of the RPC - with a slightly different function.  In that case, > Martin’s text fits quite neatly: > >> I think that I proposed something slightly different: we let the RPC >> proceed with a decision grounded in their own best judgment (which I >> would hope, but not insist, would involve some attempt at >> consultation).  Then we live with the consequences of mistakes if the >> eventual community position differs when consensus is reached. > > That would simply leave open how this person takes on strategic work. >  On their own initiative?  At the behest of the community?  Both? >  Should I hope an issue on this?  Maybe we can start discussion here > though? > > Eliot > > From nobody Mon Nov 9 07:47:36 2020 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 DB7683A115A; Mon, 9 Nov 2020 07:47:34 -0800 (PST) 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 ZxzVSJ6oy1SI; Mon, 9 Nov 2020 07:47:33 -0800 (PST) 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 5FC7E3A1149; Mon, 9 Nov 2020 07:47:33 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kc9OG-000OeD-1i; Mon, 09 Nov 2020 10:47:32 -0500 Date: Mon, 09 Nov 2020 10:47:26 -0500 From: John C Klensin To: Eliot Lear , rfced-future@iab.org Message-ID: <42DB7FA178B7FA8180956051@PSB> In-Reply-To: <948AEA96-BF3F-4159-8666-5268D27B726B@cisco.com> References: <948AEA96-BF3F-4159-8666-5268D27B726B@cisco.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] Continuing on Issue 12: Is there an Executive Editor or an Advisor? 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, 09 Nov 2020 15:47:35 -0000 --On Monday, November 9, 2020 11:57 +0100 Eliot Lear wrote: > Thank you to those who have commented on this issue. > > What was proposed: >... > To remedy this, we can do something along these lines, > recognizing that a bit of wordsmithing will still be necessary > if this hits a draft: > >> One possible resolution is that the expert provides guidance >> when asked by the RPC within the existing framework. If the >> existing framework is found to be wanting, the advisor might >> point this out to strategy body. It is then up to them to >> resolve through whatever processes they have. They might >> seek guidance from the advisor to resolve issues. Eliot, Time constraints make it impossible for me to communicate all of my thoughts on this subject, which I assume some will consider an act of mercy. But... Skipping over the "advisor", "executive editor", "managing editor", etc., distinctions as part of a different topic... If this person is to provide advice only when the RPC asks (and whether they are nominally part of the RPC or separate), that downgrades the role to that of a consultant on retainer who gets involved only when someone internal decides there is a problem. While I completely trust the current RPC and its leadership to know when there is an issue and reach out for advice (and hope they will be with us forever), that is not a good basis for a long-term organizational plan. As long as we don't get ourselves into an extreme version of "the LLC decides what contractors are allowed to say and to whom", "might point this out to strategy body..." is essentially a no-op because anyone participating (or even interested) constructively in the IETF and associated activities ought to be able to point out anything they like to whomever they like. See Joel's recent comment for a different take on what may be the same concern. And, at the risk of repeating myself, expecting a/the strategy body to make decisions assumes a great deal of subject matter expertise in that body, starting with every single member knowing what they don't know, no matter how strong their opinions and gut feelings. One option that might help would be to make this person an ex-officio and voting member of the strategy body who could be locked out of its meetings only when their own job performance was being reviewed. More on your other concerns later (unless others get to them first), but creating a job that needs a senior person and then treating the party involved as a junior one and / or someone who is expected to stand by and be available on call gets you either a candidate who is mostly retired but willing to pick up an occasional on-demand task or someone who isn't really qualified. best, john From nobody Mon Nov 9 08:35:36 2020 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 8E2DA3A11CE for ; Mon, 9 Nov 2020 08:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 GnUEvOmsxdZ5 for ; Mon, 9 Nov 2020 08:35:33 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A05023A11D0 for ; Mon, 9 Nov 2020 08:35:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3476; q=dns/txt; s=iport; t=1604939732; x=1606149332; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=SCx6go1VtmLiGJ1fLawrJPplUpuTLFWgeD8lGGvLhro=; b=Ec5z4Wqt+u0RUJMvzyOGPN7/Pat90dkO8VD6Kv5S60TprpHBrY3osjUD 26zPtURZMnw11dRbfNkGTtU7VEzHWZyhEsdy/OC27J8JDLE1OHPdUGyDn 8Qk7QY/KO9DDw70ziZDL0ivqUL4haesT+jOQK1rJZzLIKPW64fI2uhK1t E=; X-IPAS-Result: =?us-ascii?q?A0ADAwBkb6lf/xbLJq1iHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+DHlUBMi6EPYkFh3UmnCsLAQEBDQEBGAsMBAEBhEoCghMmOBMCAwEBAQMCA?= =?us-ascii?q?wEBAQEFAQEBAgEGBHGFYQyFcgEBAQECAQEBIUgDBAcFCwkCGAICJgICJzAGE?= =?us-ascii?q?xSDEgGCZiAPkmWbD3aBMoVXhGwGgQ4qjVqCAIERJwwQgk8+gl0BgWCDFzOCL?= =?us-ascii?q?AS4JoJ3gxqRagiGAQMWCaFwsDKDYgIEBgUCFYFrI4FXMxoIGxUaISoBgj4+E?= =?us-ascii?q?hkNjlaIToVFQAMwOAIGAQkBAQMJjkgBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,463,1596499200"; d="scan'208";a="30980600" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Nov 2020 16:35:28 +0000 Received: from ams3-vpn-dhcp5299.cisco.com (ams3-vpn-dhcp5299.cisco.com [10.61.84.178]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A9GZRlw012755 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 9 Nov 2020 16:35:28 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Eliot Lear In-Reply-To: <173fafb6-bd51-ce1a-73f1-d01c1f874471@joelhalpern.com> Date: Mon, 9 Nov 2020 17:35:27 +0100 Cc: Eliot Lear , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <948AEA96-BF3F-4159-8666-5268D27B726B@cisco.com> <173fafb6-bd51-ce1a-73f1-d01c1f874471@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.84.178, ams3-vpn-dhcp5299.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Continuing on Issue 12: Is there an Executive Editor or an Advisor? 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, 09 Nov 2020 16:35:35 -0000 Hi Joel and John, Thanks for your feedback. Do you think you could take the modify the = text in some way that would address the concerns you=E2=80=99re raising? = So for instance, perhaps you would s/when asked by the/to/ so that the = sentence reads, =E2=80=9COne possible resolution is that the expert = provides guidance to RPC=E2=80=A6=E2=80=9D. What would you say about the = relationship of this person to the strategic body? Others should of course feel free to throw their own variants out there. Eliot > On 9 Nov 2020, at 16:27, Joel M. Halpern wrote: >=20 > This seems to assume that in almost all cases the stragic body knows = what the issues are and what the reasonable paths are. And that it can = tell when it needs to ask for advice. >=20 > =46rom my time on the RSOC, what struck me early on was the number of = things Heather was bringing up that would not have occurred to me. > I am concerned that the formulations proposed ignore the need for = active participation in the strategy work by a respected expert in the = domain. >=20 > Yours, > Joel >=20 > On 11/9/2020 5:57 AM, Eliot Lear wrote: >> Thank you to those who have commented on this issue. >> What was proposed: >> One possible resolution is that the expert exercises moral authority = =E2=80=93 as experts do =E2=80=93 and provides guidance when asked by = the RPC within the existing framework. If the existing framework is = found to be wanting, the advisor might point this out to strategy body. = It is then up to them to resolve through whatever processes they have. = They might seek guidance from the advisor to resolve issues. >> There was quite a bit of objection to the term =E2=80=9Cmoral = authority=E2=80=9D. >> To remedy this, we can do something along these lines, recognizing = that a bit of wordsmithing will still be necessary if this hits a draft: >>> One possible resolution is that the expert provides guidance when = asked by the RPC within the existing framework. If the existing = framework is found to be wanting, the advisor might point this out to = strategy body. It is then up to them to resolve through whatever = processes they have. They might seek guidance from the advisor to = resolve issues. >> This leaves several stated concerns open. As I see it, it takes = three forms: >> * Could we write a job description for the role such that it could = be >> filled? >> * What is the title of the individual? >> * What is the contract period / how is this person treated? >> Another way to look at this would be to view this person as a senior = member of the RPC - with a slightly different function. In that case, = Martin=E2=80=99s text fits quite neatly: >>> I think that I proposed something slightly different: we let the RPC = proceed with a decision grounded in their own best judgment (which I = would hope, but not insist, would involve some attempt at consultation). = Then we live with the consequences of mistakes if the eventual = community position differs when consensus is reached. >> That would simply leave open how this person takes on strategic work. = On their own initiative? At the behest of the community? Both? = Should I hope an issue on this? Maybe we can start discussion here = though? >> Eliot >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Mon Nov 9 09:31:48 2020 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 0E9E23A12B2; Mon, 9 Nov 2020 09:31:40 -0800 (PST) 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 2mrfyc9iPKaD; Mon, 9 Nov 2020 09:31:38 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854633A12E3; Mon, 9 Nov 2020 09:31:36 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kcB0w-000P1u-EY; Mon, 09 Nov 2020 12:31:34 -0500 Date: Mon, 09 Nov 2020 12:31:28 -0500 From: John C Klensin To: Eliot Lear , "Joel M. Halpern" cc: rfced-future@iab.org Message-ID: <77D6CA4AB9C00270EE233488@PSB> In-Reply-To: References: <948AEA96-BF3F-4159-8666-5268D27B726B@cisco.com> <173fafb6-bd51-ce1a-73f1-d01c1f874471@joelhalpern.com> 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@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Continuing on Issue 12: Is there an Executive Editor or an Advisor? 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, 09 Nov 2020 17:31:46 -0000 --On Monday, November 9, 2020 17:35 +0100 Eliot Lear wrote: > Hi Joel and John, >=20 > Thanks for your feedback. Do you think you could take the > modify the text in some way that would address the concerns > you're raising? So for instance, perhaps you would s/when > asked by the/to/ so that the sentence reads, "One possible > resolution is that the expert provides guidance to = RPC=E2=80=A6". > What would you say about the relationship of this person to > the strategic body? Eliot, I'm reluctant to even try to do that for the same reasons I had problems with the way the interim meeting was summarized -- I just see too many of the issues are interconnected and I think there are fundamental differences of opinion within the group who have been commenting that won't be resolved by circling around and coming at the problem from different directions. =20 As an example, unless the "strategy body" can be populated with people with real (broad and in-depth) expertise in publications-related areas (and that means the appointing body has to have sufficient expertise to recognize an expert when they see one), I think we are setting ourselves up for a replay of the last few years -- a situation in which an expert, independent of how we categorize or title to role, will eventually get frustrated and leave (regardless of the "last straw" cause). I don't see that as speculation; I see it as closer to "been there, tried that, have yet to learn from our mistakes". =20 I also see an interesting analogy: we need ADs with management, even strategic management, skills and have found ADs who lacked them problematic. But we also expect in-depth subject matter expertise (including knowing and accepting what they don't know about other areas) and we assume the Nomcom and those who provide feedback to be able to evaluate that (even if, on occasion, they have not been good at evaluating management potential). If we can't populate a "strategy body" with a comparable level of publications knowledge and skill --and individual members who are willing to be educated in areas where they are not expert-- we've better not give them final = authority. Similarly, a key requirement for the RS-whatever position is that whomever has it has a good deal of respect from the community and be, nor only able but willing to educate others on issues and that we do _nothing_ to constrain them in that role. Joh Postel had that respect (albeit partially for other reasons) as did Bob Braden and Olaf Kolkman. So did Heather, especially once she settled in a bit. In at least the publications area, Glen Kowack did not and that may be why we keep forgetting him in discussions of RFC Series management. Getting that level of respect probably requires community buy-in for whomever gets the position (we lucked out with Heather), not either a "strategy body" isolated from the community making the decision or a conventional RFP on which the LLC has ultimate decision authority. And, while I could figure out a way to adjust language a bit, I fear that doing so would just paper over those issues (some of which I'm probably an outlier about) and leave us with very different expectations and assumptions about what the words = mean. best, john From nobody Mon Nov 9 09:33:55 2020 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 989FB3A127A; Mon, 9 Nov 2020 09:33:53 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, 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 (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 7qh1-RKT7GR2; Mon, 9 Nov 2020 09:33:52 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778033A09D9; Mon, 9 Nov 2020 09:33:52 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 0A9HTuXr001525; Mon, 9 Nov 2020 17:33:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=2qdP80bYfcBpF8JnhsMilv7/jCu/KAxDJUjlCtEz/Os=; b=lw4EJxYubgUhFHl8Y0fWLCNaJ1yjl6NdK/vtS4Lk2pyLk9JpLmHNeSUXkIXnAwU0nSCT yebNgrbOYwlSN1QYkvW25om55T9aR70VFy5EE0J9DKMQwEjEgY6s9zKahzQMFi8UMA4f C1VlOi+fEArOml/YV6gB4r6ItWlOHq3kp36JQzPtCk6KXtsBWgoTD6HBKqulyrOBCcA+ iTUXv1nf5AQwIe8ExIWSssHUGFsj8WutLH4EIq38yoZzWmfHo2eoSQYAD7zLGxiTN+2o pCZE0em9CJEtrC8FILkP6kxrurZcWIP9e/6Ou3VjQ7Ie+2Q4CrHbVSwt9FCz+n2k7m7e FQ== Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 34p0axv0j3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 Nov 2020 17:33:52 +0000 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0A9HOqbw000308; Mon, 9 Nov 2020 12:33:51 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint8.akamai.com with ESMTP id 34nqt25ncg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 09 Nov 2020 12:33:51 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Nov 2020 12:33:49 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1497.007; Mon, 9 Nov 2020 12:33:50 -0500 From: "Salz, Rich" To: Eliot Lear , "Joel M. Halpern" CC: "rfced-future@iab.org" Thread-Topic: [Rfced-future] Continuing on Issue 12: Is there an Executive Editor or an Advisor? Thread-Index: AQHWtodAUcfm24kvH0CWOOEC563ofqnAQH+AgAAS7ID//7x9gA== Date: Mon, 9 Nov 2020 17:33:49 +0000 Message-ID: <273B0831-ABED-43C7-B0C4-C7E36B68B6AE@akamai.com> References: <948AEA96-BF3F-4159-8666-5268D27B726B@cisco.com> <173fafb6-bd51-ce1a-73f1-d01c1f874471@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110105 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-09_10:2020-11-05, 2020-11-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 mlxlogscore=999 spamscore=0 bulkscore=0 malwarescore=0 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011090119 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-09_10:2020-11-05, 2020-11-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0 spamscore=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 suspectscore=0 impostorscore=0 phishscore=0 malwarescore=0 clxscore=1011 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011090120 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.34) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint8 Archived-At: Subject: Re: [Rfced-future] Continuing on Issue 12: Is there an Executive Editor or an Advisor? 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, 09 Nov 2020 17:33:54 -0000 UGVyaGFwcyBzb21ldGhpbmcgbGlrZSBhIG5ldyBzZW50ZW5jZTogVGhlIGV4cGVydCBzaG91bGQg YWxzbyBicmluZyB1cCBuZXcgaXNzdWVzIHRoYXQgdGhlIFJQQyBoYXNuJ3QgY29uc2lkZXJlZCwg ZXZlbiBpZiB0aGUgc29sdXRpb25zIGFyZW4ndCB5ZXQga25vd24uDQogDQoNCg== From nobody Mon Nov 9 13:20:49 2020 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 769513A140C for ; Mon, 9 Nov 2020 13:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZ6rL5mxzSAr for ; Mon, 9 Nov 2020 13:20:46 -0800 (PST) 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 146163A140B for ; Mon, 9 Nov 2020 13:20:46 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id c20so9364035pfr.8 for ; Mon, 09 Nov 2020 13:20:46 -0800 (PST) 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=gmcVkrIgFbUaIiWwZrzPQ4Iy71DbWEgto0vMPGPY9/s=; b=rRY+tCg87t3Whh7y7yhd0GvaDzunaaAjPtqRWk7VKQdCHjcIyvJksGMQe0ijGbfxzV BbjOuZDdNuznQsjCT48WNUbwGs/As6DuFjIGaqoerfukKZGXCLC+LIOb1wE2WpJyDNby Crk1IAKL3qQQTrGBXomx+JubJj/SYfiW6oPFPdnNU972pltFTyD/FYz21zmYElVDlLcP zqwPj/jr4/ZhkE0PIc3P+WARvw9RJ5Elv8aTWI5LEpGmGPsCDh0/pbIap7i9agwrNp/j SbB63t/EcaxPQbwDwn1DvmOK6/zq1y0BCqZWuuG+cFqP6ESpaLuhQlxVhw/yxzmB9zww zlVQ== 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=gmcVkrIgFbUaIiWwZrzPQ4Iy71DbWEgto0vMPGPY9/s=; b=T9HXXKSjvKYYZcXrxoPhUyXwn8iGu7gA16cgdffS1jE4d2bxKBeWym4gsn+V7PXzvk tPOWsHoILPJOCic18I90EFZHvaWbt2ORgSvxNfALe3ihhlmExS6+0NYUx0iEkkJU46/2 jpG9lxtLX4m9KR/r6oicXOgyF7uoJmijB5vy1++yc4MB7iZj+JnuePQl+2NSNQok7Bfb gYxr9CKsHK9C4n870m1pqJtBdrPEe6FfIx01fxEcmDjqK6F/33un3xGR8zicidg70lWk pSHhZZ1TMHDMb1Ygi+fex2ens3FP5m9qoAf2s4pGhp6AMsHe6AcCE6gDU6i4cuuJJ+eI p4+A== X-Gm-Message-State: AOAM532JgTNGesTkN8SdlQza2oc52RexRCfY6cVuh/uNGgB180UuMFL6 yhJUpogVhsAWN3GWxhZ/BhijCRzxAuKfuQ== X-Google-Smtp-Source: ABdhPJxBuHpHtjAncyNXTTXEJjf5PhC+g0vyAHw4ywNNUnezB3vp2ZqB0LUGmvQUcpzJuZWYtHyKFA== X-Received: by 2002:a63:b24e:: with SMTP id t14mr13999503pgo.224.1604956843994; Mon, 09 Nov 2020 13:20:43 -0800 (PST) Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id w131sm11904397pfd.14.2020.11.09.13.20.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Nov 2020 13:20:42 -0800 (PST) To: Eliot Lear , rfced-future@iab.org References: <948AEA96-BF3F-4159-8666-5268D27B726B@cisco.com> From: Brian E Carpenter Message-ID: <1bcc02c7-d19c-c550-dfb2-0a5829e2a527@gmail.com> Date: Tue, 10 Nov 2020 10:20:38 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <948AEA96-BF3F-4159-8666-5268D27B726B@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Continuing on Issue 12: Is there an Executive Editor or an Advisor? 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, 09 Nov 2020 21:20:47 -0000 > the expert provides guidance when asked by the RPC within the existing = framework. If the existing framework is found to be wanting, the advisor= might point this out to strategy body. It is then up to them to resolve= through whatever processes they have. They might seek guidance from the= advisor to resolve issues. One of the reasons I used the (apparently obnoxious) term "thought leader= " is because IMHO we need the advisor to have an active, not a reactive, = role in bringing issues to the community and the strategy body, as a resu= lt of his/her own experience and expertise. I think it needs more than one paragraph. To be precise, here's a slightl= y amended version of section 8 of my draft: # Role of the RFC Series Advisor This person will be a senior professional with deep knowledge of technica= l publishing. The RSA will operate by providing expert advice to the RSAWG, and if requ= ested to the RPC, on any relevant matters. For example, the RSA might be = consulted about proposed changes to the style guide, RFC formatting in ge= neral, web presence, copyright matters, or archiving policy. The RSA is expected to attend and facilitate all RSAWG meetings, and to p= articipate in and facilitate RSAWG on-line discussions. Further, the RSA is expected to ensure that RSAWG consensus is well docum= ented and communicated to the community, the LLC, and the REP. This may i= nclude document authorship. The RSA is expected to be active in proposing improvements to the RFC Ser= ies, in developing vision and policy documents, and in establishing commu= nity consensus for them. Regards Brian On 09-Nov-20 23:57, Eliot Lear wrote: > Thank you to those who have commented on this issue. >=20 > What was proposed: >=20 >=20 > One possible resolution is that the expert exercises moral authority =E2= =80=93 as experts do =E2=80=93 and provides guidance when asked by the RP= C within the existing framework. =C2=A0If the existing framework is found= to be wanting, the advisor might point this out to strategy body. =C2=A0= It is then up to them to resolve through whatever processes they have. =C2= =A0They might seek guidance from the advisor to resolve issues. >=20 > There was quite a bit of objection to the term =E2=80=9Cmoral authority= =E2=80=9D. >=20 > To remedy this, we can do something along these lines, recognizing that= a bit of wordsmithing will still be necessary if this hits a draft: >=20 >> One possible resolution is that the expert provides guidance when aske= d by the RPC within the existing framework. =C2=A0If the existing framewo= rk is found to be wanting, the advisor might point this out to strategy b= ody. =C2=A0It is then up to them to resolve through whatever processes th= ey have. =C2=A0They might seek guidance from the advisor to resolve issue= s. >=20 > This leaves several stated concerns open. =C2=A0As I see it, it takes t= hree forms: >=20 > * Could we write a job description for the role such that it could be= filled? > * What is the title of the individual? > * What is the contract period / how is this person treated? >=20 >=20 > Another way to look at this would be to view this person as a senior me= mber of the RPC - with a slightly different function. =C2=A0In that case,= Martin=E2=80=99s text fits quite neatly: >=20 >> I think that I proposed something slightly different: we let the RPC p= roceed with a decision grounded in their own best judgment (which I would= hope, but not insist, would involve some attempt at consultation). =C2=A0= Then we live with the consequences of mistakes if the eventual community = position differs when consensus is reached. >=20 > That would simply leave open how this person takes on strategic work. =C2= =A0On their own initiative? =C2=A0At the behest of the community? =C2=A0B= oth? =C2=A0Should I hope an issue on this? =C2=A0Maybe we can start discu= ssion here though? >=20 > Eliot >=20 >=20 From nobody Mon Nov 9 14:46:51 2020 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 942073A14B3 for ; Mon, 9 Nov 2020 14:46:49 -0800 (PST) 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 DoWVHuWCxjmH for ; Mon, 9 Nov 2020 14:46:48 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09043A133D for ; Mon, 9 Nov 2020 14:46:47 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kcFvx-0000pX-7o; Mon, 09 Nov 2020 17:46:45 -0500 Date: Mon, 09 Nov 2020 17:46:39 -0500 From: John C Klensin To: Brian E Carpenter cc: Eliot Lear , rfced-future@iab.org Message-ID: In-Reply-To: <1bcc02c7-d19c-c550-dfb2-0a5829e2a527@gmail.com> References: <948AEA96-BF3F-4159-8666-5268D27B726B@cisco.com> <1bcc02c7-d19c-c550-dfb2-0a5829e2a527@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] Continuing on Issue 12: Is there an Executive Editor or an Advisor? 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, 09 Nov 2020 22:46:50 -0000 --On Tuesday, November 10, 2020 10:20 +1300 Brian E Carpenter wrote: >> the expert provides guidance when asked by the RPC within the >> existing framework. If the existing framework is found to be >> wanting, the advisor might point this out to strategy body. >> It is then up to them to resolve through whatever processes >> they have. They might seek guidance from the advisor to >> resolve issues. > > One of the reasons I used the (apparently obnoxious) term > "thought leader" is because IMHO we need the advisor to have > an active, not a reactive, role in bringing issues to the > community and the strategy body, as a result of his/her own > experience and expertise. > > I think it needs more than one paragraph. To be precise, > here's a slightly amended version of section 8 of my draft: > ># Role of the RFC Series Advisor > > This person will be a senior professional with deep knowledge > of technical publishing. > > The RSA will operate by providing expert advice to the RSAWG, > and if requested to the RPC, on any relevant matters. For > example, the RSA might be consulted about proposed changes to > the style guide, RFC formatting in general, web presence, > copyright matters, or archiving policy. > > The RSA is expected to attend and facilitate all RSAWG > meetings, and to participate in and facilitate RSAWG on-line > discussions. > > Further, the RSA is expected to ensure that RSAWG consensus is > well documented and communicated to the community, the LLC, > and the REP. This may include document authorship. > > The RSA is expected to be active in proposing improvements to > the RFC Series, in developing vision and policy documents, and > in establishing community consensus for them. Brian, This appears to be much closer to what I'm looking for (I still have problems with "advisor" and believe it will cause us recruiting difficulties). I think, however, that what you are describing above makes the RSA a sort of Executive Director (at least in the old sense in which, e.g., Bob Braden served the IAB for many years) for the RSAWG. Adjusting terminology (and maybe the name of the RSAWG) to reflect that might considerably mitigate the recruiting problem I anticipate with "advisor". john From nobody Tue Nov 10 03:36:33 2020 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 A7C553A0995 for ; Tue, 10 Nov 2020 03:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 1tT7pOSvvKvA for ; Tue, 10 Nov 2020 03:36:25 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB4F3A08AE for ; Tue, 10 Nov 2020 03:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1079; q=dns/txt; s=iport; t=1605008181; x=1606217781; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=neTEng1eIL6jrMlsFnTS/aZJst9JZKhYlSc4t3/PWiA=; b=VZ2Zz459lOOKrCPG0YEBELg5qzMil77rMGUgHyVnjDY3XsEGUZkVgJgj jfrGNVIFxU2cpBncG2axANwVGWxKEKecHHht1vMVwZCDoL/JtaWQ0TniT bjJaW2H5GwYRRzD7ctdnf3OuLrrTpykcjObwKdqYtgDLGJArfuBsxuYSo 0=; X-IPAS-Result: =?us-ascii?q?A0AZBAAoeqpf/xbLJq1iHQEBAQEJARIBBQUBQIFPg3MBI?= =?us-ascii?q?BKEa4kFomCBaAsBAQENAQEvBAEBhEoCghMmOBMCAwEBAQMCAwEBAQEFAQEBA?= =?us-ascii?q?gEGBHGFbYVzBiNIDhALGgImAgJXBieDEoMHrQ12gTKFV4R3gQ4qjVqCAIE4H?= =?us-ascii?q?IJPPoQBPYMXM4IsBJBepj+BDIJ3gxqXdgMfkk+PJbA4g2ICBAYFAhWBayOBV?= =?us-ascii?q?zMaCBsVZQGCPz0SGQ2OVo4TQANoAgYBCQEBAwmOSAEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,466,1596499200"; d="scan'208";a="31005036" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Nov 2020 11:36:19 +0000 Received: from [10.61.165.142] ([10.61.165.142]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AABaHdU010958 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 Nov 2020 11:36:18 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Eliot Lear In-Reply-To: <1bcc02c7-d19c-c550-dfb2-0a5829e2a527@gmail.com> Date: Tue, 10 Nov 2020 12:36:17 +0100 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <8EE1E021-8DAD-421F-80CB-27CFC8078206@cisco.com> References: <948AEA96-BF3F-4159-8666-5268D27B726B@cisco.com> <1bcc02c7-d19c-c550-dfb2-0a5829e2a527@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.165.142, [10.61.165.142] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Continuing on Issue 12: Is there an Executive Editor or an Advisor? 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, 10 Nov 2020 11:36:33 -0000 Ok. So maybe the thing to do is to use Brian=E2=80=99s text below as = the basis for discussion next week? Eliot >=20 > # Role of the RFC Series Advisor >=20 > This person will be a senior professional with deep knowledge of = technical publishing. >=20 > The RSA will operate by providing expert advice to the RSAWG, and if = requested to the RPC, on any relevant matters. For example, the RSA = might be consulted about proposed changes to the style guide, RFC = formatting in general, web presence, copyright matters, or archiving = policy. >=20 > The RSA is expected to attend and facilitate all RSAWG meetings, and = to participate in and facilitate RSAWG on-line discussions. >=20 > Further, the RSA is expected to ensure that RSAWG consensus is well = documented and communicated to the community, the LLC, and the REP. This = may include document authorship. >=20 > The RSA is expected to be active in proposing improvements to the RFC = Series, in developing vision and policy documents, and in establishing = community consensus for them. From nobody Tue Nov 10 03:46:01 2020 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 F0DFA3A0937 for ; Tue, 10 Nov 2020 03:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 D27Ie5paZNj9 for ; Tue, 10 Nov 2020 03:45:58 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6A43A095F for ; Tue, 10 Nov 2020 03:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7189; q=dns/txt; s=iport; t=1605008758; x=1606218358; h=from:mime-version:subject:message-id:date:to; bh=7BxnA2np72ckZw8uN0y2LzrIShw2Gk7WYuqh4e/i7XE=; b=I6tM+9oYdQ9UnIHzgyrJ6j/nHdnvC+G5vQVxiBEnVch6gORf1jfn6Zf/ LGqlI2NVntK+WNnoKk0j2zPWiJz3ZsdQTlL0czIzJ77hNOJBu/FUXZEtN w9HhQmGA4RDhlRxsaeZ5vDMDFTXPVDBbTtLu1vw0zYCqutSRgHfHIdleN U=; X-IPAS-Result: =?us-ascii?q?A0BlBAAafKpf/xbLJq1iHgEBCxIMggQLg3MBIBKEa4kFh?= =?us-ascii?q?3WUOYYxgWgLAQEBDQEBLwQBAYZfJjcGDgIDAQEBAwIDAQEBAQUBAQECAQYEc?= =?us-ascii?q?YVthhyBHhUCgQaDEoMHnnOOGXaBMoVXhHWBOI1aggCBEScMEIIhbIN3EXWCW?= =?us-ascii?q?DOCLASQFiEKp2iCd4MakXOGAwMWCYMYOYlchSKPJbA4g2ICBAYFAhWBaiSBV?= =?us-ascii?q?zMaCBsVZQGCPz0SGQ2caUADaAIGAQkBAQMJjkgBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos; i="5.77,466,1596499200"; d="scan'208,217"; a="31007514" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Nov 2020 11:45:56 +0000 Received: from [10.61.165.142] ([10.61.165.142]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AABjtVO003411 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 10 Nov 2020 11:45:55 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_5B34D975-EE9D-45C1-BFE8-7ADCE2894DA7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Tue, 10 Nov 2020 12:45:54 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.165.142, [10.61.165.142] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Rfced-future] Issue 13: Is decision making in the strategy body is open to all? 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, 10 Nov 2020 11:46:00 -0000 --Apple-Mail=_5B34D975-EE9D-45C1-BFE8-7ADCE2894DA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The chairs would like to tackle Issue 13. This issue looks at whether = there is something like an RSEB or whether there is a more WG-like open = decision process. It is a big issue and will surely require lots of = discussion. And so we would welcome two forms of discussion. The first = is sort of meta: recognizing the differences here, if people have = suggestions on how to bridge gaps, we=E2=80=99re happy to hear them. = The second is the logic and substance of the issue. I believe, and please correct me if I am wrong, that there is no = disagreement about having public access to meetings, perhaps with the = exception of personnel discussions in the case of the RSEB. Backing up = to non-strategic decisions that relate to Issue 12, I believe, unless I = am again mistaken, that there is something close to common ground about = how day to day decisions are handled. In the advisory model, these = would fall largely to the RPC, but if the advisor is viewed as a senior = member of the RPC, then this approximates how the RSE would operate = under the RSEB model. The only question at issue here is who gets to take part in the decision = process. Tell us if this summarizes the arguments on both sides: On the one hand, the argument goes that the community should drive = change, and the best approximation we have as a community is an open = process in which all are invited to participate. The value of this is = that change happens only when there is rough consensus, and nobody can = claim surprise (assuming we adhere to usual WG practices like LCs, rough = consensus, etc). The argument against would be analysis paralysis = within the WG when change needs to happen, and potentially decision = making by those who really don=E2=80=99t have a grasp of the issues. In = this model, primarily the RPC process is governed and the RSE/RSA offers = advice to the RPC and to the WG. On the other hand, in the RSEB model, only those serving members take = part in decision making relating to strategy that is output in a new = track, presumably after notice and taking into account of community = views. The benefit of this model is that one can avoid analysis = paralysis due to lack of WG consensus (still possible that a closed = committee could be split), can take on people for some length of service = whose responsibility is to keep the ship afloat and can be held = accountable in some way, and each of the streams in particular receives = a bit more weight in terms of their particular needs. The negative = aspect is that accountability is diluted through various selection = processes (some will find this negative a positive). Maybe the right approach to have this discussion is for each of us to = think in terms of benefits and drawbacks of each of these models. Also, = if there is a negative that is listed, can it be remedied in some way = without jumping to the other approach? We are looking for guidance from you as to how to proceed.= --Apple-Mail=_5B34D975-EE9D-45C1-BFE8-7ADCE2894DA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    The chairs would like to tackle Issue 13.  This issue = looks at whether there is something like an RSEB or whether there is a = more WG-like open decision process.  It is a big issue and will = surely require lots of discussion.  And so we would welcome two = forms of discussion.  The first is sort of meta: recognizing the = differences here, if people have suggestions on how to bridge gaps, = we=E2=80=99re happy to hear them.  The second is the logic and = substance of the issue.

    I believe, and please correct me if I am wrong, that there is = no disagreement about having public access to meetings, perhaps with the = exception of personnel discussions in the case of the RSEB. =  Backing up to non-strategic decisions that relate to Issue 12, I = believe, unless I am again mistaken, that there is something close to common ground about how day to day = decisions are handled.  In the advisory model, these would fall = largely to the RPC, but if the advisor is viewed as a senior member of = the RPC, then this approximates how the RSE would operate under the RSEB = model.

    The = only question at issue here is who gets to take part in the decision = process.

    Tell = us if this summarizes the arguments on both sides:

    • On the one hand, the argument goes = that the community should drive change, and the best approximation we = have as a community is an open process in which all are invited to = participate.  The value of this is that change happens only when = there is rough consensus, and nobody can claim surprise (assuming we = adhere to usual WG practices like LCs, rough consensus, etc).  The = argument against would be analysis paralysis within the WG when change = needs to happen, and potentially decision making by those who really = don=E2=80=99t have a grasp of the issues.  In this model, primarily = the RPC process is governed and the RSE/RSA offers advice to the RPC and = to the WG.
    • On the other hand, in the RSEB model, only = those serving members take part in decision making relating to strategy = that is output in a new track, presumably after notice and taking into = account of community views.  The benefit of this model is that one = can avoid analysis paralysis due to lack of WG consensus (still possible = that a closed committee could be split), can take on people for some = length of service whose responsibility is to keep the ship afloat and = can be held accountable in some way, and each of the streams in = particular receives a bit more weight in terms of their particular = needs.  The negative aspect is that accountability is diluted = through various selection processes (some will find this negative a = positive).

    Maybe the right approach to have this discussion is for each = of us to think in terms of benefits and drawbacks of each of these = models.  Also, if there is a negative that is listed, can it be = remedied in some way without jumping to the other approach?

    We are looking for = guidance from you as to how to proceed.
    = --Apple-Mail=_5B34D975-EE9D-45C1-BFE8-7ADCE2894DA7-- From nobody Tue Nov 10 10:07:30 2020 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 678CA3A0E0F for ; Tue, 10 Nov 2020 10:07:28 -0800 (PST) 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 ogoaaRRYqEgb for ; Tue, 10 Nov 2020 10:07:26 -0800 (PST) Received: from aws.hosed.org (aws.hosed.org [50.16.104.137]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 461E13A1104 for ; Tue, 10 Nov 2020 10:06:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by aws.hosed.org (Postfix) with ESMTP id 01C4CE02E6; Tue, 10 Nov 2020 13:06:48 -0500 (EST) Received: from aws.hosed.org ([127.0.0.1]) by localhost (aws.hosed.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrRAhPUhBIte; Tue, 10 Nov 2020 13:06:47 -0500 (EST) Received: from [172.16.12.105] (c-73-71-250-98.hsd1.ca.comcast.net [73.71.250.98]) by aws.hosed.org (Postfix) with ESMTPSA id 7BA92E02E5; Tue, 10 Nov 2020 13:06:47 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Sarah Banks In-Reply-To: <8EE1E021-8DAD-421F-80CB-27CFC8078206@cisco.com> Date: Tue, 10 Nov 2020 10:06:46 -0800 Cc: Brian E Carpenter , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <9F97293E-039F-4354-9D16-7F13F0053308@encrypted.net> References: <948AEA96-BF3F-4159-8666-5268D27B726B@cisco.com> <1bcc02c7-d19c-c550-dfb2-0a5829e2a527@gmail.com> <8EE1E021-8DAD-421F-80CB-27CFC8078206@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Rfced-future] Continuing on Issue 12: Is there an Executive Editor or an Advisor? 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, 10 Nov 2020 18:07:28 -0000 Hi, To "yes, and" to what Joel wrote, I'm deeply concerned with the role = as written. On one hand, we want someone with senior-level skill and = experience. On the other, we want them to be a secretary (documenting = consensus and communication to the community). As an advisor, they're = empowered with ... what, exactly? What I'm getting at is - I think we're = going to have a very, very difficult path to hiring someone with this as = the job description. Heather DID bring issues we didn't expect to the = RSOC, and seemed to relish in resolving them. An advisor wouldn't be = doing that. So what are they getting out of this? Separate but somewhat related, I'd share the feedback that with the = current model, in the RSOC, and even through discussions with Heather, = the costs, level of staffing and level of efforts required to move = documents through the process was a topic of conversation. I am all for = community consensus, but I'd urge folks to think through, as we consider = different resolutions to the documented Issues, that we don't have a = track record as a community of considering the amount of effort proposed = changes take, or the amount of money that translates to. I'm not = suggesting we do tackle those issues, but I am suggesting that a model = that puts community consensus squarely in the middle would be presented = with that challenge, since there IS a contract involved (despite who = negotiates, signs, and administers it), and the costs associated with an = SLA are real. Thanks, Sarah > On Nov 10, 2020, at 3:36 AM, Eliot Lear = wrote: >=20 > Ok. So maybe the thing to do is to use Brian=E2=80=99s text below as = the basis for discussion next week? >=20 > Eliot >=20 >>=20 >> # Role of the RFC Series Advisor >>=20 >> This person will be a senior professional with deep knowledge of = technical publishing. >>=20 >> The RSA will operate by providing expert advice to the RSAWG, and if = requested to the RPC, on any relevant matters. For example, the RSA = might be consulted about proposed changes to the style guide, RFC = formatting in general, web presence, copyright matters, or archiving = policy. >>=20 >> The RSA is expected to attend and facilitate all RSAWG meetings, and = to participate in and facilitate RSAWG on-line discussions. >>=20 >> Further, the RSA is expected to ensure that RSAWG consensus is well = documented and communicated to the community, the LLC, and the REP. This = may include document authorship. >>=20 >> The RSA is expected to be active in proposing improvements to the RFC = Series, in developing vision and policy documents, and in establishing = community consensus for them. >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Thu Nov 12 00:44:38 2020 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 7D7833A11E8 for ; Thu, 12 Nov 2020 00:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.601 X-Spam-Level: X-Spam-Status: No, score=-8.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_AFFORDABLE=1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 IGMqnZ3U-BXP for ; Thu, 12 Nov 2020 00:44:33 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138983A11C5 for ; Thu, 12 Nov 2020 00:44:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3237; q=dns/txt; s=iport; t=1605170673; x=1606380273; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=iTeYQELhs9Kbjo4mH0uOkea3HuxHn38G8iAdqqG77dI=; b=X5mF+REAcJ5qMu6nU4qq8QBRzYDs+F1+hFENeQ/j+mco2PuazTARKd6F j3dGBaTJMY86bFytLGtn1tuB8iO/qBThG0H2hUIUj6qglcwRRxJIPTOqA ukNVdyMJtew9H7N8SNpuAwqO8wtYBh5BwM+uA8dkOS0095/gphwQtGpZt o=; X-IPAS-Result: =?us-ascii?q?A0BfAQD69Kxf/xbLJq1iGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBTwKDcQEyLoQ9iQWIHZpFgWgLAQEBDQEBLwQBAYRKAoIZJjkFDQIDA?= =?us-ascii?q?QEBAwIDAQEBAQUBAQECAQYEcYVthXIBAQEDASNEEgULCw4KAgImAgJXBhMUg?= =?us-ascii?q?xKCZyCvcnaBMoVXhHmBDiqLfIEmOIIAgREnHIJPPoQAPoMXM4IsBIt0rDeCd?= =?us-ascii?q?4MajFiFH4YDAx+hd7A9g2MCBAYFAhWBbCKBVzMaCBsVGksBgj4+EhkNjisXF?= =?us-ascii?q?I4TQAMwOAIGAQkBAQMJjWhgAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,471,1596499200"; d="scan'208";a="31056428" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Nov 2020 08:44:28 +0000 Received: from ams3-vpn-dhcp924.cisco.com (ams3-vpn-dhcp924.cisco.com [10.61.67.156]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AC8iSTN006586 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 Nov 2020 08:44:28 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Eliot Lear In-Reply-To: <9F97293E-039F-4354-9D16-7F13F0053308@encrypted.net> Date: Thu, 12 Nov 2020 09:44:25 +0100 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <8FF95578-EE6D-4FED-A1B9-FEB558257221@cisco.com> References: <948AEA96-BF3F-4159-8666-5268D27B726B@cisco.com> <1bcc02c7-d19c-c550-dfb2-0a5829e2a527@gmail.com> <8EE1E021-8DAD-421F-80CB-27CFC8078206@cisco.com> <9F97293E-039F-4354-9D16-7F13F0053308@encrypted.net> To: Sarah Banks X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.67.156, ams3-vpn-dhcp924.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Rfced-future] Continuing on Issue 12: Is there an Executive Editor or an Advisor? 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, 12 Nov 2020 08:44:37 -0000 Sarah, thank you for engaging on this point. I have a request: > On 10 Nov 2020, at 19:06, Sarah Banks wrote: >=20 > Hi, > To "yes, and" to what Joel wrote, I'm deeply concerned with the = role as written. Could you (or others) perhaps take Brian=E2=80=99s words, make changes = you think are appropriate, and attempt to come up with a role that you = believe (a) accurately reflects what you believe the IETF needs and (b) = is someone you believe we could find? It=E2=80=99s a very tall order = but that=E2=80=99s why we pay you those big bucks ;-). Seriously, it = will help us move the ball forward to have more alternatives out there. = You can even start with the title. > On one hand, we want someone with senior-level skill and experience. = On the other, we want them to be a secretary (documenting consensus and = communication to the community). As an advisor, they're empowered with = ... what, exactly? What I'm getting at is - I think we're going to have = a very, very difficult path to hiring someone with this as the job = description. Heather DID bring issues we didn't expect to the RSOC, and = seemed to relish in resolving them. An advisor wouldn't be doing that. = So what are they getting out of this? Why do we think that an advisor couldn=E2=80=99t do that? My accountant = brings issues to my attention all the time. I would fire him if he = didn=E2=80=99t. We had a lovely conversation about crypto currencies = this time around. > Separate but somewhat related, I'd share the feedback that with the = current model, in the RSOC, and even through discussions with Heather, = the costs, level of staffing and level of efforts required to move = documents through the process was a topic of conversation. I am all for = community consensus, but I'd urge folks to think through, as we consider = different resolutions to the documented Issues, that we don't have a = track record as a community of considering the amount of effort proposed = changes take, or the amount of money that translates to. I'm not = suggesting we do tackle those issues, but I am suggesting that a model = that puts community consensus squarely in the middle would be presented = with that challenge, since there IS a contract involved (despite who = negotiates, signs, and administers it), and the costs associated with an = SLA are real. Yes. Someone comes up with a proposed idea they would like to see = carried out, it is then somehow costed out by someone else, and someone = has to say, =E2=80=9Cthis is affordable=E2=80=9D or =E2=80=9Cthis is = not=E2=80=9D, and someone has to say, =E2=80=9Cgo=E2=80=9D. I think the = model we are aiming at is that the strategic body develops some initial = idea, perhaps with the RS[EA], Jay or someone in the RPC costs it out, = perhaps in consultation with the RS[EA], the LLC provides their initial = views, the strategic body says, =E2=80=9Cgo=E2=80=9D and then the LLC = has to decide to fund or not fund. That all needs to be documented out, right? Are there words you like in = one of the drafts that comes close to this or would you (or anyone else) = like to write some? Eliot From nobody Thu Nov 12 12:08:14 2020 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 7A4733A03FB for ; Thu, 12 Nov 2020 12:08:12 -0800 (PST) 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=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 2ETTmA7q_TwM for ; Thu, 12 Nov 2020 12:08:10 -0800 (PST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 E18633A0400 for ; Thu, 12 Nov 2020 12:08:10 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id i26so5141666pgl.5 for ; Thu, 12 Nov 2020 12:08:10 -0800 (PST) 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=EkS0TMC/YUutPSa4oWFvEmSmI1vGXuz+nywzxrLTVTg=; b=BBJzWNz1RVWqtA4Egz4MnHYV/cClsByqP8nMI834yPkz2X7LsC8BAKCzi10646SkrG JIbCxiVgWDIK0S5WGwtEYmldShALoHYygvZJq5EUJMVtDAXstbnA2bpQfFjZGb+AKz8i /wnZDMg7Nc9XTzyNHDsW2KXkUgvxsDQSNhSriXLpWHdr7+1/SceC2yraOkePjekyu2qU w+/RDk5DAEgwcE0fsYjuFaEP6PD+nUVV1bHu442ke5/bm9mvk97LsvaeOESZ8MQCWuLe fW/6UWQknHXvYf+ajfVijL99FWWTHpqzV8GKF1sJ5/f5Hdgu3aUXYBZ+gh/zsZT9HAwa X+XQ== 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=EkS0TMC/YUutPSa4oWFvEmSmI1vGXuz+nywzxrLTVTg=; b=WPw0mIj5hYIvOT5kQGo1WGVNFUTflwQRqFtk0/LwvboCx78yMGqmHHeFuRO+2Z/QVZ ZnFBaWCdccdWVyIXDQIHAVAlh8cPOkUluaH3FdVWvBZqhVsdM1PCUR1/NkaYc16vjAB/ 09y6oXduENd78K2xGGAtZmG5dsci/v6MqoMSwyr5jzRBT2x++8UQzdQ0DcJo/uxMd3R9 hbl91l/YIZqnScjzoUEzIS5jMSsArdF8SGyxysMrF8G5gWEFRZgdJmRWgyYvdl1iiHoL mBS+swI/7auuypKOmCrx8lMxhes6V9oJ9NFVQFGXbpJ195m7XX/O93WuWwN3fEAlrCmF pxuA== X-Gm-Message-State: AOAM530M0DUzQhAp3JQKh4+mcURFpTBwZ7K9FCfHAK3Cikz19FQAEAID jidlS8gETSmGHTvb1cDpBGY3bk+M2ZQ2OQ== X-Google-Smtp-Source: ABdhPJxSM1Dl2Ahq8lvbvrhG9bg/KXDVVZesNVtTU4NJDodUfla6UUkYY2m0ziPNrEwksTCjrXAQhw== X-Received: by 2002:a62:7656:0:b029:18b:c0f:1b7a with SMTP id r83-20020a6276560000b029018b0c0f1b7amr1050716pfc.80.1605211689834; Thu, 12 Nov 2020 12:08:09 -0800 (PST) Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id a8sm6203215pfa.132.2020.11.12.12.08.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Nov 2020 12:08:08 -0800 (PST) To: Sarah Banks , Eliot Lear Cc: rfced-future@iab.org References: <948AEA96-BF3F-4159-8666-5268D27B726B@cisco.com> <1bcc02c7-d19c-c550-dfb2-0a5829e2a527@gmail.com> <8EE1E021-8DAD-421F-80CB-27CFC8078206@cisco.com> <9F97293E-039F-4354-9D16-7F13F0053308@encrypted.net> From: Brian E Carpenter Message-ID: Date: Fri, 13 Nov 2020 09:08:04 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <9F97293E-039F-4354-9D16-7F13F0053308@encrypted.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Continuing on Issue 12: Is there an Executive Editor or an Advisor? 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, 12 Nov 2020 20:08:13 -0000 Sarah, Sometimes terminology is everything. I take your point, and the point of = Eliot challenging you to rewrite the job description. If there was consen= sus to call the revised role "Series Editor" I'd be fine with that too. B= ut if the role isn't line management of the RPC, which seems to be the pr= ovince of the LLC, and isn't content management, which seems to be the pr= ovince of the stream managers, it's inevitably a role where facilitation,= wise advice, and coordination are the daily grind. (What Eugenia Cheng c= alls a "congressive" role in her book x+y.) Regards Brian On 11-Nov-20 07:06, Sarah Banks wrote: > Hi, > To "yes, and" to what Joel wrote, I'm deeply concerned with the rol= e as written. On one hand, we want someone with senior-level skill and ex= perience. On the other, we want them to be a secretary (documenting conse= nsus and communication to the community). As an advisor, they're empowere= d with ... what, exactly? What I'm getting at is - I think we're going to= have a very, very difficult path to hiring someone with this as the job = description. Heather DID bring issues we didn't expect to the RSOC, and s= eemed to relish in resolving them. An advisor wouldn't be doing that. So = what are they getting out of this? > Separate but somewhat related, I'd share the feedback that with the= current model, in the RSOC, and even through discussions with Heather, t= he costs, level of staffing and level of efforts required to move documen= ts through the process was a topic of conversation. I am all for communit= y consensus, but I'd urge folks to think through, as we consider differen= t resolutions to the documented Issues, that we don't have a track record= as a community of considering the amount of effort proposed changes take= , or the amount of money that translates to. I'm not suggesting we do tac= kle those issues, but I am suggesting that a model that puts community co= nsensus squarely in the middle would be presented with that challenge, si= nce there IS a contract involved (despite who negotiates, signs, and admi= nisters it), and the costs associated with an SLA are real. >=20 > Thanks, > Sarah >=20 >=20 >> On Nov 10, 2020, at 3:36 AM, Eliot Lear wrote: >> >> Ok. So maybe the thing to do is to use Brian=E2=80=99s text below as = the basis for discussion next week? >> >> Eliot >> >>> >>> # Role of the RFC Series Advisor >>> >>> This person will be a senior professional with deep knowledge of tech= nical publishing. >>> >>> The RSA will operate by providing expert advice to the RSAWG, and if = requested to the RPC, on any relevant matters. For example, the RSA might= be consulted about proposed changes to the style guide, RFC formatting i= n general, web presence, copyright matters, or archiving policy. >>> >>> The RSA is expected to attend and facilitate all RSAWG meetings, and = to participate in and facilitate RSAWG on-line discussions. >>> >>> Further, the RSA is expected to ensure that RSAWG consensus is well d= ocumented and communicated to the community, the LLC, and the REP. This m= ay include document authorship. >>> >>> The RSA is expected to be active in proposing improvements to the RFC= Series, in developing vision and policy documents, and in establishing c= ommunity consensus for them. >> >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 >=20 From nobody Fri Nov 13 09:11:24 2020 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 10BFC3A0F74 for ; Fri, 13 Nov 2020 09:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 rPW6A7sZglEW for ; Fri, 13 Nov 2020 09:11:21 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CCC73A0F5E for ; Fri, 13 Nov 2020 09:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3677; q=dns/txt; s=iport; t=1605287481; x=1606497081; h=from:mime-version:subject:message-id:date:to; bh=VuhbLFL42vOiQZ9ORDKCwI9seV84CB0I4KYWeKMn2No=; b=gFgZxOpLnrlBxF6DBjixyQsWIFsl4s2Jk53Ap+4NxXDgjj1F9O2uz81Q K7SU1ICzwN7WQ0G0S6ho7axuXdphfeF9AuKylb1xRW7zKbPm2NGr7iYiQ tUb8r4nM+siM/cfWUqCwVe10klJLEx6SUYCrAevoyMDu6uBUOgfhh06ab k=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AWBQBHva5f/xbLJq1iHgEBCxIMQIJygQeBSQEgEo1vk?= =?us-ascii?q?AqMKogZBAcBAQEKAwEBLwQBAYZpJjgTAgMBAQEDAgMBAQEBBQEBAQIBBgRxh?= =?us-ascii?q?W2HEYRYAYMGog2OGnSBNIpDEIE4gVOMCIIAgTgcgiIBhXWCfYIsBJxDm2uCd?= =?us-ascii?q?wSDFoE3lkQDH6F5sEGDZAIEBgUCFYFrI4FXMxoIGxVlAYI/PRIZDZxpQANoA?= =?us-ascii?q?gYKAQEDCY5IAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,476,1596499200"; d="asc'?scan'208,217";a="31098394" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Nov 2020 17:11:16 +0000 Received: from dhcp-10-61-101-74.cisco.com (dhcp-10-61-101-74.cisco.com [10.61.101.74]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0ADHBFIY005594 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 13 Nov 2020 17:11:16 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_97100EA3-80C5-4746-828C-158CCE5ACD4F"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <1CF417E5-B132-4F9D-B666-7F9C17FFD8D0@cisco.com> Date: Fri, 13 Nov 2020 18:11:13 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.101.74, dhcp-10-61-101-74.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [Rfced-future] Agenda for next week posted 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, 13 Nov 2020 17:11:23 -0000 --Apple-Mail=_97100EA3-80C5-4746-828C-158CCE5ACD4F Content-Type: multipart/alternative; boundary="Apple-Mail=_3645DCB6-D021-48AD-B709-182D3CB56B6B" --Apple-Mail=_3645DCB6-D021-48AD-B709-182D3CB56B6B Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii It is as follows: 1. Note Well 2. Bash 3. Review Issues 4. Getting to a draft 5. Meeting timing and operating methods 6. AOB --Apple-Mail=_3645DCB6-D021-48AD-B709-182D3CB56B6B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
    It is as follows:


    1. Note Well
    2. = Bash
    3. Review Issues
    4. Getting to a draft
    5. = Meeting timing and operating methods
    6. AOB

    = --Apple-Mail=_3645DCB6-D021-48AD-B709-182D3CB56B6B-- --Apple-Mail=_97100EA3-80C5-4746-828C-158CCE5ACD4F 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl+uvjEACgkQh7ZrRtnS ejPo4Af+PEoP/APFuQNkWEWvteoE0q8xR56tF4gfWq5wK7tYWj+r5AWEAQCxC+5b h98X2K39ijJNpucXQ08cFx0d7ME2ib0I5xaVop0v0PJTmvJQ9aOwKjt0It8KtHYV LvijCNz7NGfSZAK5SyuqYCkLpRq20Pa5a1NOyDGGTUfi6H/URQU5H/sQLW5bYL6D p/QCG+f9wySFInzLNNz2W2euwVxL0O7aoxmpWhD1VKuvIy5l4AQDC0nNLfF6J3Gd 7txwCCppf7Cnm+s93D1KGXuho+tPpuxoU/f9kTmovjr8UQVV0o5Hmdut+rcU/mG+ hRSeyCKVf3ZEZdegYsn9aG9GP1w5dw== =OT6L -----END PGP SIGNATURE----- --Apple-Mail=_97100EA3-80C5-4746-828C-158CCE5ACD4F-- From nobody Tue Nov 17 07:52:27 2020 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 630AF3A145F for ; Tue, 17 Nov 2020 07:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 zh6vHmnpKsvG for ; Tue, 17 Nov 2020 07:52:25 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3273A145A for ; Tue, 17 Nov 2020 07:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1088; q=dns/txt; s=iport; t=1605628345; x=1606837945; h=from:mime-version:subject:message-id:date:to; bh=XIxBxlEL3ZtTaRaeZKpvadnqkVUKLksNC2pvg/XXMI8=; b=f2CdragVtiYLfTDJLMz8Nd8I0RPLgKzpVhUrfDc/Zwahatv+wYxI7ksS xpvG2GfqKA+nVRAC6vTgkrcBn7vBvPlG6lHx9HHEqfK1cXlLlPLwADywG ZuiCRyTl0S7OKtCFQHchEPPwQztIa4xdUxwGeYozMO42YSe3kUlcXkXZ9 Q=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0CCBABa8bNf/xbLJq1iHgEBCxIMQIFEC4NzASASjW+He?= =?us-ascii?q?5xUBAcBAQEKAwEBLwQBAYZvJjcGDgIDAQEBAwIDAQEBAQUBAQECAQYEcYVti?= =?us-ascii?q?2kBgwafWI4bdIE0ijAQgTiBU4wIggCBOAwQiBiCfYIsBJxFm26CdwSDGIE3l?= =?us-ascii?q?kYDH4MHARGKFoUijyiwRYNkAgQGBQIVgWokgVczGggbFWUBgj89EhkNnGlAA?= =?us-ascii?q?2cCBgoBAQMJjkgBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,485,1596499200"; d="asc'?scan'208";a="31190298" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Nov 2020 15:52:01 +0000 Received: from [10.61.214.177] ([10.61.214.177]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AHFq0bx013610 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 17 Nov 2020 15:52:01 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_A26C75C4-09B5-44D7-8929-AD8877675BBF"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Tue, 17 Nov 2020 16:52:00 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.214.177, [10.61.214.177] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: [Rfced-future] Minute taker / Jabber scribe sought 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, 17 Nov 2020 15:52:26 -0000 --Apple-Mail=_A26C75C4-09B5-44D7-8929-AD8877675BBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If you are available for the Thursday session of this program, please = drop one of the chairs a note. Thanks, Eliot --Apple-Mail=_A26C75C4-09B5-44D7-8929-AD8877675BBF 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl+z8aAACgkQh7ZrRtnS ejM9JAgAyRBYa28PoF+EZEPkk4NGUi3TN6qOPju9kIk7y8rOYJ+Jotss98wj1bUd IfMGMcEKPz7dx/d6sQVE8klkWzEoR1xMLjbFTI0XckzcgjVXgFCNYxNYVO4Vvo5K eqBm8bFnPxf5toH0MOfW6R5y/1dby5AqyfvGiaeaDsHf7tKOfa5STZIzjjHEvsFc SBwzK1oag2m7QuqQvQpnwq7Z8NoGJXARW9XfcEUsAoOw6TWd79xhHpYEcHbRP4k3 f3vmDzweaqzdUVz1FYh+Jengza+BbgLaNw1MIgS+dZ028IhUcYTHF8/tQqo8XsFb MDSl4qBbI0ldXCgjwwz7O+Xum+jNdQ== =l/WB -----END PGP SIGNATURE----- --Apple-Mail=_A26C75C4-09B5-44D7-8929-AD8877675BBF-- From nobody Tue Nov 17 12:03:00 2020 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 F24AD3A03EC for ; Tue, 17 Nov 2020 12:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrP4uJK2p8j6 for ; Tue, 17 Nov 2020 12:02:56 -0800 (PST) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 9323A3A113A for ; Tue, 17 Nov 2020 12:01:52 -0800 (PST) Received: by mail-ua1-x92e.google.com with SMTP id q4so6920992ual.8 for ; Tue, 17 Nov 2020 12:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=VXaJKNxC7h4COp9NuRymdfW35OWLJ78wO6gSmtExXB0=; b=Slvvqfq2h1k66lo3KdtdEb4qx3+Hu9yYhXlhIIG9eDddZ5HI4A496huk1N1TSOrT8D CCPYQvCmPoFcjhvOrsZjfiJ1KDsks2h9GPA7gqMLHCoFtWqFUC0DvHYwOzwp+2pZUY2n k9AhLjWFntKP32e5YoW2tc6Du7BpJnPpMH5bxOravoZN75JHijVowgOSIFwk2Q6YEO+y x2zDV6omJy38gvEyjnqgolopZQK4QJuNYqLFcJ3fGJ8MJZKCa8qSfFFVro1xf2Wre45s v+I+cce/OSfkfj3gYBUkZ2PQiFLqSzQ6OM3znxhhwsZqBtpHXp6TKBuqUyv/Ja0Lc/LB UAuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VXaJKNxC7h4COp9NuRymdfW35OWLJ78wO6gSmtExXB0=; b=KPJR7OtU8ZW7P3Jxj7nq5e4nPbHIbQboSJqwXh2yueUicYZMdZ4BqYVdGOJzWLEiX6 AIGvcObc+exxlLamYwz5bO6pm7uyQc/KEGtAn9Gix79k7/ubVhCq6hK0/NJS0CyIwhbe /os/x7XZ870B+ODgBwNlkuVcFD3+CtilK+oRIPCsWB7aLTsJThWbjggLq7uhYd0wuHf2 RcyX4R7BOM5VFEId05OSix77LV14rGjSRox2oGcgOqRfGVto2CkShmJFSTFYazQji3il C8y4K2da0GFUenJRJYIo9ZcY7O5f5ouEpLq3wh6YPZGiqZtlhlMbh8uNXsTG5uz+rYJD 4COw== X-Gm-Message-State: AOAM532V7gSFe/EPLjurHjpwyUj0byV09P6QcVdfq0MBqXAeU3cGmFai DL77JGRyGFtojXvSk0lCutVFuLXnF5SSceBnxqHtU73xkMe+rA== X-Google-Smtp-Source: ABdhPJzV/iKD5DohDOEOrTi8CW1yjRlpT/s/nGKGd7Bqh1Mdyb+3zBh7OvbEnaWt0eDiaUux4IHfC1A3wSyBwZiTOmI= X-Received: by 2002:a9f:2c92:: with SMTP id w18mr1125018uaj.58.1605643311337; Tue, 17 Nov 2020 12:01:51 -0800 (PST) MIME-Version: 1.0 From: Nevil Brownlee Date: Wed, 18 Nov 2020 09:01:23 +1300 Message-ID: To: rfced-future@iab.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Rfced-future] Role and responsibilities of RSE 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, 17 Nov 2020 20:02:59 -0000 I'm away from home this week, and won't be able to attend this week's rfced-future meeting, sorry. Meanwhile, 1. I think Brian's draft text for the RSE's duties is about right 2. Although words like "Advisor", Facilitator" and such come to mind, In my opinion, the job title should be "RFC Series Editor" 3. It should be a paid position, probably a half-time one 4. The Series Editor will work with the community/stream managers/strategy group/etc to achieve a workable consensus of any proposals for changes in the RFC Series Cheers, Nevil ----------------------------------- Nevil Brownlee, Taupo, NZ From nobody Thu Nov 19 04:33:48 2020 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 2E01F3A0CE0 for ; Thu, 19 Nov 2020 04:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 95ili4xQzZgw for ; Thu, 19 Nov 2020 04:33:44 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D603A0CDC for ; Thu, 19 Nov 2020 04:33:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1323; q=dns/txt; s=iport; t=1605789224; x=1606998824; h=from:mime-version:subject:message-id:date:to; bh=amjTXixmzb9BHZtwZCgjYMkPN1ylo6RvkBCgV2PSNT0=; b=gnY2D0GueBD+4dYmnb6GyBoL8Ul+F3hCJ8Yo0LsK4id9sXzXvCLepwoM BvoYt3GuWc6PkawLpNHXbCeSQHA6FNeFdWkb+j7y/xTeCqpyzytnDUlKn 5NKLjwlV3TMRHZqf0oZXw2D/Kom3o+x0UXu9MEpjIj2FGDk3WT7MaB+uu w=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0DlBAArZbZf/xbLJq1iHgEBCxIMhDl0VQEyLoQ9iQWkU?= =?us-ascii?q?QQHAQEBCgMBASMMBAEBhnYmOBMCAwEBAQMCAwEBAQEFAQEBAgEGBHGFYQyGH?= =?us-ascii?q?IEzAkODVQGDBg+faY4bdoEyhD4BAwOFegoGgTiBU4wIggCBOByCIgGDRwIBg?= =?us-ascii?q?iuCSjOCLASQc4tUm22CdwSDGYE3lkYDH4MIARGPY45/iQCnSYNkAgQGBQIVg?= =?us-ascii?q?WsjgVczGggbFWUBgj4+EhkNlySFRUADMAI1AgYBCQEBAwmOSAEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,490,1596499200"; d="asc'?scan'208";a="31248439" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Nov 2020 12:33:40 +0000 Received: from dhcp-10-61-98-59.cisco.com (dhcp-10-61-98-59.cisco.com [10.61.98.59]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AJCXcwu029414 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 19 Nov 2020 12:33:39 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_334205D9-3620-4878-B44B-52F9460AE410"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <991C4CF2-EEF0-4D60-B0E4-CAF0ACB99BFA@cisco.com> Date: Thu, 19 Nov 2020 13:33:38 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.98.59, dhcp-10-61-98-59.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [Rfced-future] Jabber logs 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, 19 Nov 2020 12:33:46 -0000 --Apple-Mail=_334205D9-3620-4878-B44B-52F9460AE410 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Pete made the comment that the chairs should read through the jabber = logs because there was perhaps more common ground than might appear on = the surface. For those who are interested, the jabber logs can be found = at the following URL: https://www.ietf.org/jabber/logs/rfcefdp/2020-11-19.html Summary of today=E2=80=99s meeting to follow. Eliot --Apple-Mail=_334205D9-3620-4878-B44B-52F9460AE410 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl+2ZiIACgkQh7ZrRtnS ejOLHwf9HdgvgAPfFOTH7aAVIX9iSk8Qsc7GjoihPkxR1qtBmR0Vw2kmSTb75p2C rCbFA0rsYPzHEASUZkRHZOW5eOdmEbxv0DQ22OrGZP/QdFxg/U3o59k6gMeg2BiQ 8cznNV0RgMxMhpG49f/lIOwdXypr/gJOQ04eTUM/SOcFrMnbNVEMHz12etuPCVPX PFyOEvmVYrtHbDHpGP1A6Cno2g2jk2yrogjyf6vYH6wJ3aQIyULsLyV3uDUexf1u WpCAId7+MEPjcHmHQVNf/jBfP2iqykx6f/vXeKmhVhAZIpS0qHG8ViCzbWmLQhlp 4EdV51g+Vx2iHDX3GU3B8saEKiEoHQ== =/M65 -----END PGP SIGNATURE----- --Apple-Mail=_334205D9-3620-4878-B44B-52F9460AE410-- From nobody Tue Nov 24 00:45:17 2020 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 0A4E23A1A80 for ; Tue, 24 Nov 2020 00:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.701 X-Spam-Level: X-Spam-Status: No, score=-7.701 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 8jMekCj83iEU for ; Tue, 24 Nov 2020 00:45:14 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1DC53A1A7E for ; Tue, 24 Nov 2020 00:45:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7535; q=dns/txt; s=iport; t=1606207513; x=1607417113; h=from:mime-version:subject:message-id:date:to; bh=RlSuqyuRUy8b+/dRalknvF8XnHOadfyk5RVBVYHL/as=; b=EIAkxGR1VH19SE9uvY4a+FSz6kSNJ0RPqRUlp/MTXpe/ZVI/mmsJ4Ai6 0x83/TYsyuUeVaPGhpgPdzLNnQBM+nOHiOjiNCZdJV4dz+2Y0D5MtOWyP kxuQHQDxZknz4RZ4vBGp1Sb7HJQG8PGSP3wNpwzaMzRc0v/tCWfbsULTI M=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BWBAC1x7xf/xbLJq1iHgEBCxIMggQLgiqBSQEyhGuJB?= =?us-ascii?q?aRPBAcBAQEKAwEBLwQBAYZ4JjcGDgIDAQEBAwIDAQEBAQUBAQECAQYEcYVth?= =?us-ascii?q?hxIawKBBoMSAYMGnxKOG3aBMopTEIE4gVOMCIIAgREnHIIiAYUKgzUzgiwEk?= =?us-ascii?q?HaLWopTkSaCeASDGYE3lkwDH4MaihmUU7Bag2YCBAYFAhWBaiSBVzMaCBsVG?= =?us-ascii?q?iEqAYI/PRIZDY4rF44nQANnAgYBCQEBAwmQRQEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,365,1599523200"; d="asc'?scan'208";a="28927685" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Nov 2020 08:45:09 +0000 Received: from dhcp-10-61-100-184.cisco.com (dhcp-10-61-100-184.cisco.com [10.61.100.184]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AO8j81h010949 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 24 Nov 2020 08:45:09 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_45170E8D-A486-4CEE-8589-FEF974DBC69B"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Tue, 24 Nov 2020 09:45:08 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.100.184, dhcp-10-61-100-184.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Draft minutes and next 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, 24 Nov 2020 08:45:16 -0000 --Apple-Mail=_45170E8D-A486-4CEE-8589-FEF974DBC69B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks to all who attended the IETF 109 meeting. Draft minutes have been uploaded. They are here for your perusal. = Please note that the proposed next interim meeting is December 17 at = 23.00 GMT. Could you please send any comments back to the chairs in the = next three weeks? Please note what the chairs think. We=E2=80=99ll = call that out separately in follow-on messages. Minutes for IETF 109 RFC Editor Future Development Program Chairs: Brian Rosen, Eliot Lear Minute taker: Rich Salz (thank you, Rich). Jabber Scribe: Brian Trammell (thank you, Brian) Eliot opened the meeting with Note Well and Agenda Bashing. Everyone = noted well and there were no bashes to the agenda at that moment. We proceeded to discuss issues 10, 11, 12, 24, and 13. Many of the = issues were linked. Issue 10: Is there a figurehead and thought leader? Mostly we deferred this. Decisions for confirmation on list for Issue 10: - don't use "thought = leader" Issue 11: If there is a figurehead, is the person a paid expert in = technical publishing One person was concerned that we couldn't decide this without a more = formal job description. The chairs didn't call the question for now on = this, to accommodate that concern. Issues12, 24: Is the person an advisor (RSA) or an Executive Editor = (RSE) What is the person's title? All of the following is predicated on there being a person in the first = place. We had a lengthy discussion about the text that Brian put forth. There = were a few open issues with it. =E2=80=A2 Mixing of the role of the expert and the chair There = seemed to be a general view (not sure about consensus) that the role of = the chair and the expert should be split. =E2=80=A2 The chairs think we have consensus that that person = can raise issues =E2=80=A2 The chairs think there is likely rough consensus that = the person does not make strategic decisions but that those are decided = by the strategic body =E2=80=A2 The chairs think there is likely rough consensus that = the person does not direct the RPC/REP. The chair asked the question: what if this person is viewed as a senior = member of the RPC/Tooling team? There were some positive comments, but not a lot of discussion. One = comment made was that much of the work that is needed is "grunt work", = in terms of drafting and managing draft progression for proposals. Russ = pointed out that this wasn't particularly an issue in the context of = earlier work. We also looked at a hypothetical that was raised about = tooling, just to see how the pieces might fit together. Where we left it: people should share their views about how they see the = interface between the RPC and the strategy body functioning. 13: Is decision making in the strategy body open to all? Early in the course of the discussion, it became clear that people = disliked the terminology. People prefer the "board model" to "closed = model=E2=80=9D (used in these minutes from this point). Eliot presented some slideware on this, characterizing the choices, for = purposes of discussion, noting that people were entirely free to agree, = disagree, or use their own characterizations. One note about the slides: = anything written in red is intended to indicate Eliot's view that there = is no consensus on a matter. One point made and reiterated was that even if a board model is chosen, = the decision process has to be transparent, without decisions happening = in back rooms. =E2=80=A2 The chairs think that everybody agrees that there is = some strategic body =E2=80=A2 The chairs think that strategic decisions get = documented in RFCs =E2=80=A2 but we're not sure if this has been = sufficiently discussed and may need its own issue =E2=80=A2 The chairs think that there is consensus that the = strategic body is open to all to engage openly, and that meetings should = be open, minuted, agendas posted. =E2=80=A2 The chairs think that the only point of disagreement = is who has decision-making power: is it the board or an open WG? One of the points of discussion was who to hold accountable if things go = wrong. One person expressed a desire for the board model based on being = able to hold some group of people accountable. The two approaches presented were open membership to decision making and = closed membership for decision making, or a board of appointed people or = the community. There was no consensus for either open or board model = yet. One concern raised was that an open group model with a weak RS[EA] would = be problematic. This linked to an issue that was going on in the jabber = room, which is how consensus is declared in an open group. We did not = discuss how decisions are made in the board model. One hybrid model = discussed in the jabber was the idea that you have appointed people = manage the consensus call, similar to the way that the IESG judges = community consensus. Where we left it: the chair asked that people post to the list what = their preferences are, and also what would make their lesser preferred = choice(s) more pallatable. Getting to a draft The chair suggested that as we begin to document agreement points we = should have a draft so that people can clearly see what they're agreeing = to, or raise issues. He suggested that we start with a skeleton and then = include items that we have consensus on. If the text then needs to be = wordsmithed, fine. There were no strong objections. One person raised = half a concern, another noted that we must be careful not to paper over = issues. The chairs noted that they would be very conservative in calling = consensus for that purpose. That doesn't mean we have no consensus. There are a number of points = listed in the tracker on which we do. The chairs propose to find a = stuckee for this purpose. Meeting timing and operating methods We had said we would meet every four weeks, accomodating global = timezones. We had said that every issue would be aired in person at = least once. We want to modify that to say that if an issue can be closed = with clear consensus, then it wouldn't not need discussion. The room = agreed under the following parameters: Clear beginning and end of discussion period for purposes of calling = discussion (BIG BOLD BRIGHT WORDS IN SUBJECT LINE or similar). We will = be conservative in calling consensus. We agreed to hold our next interim on 17 Dec 23.00 GMT AOB None. --Apple-Mail=_45170E8D-A486-4CEE-8589-FEF974DBC69B 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl+8yBQACgkQh7ZrRtnS ejPZIQgAj+Jq0BykLC6UHe38zhnYfHuJco0B9Zlz0auH9krozMtUUOdfte/E29JL k8OS30jv5o+TrWNL3XOGK7Zz1gLZV6SCc4wzK7F1I+RDHlLACJS5RtWtPL0kjF/s PkqLNL/PqOtq59cLibZkg1bdhk3WWNYTAL/kXK6G0SE6zckRVcbLAtJLR18XI/XF wKCg2w8XAVI5DM5APz0spRcrDlb95tsBiFFdGpHZY28ut/yqOxXYjHw5TYg0p8Sn MY5m3150gggmo5JgxPaojDXmiWiNRJmqJQzKKjhn4W6rYM8QtoGjRH7OcmgfbXPn 2cmkvEPcfxBMRSRQmC9XEEAn44kRwg== =qmv3 -----END PGP SIGNATURE----- --Apple-Mail=_45170E8D-A486-4CEE-8589-FEF974DBC69B-- From nobody Wed Nov 25 08:40:37 2020 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 5F1C83A1A78 for ; Wed, 25 Nov 2020 08:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 5ypT1yljbcnW for ; Wed, 25 Nov 2020 08:40:32 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0413A1A75 for ; Wed, 25 Nov 2020 08:40:31 -0800 (PST) Received: from [192.168.217.120] (p548dce71.dip0.t-ipconnect.de [84.141.206.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Ch67x6t2Mz114k; Wed, 25 Nov 2020 17:40:29 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 628015229.453391-234dd283fb89dfa6787489085489e775 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 25 Nov 2020 17:40:29 +0100 Message-Id: <9D0D4CBA-677A-410F-95F3-5C452970B842@tzi.org> To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [Rfced-future] Community input 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, 25 Nov 2020 16:40:35 -0000 For a good view at the skeptical components of my stance on running the = publishing activity entirely based on =E2=80=9Ccommunity input=E2=80=9D, = please see these messages. =20 https://mailarchive.ietf.org/arch/search/?q=3Dretiring+ftp+service All 196 of them. And when you are done, please keep in mind that this is only a revival = of an attempt in 2015 to retire IETF=E2=80=99s FTP service, which = (attempt) was eventually abandoned. We continue to offer FTP access to our documents. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Nov 25 09:01:57 2020 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 370533A1AB7 for ; Wed, 25 Nov 2020 09:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 tRKf_9ZEii9K for ; Wed, 25 Nov 2020 09:01:54 -0800 (PST) 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 30A3C3A1AB6 for ; Wed, 25 Nov 2020 09:01:52 -0800 (PST) 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 0APH1oge023270; Wed, 25 Nov 2020 17:01:50 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B00E92203D; Wed, 25 Nov 2020 17:01:50 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id 9B3602203C; Wed, 25 Nov 2020 17:01:50 +0000 (GMT) Received: from LAPTOPK7AS653V ([195.166.134.90]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0APH1nJW028534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 25 Nov 2020 17:01:49 GMT Reply-To: From: "Adrian Farrel" To: "'Carsten Bormann'" Cc: References: <9D0D4CBA-677A-410F-95F3-5C452970B842@tzi.org> In-Reply-To: <9D0D4CBA-677A-410F-95F3-5C452970B842@tzi.org> Date: Wed, 25 Nov 2020 17:01:48 -0000 Organization: Old Dog Consulting Message-ID: <019001d6c34c$aa867e40$ff937ac0$@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 Thread-Index: AQLHBe6V49ZmeBVY+0/71IElyp1ewqf4ivoQ Content-Language: en-gb X-Originating-IP: 195.166.134.90 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25812.001 X-TM-AS-Result: No--8.320-10.0-31-10 X-imss-scan-details: No--8.320-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25812.001 X-TMASE-Result: 10--8.320400-10.000000 X-TMASE-MatchedRID: 0dFPYP4mu5TxIbpQ8BhdbBlJRfzNw8afL5yduZDCCtu6pZ/o2Hu2YQfh L6pjLkc5xmaUaNm1iLLxamh5T12IAqrSlx/+C2I3Thh/2J+QysXnaaW2UTafyB7doR5EcVvjCt5 V56tXaop9Bh/FDxOVxvqjekXxTYI8Jda7ktb7ayWRS9zmYCUyQZ4YRoT55lhLK4YqHgCSopXEt8 fYeax4pDOAVx9QHw/ztMe31YblSPwcSy4WiRXnN+VSr005h5SpGbJMFqqIm9xoe+v2w6RhK7TML GnLhsRpqUMnwZCXWdfRssSdd19BspFN+B8oJZ5aggra2NOo2i3Xof+XRfBH218mdKW8Crqfk66/ gtVjZsXeAyV/CtDqTonSFowkH6MLvT3ZNP41VyTsDsv6raIUIc6gBdMBUo41Vj3J63pAR3xJFiH 5mE0Je9Wc2YeiJhGVcFf//rnUkXaPl8suWHSuVJ4CIKY/Hg3AWQy9YC5qGvyLZAVphLW/bSq2rl 3dzGQ1U8bna582ze1XAcwrAOJvsSkz1KoEekfB+8KhBRJ9/6bH5SEp5wNMzw== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Community input 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, 25 Nov 2020 17:01:56 -0000 Carsten,=20 I think you make an excellent point about how free-range discussions can = go in this/any community when opinions are held more strongly than the = desire to reach consensus, and when the exposition of all the parameters = is not clear. This is a salutary lesson for us, and your point is well made (to me).=20 The flip side of some form of delegation (i.e., not leaving it up to the = community) is that there is a risk that, no matter how strongly you hold = your opinion and how loudly you shout, you might not get what you want. = I believe that that is a risk I am willing to take (with some safeguards = about firing and steering). A -----Original Message----- From: Rfced-future On Behalf Of Carsten = Bormann Sent: 25 November 2020 16:40 To: rfced-future@iab.org Subject: [Rfced-future] Community input For a good view at the skeptical components of my stance on running the = publishing activity entirely based on =E2=80=9Ccommunity input=E2=80=9D, = please see these messages. =20 https://mailarchive.ietf.org/arch/search/?q=3Dretiring+ftp+service All 196 of them. And when you are done, please keep in mind that this is only a revival = of an attempt in 2015 to retire IETF=E2=80=99s FTP service, which = (attempt) was eventually abandoned. We continue to offer FTP access to our documents. Gr=C3=BC=C3=9Fe, Carsten --=20 Rfced-future mailing list Rfced-future@iab.org https://www.iab.org/mailman/listinfo/rfced-future From nobody Thu Nov 26 04:43:23 2020 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 2A4F03A12DE for ; Thu, 26 Nov 2020 04:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.943 X-Spam-Level: X-Spam-Status: No, score=-8.943 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FAKE_REPLY_B=0.658, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 NKVZ40eMGaMs for ; Thu, 26 Nov 2020 04:43:20 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F0523A12DB for ; Thu, 26 Nov 2020 04:43:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1866; q=dns/txt; s=iport; t=1606394599; x=1607604199; h=from:mime-version:subject:message-id:date:to; bh=o+Senk8ORWnv6UhKkWN122RgIqkrxCwLDOIafymJjvw=; b=XNfKOHmVIcZ0IuEJ92mjbZO1RdX+IqxV98iiynrbd572+J8zNSHlvnq/ 3e/7TMhXpnVVOmx48bJfyEeXo/Bh6co0uTReXUhXt2VZFPECGeMdWRwlC avlQ865krR1C25w45Wt2aFoWF4ulnltk8zLmV2k6taFLJGdMQtJgUaRe1 4=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0A1BQB4or9f/xbLJq1iHgEBCxIMhDmBSwEgEoRriQWkU?= =?us-ascii?q?QQHAQEBCgMBAS8EAQGGdSY4EwIDAQEBAwIDAQEBAQUBAQECAQYEcYVthhxxQ?= =?us-ascii?q?gKBBoMSAYMGoAeOHHaBMopVEIE4gVOMCIIAZlIcgiA1PoQcAQFtgkozgiwEn?= =?us-ascii?q?FucB4J4gx2BN5ZXAx+iEbBlg2oCBAYFAhWBbSOBVzMaCBsVZQGCPz0SGQ2OL?= =?us-ascii?q?ReOJ0ADZwIGAQkBAQMJkF4BAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,372,1599523200"; d="asc'?scan'208";a="31429260" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Nov 2020 12:43:15 +0000 Received: from dhcp-10-61-104-106.cisco.com (dhcp-10-61-104-106.cisco.com [10.61.104.106]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AQChEDq002344 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 26 Nov 2020 12:43:15 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_2B8714D8-A882-4217-BA1C-F4AB507764CF"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <6AA69D33-9A8E-4EF4-915F-611D60DDFA50@cisco.com> Date: Thu, 26 Nov 2020 13:43:14 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.104.106, dhcp-10-61-104-106.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Community input 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, 26 Nov 2020 12:43:21 -0000 --Apple-Mail=_2B8714D8-A882-4217-BA1C-F4AB507764CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There appears to have been a technical problem regarding Adrian=E2=80=99s = mail (I didn=E2=80=99t receive it, although I know that some did). Just = in case you didn=E2=80=99t see his response to Carsten: > Carsten, >=20 > I think you make an excellent point about how free-range discussions = can go in this/any community when opinions are held more strongly than = the desire to reach consensus, and when the exposition of all the = parameters is not clear. >=20 > This is a salutary lesson for us, and your point is well made (to me). >=20 > The flip side of some form of delegation (i.e., not leaving it up to = the community) is that there is a risk that, no matter how strongly you = hold your opinion and how loudly you shout, you might not get what you = want. I believe that that is a risk I am willing to take (with some = safeguards about firing and steering). >=20 > A --Apple-Mail=_2B8714D8-A882-4217-BA1C-F4AB507764CF 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl+/ouIACgkQh7ZrRtnS ejO7Tgf/bTlwv2xOhWgSN2DSVvEDmLimWaJ03YMOwCM6U2S6N/ZHwDs6BVFkeyXT 11drhpNULXiFP6Dq5ibfaGVLfZqSOH0KN6bKQfhqwlkP5408yza+y17ioxq74DQy NoFP3PofZbqSfaGqRKyXI3WRylpuhDbEZ/i9pzzSdQe32T6Z3qED3PCg4kKhQWau ZfaDZg6FkK9IaTOqwayUiRHkn98iRYtezKEm38RrIhJ3ZaVkvRu66ptE7bewEsjD WufqJiqqTEr1V8oCTN4W3r7FIEx55zenLoCXXZX/ewJQ7DN4fEH4nuD5Plncdu9U kU91333/5Wf+GKKUXXTGta4+qNhAEg== =aJ0b -----END PGP SIGNATURE----- --Apple-Mail=_2B8714D8-A882-4217-BA1C-F4AB507764CF-- From nobody Fri Nov 27 07:36:51 2020 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 CB9133A1033 for ; Fri, 27 Nov 2020 07:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 60m5UvTbcYnT for ; Fri, 27 Nov 2020 07:36:48 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5427F3A102F for ; Fri, 27 Nov 2020 07:36:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1622; q=dns/txt; s=iport; t=1606491408; x=1607701008; h=from:mime-version:subject:message-id:date:to; bh=U47qjb0Ya9633YY8ja2xKM7fnexq/acStMuxWUNK6KU=; b=ixHgZ/dqSAN+rodt5/PUn9t3nJ72XoJPewydOrwtsVd8d4FJMnuplb7g VeO2+c2XIypEH5Z6r4gX+d+rRkZHd7tFb4wn+/8J+Qqt8r4uLiMkf1x4b /C/KGmjYnYjNPtwuo3qLfYy96lEo3fpaJdGtxC2OHgMKuF6DR4Zh/gvW/ A=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0ACBQDNG8Ff/xbLJq1iHQEBAQEJARIBBQUBgg+DdQEgE?= =?us-ascii?q?oRriQWHf5xXBAcBAQEKAwEBLwQBAYZ2JjgTAgMBAQEDAgMBAQEBBQEBAQIBB?= =?us-ascii?q?gRxhW2GHIEsBwKEGAGDBqESjhx2gTKKbRCBOIFTjAiCAIE4DBCCJ2yFC4JKM?= =?us-ascii?q?4IsBJxgnAqCeYMdgTeWWAMfgx2KHYUmjzSwaYNqAgQGBQIVgW0jgVczGggbF?= =?us-ascii?q?WUBgj89EhkNjliOE0ADZwIGAQkBAQMJj3cBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,374,1599523200"; d="asc'?scan'208";a="31459827" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Nov 2020 15:36:44 +0000 Received: from [10.61.164.156] ([10.61.164.156]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0ARFahXk028379 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 27 Nov 2020 15:36:44 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_72458E74-396B-46DF-A092-CD7B3B62565D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <4A34B713-E013-4A36-9296-694F07EC5AC5@cisco.com> Date: Fri, 27 Nov 2020 16:36:43 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.164.156, [10.61.164.156] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [Rfced-future] ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 27 Nov 2020 15:36:50 -0000 --Apple-Mail=_72458E74-396B-46DF-A092-CD7B3B62565D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As mentioned in the minutes: Please let us know if you disagree with any of the following: =E2=80=A2 The chairs think that there is likely rough consensus that = role of the chair and the RS[EA] should be split. =E2=80=A2 The chairs think we have consensus that that person can raise = issues to the strategic group =E2=80=A2 The chairs think there is likely rough consensus that the = person does not make strategic decisions but that those are decided by = the strategic body =E2=80=A2 The chairs think there is likely rough consensus that the = person does not direct the RPC/REP. This does not resolve all of issue 12, of course. --Apple-Mail=_72458E74-396B-46DF-A092-CD7B3B62565D 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/BHQsACgkQh7ZrRtnS ejPe6wf+MvDe9RxNO4fFpT1FORl1i8By7g1zSlz6+yILQrACoPWf1JrWT4r6Ed2c /AMNO8mOCq0rXxo4nQc0MhXECHcg3azeQ/MKyU2qYIKUTbCYhd983xVvMut/BAhX iyazNX68Fw/EXRgA6LxJ09Xa8wtfR6cBJc/mGnUKzDjpPrizVpVWD8T/6p9qf5Gf a029bnQVOg8YJBiy1Bk54HNbBWslJ5P22Dg0wUHAYDXY8DK4czBHT3eHMtfGcuSZ ukdA4A4L8xZrzZqymZJ6ubSU+zO1dFPLvwn0xS4WnHZRvP+DkgZzqxFLrz3p+pIu I1mN8Yjrv8wHUqkA0/QDS3S+xIPiEQ== =8dwN -----END PGP SIGNATURE----- --Apple-Mail=_72458E74-396B-46DF-A092-CD7B3B62565D-- From nobody Fri Nov 27 07:38:13 2020 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 88C7D3A1039 for ; Fri, 27 Nov 2020 07:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 uGrsX9TI8OLc for ; Fri, 27 Nov 2020 07:38:09 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F04863A103F for ; Fri, 27 Nov 2020 07:38:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1742; q=dns/txt; s=iport; t=1606491489; x=1607701089; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=UwUcnTDNrJNBGfvw0ciZK7DpXsAZb+uwT+TiNiZoPSA=; b=cWHNKLWTNclK8Q37IhH9beW4AFu3C6Tu3jbKf+XJ8y7UFhFJuUywUBvN u3LlfSQJ9QfN7Yg5fJ6+qs6z89Lkm6a6OsA4Z405PdVObnzvAUloqcGfJ /OhDnTVMRbPUbTRjP1m/Y/PwpnX+CsSvldDJGLO0az+eK1ICPlYqitW1u M=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BoAABQHMFf/xbLJq1iHAEBAQEBAQcBARIBAQQEAQGBf?= =?us-ascii?q?QUBAQsBg3QBIBKEa4kFh38nmjSBfAQHAQEBCgMBAS8EAQGESgKCKiY2Bw4CA?= =?us-ascii?q?wEBAQMCAwEBAQEFAQEBAgEGBHGFbYVzAQQBI1YFCws7BwICVwaDOQGCZiCvL?= =?us-ascii?q?naBMoVXhRMQgTgBgVKMCIIAgTgMEIInLj6HVTOCLASRAYtfnAqCeYMdgTeWW?= =?us-ascii?q?AMfgx2KHYUmjzSwaYNqAgQGBQIVgV0BMoFXMxoIGxVlAYI/PRIZDY5YjhNAA?= =?us-ascii?q?2cCBgEJAQEDCY93AQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,374,1599523200"; d="asc'?scan'208";a="31457864" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Nov 2020 15:38:04 +0000 Received: from [10.61.164.156] ([10.61.164.156]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0ARFc473028635 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Nov 2020 15:38:04 GMT From: Eliot Lear Message-Id: <0D35C29C-5B29-4918-B838-8C62C13D8587@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_B0D203CD-E48A-4FCB-B397-33903D055433"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 27 Nov 2020 16:38:03 +0100 In-Reply-To: <4A34B713-E013-4A36-9296-694F07EC5AC5@cisco.com> Cc: rfced-future@iab.org To: Eliot Lear References: <4A34B713-E013-4A36-9296-694F07EC5AC5@cisco.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.164.156, [10.61.164.156] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 27 Nov 2020 15:38:12 -0000 --Apple-Mail=_B0D203CD-E48A-4FCB-B397-33903D055433 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Just to add: this check will end three weeks from today. > As mentioned in the minutes: >=20 > Please let us know if you disagree with any of the following: >=20 >=20 > =E2=80=A2 The chairs think that there is likely rough consensus that = role of the chair and the RS[EA] should be split. >=20 > =E2=80=A2 The chairs think we have consensus that that person can = raise issues to the strategic group >=20 > =E2=80=A2 The chairs think there is likely rough consensus that the = person does not make strategic decisions but that those are decided by = the strategic body >=20 > =E2=80=A2 The chairs think there is likely rough consensus that the = person does not direct the RPC/REP. >=20 >=20 > This does not resolve all of issue 12, of course. >=20 >=20 --Apple-Mail=_B0D203CD-E48A-4FCB-B397-33903D055433 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/BHVsACgkQh7ZrRtnS ejOsHwf/T5ZhWJ1dCufp6zEPg+xP+94RUfrE4aDNP5iAT3lM1AIAndSvON/K+IKG OoBFetIb/7Yam8RDKNSf6K3mFIrjKs6CDEZsvMmqZyGx8WDOPzv6WTD23q6UY0qm N9HNkDjtuBpepc8tl8BrmcwEu0qptxdQKP4D15a4DXVISGZ9Ue/sMaJb4Y0TZjEA H/p27wSC7J5hk4MApnA0YFz9yN+f1Uku1USDjMhcC4eBMfn36glhWl6TrXcSOQ4p bEYeUUiRjduqVD0OKjfgSTtaQSM2XDzVvKt3atDMTbIXARPfBmx/2LBF4hBg3Rzw onCE+2qDCOYy2x8ObuwgCIeH4Hx84w== =2Mpq -----END PGP SIGNATURE----- --Apple-Mail=_B0D203CD-E48A-4FCB-B397-33903D055433-- From nobody Fri Nov 27 07:40:04 2020 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 473EE3A0045 for ; Fri, 27 Nov 2020 07:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 IPIONoEfhDlY for ; Fri, 27 Nov 2020 07:40:02 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5833A003E for ; Fri, 27 Nov 2020 07:40:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1543; q=dns/txt; s=iport; t=1606491602; x=1607701202; h=from:mime-version:subject:message-id:date:to; bh=C7RJJi2tCR23KkNBzaL0FcEOjrh1mFYHLEoQiunKS5s=; b=Wh+dWmkoV+/99MVn2ToQdLmQashpU8hk4Lf4F65X9XgqYBHSJOuin4/j HS7oEkjWcRYmKpI8svmEZ4cts9XRM9Qm64Yi1/40LgrELuU65aDjvO7cR 6AXtLVGmNp6hC37uO7naCpRwnWXgu5qDoinEyiJ79UVZS3TYWvwH73ykU 0=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0ACBACJHcFf/xbLJq1iHQEBAQEJARIBBQUBgg+DdQEgE?= =?us-ascii?q?oRriQWkVQQHAQEBCgMBAS8EAQGGdiY4EwIDAQEBAwIDAQEBAQUBAQECAQYEc?= =?us-ascii?q?YVthhyBMwKEGAGDBqEVjhx2gTKKZhCBOIFTjAiCAIE4HIInbIULgkqCXwScY?= =?us-ascii?q?JwKgnmDHYE3llgDH4MLEoodhSaPNLBpg2oCBAYFAhWBbSOBVzMaCBsVZQGCP?= =?us-ascii?q?z0SGQ2OWI4TQANnAgYBCQEBAwmPdwEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,374,1599523200"; d="asc'?scan'208";a="31457880" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Nov 2020 15:39:57 +0000 Received: from [10.61.164.156] ([10.61.164.156]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0ARFdvGL014894 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 27 Nov 2020 15:39:57 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_C9B790FB-BF72-47C2-B001-68AFAA10CF34"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <5EE071CB-30CA-474F-BFA5-45129FFFFCBA@cisco.com> Date: Fri, 27 Nov 2020 16:39:56 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.164.156, [10.61.164.156] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Rfced-future] **Consensus check on part of Issue 13: Is decision making in the strategy body open to all?** 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, 27 Nov 2020 15:40:03 -0000 --Apple-Mail=_C9B790FB-BF72-47C2-B001-68AFAA10CF34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Please let us know in within the next three weeks if you disagree with = any of the following: =E2=80=A2 The chairs think that everybody agrees that there is some = strategic body =E2=80=A2 The chairs think that strategic decisions get documented in = RFCs =E2=80=A2 The chairs think that there is consensus that the strategic = body is open to all to engage openly, and that meetings should be open, = minuted, agendas posted. This is not to say that there is consensus = about how the strategic body is composed. These points obviously do not close Issue 13. --Apple-Mail=_C9B790FB-BF72-47C2-B001-68AFAA10CF34 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/BHc0ACgkQh7ZrRtnS ejOFsQf/RaI9Yc4dx35VJ2e9uUMBq2+mfcRVuvG6uKLFiA6RpTJUiCnMFNvlOzfK XBT6yhRsg4zE83RRIi/zGue7iHnjlGrNF/Ja52rznOQ9g+iFOirPefP8n+PCewt9 K4vBkUcDGEZbPCrUm3FK6HJOapQDaZ9oaD6SHgU09wbIRLGmJQwvh/zkaEewFRqC aspKzbuedr5qU44ll78Xhb/JyYxBCbvBaJAa1wZBAETfMQAfOhIsTh/w31QzyOmv UgfEM8y3Gj3J0YfOSzYSMwbhk9s3j6rLQrlFVoUWLegWh3k+/SyGVgQcowKQujwb E++YehZZOJF/YK3eJPa1cSqBDDfY/Q== =DTfH -----END PGP SIGNATURE----- --Apple-Mail=_C9B790FB-BF72-47C2-B001-68AFAA10CF34-- From nobody Fri Nov 27 08:26:25 2020 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 900333A07DF for ; Fri, 27 Nov 2020 08:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 t7ebYNzLgsme for ; Fri, 27 Nov 2020 08:26:22 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55AC53A07DE for ; Fri, 27 Nov 2020 08:26:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7127; q=dns/txt; s=iport; t=1606494382; x=1607703982; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=0jGs8vtOdAsFwPTxKU5MVbz5bGHYy8Pqq0pz0eZlMtE=; b=KNyvMgFtIFdgcPar7daVtKktpxBnK3umICdZxAyJbJdXNLx+C8d/6Dzx K1lqATLRFW86c93KIFBES5gHcgFFvXo1CYqS332+2xwqsxbKvE6Pm/XER MKZfCOzPTkEZGh8Ly90iRgKDLp0teWDC5iuiJDgFucTFUbw0xL0JgUWd5 o=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0CsAAC8J8Ff/xbLJq1iHAEBAQEBAQcBARIBAQQEAQGBf?= =?us-ascii?q?gQBAQsBgx5WASASLoQ9iQWIJZQViBsEBwEBAQoDAQEjDAQBAYRKAoIqJjcGD?= =?us-ascii?q?gIDAQEBAwIDAQEBAQUBAQECAQYEcYVhDIVyAQEBAwEjVgULCQIOCioCAlcGE?= =?us-ascii?q?xSDEgGCZiAPk3abEnaBMoVXhQkKBoE4AYFSjAiCAIERJxyCVT6CXQICF4RdM?= =?us-ascii?q?4IsBJBWjAqKXJEugnmDHYE3hEOSFQMfgx2KHYUmjzSea5F+g2oCBAYFAhWBb?= =?us-ascii?q?CSBVzMaCBsVZQGCPj4SGQ2FdJEyhUVAAzA3AgYBCQEBAwmPdwEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,375,1599523200"; d="asc'?scan'208,217";a="31460919" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Nov 2020 16:26:18 +0000 Received: from [10.61.164.156] ([10.61.164.156]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0ARGQHt8010567 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Nov 2020 16:26:18 GMT From: Eliot Lear Message-Id: <88B51C37-9DD1-42B1-AE71-26B279A8CB1E@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_BD964F69-2ACE-44ED-A33F-1CAF052772AF"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 27 Nov 2020 17:26:17 +0100 In-Reply-To: <9D0D4CBA-677A-410F-95F3-5C452970B842@tzi.org> Cc: rfced-future@iab.org To: Carsten Bormann References: <9D0D4CBA-677A-410F-95F3-5C452970B842@tzi.org> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.164.156, [10.61.164.156] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Rfced-future] Community input 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, 27 Nov 2020 16:26:25 -0000 --Apple-Mail=_BD964F69-2ACE-44ED-A33F-1CAF052772AF Content-Type: multipart/alternative; boundary="Apple-Mail=_70B56018-05F4-4721-AFFB-4CCB785C8649" --Apple-Mail=_70B56018-05F4-4721-AFFB-4CCB785C8649 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Good evening Carsten, > On 25 Nov 2020, at 17:40, Carsten Bormann wrote: >=20 > For a good view at the skeptical components of my stance on running = the publishing activity entirely based on =E2=80=9Ccommunity input=E2=80=9D= , please see these messages. >=20 > https://mailarchive.ietf.org/arch/search/?q=3Dretiring+ftp+service >=20 > All 196 of them. >=20 > And when you are done, please keep in mind that this is only a revival = of an attempt in 2015 to retire IETF=E2=80=99s FTP service, which = (attempt) was eventually abandoned. > We continue to offer FTP access to our documents. >=20 > Gr=C3=BC=C3=9Fe, Carsten Just to point out- there are hybrid models that could be employed. For = instance, one could envision an =E2=80=9CIESG-like=E2=80=9D model in = which community input is facilitated differently, where people provide = written comments, but dialog is reserved for in person discussions, with = consensus measurement being separated ins one way. Input could come in = the form of a Github PR to a policy of some form. The structure this = group establishes (a) needn=E2=80=99t adhere strictly to the WG model as = we have it defined and (b) could conceivably be used as a guide to = improve the WG model if we get it right. Also, we have a separate issue 23 about what is strategic, which is = really where community input is needed. I think we might even be coming = close to being able to answer that question. And by the way, in that dialog about FTP, I think the answer to = Roman=E2=80=99s query seems pretty clear in rough consensus terms, even = if conversation has been=E2=80=A6 wide ranging. Is that level of noise = ok in this context? We talked about hypotheticals at the last meeting. Here are two to = bracket this discussion: A change people would generally like (everyone who submits an RFC to the = queue gets an ice cream) A change people would generally not like (output encoding to be EBCDIC). A change that seems okay but might need seem tweaking (output encoding = to Unicode v-Next). And a caution. It may be good to allow some fluid operating methods if = there is a WG model, as consensus may be trickier in some instances to = find than in others. Eliot --Apple-Mail=_70B56018-05F4-4721-AFFB-4CCB785C8649 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Good = evening Carsten,

    On 25 Nov 2020, at 17:40, = Carsten Bormann <cabo@tzi.org> wrote:

    For = a good view at the skeptical components of my stance on running the = publishing activity entirely based on =E2=80=9Ccommunity input=E2=80=9D, = please see these messages.  

    https://mailarchive.ietf.org/arch/search/?q=3Dretiring+ftp+serv= ice

    All 196 of them.

    And when you are done, please keep in mind that this is only = a revival of an attempt in 2015 to retire IETF=E2=80=99s FTP service, = which (attempt) was eventually abandoned.
    We continue to = offer FTP access to our documents.

    Gr=C3=BC=C3= =9Fe, Carsten


    Just to = point out- there are hybrid models that could be employed.  For = instance, one could envision an =E2=80=9CIESG-like=E2=80=9D model in = which community input is facilitated differently, where people provide = written comments, but dialog is reserved for in person discussions, with = consensus measurement being separated ins one way.  Input could = come in the form of a Github PR to a policy of some form.  The = structure this group establishes (a) needn=E2=80=99t adhere strictly to = the WG model as we have it defined and (b) could conceivably be used as = a guide to improve the WG model if we get it right.

    Also, we have a separate = issue 23 about what is strategic, which is really where community input = is needed.  I think we might even be coming close to being able to = answer that question.

    And by the way, in that dialog about FTP, I think the answer = to Roman=E2=80=99s query seems pretty clear in rough consensus terms, = even if conversation has been=E2=80=A6 wide ranging.  Is that level = of noise ok in this context?

    We talked about hypotheticals at the = last meeting.  Here are two to bracket this discussion:
    • A change people would generally = like (everyone who submits an RFC to the queue gets an ice = cream)
    • A change people would generally not like = (output encoding to be EBCDIC).
    • A change that seems = okay but might need seem tweaking (output encoding to Unicode = v-Next).
    And a caution.  It may be = good to allow some fluid operating methods if there is a WG model, as = consensus may be trickier in some instances to find than in = others.

    Eliot


    = --Apple-Mail=_70B56018-05F4-4721-AFFB-4CCB785C8649-- --Apple-Mail=_BD964F69-2ACE-44ED-A33F-1CAF052772AF 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/BKKkACgkQh7ZrRtnS ejP70ggAjkOBHJL6hlQyZdvlxVrFZIM9f/WXNX1iQt8GgAmccQ2nXV7z5useaRE6 OlQSHzWZyD0wvpkkCCzuGhGAEc8BqQvl3X/jBzJ965Cvt7R429esGoB8HbPYgpUN krw4fa0hWSWRK38LcoZORRf5qf8592IeQj7YzHSHXcr58LOThBEFy23svoet8gwI rZ7hwV13g1UA5qeUKzmZoqFZlEQoBoguex667nAjmPklWjCbTikL1UQu3XNDd5sK 1GBDyVUplolb8qVdmZttCEj4TcZK3CzPZfMMxYLbpvSObTffMy/69xTLPkJD98hG yjGwz9dk8EIxoM3Fgo7CeY0oIHGM9g== =8PlC -----END PGP SIGNATURE----- --Apple-Mail=_BD964F69-2ACE-44ED-A33F-1CAF052772AF-- From nobody Fri Nov 27 08:26:52 2020 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 CE91D3A07DF; Fri, 27 Nov 2020 08:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 X6LloeHXV5id; Fri, 27 Nov 2020 08:26:49 -0800 (PST) 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 01CC23A047D; Fri, 27 Nov 2020 08:26:48 -0800 (PST) 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 0ARGQlwg013770; Fri, 27 Nov 2020 16:26:47 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 18CF92203C; Fri, 27 Nov 2020 16:26:47 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id 0315522032; Fri, 27 Nov 2020 16:26:47 +0000 (GMT) Received: from LAPTOPK7AS653V ([195.166.134.111]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0ARGQjvZ016044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Nov 2020 16:26:46 GMT Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , References: <4A34B713-E013-4A36-9296-694F07EC5AC5@cisco.com> In-Reply-To: <4A34B713-E013-4A36-9296-694F07EC5AC5@cisco.com> Date: Fri, 27 Nov 2020 16:26:44 -0000 Organization: Old Dog Consulting Message-ID: <04e901d6c4da$192afa90$4b80efb0$@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 Thread-Index: AQK2WJxmIEQv+FUkp3uHd370w58a+qgc/19A Content-Language: en-gb X-Originating-IP: 195.166.134.111 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25816.001 X-TM-AS-Result: No--4.611-10.0-31-10 X-imss-scan-details: No--4.611-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25816.001 X-TMASE-Result: 10--4.611200-10.000000 X-TMASE-MatchedRID: 8+bhjh9TQnFq0U6EhO9EEyEyJ8xFEVolkW0zU11KKK3aOIP2b6ZfX70s A/cGYry6py+dwKxMjsDRa+XTiZwbMtBo81ST2NRRGUlF/M3Dxp+mJtY0iSfJ/bV5fSMRD1zqhGz G3wY/cLdt7em2i8cWux8iOqc8ylAx/8TykoC75C35WZT2GFh+neAeEI3tbHhVWsKKuc6vT6z5ih 3vHFgxg/5Z91GSApBaRCVxhki+AcMsMLcUZMcjdzlRhU08NvGHQfblIp3oBdEutoY2UtFqGGK3y skfEbaLo/mqMFSx4F7DAp66YwIpWLkWDqm7WNaJOQ2HvvZCJ0wX705dnYk+LFMnnsDzMI/0Xv0U vr1nqBcl17aQoQXxXF+24nCsUSFN/fTpDjOELgPdB/CxWTRRuwihQpoXbuXFHfUkXbq09y/LyZ7 6YXOLqaB5TxsKqEn2Hw7b3CJb0nnf2qL85ahrlo/iqdL4ttHpVrfA5PRTp0+YafFZowXWnu5Ret YWKft1kc8vZYcPwmShurVaY1hyX4xdVwkeE3a3UyOqrFz2uoieqD9WtJkSIw== 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 on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 27 Nov 2020 16:26:51 -0000 Hi Eliot, Happy Black Friday. I found this just a tiny bit ambiguous. I think that, in the context of = the subject line, I can work it out. So, to be clear... =E2=80=A2 The chairs think that there is likely rough consensus that = role of the chair and the RS[EA] should be split. =E2=80=A2 The chairs think we have consensus that the RS[EA] can raise = issues to the strategic group =E2=80=A2 The chairs think there is likely rough consensus that the = RS[EA] does not make strategic decisions but that those are decided by = the strategic body =E2=80=A2 The chairs think there is likely rough consensus that the = RS[EA] does not direct the RPC/REP. Right? Thanks, Adrian -----Original Message----- From: Rfced-future On Behalf Of Eliot = Lear Sent: 27 November 2020 15:37 To: rfced-future@iab.org Subject: [Rfced-future] ** Consensus check on part of Issue 12: Is the = person an advisor (RSA) or an Executive Editor (RSE) ** As mentioned in the minutes: Please let us know if you disagree with any of the following: =E2=80=A2 The chairs think that there is likely rough consensus that = role of the chair and the RS[EA] should be split. =E2=80=A2 The chairs think we have consensus that that person can raise = issues to the strategic group =E2=80=A2 The chairs think there is likely rough consensus that the = person does not make strategic decisions but that those are decided by = the strategic body =E2=80=A2 The chairs think there is likely rough consensus that the = person does not direct the RPC/REP. This does not resolve all of issue 12, of course. From nobody Fri Nov 27 08:26:57 2020 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 E25B43A047D; Fri, 27 Nov 2020 08:26:51 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-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 jtE5CKe-J7uL; Fri, 27 Nov 2020 08:26:50 -0800 (PST) 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 C42963A07DE; Fri, 27 Nov 2020 08:26:48 -0800 (PST) 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 0ARGQkHx003034; Fri, 27 Nov 2020 16:26:46 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8617A22056; Fri, 27 Nov 2020 16:26:46 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id 79BBC22052; Fri, 27 Nov 2020 16:26:46 +0000 (GMT) Received: from LAPTOPK7AS653V ([195.166.134.111]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0ARGQjvY016044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Nov 2020 16:26:46 GMT Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , References: <5EE071CB-30CA-474F-BFA5-45129FFFFCBA@cisco.com> In-Reply-To: <5EE071CB-30CA-474F-BFA5-45129FFFFCBA@cisco.com> Date: Fri, 27 Nov 2020 16:26:44 -0000 Organization: Old Dog Consulting Message-ID: <04e101d6c4da$18dadec0$4a909c40$@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 Thread-Index: AQGx5aRnig5hkp6VFi94dcUuyC7i4qol5vBw Content-Language: en-gb X-Originating-IP: 195.166.134.111 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25816.001 X-TM-AS-Result: No--6.235-10.0-31-10 X-imss-scan-details: No--6.235-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25816.001 X-TMASE-Result: 10--6.235500-10.000000 X-TMASE-MatchedRID: HXSqh3WYKfu9GVQT/CmkaCEyJ8xFEVolkW0zU11KKK3aOIP2b6ZfX9Ei m4gTRv0SAPHKes87ZbBBS1PQQ1i1NZ2DGfbmRbvP+ACG5oWJ7tJ4Xox68xVlQJCMofw0mbSu58S ju1ep5ml2mzSFmhL2Ygjr4u3LUP1sbBfEWzUJPFdIcJTn2HkqsRpxmKWTfsQIYANrKD2dIzoRZc CYVXElTp0rIOpoHYpOmfHUPwJ5HXNoWWTS0CIqzt83p9W/k4fKwuIWIvQEbW6bKItl61J/yY3BZ j4qY5QbDMq3z/Y/gtV5zdAzex5xZrCuwQ6KM3KeiKzwUUQC5KhlPtYC/i3Xx/4DQmHlw+4RL+Kq 22yZJmuUTGVAhB5EbQ== 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 on part of Issue 13: Is decision making in the strategy body open to all?** 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, 27 Nov 2020 16:26:52 -0000 Thanks Eliot, I can agree with all of that. Hiding behind the third bullet is the question about how the strategic = body makes decisions: by votes of the body, by consensus of the body, by = consensus of all those who engage. And that leads to a question non the second bullet as to whether the = RFCs need any form of consensus (e.g., IETF consensus on the IETF = stream, IAB consensus on the IAB stream) or are publications of record = by the strategic body. Ciao, Adrian -----Original Message----- From: Rfced-future On Behalf Of Eliot = Lear Sent: 27 November 2020 15:40 To: rfced-future@iab.org Subject: [Rfced-future] **Consensus check on part of Issue 13: Is = decision making in the strategy body open to all?** Please let us know in within the next three weeks if you disagree with = any of the following: =E2=80=A2 The chairs think that everybody agrees that there is some = strategic body =E2=80=A2 The chairs think that strategic decisions get documented in = RFCs =E2=80=A2 The chairs think that there is consensus that the strategic = body is open to all to engage openly, and that meetings should be open, = minuted, agendas posted. This is not to say that there is consensus = about how the strategic body is composed. These points obviously do not close Issue 13. From nobody Fri Nov 27 08:31:08 2020 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 69E133A0844 for ; Fri, 27 Nov 2020 08:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 P2DJtCHrJ17U for ; Fri, 27 Nov 2020 08:31:02 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CA63A083F for ; Fri, 27 Nov 2020 08:31:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1838; q=dns/txt; s=iport; t=1606494661; x=1607704261; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=RF02Xl5iD80S/HAcCGHiWzsHG0qGu7Za9+rzWcZVahU=; b=b+GB4STDGxHkwN2Qszvy0X1H5y3MxqUu2/z9iYakKxl2R+TTJ5pikF6o tRB6PW6LD+S8WuA23ylXaWM/fF5a5kT6lltGmGJAUwppIG71LDW1kCGpL q6ANdLRA7Ns3JTeIlUcZhRoqB6Otr+CLqKG758074e5bxL2SU/RBawxmb Y=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BIAABaKcFf/xbLJq1iHAEBAQEBAQcBARIBAQQEAQGBf?= =?us-ascii?q?AYBAQsBg3QBIBIuhD2JBYd+J5o0gXwEBAMBAQEKAwEBLwQBAYRKAoIqJjUID?= =?us-ascii?q?gIDAQEBAwIDAQEBAQUBAQECAQYEcYVthXIBAQEDASNWBQsLGCMHAgJXGYMmA?= =?us-ascii?q?YJmIK5NBlN2gTKFV4UJEDeBAQGBUowIggCBOAwQgicuPoULgkozgiwEnGCKX?= =?us-ascii?q?JEugnmDHYE3llgDH5JgjzSwaYNqAgQGBQIVgVgCNoFXMxoIGxVlAYI+PhIZD?= =?us-ascii?q?Y5YjhNAAzA3AgYBCQEBAwmPdwEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,375,1599523200"; d="asc'?scan'208";a="29025144" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Nov 2020 16:30:57 +0000 Received: from [10.61.164.156] ([10.61.164.156]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0ARGUuWt006722 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Nov 2020 16:30:57 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F348C2DD-5CE6-4F35-B7F5-8C277EA53271"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 27 Nov 2020 17:30:56 +0100 In-Reply-To: <04e901d6c4da$192afa90$4b80efb0$@olddog.co.uk> Cc: rfced-future@iab.org To: adrian@olddog.co.uk References: <4A34B713-E013-4A36-9296-694F07EC5AC5@cisco.com> <04e901d6c4da$192afa90$4b80efb0$@olddog.co.uk> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.164.156, [10.61.164.156] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 27 Nov 2020 16:31:06 -0000 --Apple-Mail=_F348C2DD-5CE6-4F35-B7F5-8C277EA53271 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Happy Black Friday to you as well, Adrian. > On 27 Nov 2020, at 17:26, Adrian Farrel wrote: >=20 > Hi Eliot, >=20 > Happy Black Friday. >=20 > I found this just a tiny bit ambiguous. I think that, in the context = of the subject line, I can work it out. So, to be clear... >=20 > =E2=80=A2 The chairs think that there is likely rough consensus that = role of the chair and the RS[EA] should be split. >=20 > =E2=80=A2 The chairs think we have consensus that the RS[EA] can raise = issues to the strategic group >=20 > =E2=80=A2 The chairs think there is likely rough consensus that the = RS[EA] does not make strategic decisions but that those are decided by = the strategic body >=20 > =E2=80=A2 The chairs think there is likely rough consensus that the = RS[EA] does not direct the RPC/REP. >=20 > Right? Right. Eliot --Apple-Mail=_F348C2DD-5CE6-4F35-B7F5-8C277EA53271 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/BKcAACgkQh7ZrRtnS ejMSRwf+I3uiPi1zMYjZGMcIHJ+4SfsnUsuksheASsNl7hw452OrpayboTvw0RD9 kAP0wTWHkWRXnrCtm3ZgNZM4HoD2RGTafFCuoXSczP5glucLgCFqGWBBugPDI0cY sgwruQ1MjSmSGz0Klb8a8GF7Y/sJmr1pRAifE3AE73SwtDvqixMGk9k33VDQVPYu VHCfs3tF649yZFRWJ8e2d4eRMSwLVCNBlAY0cD2Zyqtx6bHtMiWXXrw1OXojTFtP wlM7VD028Z+NSmI+2eprEzmoRRIh8+Pj8X8LvktDhT/Eeh+HGWWBM4h/OGlu12CI wm83kw1h9HAvLvTmNO8hVis+543PJA== =3dFp -----END PGP SIGNATURE----- --Apple-Mail=_F348C2DD-5CE6-4F35-B7F5-8C277EA53271-- From nobody Fri Nov 27 08:47:01 2020 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 6125F3A0953 for ; Fri, 27 Nov 2020 08:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ENpBBLAOYF-h for ; Fri, 27 Nov 2020 08:46:59 -0800 (PST) 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 BDB463A0896 for ; Fri, 27 Nov 2020 08:46:57 -0800 (PST) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0ARGkqLB004108; Fri, 27 Nov 2020 16:46:52 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5AAE822044; Fri, 27 Nov 2020 16:46:52 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id 4EED52204A; Fri, 27 Nov 2020 16:46:52 +0000 (GMT) Received: from LAPTOPK7AS653V ([195.166.134.111]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0ARGkoR8028721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Nov 2020 16:46:51 GMT Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" Cc: References: <4A34B713-E013-4A36-9296-694F07EC5AC5@cisco.com> <04e901d6c4da$192afa90$4b80efb0$@olddog.co.uk> In-Reply-To: Date: Fri, 27 Nov 2020 16:46:49 -0000 Organization: Old Dog Consulting Message-ID: <04f701d6c4dc$e7968960$b6c39c20$@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 Thread-Index: AQK2WJxmIEQv+FUkp3uHd370w58a+gJQI7vxAmmVomCn9zcUoA== Content-Language: en-gb X-Originating-IP: 195.166.134.111 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25816.001 X-TM-AS-Result: No--7.333-10.0-31-10 X-imss-scan-details: No--7.333-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25816.001 X-TMASE-Result: 10--7.333500-10.000000 X-TMASE-MatchedRID: X4bcv0S75Klq0U6EhO9EEyEyJ8xFEVolkW0zU11KKK2HR+DYCLc5t4u3 renu5Y0weZfvvpNSympaycUW8GwsYffuVpATnjcHalRqQPhHMT4ZskwWqoib3Bw0HKhKjTfpT5l XSvqvBrzkizndBEr04RP+4hrT4NGjfuV++H9cjCu9NsL2xEmLy+9KnaK64e2ig8vHe9ji82Kwjk gQC93hzpRg+a1Bbv8FozxntnaswsTIarh/uoUlq6JVTu7sjgg1SkWlzdsmIx4bVUVEY6U/r8gSV UJPg3tlDtJPaAMD/JN2rB/h5898rFIq48tvI8/gmvnKSb020hxxDjcOu4ElXC556rUMDXk2CPIv P3uOlZfLEpVi2vdpV5FKQVDMSa4KafFVMpfEiu2eAiCmPx4NwFkMvWAuahr8i2QFaYS1v20qtq5 d3cxkNa0nWc4fHJdO9v9aYKuUbQeI5vHxN7rFQL96ZwmKoIFanvwpfk0gsfDAvpLE+mvX8g== 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 on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 27 Nov 2020 16:47:00 -0000 >> I found this just a tiny bit ambiguous. I think that, in the context = of the subject line, I can work it out. So, to be clear... >>=20 >> =E2=80=A2 The chairs think that there is likely rough consensus that = role of the chair and the RS[EA] should be split. >>=20 >> =E2=80=A2 The chairs think we have consensus that the RS[EA] can = raise issues to the strategic group >>=20 >> =E2=80=A2 The chairs think there is likely rough consensus that the = RS[EA] does not make strategic decisions but that those are decided by = the strategic body >>=20 >> =E2=80=A2 The chairs think there is likely rough consensus that the = RS[EA] does not direct the RPC/REP. >>=20 >> Right? > > Right. Good, then I'm OK with the first three bullets, but unsure about the = last one. It covers a rather large area since there are number of things = on which the RPC need advice, guidance, and direction per the helpful = email from Sandy.=20 This bullet doesn't mention "strategic" and that may be the line. Let's = take something that might be considered less than the most important = issue: the style guide. Someone has to make decisions about what is in = the style guide, and the style guide directs the RPC.=20 Maybe the strategic body is able to take advice while understanding its = limitations in processing the subject matter. Or maybe, in some matters, = the RS[EA] does direct the RPC. Cheers, Adrian From nobody Fri Nov 27 12:05:45 2020 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 AED093A0E5F for ; Fri, 27 Nov 2020 12:05:43 -0800 (PST) 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, 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=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 gNu8pIlrtAu6 for ; Fri, 27 Nov 2020 12:05:41 -0800 (PST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 511733A0E60 for ; Fri, 27 Nov 2020 12:05:41 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id t37so5097731pga.7 for ; Fri, 27 Nov 2020 12:05:41 -0800 (PST) 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=eBut6uq6Jgu5Kp1eLIAJuJpqByvSTYKz5RGmDjK6Kbk=; b=EvgamakwKDFhc0qm1DJRB302JOrKJT29o/OQZgGYaNp4Ag2CF17TYwKyHdgg6YTiGr 268WR7JlPyXCn2Oq+Hf+lQBeyiPn5HZLvCnf7UHRKXLh+uJHjihvwgsys/H83OoIxTLY 7WnrSncN4wFCezJLP+LwIjRe5BXG9dgwkmWObCCBCPDgJKiL+3XneMKkxdis3h3QEo/Q M6SHNpykaCni+h2efm1y2Oc+nUfRVM6Tj9+byFYmGs5g8hZL1u0ePtEiwq6JCOM5oxFC tab+VbG5CCWFfy6Oqpdju+EzDojp9Nngrq6cHGSzxNLj9UD9xjbOu4JBE21tCtUP8q7r pA1g== 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=eBut6uq6Jgu5Kp1eLIAJuJpqByvSTYKz5RGmDjK6Kbk=; b=U/XF3bobu2dq0gn+yfIwKU8X7Ck6BjbUXoloT+RmDS9GGWPRKrETP5coM0yxIzi611 hYAvzJaGeD5NBYgOaK2lqcD+9/xMZ5cepuEer0Enho2EjNh9I3p4UOeEUd6wV4MraFlZ YW2FGRuk/aPZ2FV3iX+T3aO6fbXC/Bzn4TATny7VtJpB8B4rUlz6CScBiwfWHJOKBmKa h/i8PB7jhAcnPRAs6qLEkhQcGPXK9GnU235Raf/rldLjHnQaiWNaXAWuCmzgawjAkPY5 4e8lEdShoxfnMU6Pg+LiJVRjIG9i8RhBPBWnXkS7GDyxnZmm2WnXsePo/xxkAst6KuT0 9ZaQ== X-Gm-Message-State: AOAM532crXglAA92tUTTY8C4Bi+lPFMOL2Qve5XIwe3YBjdyJZXjvt96 naL3/DJvOo4G5X0UA45MZpHMQ2NAs8I+XA== X-Google-Smtp-Source: ABdhPJyijL9SSHRbadh5jdR8y5rFZyK4Xk48I1OUK033yKXAwuc5vF23zLNwGn69gHZvX+uA1wecrg== X-Received: by 2002:a62:c1c1:0:b029:198:14d8:6e98 with SMTP id i184-20020a62c1c10000b029019814d86e98mr8712567pfg.10.1606507540314; Fri, 27 Nov 2020 12:05:40 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id n2sm8405211pfq.129.2020.11.27.12.05.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Nov 2020 12:05:39 -0800 (PST) To: Eliot Lear , Carsten Bormann Cc: rfced-future@iab.org References: <9D0D4CBA-677A-410F-95F3-5C452970B842@tzi.org> <88B51C37-9DD1-42B1-AE71-26B279A8CB1E@cisco.com> From: Brian E Carpenter Message-ID: <468c74fe-1bdf-08e8-99a3-b8c6376d811b@gmail.com> Date: Sat, 28 Nov 2020 09:05:35 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <88B51C37-9DD1-42B1-AE71-26B279A8CB1E@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Community input 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, 27 Nov 2020 20:05:44 -0000 On 28-Nov-20 05:26, Eliot Lear wrote: > Good evening Carsten, >=20 >> On 25 Nov 2020, at 17:40, Carsten Bormann > wrote: >> >> For a good view at the skeptical components of my stance on running th= e publishing activity entirely based on =E2=80=9Ccommunity input=E2=80=9D= , please see these messages. =C2=A0 >> >> https://mailarchive.ietf.org/arch/search/?q=3Dretiring+ftp+service >> >> All 196 of them. >> >> And when you are done, please keep in mind that this is only a revival= of an attempt in 2015 to retire IETF=E2=80=99s FTP service, which (attem= pt) was eventually abandoned. >> We continue to offer FTP access to our documents. >> >> Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > Just to point out- there are hybrid models that could be employed. =C2=A0= For instance, one could envision an =E2=80=9CIESG-like=E2=80=9D model in = which community input is facilitated differently, where people provide wr= itten comments, but dialog is reserved for in person discussions, with co= nsensus measurement being separated ins one way. =C2=A0Input could come i= n the form of a Github PR to a policy of some form. =C2=A0The structure t= his group establishes (a) needn=E2=80=99t adhere strictly to the WG model= as we have it defined and (b) could conceivably be used as a guide to im= prove the WG model if we get it right. >=20 > Also, we have a separate issue 23 about what is strategic, which is rea= lly where community input is needed. =C2=A0I think we might even be comin= g close to being able to answer that question. >=20 > And by the way, in that dialog about FTP, I think the answer to Roman=E2= =80=99s query seems pretty clear in rough consensus terms, even if conver= sation has been=E2=80=A6 wide ranging. =C2=A0Is that level of noise ok in= this context? >=20 > We talked about hypotheticals at the last meeting. =C2=A0Here are two t= o bracket this discussion: >=20 > * A change people would generally like (everyone who submits an RFC t= o the queue gets an ice cream) Knowing our community, we would soon get 98 messages about the preferred = flavour of ice cream, followed by another 98 about the preferred spelling= of "flavour". But isn't that the price we have collectively decided to p= ay for technical decisions, rather than voting? Why should it be differen= t for editorial strategy? > * A change people would generally not like (output encoding to be EBC= DIC). > * A change that seems okay but might need seem tweaking (output encod= ing to Unicode v-Next). >=20 > And a caution. =C2=A0It may be good to allow some fluid operating metho= ds if there is a WG model, as consensus may be trickier in some instances= to find than in others. Yes. But again, we have exactly that problem in technical WGs, and a hist= ory of using a pragmatic approach to resolving it. Brian From nobody Fri Nov 27 12:23:54 2020 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 CEEF43A0AF9 for ; Fri, 27 Nov 2020 12:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 mcQONSCC4VYx for ; Fri, 27 Nov 2020 12:23:51 -0800 (PST) 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 167593A0E67 for ; Fri, 27 Nov 2020 12:23:50 -0800 (PST) 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 0ARKNkaL002951; Fri, 27 Nov 2020 20:23:46 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 394AB2203C; Fri, 27 Nov 2020 20:23:46 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id 2380E22032; Fri, 27 Nov 2020 20:23:46 +0000 (GMT) Received: from LAPTOPK7AS653V ([195.166.134.111]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0ARKNWD2031402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Nov 2020 20:23:44 GMT Reply-To: From: "Adrian Farrel" To: "'Brian E Carpenter'" , "'Eliot Lear'" , "'Carsten Bormann'" Cc: References: <9D0D4CBA-677A-410F-95F3-5C452970B842@tzi.org> <88B51C37-9DD1-42B1-AE71-26B279A8CB1E@cisco.com> <468c74fe-1bdf-08e8-99a3-b8c6376d811b@gmail.com> In-Reply-To: <468c74fe-1bdf-08e8-99a3-b8c6376d811b@gmail.com> Date: Fri, 27 Nov 2020 20:23:30 -0000 Organization: Old Dog Consulting Message-ID: <052d01d6c4fb$3405f790$9c11e6b0$@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 Thread-Index: AQLHBe6V49ZmeBVY+0/71IElyp1ewgHEwq5SActiqcen32i/EA== Content-Language: en-gb X-Originating-IP: 195.166.134.111 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25816.002 X-TM-AS-Result: No--5.774-10.0-31-10 X-imss-scan-details: No--5.774-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25816.002 X-TMASE-Result: 10--5.774200-10.000000 X-TMASE-MatchedRID: QfHZjzml1E/xIbpQ8BhdbLIGMNfiwa5N4GUI7stBirpLjXXGQy6nlCj5 3aEB5qDLrniTHHylWEx1jYNX3WIaFLZi82whfl/XMiMrbc70PffFdEMoTK7bMSNBWGZQkFR8pur QOvjX+YQjWb4w1a6vZN6Uoj2d4Up/1NhATl9WiiE5y1daw17SpW0TAJ1EuNBm5CL5Q9KAbJby0O MMa4h0v6G2av8NTWSXzzU2+MLrDVQdTvK9m3LsxiqRJ4M9q7OvwEM6ofA+CGObKItl61J/ySKve Q4wmYdM3UZhrlpuBAXQLWxBF9DMQcRB0bsfrpPIfiAqrjYtFiSDjjMaPWkhLv9dbobfp+QQssho i2h1WXdFPNqv4nkQUH7cGd19dSFd X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Community input 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, 27 Nov 2020 20:23:53 -0000 We have a draft for every occasion... >> We talked about hypotheticals at the last meeting. Here are two to >> bracket this discussion: >>=20 >> * A change people would generally like (everyone who submits an RFC >> to the queue gets an ice cream) > > Knowing our community, we would soon get 98 messages about the > preferred flavour of ice cream, followed by another 98 about the = preferred > spelling of "flavour". But isn't that the price we have collectively = decided to > pay for technical decisions, rather than voting? Why should it be = different > for editorial strategy? I should point you at = https://www.ietf.org/archive/id/draft-farrel-problem-protocol-icrm-00.txt= Adrian From nobody Fri Nov 27 12:28:08 2020 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 877773A0E70 for ; Fri, 27 Nov 2020 12:28:07 -0800 (PST) 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 JE7sBfkKeATn for ; Fri, 27 Nov 2020 12:28:06 -0800 (PST) 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 213293A0E6F for ; Fri, 27 Nov 2020 12:28:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9C14E300ADB for ; Fri, 27 Nov 2020 15:28:03 -0500 (EST) 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 dSYJpLQ65ikZ for ; Fri, 27 Nov 2020 15:28:02 -0500 (EST) 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 A1307300670; Fri, 27 Nov 2020 15:28:02 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: Date: Fri, 27 Nov 2020 15:28:03 -0500 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A34B713-E013-4A36-9296-694F07EC5AC5@cisco.com> <04e901d6c4da$192afa90$4b80efb0$@olddog.co.uk> To: Eliot Lear X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Rfced-future] ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 27 Nov 2020 20:28:08 -0000 Eliot: Without knowing who makes the consensus calls for a "strategic body", I = cannot agree to anything you have said about that body. > =E2=80=A2 The chairs think there is likely rough consensus that the = RS[EA] does not direct the RPC/REP. I think that there is rough consensus that the IETF LLC holds the = contract for the RPC and RFC Publisher, and both of these may reach out = to the RS[EA] for advice. Not clear whether you meant that or not. Russ From nobody Fri Nov 27 12:37:39 2020 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 2F2E93A0E7D for ; Fri, 27 Nov 2020 12:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKunkde1Vg08 for ; Fri, 27 Nov 2020 12:37:36 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 C674B3A0E7A for ; Fri, 27 Nov 2020 12:37:36 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id f17so5155365pge.6 for ; Fri, 27 Nov 2020 12:37:36 -0800 (PST) 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=w2V+LIoxbAYINRazzrJn7kHt0jxAGm+hUlLHgMcHh5k=; b=iRQYtOGUFPTIDsEB2cRghUGLhI+nEJDj7LJK6eOMiPn0K4PLu/+lQkgvDPNxISs0K3 7T+/+VpNZp9Kty9NpE72ijnTRaRUpXKYTO16w9uQq5P+6YCBsfg/QddL1ZkEdF0MEYG2 oIhbDHsQZYksZk7WNdPhgFpJf7n6AgIr0m2MwBnUknYjamVGWtHFR7gn2JitSXm1YJPF SA6Oj0JSiXvAy3/FeP5CyWoektMoa5vkbZeb7lxhCdiJKTBMrbvw7rDYAjUzgxeihchi ymw/9Q/aLTohZZX9uil4SUGXZDPRxo7cyl41I4IL13cRBxGu1UYpvauoKcCpDTNtpRuY DOMg== 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=w2V+LIoxbAYINRazzrJn7kHt0jxAGm+hUlLHgMcHh5k=; b=bbuZQ6UQLRVQ8NoQphHpdvqYNHmYLXhGx7vCFapkQWdsM8I3AxZ2NLbhFV62Cwmn6R lCdyNokGbRuWMwyXxxpgBZMlyD47U3eR3fE7vZjl9D/s5fuCaXEBcRPyzEMZQVStAwsA pqNYFYQwDpYfSuYSFdpS/LzPimkZnAoyz4mZLTAsJ3V5Lm8obFTeu5HYOqijSnCnMQ+4 7+XRisiF1LVXLdkyxCb1TW7Z6hibtJqZs8CPofojP3wtnhxKU/F9O8Zy+ULJWaajPMOG bFXtzto0IPKVsvVFAknEZougw25LbKfGgGQvFVKpwdS8l5kjROsClxK+6FGBRckX7Ra6 lc0g== X-Gm-Message-State: AOAM532V7jfPhgx/dtpuYO0C/PcLTLWNtWxvhWKPTO1YV5kk7r83Z382 par9oMu+7xbaYkndgEKdh9fzvPCTP8Qvcg== X-Google-Smtp-Source: ABdhPJy5zKWCIrkyaTqWgAWIQalQ5B8M97Qyx9wVilAVdKwCOtMjITuOWNrBtNKyc4eOs4lFjio9aQ== X-Received: by 2002:a17:90a:a501:: with SMTP id a1mr12244251pjq.4.1606509455712; Fri, 27 Nov 2020 12:37:35 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id gb4sm11635621pjb.30.2020.11.27.12.37.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Nov 2020 12:37:34 -0800 (PST) To: adrian@olddog.co.uk, 'Eliot Lear' Cc: rfced-future@iab.org References: <4A34B713-E013-4A36-9296-694F07EC5AC5@cisco.com> <04e901d6c4da$192afa90$4b80efb0$@olddog.co.uk> <04f701d6c4dc$e7968960$b6c39c20$@olddog.co.uk> From: Brian E Carpenter Message-ID: <457f9ee9-be00-0aa4-dc1a-5cb2fc003b16@gmail.com> Date: Sat, 28 Nov 2020 09:37:30 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <04f701d6c4dc$e7968960$b6c39c20$@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] ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 27 Nov 2020 20:37:38 -0000 On 28-Nov-20 05:46, Adrian Farrel wrote: >>> I found this just a tiny bit ambiguous. I think that, in the context = of the subject line, I can work it out. So, to be clear... >>> >>> =E2=80=A2 The chairs think that there is likely rough consensus that = role of the chair and the RS[EA] should be split. >>> >>> =E2=80=A2 The chairs think we have consensus that the RS[EA] can rais= e issues to the strategic group >>> >>> =E2=80=A2 The chairs think there is likely rough consensus that the R= S[EA] does not make strategic decisions but that those are decided by the= strategic body >>> >>> =E2=80=A2 The chairs think there is likely rough consensus that the R= S[EA] does not direct the RPC/REP. >>> >>> Right? >> >> Right. >=20 > Good, then I'm OK with the first three bullets, but unsure about the la= st one. It covers a rather large area since there are number of things on= which the RPC need advice, guidance, and direction per the helpful email= from Sandy.=20 I think there is some ambiguity about the word "direct". Does it mean "gi= ve orders to" as in "the policeman directed me to put my hands behind my = head", or "give authoritative advice to" as in "Heather directed Sandy to= wards the new edition of the Chicago Manual of Style"? If the former, I'm sure bullet 3 is correct, as orders come from the cust= omer, which is the IETF LLC. If it's the latter, I'm sure it's wrong. So, maybe "direct" is the wrong word. Brian >=20 > This bullet doesn't mention "strategic" and that may be the line. Let's= take something that might be considered less than the most important iss= ue: the style guide. Someone has to make decisions about what is in the s= tyle guide, and the style guide directs the RPC.=20 >=20 > Maybe the strategic body is able to take advice while understanding its= limitations in processing the subject matter. Or maybe, in some matters,= the RS[EA] does direct the RPC. >=20 > Cheers, > Adrian >=20 From nobody Fri Nov 27 13:01:07 2020 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 9F9983A0E8E for ; Fri, 27 Nov 2020 13:01:06 -0800 (PST) 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_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 MhZjmkGoAknP for ; Fri, 27 Nov 2020 13:01:02 -0800 (PST) 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 51CF03A0E8C for ; Fri, 27 Nov 2020 13:01:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4CjRqf0Lq9z6G9fH for ; Fri, 27 Nov 2020 13:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1606510862; bh=Qc9guMbMk8t0A+1V4ImGilTfNgz/S554g3f0h/Pmdn4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Sm8B7pq+lgdTu+KIHyt/W/MH1Y98ZkztfOO6S1hETU5r+OMpLZ6alliZe44wkMZiF /DjoI/yCq41DTcxmkuaCxR1Ci4+j8SBBibEPqQ7HnJOi4StRBFbwEnOs0cbWmh18Ho qdKp16mhIHtd6ezT5flSnruLat8ugRdeYi27CTM0= X-Quarantine-ID: <0W5ASLSTvrpx> X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4CjRqd2f5Yz6G8pH for ; Fri, 27 Nov 2020 13:01:01 -0800 (PST) To: rfced-future@iab.org References: <4A34B713-E013-4A36-9296-694F07EC5AC5@cisco.com> From: "Joel M. Halpern" Message-ID: <7f6844fe-9cc3-0b16-380d-35009278a05d@joelhalpern.com> Date: Fri, 27 Nov 2020 16:01:00 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <4A34B713-E013-4A36-9296-694F07EC5AC5@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 27 Nov 2020 21:01:07 -0000 To me, almost all of these depend upon the construction of the "stragei group". Depending upon how we conclude that should be constructed and operated, different answers as to the relationship to the senior technical publishing advisor (or whatever we call the person) would seem to make sense. In the extreme case, if the strategic group is an IETF working group, with chairs without background in technical publishing, and no mechanism better than the IETF list has to ground the discussions in reality, I have trouble seeing why anyone with the relevant skills would take the job, or even if they did now they could accomplish it. Yours, Joel On 11/27/2020 10:36 AM, Eliot Lear wrote: > As mentioned in the minutes: > > Please let us know if you disagree with any of the following: > > > • The chairs think that there is likely rough consensus that role of the chair and the RS[EA] should be split. > > • The chairs think we have consensus that that person can raise issues to the strategic group > > • The chairs think there is likely rough consensus that the person does not make strategic decisions but that those are decided by the strategic body > > • The chairs think there is likely rough consensus that the person does not direct the RPC/REP. > > > This does not resolve all of issue 12, of course. > > From nobody Fri Nov 27 13:05:31 2020 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 5F4513A0E8C for ; Fri, 27 Nov 2020 13:05:28 -0800 (PST) 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_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 KgTf6HNr4MF3 for ; Fri, 27 Nov 2020 13:05:26 -0800 (PST) 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 A954A3A0E8E for ; Fri, 27 Nov 2020 13:05:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4CjRwk46Pnz6G9Yw for ; Fri, 27 Nov 2020 13:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1606511126; bh=hMhyJo0zjYvINeKvAVDY4OoQs5W7YlDHGAPI9Fc0nuE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=I9oVv/uHUOdN2Se0/6Ntb8VwOWpZW7gX/YDGREyS4qxOP8cDR9TAd9eFty3/kchg0 iN+IHEO4ANHzFgYtKJtlE1YK+T+xCRhHGHcR9fNCAjg7KWI4Q9jFzdo6mK6DEe3p+E SIZgDnxGElhwaEKJ1iOCUIpyShwy30oxAGUOI/Jg= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4CjRwk0t99z6G8pv for ; Fri, 27 Nov 2020 13:05:26 -0800 (PST) To: rfced-future@iab.org References: <5EE071CB-30CA-474F-BFA5-45129FFFFCBA@cisco.com> From: "Joel M. Halpern" Message-ID: <3689021a-b3b2-0baa-7463-45b677c72846@joelhalpern.com> Date: Fri, 27 Nov 2020 16:05:25 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <5EE071CB-30CA-474F-BFA5-45129FFFFCBA@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] **Consensus check on part of Issue 13: Is decision making in the strategy body open to all?** 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, 27 Nov 2020 21:05:28 -0000 I do not understand the third point below. If the strategic body is open to everyone to participate in, then that seems to be the answer to "how is it composed". With a stronger senior technical publishing advisor than we seem to be moving towards, I can see how that can work. But if this body owns the whole strategic task, I think what you describe is a recipe for failure over time. Sure, we can make it work for a while. We are making the current setup work for a while. But our goal is a long term structure, and I just don't see it working well. Given the number of working groups I have seen where strong differences in philosophy have practically paralyzed the working group, combined with the strong differences in philosophy I have seen in this group, I have trouble getting my head around how this is expected to actually work. Having said that I will reiterate that having a means for community participation that is a serious part of the process seems to me to be a good thing. I am not saying "go away and let the experts do this behind closed doors." Yours, Joel On 11/27/2020 10:39 AM, Eliot Lear wrote: > Please let us know in within the next three weeks if you disagree with any of the following: > > • The chairs think that everybody agrees that there is some strategic body > > • The chairs think that strategic decisions get documented in RFCs > > • The chairs think that there is consensus that the strategic body is open to all to engage openly, and that meetings should be open, minuted, agendas posted. This is not to say that there is consensus about how the strategic body is composed. > > These points obviously do not close Issue 13. > > From nobody Fri Nov 27 21:02:31 2020 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 22D173A0F0C; Fri, 27 Nov 2020 21:02:30 -0800 (PST) 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.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160653974994.12259.12100973874618348178@ietfa.amsl.com> Date: Fri, 27 Nov 2020 21:02:30 -0800 Archived-At: Subject: [Rfced-future] RFC Editor Future Development (rfcefdp) PROGRAM Virtual Meeting: 2020-12-18 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: Sat, 28 Nov 2020 05:02:30 -0000 The RFC Editor Future Development (rfcefdp) Program will hold a virtual interim meeting on 2020-12-18 from 00:00 to 01:30 Europe/Zurich (23:00 to 00:30 UTC on 2020-12-17). Agenda: Continue on Issues 12, 24, 13. Maybe touch further on Issue 14. Information about remote participation: https://cisco.webex.com/cisco/j.php?MTID=m46c39cb3ba692f4478c24819c0fbe54a From nobody Sat Nov 28 02:12:07 2020 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 383963A09CF for ; Sat, 28 Nov 2020 02:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 KgFXNs611Asp for ; Sat, 28 Nov 2020 02:12:03 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A7A3A09C4 for ; Sat, 28 Nov 2020 02:12:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3323; q=dns/txt; s=iport; t=1606558323; x=1607767923; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=8c9e/3Rix61IIbtAHTuJ9ho6qt+AnW70ipA9oXvdGe4=; b=jz4VacLayfI1kUfUwvDCaTNNtzzDAdc1IwauKytkRY6XVLiluxRxXcvE BUMGisFqrY0kyalZyvu+jWpQh2sAZy6ds8nWWNT/5+Eubj7UsWvkoVevk C0LecGNylTq2H04sT7QOgQukY4mha3KpYfXu3X3pV6lH2sWwuWG9llpfJ g=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BdAAAXIsJf/xbLJq1iHAEBAQEBAQcBARIBAQQEAQGBf?= =?us-ascii?q?QUBAQsBgimBSwEgEi6EPYkFh3onihaQHhSBaAQHAQEBCgMBAS8EAQGESgKCK?= =?us-ascii?q?iY2Bw4CAwEBAQMCAwEBAQEFAQEBAgEGBHGFbYVyAQEBAwEjVgULCQIYIwcCA?= =?us-ascii?q?iE2BhODJgGCVQMOIJMTmxJ2gTKFV4I4DYIUEIE4AYFSjAiCAIE4DBCCJy4+g?= =?us-ascii?q?huBbgESAYM4M4IsBJxgmzNXgnqDHYE3iyyGFYUXAx+iFKFfjwuDagIEBgUCF?= =?us-ascii?q?YFcATNncDMaCBsVZQGCPj4SGQ2OWI4TQAMwAjUCBgEJAQEDCY9sAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,377,1599523200"; d="asc'?scan'208";a="31472920" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Nov 2020 10:11:59 +0000 Received: from dhcp-10-61-102-28.cisco.com (dhcp-10-61-102-28.cisco.com [10.61.102.28]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0ASABw9Q018601 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 28 Nov 2020 10:11:58 GMT From: Eliot Lear Message-Id: <108359F4-D858-4617-8AC7-3ECF4809833B@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_ABC6D8D8-74BC-496E-A5B5-F153B1AD0AE4"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 28 Nov 2020 11:11:57 +0100 In-Reply-To: <457f9ee9-be00-0aa4-dc1a-5cb2fc003b16@gmail.com> Cc: adrian@olddog.co.uk, rfced-future@iab.org To: Brian E Carpenter References: <4A34B713-E013-4A36-9296-694F07EC5AC5@cisco.com> <04e901d6c4da$192afa90$4b80efb0$@olddog.co.uk> <04f701d6c4dc$e7968960$b6c39c20$@olddog.co.uk> <457f9ee9-be00-0aa4-dc1a-5cb2fc003b16@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.102.28, dhcp-10-61-102-28.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Rfced-future] ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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: Sat, 28 Nov 2020 10:12:05 -0000 --Apple-Mail=_ABC6D8D8-74BC-496E-A5B5-F153B1AD0AE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Good morning/evening both of you, > On 27 Nov 2020, at 21:37, Brian E Carpenter = wrote: >=20 > On 28-Nov-20 05:46, Adrian Farrel wrote: >>>> I found this just a tiny bit ambiguous. I think that, in the = context of the subject line, I can work it out. So, to be clear... >>>>=20 >>>> =E2=80=A2 The chairs think that there is likely rough consensus = that role of the chair and the RS[EA] should be split. >>>>=20 >>>> =E2=80=A2 The chairs think we have consensus that the RS[EA] can = raise issues to the strategic group >>>>=20 >>>> =E2=80=A2 The chairs think there is likely rough consensus that the = RS[EA] does not make strategic decisions but that those are decided by = the strategic body >>>>=20 >>>> =E2=80=A2 The chairs think there is likely rough consensus that the = RS[EA] does not direct the RPC/REP. >>>>=20 >>>> Right? >>>=20 >>> Right. >>=20 >> Good, then I'm OK with the first three bullets, but unsure about the = last one. It covers a rather large area since there are number of things = on which the RPC need advice, guidance, and direction per the helpful = email from Sandy. >=20 > I think there is some ambiguity about the word "direct". Does it mean = "give orders to" as in "the policeman directed me to put my hands behind = my head", or "give authoritative advice to" as in "Heather directed = Sandy towards the new edition of the Chicago Manual of Style"? >=20 > If the former, I'm sure bullet 3 is correct, as orders come from the = customer, which is the IETF LLC. If it's the latter, I'm sure it's = wrong. >=20 Yes, just to be clear, we are talking in the negative here. So=E2=80=A6 = =E2=80=9CThe RS[EA] does not direct me to put my hands on my head=E2=80=9D= ;-) or perhaps more apposite: =E2=80=9CThe RS[EA] does not order the = staff to take specific actions. That person may offer guidance in = specific situations, but is not in the chain of command.=E2=80=9D Is there general agreement on what I just wrote? As to the style guide, perhaps that=E2=80=99s a separate issue or a good = more-than-hypothetical to work out. Is it maintained by the RPC with = guidance of the RS[EA]? Is it maintained by the strategic body? Is it = maintained by the RS[EA]? Does that need to be specified here or by the = strategic body? Eliot --Apple-Mail=_ABC6D8D8-74BC-496E-A5B5-F153B1AD0AE4 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/CIm0ACgkQh7ZrRtnS ejNYaAgA06HUoaqGkWLzr+LTgKCwiJJxJnIGjob9QU0WUS8iQOscFWiCeaCTiNyu vFm4xNXJ4L+Vp8/LFBk+xrkwQQwrSLEEDoQYSyd7xXZlnBMsRMjODAsneIIG4D3g NWOb0PIrP5XuXhyIcMGX68bTVh/QoN6iFyoUBszqLcNV39Je+7sjdiKs6X7E4c+P 3Dp5wVrqtQGRGbACqzKkxMDzBog6LGw7LVLAKtum5Ct4sqigclhqKU5o5oglogXZ DffjuwhxO+p+tdpI4GfzXZAe9/AGDOg/PfkGaMU4B9eIB+IFfVfEptWRYjJ/XpbN hmrSzXVeLM/3ka0XIJoplKU6X6EFnA== =SJVp -----END PGP SIGNATURE----- --Apple-Mail=_ABC6D8D8-74BC-496E-A5B5-F153B1AD0AE4-- From nobody Sat Nov 28 03:04:51 2020 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 ADC783A0A87 for ; Sat, 28 Nov 2020 03:04:49 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-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 qXToPEgnXFxZ for ; Sat, 28 Nov 2020 03:04:47 -0800 (PST) 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 A5A793A0995 for ; Sat, 28 Nov 2020 03:04:46 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0ASB4eJj031478; Sat, 28 Nov 2020 11:04:40 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3115F2203B; Sat, 28 Nov 2020 11:04:40 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS id 1C1E82203A; Sat, 28 Nov 2020 11:04:40 +0000 (GMT) Received: from LAPTOPK7AS653V ([195.166.134.111]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0ASB4cO1012049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 28 Nov 2020 11:04:39 GMT Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , "'Brian E Carpenter'" Cc: Date: Sat, 28 Nov 2020 11:04:38 -0000 Organization: Old Dog Consulting Message-ID: <058501d6c576$43e4cfd0$cbae6f70$@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 Thread-Index: AdbFdkHy85U6SeOtQl2OgLR5tlLUrw== Content-Language: en-gb X-Originating-IP: 195.166.134.111 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25816.007 X-TM-AS-Result: No--11.859-10.0-31-10 X-imss-scan-details: No--11.859-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25816.007 X-TMASE-Result: 10--11.858900-10.000000 X-TMASE-MatchedRID: Eouh3vgZL4pq0U6EhO9EEyEyJ8xFEVolkW0zU11KKK07S7kQJT05JFiq Ayk7LkbkVhi48c2D9TeBRNVuc6Ppa226mUgLn3m/jrcVcgNMnovg02I3oyGU8CATiLvsSv4cDE1 Y/wJPx0sqegugNzsJfXH5R0bnYPNvhnBMPbxjCXR9r3RiYxSnPct3zHe6QppeIFWQH/JudNgqdH ODFD1EcnKvZBcntMqp9ims4cVMXfI6k8DwKL1tBIxwx0FSBgmNAp+UH372RZWWX300fYYVq70R7 AVPYalKmmgWMJS+ZT66j782+DQgoWl4Bykl/FQe2bpX2XJNwqEEa8g1x8eqFwg2kgWdt3qaP1P+ cNLm2bhuG10X5NZAwIlDrJWpFiaIp/RCY+priR6h4ILTlgBL0fg/s23WPBIpUHcBn70iJQfj9MX Trwp7Rfi/h8b7a0vRZV33nMkX4spvN14bTs89YPlZlPYYWH6d4B4Qje1seFVawoq5zq9PrNNZnq bwOWHjEuJtD6Cp80OjXgj0HIY8Aoxpy4UOhqKryf21YeIsPYYHmzHO3TfA+MuSXx71bvSLZshp/ ob4pluRkwGirjQk298fGcd5SSodJie+OrUoVcdgqbvjZaUg3gHgke2JqaQs3SL+X3YJA7WYpuG7 kpoKR9xQHjHEE9Oi6QWSh/rmuC3X/CwwaUemurXkpFHAEbgzF9s8UTYYetVrvf5eVgMu7MqEPxI kcXd02kAb/mrv4wtftuJwrFEhTbew1twePJJBKzfM9B6IRt76C0ePs7A07YVH0dq7wY7uGf3MS5 o4yLfX7YH+OGOLJH2yHnX4/lCALf3HBTG3pBTitqfCydAvbg== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Rfced-future] Style guide and other non-strategic things ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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: Sat, 28 Nov 2020 11:04:50 -0000 Tweaking the subject line since I *think* he have travelled out of the = "strategic" zone. That is, the style guide is something with long term effects, but its = implementation is very much document-by-document. Let's take this a step closer to the everyday... The RPC edits a document, the authors object to one of the edits = claiming the RPC's understanding of the English language is incorrect: = who arbitrates or makes the final decision? I can be happy with many answers to that question, but would point out = that historically, someone has been paid to do that work. There is, IMHO, a difference between having a go-to backstop who ensures = consistency and is responsible for decisions, and having someone to whom = you can go for advice. In the first case the RPC is paid to try, and the = backstop is paid to hold the line. In the second case, the RPC is paid = to hold the line, and someone is paid to give advice.=20 It's a small thing, but it is a realignment of 'powers' and should have = a consequent redistribution of financial resources. Cheers, Adrian -----Original Message----- From: Eliot Lear =20 Sent: 28 November 2020 10:12 To: Brian E Carpenter Cc: adrian@olddog.co.uk; rfced-future@iab.org Subject: Re: [Rfced-future] ** Consensus check on part of Issue 12: Is = the person an advisor (RSA) or an Executive Editor (RSE) ** Good morning/evening both of you, > On 27 Nov 2020, at 21:37, Brian E Carpenter = wrote: >=20 > On 28-Nov-20 05:46, Adrian Farrel wrote: >>>> I found this just a tiny bit ambiguous. I think that, in the = context of the subject line, I can work it out. So, to be clear... >>>>=20 >>>> =E2=80=A2 The chairs think that there is likely rough consensus = that role of the chair and the RS[EA] should be split. >>>>=20 >>>> =E2=80=A2 The chairs think we have consensus that the RS[EA] can = raise issues to the strategic group >>>>=20 >>>> =E2=80=A2 The chairs think there is likely rough consensus that the = RS[EA] does not make strategic decisions but that those are decided by = the strategic body >>>>=20 >>>> =E2=80=A2 The chairs think there is likely rough consensus that the = RS[EA] does not direct the RPC/REP. >>>>=20 >>>> Right? >>>=20 >>> Right. >>=20 >> Good, then I'm OK with the first three bullets, but unsure about the = last one. It covers a rather large area since there are number of things = on which the RPC need advice, guidance, and direction per the helpful = email from Sandy. >=20 > I think there is some ambiguity about the word "direct". Does it mean = "give orders to" as in "the policeman directed me to put my hands behind = my head", or "give authoritative advice to" as in "Heather directed = Sandy towards the new edition of the Chicago Manual of Style"? >=20 > If the former, I'm sure bullet 3 is correct, as orders come from the = customer, which is the IETF LLC. If it's the latter, I'm sure it's = wrong. >=20 Yes, just to be clear, we are talking in the negative here. So=E2=80=A6 = =E2=80=9CThe RS[EA] does not direct me to put my hands on my = head=E2=80=9D ;-) or perhaps more apposite: =E2=80=9CThe RS[EA] does not = order the staff to take specific actions. That person may offer = guidance in specific situations, but is not in the chain of = command.=E2=80=9D Is there general agreement on what I just wrote? As to the style guide, perhaps that=E2=80=99s a separate issue or a good = more-than-hypothetical to work out. Is it maintained by the RPC with = guidance of the RS[EA]? Is it maintained by the strategic body? Is it = maintained by the RS[EA]? Does that need to be specified here or by the = strategic body? Eliot From nobody Sat Nov 28 10:53:11 2020 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 223253A0FB5 for ; Sat, 28 Nov 2020 10:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, 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 cEfKKh300OAA for ; Sat, 28 Nov 2020 10:53:08 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 A17323A0EBE for ; Sat, 28 Nov 2020 10:53:08 -0800 (PST) Received: from xse366.mail2web.com ([66.113.197.112] helo=xse.mail2web.com) by mx128.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kj5LD-000ZD8-Qv for rfced-future@iab.org; Sat, 28 Nov 2020 19:53:05 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4Ck0mW39nFzL89 for ; Sat, 28 Nov 2020 10:45:15 -0800 (PST) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kj5Df-0004RG-Aa for rfced-future@iab.org; Sat, 28 Nov 2020 10:45:15 -0800 Received: (qmail 16186 invoked from network); 28 Nov 2020 18:45:14 -0000 Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.58.46.151]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Nov 2020 18:45:14 -0000 To: adrian@olddog.co.uk, 'Eliot Lear' , 'Brian E Carpenter' Cc: rfced-future@iab.org References: <058501d6c576$43e4cfd0$cbae6f70$@olddog.co.uk> From: Christian Huitema Message-ID: Date: Sat, 28 Nov 2020 10:45:15 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <058501d6c576$43e4cfd0$cbae6f70$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 66.113.197.112 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0fJVsTFCFA1YlcTpjJcy6PSpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjRzgyua+oKUgQGcbmeu+KPhY RkpFG1KU35iPF8F1Y4gWf4Xo3Kfg1pFBAjKFVaNZQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEkCyqCRM97FQO8waqZwM6Te42Vki7412dpbhrD2d47zbC3VvU djSCswikK/licfX+oIF6uBSWByrPG2Vxuo/vVPllrFEbCkMryfcYCsgMUJObfBQoU3roWy2GH1DY sAiH3gousbgNfxi2R3uFLvZP/HBXvrLBlKCVRjjdPbjQ4HnBNho1Lszw5OO01yYoll8q2UgzFF+j HNSbIoW1Q++Wvj3dKxLhoxcmaInYbR5vlqFg3eKzPG9E5MikC2dVXWcpK172i/E5sOgbaCtBiSIx 1XwCY8vmv+JqOVJamBHfOGVwjn7Xut/lXagsodd5qqODTFiwcpU4fyz75jxpU98RPGiH1Wgh6RAe nBR+licROGbXNqJfz6msVASTB+MD+1/p7GPMfR4JPnPUgCtpcJi9K4AvRC+AV6HrbheR6y3uKvWS ax8yVT5LNQc0pviCIZ+V87H2ECndxkpBwp1FkQyHa0qTD2ipD9y2znxCv9uYkc8RFZ4oobg8BBg3 Jq+ntzj07SEhpLiNl9wJtJvL/MBQhw9mDnaXtu0kZC/OWmUorWg366yWFgMNzvtxuarD/PDK6Ztq Y6YdTdmipN9V5DhzGXW8TfMUfXZNQGXIjuXCLLoqAa5C2HRitUAsSGZrlTrWz1caQoi44Wcfj1z/ J5tTt7j1ptfltBQnq8NvNwuG6kuhBG0YWFj/7xYZzwR7/PiKfowXlsolACJrkW/vjDp2NmSdEOMf tBjsWb6BDQzjSsG66974nkMwEqjhfSKHlA2Q3p5onVdn12r9xqR15ROHBesyXD9BkbKX7eGI2jGt /RQxL7hrJSk60SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] Style guide and other non-strategic things ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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: Sat, 28 Nov 2020 18:53:10 -0000 On 11/28/2020 3:04 AM, Adrian Farrel wrote: > Tweaking the subject line since I*think* he have travelled out of the "strategic" zone. > That is, the style guide is something with long term effects, but its implementation is very much document-by-document. > Let's take this a step closer to the everyday... > The RPC edits a document, the authors object to one of the edits claiming the RPC's understanding of the English language is incorrect: who arbitrates or makes the final decision? > I can be happy with many answers to that question, but would point out that historically, someone has been paid to do that work. > > There is, IMHO, a difference between having a go-to backstop who ensures consistency and is responsible for decisions, and having someone to whom you can go for advice. In the first case the RPC is paid to try, and the backstop is paid to hold the line. In the second case, the RPC is paid to hold the line, and someone is paid to give advice. > > It's a small thing, but it is a realignment of 'powers' and should have a consequent redistribution of financial resources. That's a good way of framing the issue, Adrian. I personally lean towards the RPC holding the line, because it makes the overall workflow simpler and does not dilute responsibilities. Also, I am not aware of past cases in which the RSE had to overrule the RPC. Do we have examples of such incidents? -- Christian Huitema From nobody Sat Nov 28 13:52:12 2020 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 DB60C3A0317 for ; Sat, 28 Nov 2020 13:52:11 -0800 (PST) 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 ErkblU_x2PKg for ; Sat, 28 Nov 2020 13:52:10 -0800 (PST) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450: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 949423A02DC for ; Sat, 28 Nov 2020 13:52:09 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id v14so12632412lfo.3 for ; Sat, 28 Nov 2020 13:52:09 -0800 (PST) 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=IeTaX8GzuFcTKnIQgzM/p08hVc4MgiT4DehWwZZx/8I=; b=eK6qMcLBkEjqAI6QruxDdny1XwmmUyclTBPLRpvyq8Uz3NZoJ56a7YcqOXFhlla1nv BJRniNQQChZUp+Ts/e5ELYBlZd7m8UDI54Y0C/1uRZK8XmDCHa4TnlY/3AA4Afi8mFME M+3TTyjZIbZm7ZO0Lj/Oo6WLSGNn2xT4dDwdCYY8TwJEzt2BJ5CnDR5lTZnk7HtAgt4z 5f3YCp2oQKKPJGGF0Ju8Ry/6whXFIipOLl/jfK7obWP5CuUgwz2k1jRS4cp5DOWX8txd BXssIJy/a9Gq0MzPPFPoiSKwQmOWII8XckOz4wBkQehUR2pRaKVLftCSk3wyLW4Ww0b0 MoDQ== 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=IeTaX8GzuFcTKnIQgzM/p08hVc4MgiT4DehWwZZx/8I=; b=DyvlNnT9uZ+eI1EEKPqtxMGf+roitA3TyTsSEnKW3jX53jxcezhqz8m9FfmCKOnax3 rm9cyOav2AbfbH1qCYNWHfOoytqYuF1+IFsc+JgnlP69cC/b1hKApDru/iQJAwRBJEOh ihyGkPABy6+w4fgzS+4G/90W69G/TYfhHmdcmOhhceEh0PWHlHDAxQK2oRrBjRZfkjCX acwu7xa3+EiLdDaSW2HPtS1fte3tttaPo78LLOc9W+dK95fmyLEU2W6HTTqkVrZigcvy TEE9xmtkyHMj2ORDzwlqJuji52COGLnN+9WUzhHcZ+hQT2Fi/wtF4bI6Ep9gpPry3aL4 wZMQ== X-Gm-Message-State: AOAM533gpI/gg4HvsY9YKY/xl7QdGMxM4EBN9/U+hk4pwNzKZ0ll6BNf d6hzIilLRZl3HvZCnS/RHrE0JqKM2ya3Djc49ZFFYA== X-Google-Smtp-Source: ABdhPJxhYYEsxuEbEJ8T7gCwEZBT1H6MZl+i1dNgQbz/T2CCU6mEynwFPl8SC4UoF6CgK4etbJCPSN6lRj5GwaBsZcs= X-Received: by 2002:a05:6512:1090:: with SMTP id j16mr6244607lfg.543.1606600327672; Sat, 28 Nov 2020 13:52:07 -0800 (PST) MIME-Version: 1.0 References: <058501d6c576$43e4cfd0$cbae6f70$@olddog.co.uk> In-Reply-To: From: Eric Rescorla Date: Sat, 28 Nov 2020 13:51:31 -0800 Message-ID: To: Christian Huitema Cc: Adrian Farrel , Eliot Lear , Brian E Carpenter , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000d3cb8d05b531c929" Archived-At: Subject: Re: [Rfced-future] Style guide and other non-strategic things ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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: Sat, 28 Nov 2020 21:52:12 -0000 --000000000000d3cb8d05b531c929 Content-Type: text/plain; charset="UTF-8" On Sat, Nov 28, 2020 at 10:53 AM Christian Huitema wrote: > > On 11/28/2020 3:04 AM, Adrian Farrel wrote: > > Tweaking the subject line since I*think* he have travelled out of the > "strategic" zone. > > That is, the style guide is something with long term effects, but its > implementation is very much document-by-document. > > Let's take this a step closer to the everyday... > > The RPC edits a document, the authors object to one of the edits > claiming the RPC's understanding of the English language is incorrect: who > arbitrates or makes the final decision? > > I can be happy with many answers to that question, but would point out > that historically, someone has been paid to do that work. > > > > There is, IMHO, a difference between having a go-to backstop who ensures > consistency and is responsible for decisions, and having someone to whom > you can go for advice. In the first case the RPC is paid to try, and the > backstop is paid to hold the line. In the second case, the RPC is paid to > hold the line, and someone is paid to give advice. > > > > It's a small thing, but it is a realignment of 'powers' and should have > a consequent redistribution of financial resources. > > > That's a good way of framing the issue, Adrian. I personally lean > towards the RPC holding the line, because it makes the overall workflow > simpler and does not dilute responsibilities. Also, I am not aware of > past cases in which the RSE had to overrule the RPC. Do we have examples > of such incidents? > I actually prefer a third version: the stream manager should be the ultimate decision maker, just as they are about the technical content of the document. For the IETF stream this will typically be the responsible AD on behalf of the IESG. -Ekr --000000000000d3cb8d05b531c929 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    =
    On Sat, Nov 28, 2020 at 10:53 AM Chri= stian Huitema <huitema@huitema.ne= t> wrote:

    On 11/28/2020 3:04 AM, Adrian Farrel wrote:
    > Tweaking the subject line since I*think*=C2=A0 he have travelled out o= f the "strategic" zone.
    > That is, the style guide is something with long term effects, but its = implementation is very much document-by-document.
    > Let's take this a step closer to the everyday...
    > The RPC edits a document, the authors object to one of the edits claim= ing the RPC's understanding of the English language is incorrect: who a= rbitrates or makes the final decision?
    > I can be happy with many answers to that question, but would point out= that historically, someone has been paid to do that work.
    >
    > There is, IMHO, a difference between having a go-to backstop who ensur= es consistency and is responsible for decisions, and having someone to whom= you can go for advice. In the first case the RPC is paid to try, and the b= ackstop is paid to hold the line. In the second case, the RPC is paid to ho= ld the line, and someone is paid to give advice.
    >
    > It's a small thing, but it is a realignment of 'powers' an= d should have a consequent redistribution of financial resources.


    That's a good way of framing the issue, Adrian. I personally lean
    towards the RPC holding the line, because it makes the overall workflow simpler and does not dilute responsibilities. Also, I am not aware of
    past cases in which the RSE had to overrule the RPC. Do we have examples of such incidents?

    I actually prefer a = third version: the stream manager should be the ultimate decision maker, ju= st as they are about the technical content of the document. For the IETF st= ream this will typically be the responsible AD on behalf of the IESG.

    -Ekr


    --000000000000d3cb8d05b531c929-- From nobody Sat Nov 28 13:58:13 2020 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 0397B3A0DFC for ; Sat, 28 Nov 2020 13:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 U_T2uOiEyNmR for ; Sat, 28 Nov 2020 13:58:10 -0800 (PST) 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 254AF3A02BB for ; Sat, 28 Nov 2020 13:58:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4Ck5356Rrlz1nvJq; Sat, 28 Nov 2020 13:58:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1606600689; bh=YUZe8Cwy4lItqGK4BI91MtNHajUeaf6s02cB+vCPo1M=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=aFVko9jUI4hLzw5YyNro07wEYQRjt8NXzDfmyVHDVBqWzOm/xODE1gqjRAZSGp2zh uFalhe0wovKMW+U6RR0bNkaonpgrGpg1kswY8LLtX3TmR/yjYlUoY70g0WnT4tQnTs g4/aF2g3P+dgQsEcaWHcUCRlB3Va1/0oO6KC+qHQ= X-Quarantine-ID: <4-zjbHSau3yl> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4Ck5352DRlz1ntnl; Sat, 28 Nov 2020 13:58:09 -0800 (PST) To: Eric Rescorla Cc: rfced-future@iab.org References: <058501d6c576$43e4cfd0$cbae6f70$@olddog.co.uk> From: "Joel M. Halpern" Message-ID: Date: Sat, 28 Nov 2020 16:58:07 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] Style guide and other non-strategic things ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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: Sat, 28 Nov 2020 21:58:12 -0000 1) If the stream managers are the final authority, then different streams will get different answers, reducing the coherence and consistency of the series. That does not seem beneficial. 2) As a minor matter, the individual ADs are not the stream manager for the IETF stream. Traditional, the IETF chair has been the stream manager. I hope that the IESG has adopted a policy of appointing a separate individual stream manager. But there are not 13 stream managers for the IETF stream. And there should not be, as it would render the notion of "stream manager" rather odd. Yours, Joel On 11/28/2020 4:51 PM, Eric Rescorla wrote: > > > On Sat, Nov 28, 2020 at 10:53 AM Christian Huitema > wrote: > > > On 11/28/2020 3:04 AM, Adrian Farrel wrote: > > Tweaking the subject line since I*think*  he have travelled out > of the "strategic" zone. > > That is, the style guide is something with long term effects, but > its implementation is very much document-by-document. > > Let's take this a step closer to the everyday... > > The RPC edits a document, the authors object to one of the edits > claiming the RPC's understanding of the English language is > incorrect: who arbitrates or makes the final decision? > > I can be happy with many answers to that question, but would > point out that historically, someone has been paid to do that work. > > > > There is, IMHO, a difference between having a go-to backstop who > ensures consistency and is responsible for decisions, and having > someone to whom you can go for advice. In the first case the RPC is > paid to try, and the backstop is paid to hold the line. In the > second case, the RPC is paid to hold the line, and someone is paid > to give advice. > > > > It's a small thing, but it is a realignment of 'powers' and > should have a consequent redistribution of financial resources. > > > That's a good way of framing the issue, Adrian. I personally lean > towards the RPC holding the line, because it makes the overall workflow > simpler and does not dilute responsibilities. Also, I am not aware of > past cases in which the RSE had to overrule the RPC. Do we have > examples > of such incidents? > > > I actually prefer a third version: the stream manager should be the > ultimate decision maker, just as they are about the technical content of > the document. For the IETF stream this will typically be the responsible > AD on behalf of the IESG. > > -Ekr > > > From nobody Sat Nov 28 14:08:36 2020 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 C7F523A03F5 for ; Sat, 28 Nov 2020 14:08:34 -0800 (PST) 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 TmUjpCTyUpMo for ; Sat, 28 Nov 2020 14:08:33 -0800 (PST) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 989113A03F3 for ; Sat, 28 Nov 2020 14:08:32 -0800 (PST) Received: by mail-lj1-x243.google.com with SMTP id 142so10483342ljj.10 for ; Sat, 28 Nov 2020 14:08:32 -0800 (PST) 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=NcHW2WSPeC5ywCraXvHMOns+SrpaIRehP2DypObDijk=; b=j11XmpD15QfCWHEpmTAEWAwL4pwsPy7SREHq1vUQxDp6HsxkhVsBAIY1V8HacKJSzi wLbJ3vwE0Z6WeRa7DeFcalaY0iDfGPekQUaMe7TcNJ+Z10fZBG0OI3HvUiIjgQ47c0G1 RWfbha22vKgD/5mQdNjarzfXrNOUy4e9Cz/WXTRJS8+cjZQsQaLX+VWL2/DHKRZ5Wxjr 0uah+TvoGYzB6NPUM9tqVjFNuClEt8OKQ8RlW/UotaNyRinCNx0Wccn1kCDAr0KVL6ld fGScQlbAXUv6HAamNlTv8noK+mGLRWHUdJMO3+9rsr1aen6QjK/0/AC7/w+oynDlegUE UCRQ== 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=NcHW2WSPeC5ywCraXvHMOns+SrpaIRehP2DypObDijk=; b=V3Q1jwiJqb3zhEvaf4pptgT+u7S0/zOE4gmKuHx8ASVIiJ01X/4fgsaMEcejeXTjKx EFdxszxfeOzM0bnd85izJhk2aQobH0XYaxMSWfHEQ2MFHHljfHUd5CDRQdEMAlgVOnSA G1Xcr7krse/zi4iqpLmViA3M9BtdE318+5T3MT3q+092ZEpltEm4CE6t40TGibSVA65I ZpIGQEwrhX1vqidgbmWx3bLJiPPwnHkoNhbPIXPM8dv1pYlURjHehErynielx4NktCTd 8FoWEmaaabhKa4spk/Z7XSGobwBD5pdXKOKvawhwAExrZN8GygFAz2MhDMRD7lpyXzkn CMCg== X-Gm-Message-State: AOAM533uosO0SVBw8ABSsPcdCPfaPuFh6d596wggqV7YkPBU2zhs9XYr U9NBj8HaMNCzXM+yuUspF+phP8AszspH/Im7xa/l4F+eAQcVgoqD X-Google-Smtp-Source: ABdhPJwdGY6Jeh2eyOq9hEpiD82FLaGP3d6DUxSeAEB8YEL4nn5logrzn6MpK3A+a2QMpdoFIEVFV/JM7i6AqO3IEB0= X-Received: by 2002:a2e:50c:: with SMTP id 12mr6020949ljf.371.1606601310614; Sat, 28 Nov 2020 14:08:30 -0800 (PST) MIME-Version: 1.0 References: <058501d6c576$43e4cfd0$cbae6f70$@olddog.co.uk> In-Reply-To: From: Eric Rescorla Date: Sat, 28 Nov 2020 14:07:54 -0800 Message-ID: To: "Joel M. Halpern" Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000006a70d305b5320429" Archived-At: Subject: Re: [Rfced-future] Style guide and other non-strategic things ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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: Sat, 28 Nov 2020 22:08:35 -0000 --0000000000006a70d305b5320429 Content-Type: text/plain; charset="UTF-8" On Sat, Nov 28, 2020 at 1:58 PM Joel M. Halpern wrote: > 1) If the stream managers are the final authority, then different > streams will get different answers, reducing the coherence and > consistency of the series. That does not seem beneficial. > I suspect that we're simply going to disagree here, but I'll make an attempt to lay out my reasoning. While I think that coherence and consistency are a value, they are not the only value. For instance, we do not encourage the RPC to rewrite the documents extensively to make them read the same. Indeed, the style guide does not standardize British vs. American spelling across the series as a whole [0]. As I'm sure I've said before, from my perspective, the various streams are customers of the RFC series, and ultimately it needs to serve their needs. I believe that this includes allowing the streams to decide not only the technical content but also to a large degree the editorial content. While one might imagine some dispute about style which would be so large that it threatened the character of the series (e.g., the stream wanted to have all its documents published only in Esperanto), in my experience disputes between authors and the RPC are not generally of this nature, and therefore IMOthe stream ought to decide. 2) As a minor matter, the individual ADs are not the stream manager for > the IETF stream. Traditional, the IETF chair has been the stream > manager. I hope that the IESG has adopted a policy of appointing a > separate individual stream manager. But there are not 13 stream > managers for the IETF stream. And there should not be, as it would > render the notion of "stream manager" rather odd. > Yes. This is why I said "the AD on behalf of the IESG". I think this is a practical approach given that the AD already is involved in making publication time decisions such as which changes to the text require extra IETF processing, such as being sent back to the WG. However, I wouldn't object to having this as the IESG's designate if people prefer. -Ekr [0] https://www.rfc-editor.org/rfc/rfc7322.html#section-3.1 On 11/28/2020 4:51 PM, Eric Rescorla wrote: > > > > > > On Sat, Nov 28, 2020 at 10:53 AM Christian Huitema > > wrote: > > > > > > On 11/28/2020 3:04 AM, Adrian Farrel wrote: > > > Tweaking the subject line since I*think* he have travelled out > > of the "strategic" zone. > > > That is, the style guide is something with long term effects, but > > its implementation is very much document-by-document. > > > Let's take this a step closer to the everyday... > > > The RPC edits a document, the authors object to one of the edits > > claiming the RPC's understanding of the English language is > > incorrect: who arbitrates or makes the final decision? > > > I can be happy with many answers to that question, but would > > point out that historically, someone has been paid to do that work. > > > > > > There is, IMHO, a difference between having a go-to backstop who > > ensures consistency and is responsible for decisions, and having > > someone to whom you can go for advice. In the first case the RPC is > > paid to try, and the backstop is paid to hold the line. In the > > second case, the RPC is paid to hold the line, and someone is paid > > to give advice. > > > > > > It's a small thing, but it is a realignment of 'powers' and > > should have a consequent redistribution of financial resources. > > > > > > That's a good way of framing the issue, Adrian. I personally lean > > towards the RPC holding the line, because it makes the overall > workflow > > simpler and does not dilute responsibilities. Also, I am not aware of > > past cases in which the RSE had to overrule the RPC. Do we have > > examples > > of such incidents? > > > > > > I actually prefer a third version: the stream manager should be the > > ultimate decision maker, just as they are about the technical content of > > the document. For the IETF stream this will typically be the responsible > > AD on behalf of the IESG. > > > > -Ekr > > > > > > > --0000000000006a70d305b5320429 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    =
    On Sat, Nov 28, 2020 at 1:58 PM Joel = M. Halpern <jmh@joelhalpern.com> wrote:
    1)= If the stream managers are the final authority, then different
    streams will get different answers, reducing the coherence and
    consistency of the series.=C2=A0 That does not seem beneficial.

    I suspect that we're simply going to disagree = here, but I'll make an attempt
    to lay out my reasoning. While= I think that coherence and consistency are
    a value, they are not= the only value. For instance, we do not encourage
    the RPC to rew= rite the documents extensively to make them read the
    same. Indeed= , the style guide does not standardize British vs.
    American spel= ling across the series as a whole [0].

    As I'm = sure I've said before, from my perspective, the various streams are
    customers of the RFC series, and ultimately it needs to serve their = needs.
    I believe that this includes allowing the streams to decid= e not only the technical
    content but also to a large degree the e= ditorial content. While one might imagine
    some dispute about styl= e which would be so large that it threatened the
    character of the= series (e.g., the stream wanted to have all its documents
    publis= hed only in Esperanto), in my experience disputes between authors
    and the RPC are not generally of this nature, and therefore IMOthe st= ream
    ought to decide.


    2) As a minor matter, the individual ADs are not the stream manager for the IETF stream.=C2=A0 Traditional, the IETF chair has been the stream
    manager.=C2=A0 I hope that the IESG has adopted a policy of appointing a separate individual stream manager.=C2=A0 But there are not 13 stream
    managers for the IETF stream.=C2=A0 And there should not be, as it would render the notion of "stream manager" rather odd.

    Yes. This is why I said "the AD on behalf of the = IESG". I think this is a
    practical approach given that the A= D already is involved in making
    publication time decisions such a= s which changes to the text require
    extra IETF processing, such a= s being sent back to the WG. However,
    I wouldn't object to ha= ving this as the IESG's designate if people prefer.

    <= /div>
    -Ekr


    On 11/28/2020 4:51 PM, Eric Rescorla wrote:
    >
    >
    > On Sat, Nov 28, 2020 at 10:53 AM Christian Huitema <huitema@huitema.net
    > <mailto:hu= itema@huitema.net>> wrote:
    >
    >
    >=C2=A0 =C2=A0 =C2=A0On 11/28/2020 3:04 AM, Adrian Farrel wrote:
    >=C2=A0 =C2=A0 =C2=A0 > Tweaking the subject line since I*think*=C2= =A0 he have travelled out
    >=C2=A0 =C2=A0 =C2=A0of the "strategic" zone.
    >=C2=A0 =C2=A0 =C2=A0 > That is, the style guide is something with lo= ng term effects, but
    >=C2=A0 =C2=A0 =C2=A0its implementation is very much document-by-documen= t.
    >=C2=A0 =C2=A0 =C2=A0 > Let's take this a step closer to the ever= yday...
    >=C2=A0 =C2=A0 =C2=A0 > The RPC edits a document, the authors object = to one of the edits
    >=C2=A0 =C2=A0 =C2=A0claiming the RPC's understanding of the English= language is
    >=C2=A0 =C2=A0 =C2=A0incorrect: who arbitrates or makes the final decisi= on?
    >=C2=A0 =C2=A0 =C2=A0 > I can be happy with many answers to that ques= tion, but would
    >=C2=A0 =C2=A0 =C2=A0point out that historically, someone has been paid = to do that work.
    >=C2=A0 =C2=A0 =C2=A0 >
    >=C2=A0 =C2=A0 =C2=A0 > There is, IMHO, a difference between having a= go-to backstop who
    >=C2=A0 =C2=A0 =C2=A0ensures consistency and is responsible for decision= s, and having
    >=C2=A0 =C2=A0 =C2=A0someone to whom you can go for advice. In the first= case the RPC is
    >=C2=A0 =C2=A0 =C2=A0paid to try, and the backstop is paid to hold the l= ine. In the
    >=C2=A0 =C2=A0 =C2=A0second case, the RPC is paid to hold the line, and = someone is paid
    >=C2=A0 =C2=A0 =C2=A0to give advice.
    >=C2=A0 =C2=A0 =C2=A0 >
    >=C2=A0 =C2=A0 =C2=A0 > It's a small thing, but it is a realignme= nt of 'powers' and
    >=C2=A0 =C2=A0 =C2=A0should have a consequent redistribution of financia= l resources.
    >
    >
    >=C2=A0 =C2=A0 =C2=A0That's a good way of framing the issue, Adrian.= I personally lean
    >=C2=A0 =C2=A0 =C2=A0towards the RPC holding the line, because it makes = the overall workflow
    >=C2=A0 =C2=A0 =C2=A0simpler and does not dilute responsibilities. Also,= I am not aware of
    >=C2=A0 =C2=A0 =C2=A0past cases in which the RSE had to overrule the RPC= . Do we have
    >=C2=A0 =C2=A0 =C2=A0examples
    >=C2=A0 =C2=A0 =C2=A0of such incidents?
    >
    >
    > I actually prefer a third version: the stream manager should be the > ultimate decision maker, just as they are about the technical content = of
    > the document. For the IETF stream this will typically be the responsib= le
    > AD on behalf of the IESG.
    >
    > -Ekr
    >
    >
    >
    --0000000000006a70d305b5320429-- From nobody Sat Nov 28 18:20:29 2020 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 60CE43A0DC8 for ; Sat, 28 Nov 2020 18:20:27 -0800 (PST) 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 U-ZpRuGpTedI for ; Sat, 28 Nov 2020 18:20:25 -0800 (PST) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 0623D3A0DBB for ; Sat, 28 Nov 2020 18:20:24 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id u7so4488831vsq.11 for ; Sat, 28 Nov 2020 18:20:24 -0800 (PST) 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=JOjKwVvryr0eTIkoal2t1na5vrrd6O4u6qnievxToOc=; b=gOWYsMFd2DreqcxLO6m5FiOR+jrcYoxlZk4HVj8inHg6AvLgDCqwOGvy/Zha41Ij9a HMWxHfVVR2akYmBLuKLx558u0MBOfxQIEz6SL2FicMH73rM/u3kEJvSXJdQYGKIf1hiR mLdGwVWBNdhmKenvGyYmHZiyTApbcGDpPaGKctQu8iG/x9tE8PHZeiFps16CdBtCv985 688WVYt0n7eBfvbDyWAVVyNNvqdJxAcXPqkwtAmq/4BTZ2l6fihw2FvXKKZAYd6pauVA lxJc8VM9bebP5mqrfnckqjkILh0B2MhfkTY/l1oHr5WrtE8d4+frMiSGxF9qZ5iaEu3K /VXg== 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=JOjKwVvryr0eTIkoal2t1na5vrrd6O4u6qnievxToOc=; b=O0qGjejxd9RMieqraKrm7iQmAV9WXxpztIiUEHS3c6KCSktt490yleJjmjD+HxNLjP v2PzitBhNOQdmAYnJrzppGSQOZOcTk78tGbPlOdyQMI0hBSatgEVedsAELEcBj9S4kj8 E3EWyk4qKoWf316tl3HrWkuJ5bxcC54Nfu5fKwUeGFZFuXJ999gU5v3v2COj6XHCGOTa VI/nNf8s1jY5RJQnw2Ax9wfcvg4VcKqY5c/qPEG8MC6VF3iemFVMQ1vOdtUXbjqvpCg+ A8aY99nmN+Iz8v6A8k3/y9N/lvvtn0ixMPB0eYXGTERDl55O4RhS5VO9yx/GpP2cHFm7 pJcA== X-Gm-Message-State: AOAM5323YSmUmzuNrjqqI/rDzVTF5FwAwzeeCt6VCh/a75x7BGNen47K LzNlCtsJCtXxrwbI6vc3AEBvKUJHbmh4xJI/h5E= X-Google-Smtp-Source: ABdhPJwN21smTPmk4XwbTrTi1ZOyRYE+YRzmZzbLwJWHNKDXF4+JMzDmS+3QB9CgbbzwX7WPYlSkWdKYG/HWnWUHru4= X-Received: by 2002:a05:6102:30a4:: with SMTP id y4mr11458765vsd.59.1606616423890; Sat, 28 Nov 2020 18:20:23 -0800 (PST) MIME-Version: 1.0 References: <058501d6c576$43e4cfd0$cbae6f70$@olddog.co.uk> In-Reply-To: <058501d6c576$43e4cfd0$cbae6f70$@olddog.co.uk> From: Nevil Brownlee Date: Sun, 29 Nov 2020 15:19:57 +1300 Message-ID: To: Adrian Farrel Cc: Eliot Lear , Brian E Carpenter , rfced-future@iab.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Style guide and other non-strategic things ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 29 Nov 2020 02:20:27 -0000 Hi all: In my experience - both as ISE and sitting in on weekly RPC Editors meetings - the kind of issue that comes up has nothing to do with technical content. Instead, it's a "style" question, i.e. one where the Style Guide (or maybe the Chicago Manual of Style) doesn't work for the Author. Remembering that the Style Guide is the basis of RFCs' look and feel, changes to our Style Guide need to be decided by the RSE (i.e. Series Editor). In practice, the RFC Author(s) and whichever RPC Editor is working on her RFC will have proposed a solution for the question, and the RSE would usually accept that. Cheers, Nevil On Sun, Nov 29, 2020 at 12:04 AM Adrian Farrel wrote: > > Tweaking the subject line since I *think* he have travelled out of the "s= trategic" zone. > That is, the style guide is something with long term effects, but its imp= lementation is very much document-by-document. > Let's take this a step closer to the everyday... > The RPC edits a document, the authors object to one of the edits claiming= the RPC's understanding of the English language is incorrect: who arbitrat= es or makes the final decision? > I can be happy with many answers to that question, but would point out th= at historically, someone has been paid to do that work. > > There is, IMHO, a difference between having a go-to backstop who ensures = consistency and is responsible for decisions, and having someone to whom yo= u can go for advice. In the first case the RPC is paid to try, and the back= stop is paid to hold the line. In the second case, the RPC is paid to hold = the line, and someone is paid to give advice. > > It's a small thing, but it is a realignment of 'powers' and should have a= consequent redistribution of financial resources. > > Cheers, > Adrian > > -----Original Message----- > From: Eliot Lear > Sent: 28 November 2020 10:12 > To: Brian E Carpenter > Cc: adrian@olddog.co.uk; rfced-future@iab.org > Subject: Re: [Rfced-future] ** Consensus check on part of Issue 12: Is th= e person an advisor (RSA) or an Executive Editor (RSE) ** > > Good morning/evening both of you, > > > On 27 Nov 2020, at 21:37, Brian E Carpenter wrote: > > > > On 28-Nov-20 05:46, Adrian Farrel wrote: > >>>> I found this just a tiny bit ambiguous. I think that, in the context= of the subject line, I can work it out. So, to be clear... > >>>> > >>>> =E2=80=A2 The chairs think that there is likely rough consensus that= role of the chair and the RS[EA] should be split. > >>>> > >>>> =E2=80=A2 The chairs think we have consensus that the RS[EA] can rai= se issues to the strategic group > >>>> > >>>> =E2=80=A2 The chairs think there is likely rough consensus that the = RS[EA] does not make strategic decisions but that those are decided by the = strategic body > >>>> > >>>> =E2=80=A2 The chairs think there is likely rough consensus that the = RS[EA] does not direct the RPC/REP. > >>>> > >>>> Right? > >>> > >>> Right. > >> > >> Good, then I'm OK with the first three bullets, but unsure about the l= ast one. It covers a rather large area since there are number of things on = which the RPC need advice, guidance, and direction per the helpful email fr= om Sandy. > > > > I think there is some ambiguity about the word "direct". Does it mean "= give orders to" as in "the policeman directed me to put my hands behind my = head", or "give authoritative advice to" as in "Heather directed Sandy towa= rds the new edition of the Chicago Manual of Style"? > > > > If the former, I'm sure bullet 3 is correct, as orders come from the cu= stomer, which is the IETF LLC. If it's the latter, I'm sure it's wrong. > > > > Yes, just to be clear, we are talking in the negative here. So=E2=80=A6 = =E2=80=9CThe RS[EA] does not direct me to put my hands on my head=E2=80=9D = ;-) or perhaps more apposite: =E2=80=9CThe RS[EA] does not order the staff = to take specific actions. That person may offer guidance in specific situa= tions, but is not in the chain of command.=E2=80=9D > > Is there general agreement on what I just wrote? > > As to the style guide, perhaps that=E2=80=99s a separate issue or a good = more-than-hypothetical to work out. Is it maintained by the RPC with guida= nce of the RS[EA]? Is it maintained by the strategic body? Is it maintain= ed by the RS[EA]? Does that need to be specified here or by the strategic = body? > > Eliot > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 ----------------------------------- Nevil Brownlee, Taupo, NZ From nobody Sat Nov 28 22:12:15 2020 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 560813A11F9 for ; Sat, 28 Nov 2020 22:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 VzRf_HDCzm6A for ; Sat, 28 Nov 2020 22:12:08 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A7E83A11C4 for ; Sat, 28 Nov 2020 22:12:03 -0800 (PST) Received: from [192.168.217.118] (p548dce71.dip0.t-ipconnect.de [84.141.206.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4CkJ0x3LjMzyTV; Sun, 29 Nov 2020 07:12:01 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Sun, 29 Nov 2020 07:12:00 +0100 Cc: "Joel M. Halpern" , rfced-future@iab.org X-Mao-Original-Outgoing-Id: 628323120.917967-759d516604f4d8de28c68f9f44606a34 Content-Transfer-Encoding: quoted-printable Message-Id: References: <058501d6c576$43e4cfd0$cbae6f70$@olddog.co.uk> To: Eric Rescorla X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rfced-future] Style guide and other non-strategic things ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 29 Nov 2020 06:12:12 -0000 On 2020-11-28, at 23:07, Eric Rescorla wrote: >=20 > As I'm sure I've said before, from my perspective, the various streams = are > customers of the RFC series, and ultimately it needs to serve their = needs. Agree completely. But the RFC series may actually be better able to serve their needs if = there is a way to have actual push-back on some not-so-good ideas of a = particular stream manager. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Nov 28 22:36:54 2020 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 ADBE93A1271 for ; Sat, 28 Nov 2020 22:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 FOHxRgMQtr68 for ; Sat, 28 Nov 2020 22:36:51 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 1117F3A126E for ; Sat, 28 Nov 2020 22:36:50 -0800 (PST) Received: from xse357.mail2web.com ([66.113.197.103] helo=xse.mail2web.com) by mx169.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kjGKB-000Zzo-3c for rfced-future@iab.org; Sun, 29 Nov 2020 07:36:44 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4CkJYN39ypzLS0 for ; Sat, 28 Nov 2020 22:36:40 -0800 (PST) Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kjGK8-0001p9-Ag for rfced-future@iab.org; Sat, 28 Nov 2020 22:36:40 -0800 Received: (qmail 4106 invoked from network); 29 Nov 2020 06:36:38 -0000 Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.58.46.151]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 29 Nov 2020 06:36:38 -0000 To: Carsten Bormann , Eric Rescorla Cc: rfced-future@iab.org, "Joel M. Halpern" References: <058501d6c576$43e4cfd0$cbae6f70$@olddog.co.uk> From: Christian Huitema Message-ID: <4056534f-38a1-6127-23ea-7c97b8d1bd89@huitema.net> Date: Sat, 28 Nov 2020 22:36:37 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B0A5D5FEDE9DFC2566C4FF26" Content-Language: en-US X-Originating-IP: 66.113.197.103 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.54) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0fJVsTFCFA1YlcTpjJcy6PSpSDasLI4SayDByyq9LIhV87w9e7nRXRdR YH7H++TK90TNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjRzgyua+oKUgQGcbmeu+KPhY RkpFG1KU35iPF8F1Y4hbAHz8qoLNNUm9ZgE0YFpjQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEUE6zyPc6aUCdl00F/tjba+42Vki7412dpbhrD2d47zbC3VvU djSCswikK/licfX+oIF6uBSWByrPG2Vxuo/vVPllrFEbCkMryfcYCsgMUJObfBQoU3roWy2GH1DY sAiH3gousbgNfxi2R3uFLvZP/HBXvrLBlKCVRjjdPbjQ4HnBNho1Lszw5OO01yYoll8q2UgzFF+j HNSbIoW1Q++Wvj3dKxLhoxcmaInYbR5vlqFg3eKzPG9E5MikC2dVXWcpK172i/E5sOgbaCtBiSIx 1XwCY8vmv+JqOVJamBHfOGVwjn7Xut/lXagsodd5qqODTFiwcpU4fyz75jxpU98RPGiH1Wgh6RAe nBR+licROGb39x3Pp0qQsqDkbqmcZOiQ00yoa+Dg6Nzs0x/RbDKRZ6UEM992H6ZqaiAuTy3+MU8r cuyeNztZhTczEttfN8GcQie12lTu81QucaD9n7tPrXuXCC1A5Cukky0WFo38JXT3Y80OmAux3oN1 3+ztUzne8DDWgOYcl54TtscXVYV5cL83o7TP54FLJfg9sR3SxHJTqT8BoV8Xdw1MAJTng+awZcy9 ArEd5VjJcJdFmU/ZDYW+axx2DzNv8BNlsyaVn+WNBtnTX3bH99ZUJWl4OZ1X3UVkhX78ZcdZtWJt ri4lXS4599fEDT1GENo62d+DqD+gavEa4Cf1ILpAKBLSDHQENgjpXL2y/ONOC04/YEfTu1ss+n2f fnQxt6aJ7klZab8CvOT2YjlrAxveXsTwUzCTkiX4qyX2d5a1xbDejUjyqRVeiJQ5XjnH4gzAuCMQ 8aUxL7hrJSk60SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] Style guide and other non-strategic things ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 29 Nov 2020 06:36:53 -0000 This is a multi-part message in MIME format. --------------B0A5D5FEDE9DFC2566C4FF26 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 11/28/2020 10:12 PM, Carsten Bormann wrote: > On 2020-11-28, at 23:07, Eric Rescorla wrote: >> As I'm sure I've said before, from my perspective, the various streams are >> customers of the RFC series, and ultimately it needs to serve their needs. > Agree completely. > > But the RFC series may actually be better able to serve their needs if there is a way to have actual push-back on some not-so-good ideas of a particular stream manager. I agree with EKR that having the RPC escalate "author disagreements" to the stream manager would quickly resolve most of the issues. I am not too concerned about "uniformity of the series" arguments, since by definition research papers from the IRTF will not look exactly like proposed standards from the IETF, or individual contributions in the independent stream. If that's really becoming a problem, then the "strategic" body looks like a good place to discuss it. -- Christian Huitema --------------B0A5D5FEDE9DFC2566C4FF26 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

    On 11/28/2020 10:12 PM, Carsten Bormann wrote:

    On 2020-11-28, at 23:07, Eric Rescorla <ekr@rtfm.com> wrote:

    As I'm sure I've said before, from my perspective, the various streams are
customers of the RFC series, and ultimately it needs to serve their needs.

    Agree completely.

But the RFC series may actually be better able to serve their needs if there is a way to have actual push-back on some not-so-good ideas of a particular stream manager.


    I agree with EKR that having the RPC escalate "author disagreements" to the stream manager would quickly resolve most of the issues. I am not too concerned about "uniformity of the series" arguments, since by definition research papers from the IRTF will not look exactly like proposed standards from the IETF, or individual contributions in the independent stream. If that's really becoming a problem, then the "strategic" body looks like a good place to discuss it.

    -- Christian Huitema


    --------------B0A5D5FEDE9DFC2566C4FF26-- From nobody Sat Nov 28 22:42:24 2020 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 813CD3A1275 for ; Sat, 28 Nov 2020 22:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QyT9acvq4JTo for ; Sat, 28 Nov 2020 22:42:21 -0800 (PST) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (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 308513A0A42 for ; Sat, 28 Nov 2020 22:42:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 4CkJgw6r8Qz5bfD8; Sat, 28 Nov 2020 22:42:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1606632140; bh=ldPRlf5X/+qgCpD0eZxuBnuNtfTeUg3gvCd9uYEGLRg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=qP9a7OYK0ABZE/gxOCDM50dPHySDfk6YXBT/7GCdvnh2SiQIHluSlNoeahShJbkWe gJRyAl3HPcCGOZq3i+GRtBN/+feq1VNAevGmgyQiVpSmizifwZZIlI9N41NvioaLBf l93x1vTYESD1QDNkvq2TSyvJmmOE6KfTgsKJUwqA= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b1.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 4CkJgw27Dgz5bdQg; Sat, 28 Nov 2020 22:42:20 -0800 (PST) To: Christian Huitema Cc: rfced-future@iab.org References: <058501d6c576$43e4cfd0$cbae6f70$@olddog.co.uk> <4056534f-38a1-6127-23ea-7c97b8d1bd89@huitema.net> From: "Joel M. Halpern" Message-ID: Date: Sun, 29 Nov 2020 01:42:18 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <4056534f-38a1-6127-23ea-7c97b8d1bd89@huitema.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Style guide and other non-strategic things ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 29 Nov 2020 06:42:23 -0000 Depending upon what you mean by "look exactly like" below, the statement is either irelevant or does not match what I have seen as existing practice. We go to significant trouble to create and maintain a consistent look and feel across all RFCs. there is an argument that they should be more distinguished, as some people think / hope that would reduce the all too common confusions. (Of course, one would then want I-Ds to look more distinct as well.) But untill and unless we agree as a community on making that change, our existing practice has been to work for and value such consistency. Yours, Joel On 11/29/2020 1:36 AM, Christian Huitema wrote: > On 11/28/2020 10:12 PM, Carsten Bormann wrote: > >> On 2020-11-28, at 23:07, Eric Rescorla wrote: >>> As I'm sure I've said before, from my perspective, the various streams are >>> customers of the RFC series, and ultimately it needs to serve their needs. >> Agree completely. >> >> But the RFC series may actually be better able to serve their needs if there is a way to have actual push-back on some not-so-good ideas of a particular stream manager. > > > I agree with EKR that having the RPC escalate "author disagreements" to > the stream manager would quickly resolve most of the issues. I am not > too concerned about "uniformity of the series" arguments, since by > definition research papers from the IRTF will not look exactly like > proposed standards from the IETF, or individual contributions in the > independent stream. If that's really becoming a problem, then the > "strategic" body looks like a good place to discuss it. > > -- Christian Huitema > > From nobody Sat Nov 28 22:47:34 2020 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 B147F3A1278 for ; Sat, 28 Nov 2020 22:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 WjiQAmUdK4is for ; Sat, 28 Nov 2020 22:47:31 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 4D9F93A1277 for ; Sat, 28 Nov 2020 22:47:31 -0800 (PST) Received: from xse7.mail2web.com ([66.113.196.7] helo=xse.mail2web.com) by mx18.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kjGUO-0000eF-4g for rfced-future@iab.org; Sun, 29 Nov 2020 07:47:23 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4CkJnY3K8Hz1kbD for ; Sat, 28 Nov 2020 22:47:13 -0800 (PST) Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kjGUL-0005de-BE for rfced-future@iab.org; Sat, 28 Nov 2020 22:47:13 -0800 Received: (qmail 12463 invoked from network); 29 Nov 2020 06:47:13 -0000 Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.58.46.151]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 29 Nov 2020 06:47:12 -0000 To: "Joel M. Halpern" Cc: rfced-future@iab.org References: <058501d6c576$43e4cfd0$cbae6f70$@olddog.co.uk> <4056534f-38a1-6127-23ea-7c97b8d1bd89@huitema.net> From: Christian Huitema Message-ID: <10a60d4b-0bc5-c6d3-905c-6ddaecb98737@huitema.net> Date: Sat, 28 Nov 2020 22:47:12 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.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 X-Originating-IP: 66.113.196.7 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.7/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.7/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0fJVsTFCFA1YlcTpjJcy6PSpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjRzgyua+oKUgQGcbmeu+KPhY RkpFG1KU35iPF8F1Y4gpBbJTpbRVHiiW/YzwH8e3QVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEVy1fjNZA0UnjqgajXwVOqw7GrRD93GuKsil0DsNlfaQNjS91 xLLHjz8tOnVewUzjKn6AaXxoL/FjeXc4guU5t5coTPkiAq+E/1gvF2d40ruQVyADaS6UpCBADjTx teudCa15Ytj/yAhGv8ezOASMHW/bWfgucjnNmABpGhD9TTsjQT2BGVI0EbGkW8Q42wJCdCZm6kTr qH+fmxyzQoG+NtezYqxGMqsKjARq8PBC4qjRn0hhkccum+xyb3k4eNalTAas0edmB2q/yBRqnQY9 Wp4oEuFb796V1/nl3YbqwU/VPb6Z51AWQAUvAUQbV3oqEaMjfjmXaBok2IyAEprch60jiD6XqsJZ tjQxlyCdsezUTEAumaS8EPUiWeF3NFNfXt7BluAMaAukv11AovGyYhXpoMt52pBRrlQsf2clgvuS ax8yVT5LNQc0pviCIZ+VrEYBxX5sKcPtmaTbL1XTREqTD2ipD9y2znxCv9uYkc8RFZ4oobg8BBg3 Jq+ntzj0QgINkY+Hul+a3CMdKh9AgoaPmF/7MAKyW1Kb4FKGpjRt1rxcfJxEyn03r4GRhqyKmz6U lOoas/Ux4vgzjcGjPTLNmVyX0/oDKtieLSWbWqk5dWKRXX7DAg4Lg5nXzVBkfqb5R4VemuUI6bcE ARsm0De6PaZO6/JToEyx4tmc5OljkPSpPXAVjl2oMr8a1xm0wfXUFMjTH2DyD8i5kO5bZlYFvf25 LVONYbYifH5OzZCwIgD/xDehea09OpnwSuobZrrGExMR7eTbBjMGDKI3ijhhJn7Muv/NHXl0o++8 3wM= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] Style guide and other non-strategic things ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 29 Nov 2020 06:47:33 -0000 On 11/28/2020 10:42 PM, Joel M. Halpern wrote: > Depending upon what you mean by "look exactly like" below, the > statement is either irelevant or does not match what I have seen as > existing practice. I mean content and general organization. I do agree with you, Joel, that the same style guide applies to all streams. -- Christian Huitema > > We go to significant trouble to create and maintain a consistent look > and feel across all RFCs.  there is an argument that they should be > more distinguished, as some people think / hope that would reduce the > all too common confusions.  (Of course, one would then want I-Ds to > look more distinct as well.) > > But untill and unless we agree as a community on making that change, > our existing practice has been to work for and value such consistency. > > Yours, > Joel > > On 11/29/2020 1:36 AM, Christian Huitema wrote: >> On 11/28/2020 10:12 PM, Carsten Bormann wrote: >> >>> On 2020-11-28, at 23:07, Eric Rescorla  wrote: >>>> As I'm sure I've said before, from my perspective, the various >>>> streams are >>>> customers of the RFC series, and ultimately it needs to serve their >>>> needs. >>> Agree completely. >>> >>> But the RFC series may actually be better able to serve their needs >>> if there is a way to have actual push-back on some not-so-good ideas >>> of a particular stream manager. >> >> >> I agree with EKR that having the RPC escalate "author disagreements" >> to the stream manager would quickly resolve most of the issues. I am >> not too concerned about "uniformity of the series" arguments, since >> by definition research papers from the IRTF will not look exactly >> like proposed standards from the IETF, or individual contributions in >> the independent stream. If that's really becoming a problem, then the >> "strategic" body looks like a good place to discuss it. >> >> -- Christian Huitema >> >> From nobody Sat Nov 28 23:11:55 2020 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 4C1493A128E for ; Sat, 28 Nov 2020 23:11:53 -0800 (PST) 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 AIlPBhX5ys4P for ; Sat, 28 Nov 2020 23:11:51 -0800 (PST) Received: from [192.168.1.101] (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 72E683A11A4 for ; Sat, 28 Nov 2020 23:11:51 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-A5799FF9-84D3-4896-B8C5-531B09418431 Content-Transfer-Encoding: 7bit From: Jay Daley Mime-Version: 1.0 (1.0) Date: Sun, 29 Nov 2020 20:11:49 +1300 Message-Id: <1E1942C0-E4CF-45A6-8DD2-0BDEC44F8D09@ietf.org> References: <10a60d4b-0bc5-c6d3-905c-6ddaecb98737@huitema.net> In-Reply-To: <10a60d4b-0bc5-c6d3-905c-6ddaecb98737@huitema.net> To: rfced-future@iab.org X-Mailer: iPad Mail (18A8395) Archived-At: Subject: Re: [Rfced-future] Style guide and other non-strategic things ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 29 Nov 2020 07:11:53 -0000 --Apple-Mail-A5799FF9-84D3-4896-B8C5-531B09418431 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m a bit confused. Are we saying: A1) There is a single style guide agreed by some process yet to be determine= d, that each stream manager is responsible for ensuring compliance with; or A2) There is no single style guide and each stream manager is responsible fo= r setting the style for their stream. I=E2=80=99m guessing A1, and that is being recommended as an alternative to=20= B) There is a single style guide and the RS[E/A] is responsible for ensuring= compliance with it. Sound right? Jay --=20 Jay Daley IETF Executive Director > On 29/11/2020, at 7:47 PM, Christian Huitema wrote: >=20 > =EF=BB=BFOn 11/28/2020 10:42 PM, Joel M. Halpern wrote: >=20 >> Depending upon what you mean by "look exactly like" below, the statement i= s either irelevant or does not match what I have seen as existing practice. >=20 > I mean content and general organization. I do agree with you, Joel, that t= he same style guide applies to all streams. >=20 > -- Christian Huitema >=20 >>=20 >> We go to significant trouble to create and maintain a consistent look and= feel across all RFCs. there is an argument that they should be more distin= guished, as some people think / hope that would reduce the all too common co= nfusions. (Of course, one would then want I-Ds to look more distinct as wel= l.) >>=20 >> But untill and unless we agree as a community on making that change, our e= xisting practice has been to work for and value such consistency. >>=20 >> Yours, >> Joel >>=20 >>> On 11/29/2020 1:36 AM, Christian Huitema wrote: >>>> On 11/28/2020 10:12 PM, Carsten Bormann wrote: >>>=20 >>>> On 2020-11-28, at 23:07, Eric Rescorla wrote: >>>>> As I'm sure I've said before, from my perspective, the various streams= are >>>>> customers of the RFC series, and ultimately it needs to serve their ne= eds. >>>> Agree completely. >>>>=20 >>>> But the RFC series may actually be better able to serve their needs if t= here is a way to have actual push-back on some not-so-good ideas of a partic= ular stream manager. >>>=20 >>>=20 >>> I agree with EKR that having the RPC escalate "author disagreements" to t= he stream manager would quickly resolve most of the issues. I am not too con= cerned about "uniformity of the series" arguments, since by definition resea= rch papers from the IRTF will not look exactly like proposed standards from t= he IETF, or individual contributions in the independent stream. If that's re= ally becoming a problem, then the "strategic" body looks like a good place t= o discuss it. >>>=20 >>> -- Christian Huitema >>>=20 >>>=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail-A5799FF9-84D3-4896-B8C5-531B09418431 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m a bit confused.  Are we sa= ying:

    A1) There is a single style guide agreed by some pr= ocess yet to be determined, that each stream manager is responsible for ensu= ring compliance with; or

    A2) There is no single sty= le guide and each stream manager is responsible for setting the style for th= eir stream.

    I=E2=80=99m guessing A1, and that is being recommended as= an alternative to 

    B) There is a single style= guide and the RS[E/A] is responsible for ensuring compliance with it.
    =

    Sound right?

    Jay

    -- 
    Jay Daley
    IETF Executive Director


    On 29/11/2020, at 7:47 PM, Christia= n Huitema <huitema@huitema.net> wrote:

    =EF=BB=BFOn 11/28/2020 10:42 PM,= Joel M. Halpern wrote:

    Depending upon what you mean by "look exactly like" below, the statem= ent is either irelevant or does not match what I have seen as existing pract= ice.

    I mean content and genera= l organization. I do agree with you, Joel, that the same style guide applies= to all streams.

    -- Christian Huitema


    We go to significant trouble to create and= maintain a consistent look and feel across all RFCs.  there is an argu= ment that they should be more distinguished, as some people think / hope tha= t would reduce the all too common confusions.  (Of course, one would th= en want I-Ds to look more distinct as well.)

    But untill and unless we agree as a community on making that change, our= existing practice has been to work for and value such consistency.

    Yours,
    Joel

    On 11/29/2020 1:36 AM, C= hristian Huitema wrote:
    On 11/28/2020 10:12 PM, Carsten Bormann wrote:<= /span>

    On 2020-11-28= , at 23:07, Eric Rescorla<ekr@rtfm.com>  wrote:
    As I'm sure= I've said before, from my perspective, the various streams are
    =
    customers of the RFC series, and ultimately it needs to serve their n= eeds.
    = Agree completely.
    <= /span>
    <= blockquote type=3D"cite">
    But the RFC series m= ay actually be better able to serve their needs if there is a way to have ac= tual push-back on some not-so-good ideas of a particular stream manager.


    I agree wi= th EKR that having the RPC escalate "author disagreements" to the stream man= ager would quickly resolve most of the issues. I am not too concerned about "= uniformity of the series" arguments, since by definition research papers fro= m the IRTF will not look exactly like proposed standards from the IETF, or i= ndividual contributions in the independent stream. If that's really becoming= a problem, then the "strategic" body looks like a good place to discuss it.=

    -- Christian Huitema



    --
    Rfced-future mailing list
    Rfced-futur= e@iab.org
    https://www.iab.org/mailman/listinfo/rfced-future<= /span>
    = --Apple-Mail-A5799FF9-84D3-4896-B8C5-531B09418431-- From nobody Sat Nov 28 23:53:50 2020 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 AC01F3A12D7 for ; Sat, 28 Nov 2020 23:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 y2qTaI5SvheI for ; Sat, 28 Nov 2020 23:53:46 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E521A3A12D5 for ; Sat, 28 Nov 2020 23:53:45 -0800 (PST) Received: from [192.168.217.118] (p548dce71.dip0.t-ipconnect.de [84.141.206.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4CkLGH4MqGzyVP; Sun, 29 Nov 2020 08:53:43 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <1E1942C0-E4CF-45A6-8DD2-0BDEC44F8D09@ietf.org> Date: Sun, 29 Nov 2020 08:53:43 +0100 Cc: rfced-future@iab.org X-Mao-Original-Outgoing-Id: 628329222.991619-5f516d112137f589f3cb2c0401568475 Content-Transfer-Encoding: quoted-printable Message-Id: <92710E24-0D77-40E4-BA12-581075990D67@tzi.org> References: <10a60d4b-0bc5-c6d3-905c-6ddaecb98737@huitema.net> <1E1942C0-E4CF-45A6-8DD2-0BDEC44F8D09@ietf.org> To: Jay Daley X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rfced-future] Style guide and other non-strategic things ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 29 Nov 2020 07:53:49 -0000 On 2020-11-29, at 08:11, Jay Daley wrote: >=20 > A1) There is a single style guide agreed by some process yet to be = determined, that each stream manager is responsible for ensuring = compliance with; or > [=E2=80=A6] > B) There is a single style guide and the RS[E/A] is responsible for = ensuring compliance with it. Thanks for making this more crystal-clear. In corporate practice, there is a reason that the roles of CEO and = CFO(*) are split. It helps to have someone who has financial compliance = as a principal concern on their mind. (Now of course, =E2=80=9Ccompliance=E2=80=9D to a style guide isn=E2=80=99= t nearly as =E2=80=9Cdo or die=E2=80=9D as financial compliance. The = RSE role had a bit more to it than just that, though, some of which also = benefits from some focus.) Gr=C3=BC=C3=9Fe, Carsten (*) I hope no RSE or CFO is feeling insulted by this parable. =20 It=E2=80=99s just a parable... From nobody Sun Nov 29 12:36:03 2020 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 67E063A0E2D for ; Sun, 29 Nov 2020 12:36:02 -0800 (PST) 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 rw-PSEsvga6q for ; Sun, 29 Nov 2020 12:36:01 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 0A73D3A0E2C for ; Sun, 29 Nov 2020 12:36:01 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id w6so9072186pfu.1 for ; Sun, 29 Nov 2020 12:36:01 -0800 (PST) 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=xtSch0XIcz5kNAJCo9JBe1rWEdSaYqgNb/tN/nWqYB4=; b=cA5KZBbXoZMoZDuSEXpzUoaQlfp6bRHNKSyB0eviuXY5O3tVJ8xpdxpvrnWpK3w19g DmQUxDHM03mRpjl2uDbSL5OEE9Rsxzebiba2uPYcxYXXnJEuEQVVWyL1s9nqyPnQdoKH XbdHW4PAzJs9QL7X75VQwp8KV5ciBhIXBN+AjYUdLetPiEEStrWESvCihReGew8KTS+O XGRLY131IwbLZkV1XcfhRBWoo+mkzzxKUgPhsO0H7uKGs+21YxtkHnTByZkdscUa0x/k 60ksHXzrN1Lne3hI/9LiIJqOvJkuHX9tFdKPqSBXI7K9E/mvef1rSI0vRrhORBsxHyic 0p1w== 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=xtSch0XIcz5kNAJCo9JBe1rWEdSaYqgNb/tN/nWqYB4=; b=NGvC0A9QH1Y19dNnDfQ+U9KRWPM5UDmTQ2SRu7wl3RIT6rzb8S7oInclU4dsCW/9Am U8kzmP5t2s61gM7L72o5qUO/5asWJkDc0xtFq37H2atumxnkyzL/IdH6Kg8taBXoPYIF EydsIVz9wM2LXNgRbmMLLwgawFa9GilP9FdebaPTi/MMbxlOIyvFNcoy8mzUKUhHbkor rifS6W2bRpa667BeaMqmL5p/qzlZjzfWehB1/NROv/R+qQ7Dl1KPTU1gJr+X0f+jGkbP H8qWrc5mVhveK9HFc9ESA1r4+z2dYdIDyJu1Kh/tc5jwy/g94j50BXP171umD9Kk3olt DavA== X-Gm-Message-State: AOAM5311fBKtF+rdL5vZgFER4oO9dy1EhUzya+WoUfHM5aiUkFMdHPog cd3L2/x8nS16f1bBHC8oR/E5StxS2k9aUA== X-Google-Smtp-Source: ABdhPJwg5EB51pwC2PBv6UNc4kn1TWRTshNjfICxF4RIAcZffgX2jBAXLzD8mvLmszaAHjty/j7byw== X-Received: by 2002:a62:8f03:0:b029:18c:968a:4cf9 with SMTP id n3-20020a628f030000b029018c968a4cf9mr15490209pfd.59.1606682160037; Sun, 29 Nov 2020 12:36:00 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id e21sm14169655pfd.107.2020.11.29.12.35.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Nov 2020 12:35:59 -0800 (PST) To: Christian Huitema , "Joel M. Halpern" Cc: rfced-future@iab.org References: <058501d6c576$43e4cfd0$cbae6f70$@olddog.co.uk> <4056534f-38a1-6127-23ea-7c97b8d1bd89@huitema.net> <10a60d4b-0bc5-c6d3-905c-6ddaecb98737@huitema.net> From: Brian E Carpenter Message-ID: Date: Mon, 30 Nov 2020 09:35:54 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <10a60d4b-0bc5-c6d3-905c-6ddaecb98737@huitema.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Style guide and other non-strategic things ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 29 Nov 2020 20:36:02 -0000 On 29-Nov-20 19:47, Christian Huitema wrote: > On 11/28/2020 10:42 PM, Joel M. Halpern wrote: >=20 >> Depending upon what you mean by "look exactly like" below, the=20 >> statement is either irelevant or does not match what I have seen as=20 >> existing practice. >=20 > I mean content and general organization. I do agree with you, Joel, tha= t=20 > the same style guide applies to all streams. Agreed, but when it gets tricky is if there's disagreement between the RP= C and the stream (or authors) about interpretation of the style guide. Th= ere's no doubt that having an RSE provides a definitive tiebreaker in suc= h a case. If we have an RSA model, I think we'd have to specify who would= act as arbiter for style disagreements. Brian >=20 > -- Christian Huitema >=20 >> >> We go to significant trouble to create and maintain a consistent look = >> and feel across all RFCs.=C2=A0 there is an argument that they should = be=20 >> more distinguished, as some people think / hope that would reduce the = >> all too common confusions.=C2=A0 (Of course, one would then want I-Ds = to=20 >> look more distinct as well.) >> >> But untill and unless we agree as a community on making that change,=20 >> our existing practice has been to work for and value such consistency.= >> >> Yours, >> Joel >> >> On 11/29/2020 1:36 AM, Christian Huitema wrote: >>> On 11/28/2020 10:12 PM, Carsten Bormann wrote: >>> >>>> On 2020-11-28, at 23:07, Eric Rescorla=C2=A0 wrote: >>>>> As I'm sure I've said before, from my perspective, the various=20 >>>>> streams are >>>>> customers of the RFC series, and ultimately it needs to serve their= =20 >>>>> needs. >>>> Agree completely. >>>> >>>> But the RFC series may actually be better able to serve their needs = >>>> if there is a way to have actual push-back on some not-so-good ideas= =20 >>>> of a particular stream manager. >>> >>> >>> I agree with EKR that having the RPC escalate "author disagreements" = >>> to the stream manager would quickly resolve most of the issues. I am = >>> not too concerned about "uniformity of the series" arguments, since=20 >>> by definition research papers from the IRTF will not look exactly=20 >>> like proposed standards from the IETF, or individual contributions in= =20 >>> the independent stream. If that's really becoming a problem, then the= =20 >>> "strategic" body looks like a good place to discuss it. >>> >>> -- Christian Huitema >>> >>> >=20 From nobody Sun Nov 29 13:01:21 2020 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 33EF93A0E87 for ; Sun, 29 Nov 2020 13:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_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=nostrum.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 kLTokRU54D_K for ; Sun, 29 Nov 2020 13:01:19 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 100CF3A09F2 for ; Sun, 29 Nov 2020 13:01:18 -0800 (PST) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 0ATL175o002616 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 29 Nov 2020 15:01:09 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1606683669; bh=xXTKrE9W/Me3YDQQBTAmvFEAaprmPRUq9o54Xxhnf/g=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=GhE7gFmYz9YrfXR33Js01uhPHgiLO6t/tKBBiarhHqOyhG95hlkS4ZIbohS4gOiPx yallvhDK2gl6+3g4iM/8qALBiU9dyRokciZpMkE41ntyQbe1vK4IOYerO7S6UsHyK5 1x/mSCaXrsQkRt5reofkndoBRTtYOLrPI/ZYaKuk= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: Brian E Carpenter , Christian Huitema , "Joel M. Halpern" Cc: rfced-future@iab.org References: <058501d6c576$43e4cfd0$cbae6f70$@olddog.co.uk> <4056534f-38a1-6127-23ea-7c97b8d1bd89@huitema.net> <10a60d4b-0bc5-c6d3-905c-6ddaecb98737@huitema.net> From: Adam Roach Message-ID: Date: Sun, 29 Nov 2020 15:01:01 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 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] Style guide and other non-strategic things ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 29 Nov 2020 21:01:20 -0000 On 11/29/2020 2:35 PM, Brian E Carpenter wrote: > Agreed, but when it gets tricky is if there's disagreement between the RPC and the stream (or authors) about interpretation of the style guide. There's no doubt that having an RSE provides a definitive tiebreaker in such a case. "No doubt" overstates it a bit: it's not exactly that clear-cut, even in today's system. See, for example, RFC 4714 Section 3.3: >       In specific instances, where some or all of >       document text is the result of a careful negotiation of >       contributions (within or between working groups, reviewers, etc.), >       the technical publisher may be required to publish that text >       verbatim.  In the IETF standards process, verbatim publication may >       be requested by the IESG.  It is the expectation of the IETF >       community that this will not be done often. /a From nobody Sun Nov 29 13:19:22 2020 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 3CBD93A0E14 for ; Sun, 29 Nov 2020 13:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRujRtwNnOCm for ; Sun, 29 Nov 2020 13:19:19 -0800 (PST) Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (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 4D19B3A0E09 for ; Sun, 29 Nov 2020 13:19:19 -0800 (PST) Received: by mail-pf1-x441.google.com with SMTP id e8so9116532pfh.2 for ; Sun, 29 Nov 2020 13:19:19 -0800 (PST) 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=Sten/CFA+MKVlBmcStgAcC5EXWgpyVa/huQYndWWYT8=; b=POLUBYKqI7j0Etttc7o14xBhlSkRbUBWVqe0oOKc1ZwWTDDP2CDtuBCZMordqFAH0X 7j9+o2Q7R9Bd76KFRATfAcwLB+/oQAAK/WgBVbglWUdr6mvpfioVlnuyKbQj2s5dNMoj J9cvyRttyw7DPOmdQgMpcdjUkhs8GKh8B9F7CTtFhH7K/GfX/srwcmphzVgavKJoAzug Y4JvHk2L2xqZZ1VN2aRt1Wafrr3o7IIDQN6OBTHX3t5FLtuhaxLnNCxpqUnayKlSp1Ym KlpY7MxrmayeVZDggIPRxu7wZqbmKjBqrsZ+Tkdk9Smwe0dxKAE1OKoWwGzIBeS8rGWE VNfg== 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=Sten/CFA+MKVlBmcStgAcC5EXWgpyVa/huQYndWWYT8=; b=EGtOgeYpTP3rECcHty6MxXEUSFIUgETPYhI+Xi/dK1cxhmki7+qgJrnK4FoyjKWhX8 OyKygclMji9+BXTdDDlVsrcnR9C0veT4ANcuSKylL1EMEA7ODEpVxlF8QK0H0Y0U+dSG oxwDOBKCwS4B7doDqr3ECzr91XV0QI4QRihPqjr/y48RSzN4i1UA79RSlYUmmMe+tnPB 8L1OKpY4TiFXn6hUgf6BlKOuFzDjMGSjVfgIaFN/unrNRY0ZDENg2E5nbDOWvOP6WL+l 2R712JBMyZCTb6hUI7vxsFxlRXgP1l24bu5YdtUViORbtu5u/cb5sH6V02OkVvQTqfwB Wdmw== X-Gm-Message-State: AOAM531kKa7drVNs8f2G5ikNH+d35JaWOiLNoKWyoPyLlfY6EQgltFO0 v5hga2x3WIGfJ9YpBgRrgTDYK9bOs3Bomw== X-Google-Smtp-Source: ABdhPJyWykZRR8vas0ntTOokfcdbW054F6ctwMJnIuiMXMVkk6T2kP00kGRQUVPLddYoULEjRK4FPQ== X-Received: by 2002:a17:90a:578f:: with SMTP id g15mr22053316pji.3.1606684758462; Sun, 29 Nov 2020 13:19:18 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id g3sm14040397pfr.145.2020.11.29.13.19.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Nov 2020 13:19:17 -0800 (PST) To: Adam Roach , Christian Huitema , "Joel M. Halpern" Cc: rfced-future@iab.org References: <058501d6c576$43e4cfd0$cbae6f70$@olddog.co.uk> <4056534f-38a1-6127-23ea-7c97b8d1bd89@huitema.net> <10a60d4b-0bc5-c6d3-905c-6ddaecb98737@huitema.net> From: Brian E Carpenter Message-ID: Date: Mon, 30 Nov 2020 10:19:12 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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] Style guide and other non-strategic things ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 29 Nov 2020 21:19:20 -0000 Yes, good catch, although I was more thinking of aesthetic questions like= comma placement. Regards Brian On 30-Nov-20 10:01, Adam Roach wrote: > On 11/29/2020 2:35 PM, Brian E Carpenter wrote: >> Agreed, but when it gets tricky is if there's disagreement between the= RPC and the stream (or authors) about interpretation of the style guide.= There's no doubt that having an RSE provides a definitive tiebreaker in = such a case. >=20 >=20 > "No doubt" overstates it a bit: it's not exactly that clear-cut, even i= n=20 > today's system. See, for example, RFC 4714 Section 3.3: >=20 >=20 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In specific instances, where some or al= l of >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 document text is the result of a carefu= l negotiation of >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 contributions (within or between workin= g groups, reviewers, etc.), >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the technical publisher may be required= to publish that text >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 verbatim.=C2=A0 In the IETF standards p= rocess, verbatim publication may >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 be requested by the IESG.=C2=A0 It is t= he expectation of the IETF >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 community that this will not be done of= ten. >=20 >=20 > /a >=20 >=20 From nobody Sun Nov 29 13:48:29 2020 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 44E6A3A02BD for ; Sun, 29 Nov 2020 13:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_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=nostrum.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 7lEOHaYm6Xuj for ; Sun, 29 Nov 2020 13:48:25 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A742E3A02BB for ; Sun, 29 Nov 2020 13:48:25 -0800 (PST) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 0ATLmJb3019644 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 29 Nov 2020 15:48:21 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1606686502; bh=1UDlX7/mojy+XVLSbHTVe0o7xS/P4qlCgF3QsH9HZ3w=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Upk76LMVomsNe4KlL0otPzemx1Shsx2pQRlPr7DMEB/Uj0eFyEtf5Y80uHyHOJGpt UbjYpJTHicgNIfKDu0MIJ6dqyzKT3YxSdziEDOURkO0MaLOf7CtErIkX5aTHWlqpNT UXTB+MkY4fgt33OhBWCgrG931j/fJlDth9VPFVmg= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: Brian E Carpenter , Christian Huitema , "Joel M. Halpern" Cc: rfced-future@iab.org References: <058501d6c576$43e4cfd0$cbae6f70$@olddog.co.uk> <4056534f-38a1-6127-23ea-7c97b8d1bd89@huitema.net> <10a60d4b-0bc5-c6d3-905c-6ddaecb98737@huitema.net> From: Adam Roach Message-ID: <1d97555d-231a-646c-18c0-b0f15f44d0c1@nostrum.com> Date: Sun, 29 Nov 2020 15:48:13 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 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] Style guide and other non-strategic things ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 29 Nov 2020 21:48:28 -0000 Sure, and -- although slightly far-fetched, it's not completely implausible to imagine -- if there were a long-running and hard-fought argument within a working group regarding the placement of a specific comma, resulting in a difficult but ultimately decisive consensus call, the current system (as per the text I quote below) would seem to favor the stream manager's position of "publish the comma's position as per IETF consensus" over the RSE's aesthetic judgement. Independent of that specific clause, we have an oddly devolved system today that practically favors the stream managers over the series editor in the case of strictly editorial disputes (even if the de jure role definitions don't make that clear), but it is admittedly ambiguous and contradictory in certain ways. It would be good if the outcome of this process were explicit on that topic, and I *think* it's separable from the other structural elements (e.g., RSE vs. RSA). That's really my only  point. /a On 11/29/2020 3:19 PM, Brian E Carpenter wrote: > Yes, good catch, although I was more thinking of aesthetic questions like comma placement. > > Regards > Brian > > On 30-Nov-20 10:01, Adam Roach wrote: >> On 11/29/2020 2:35 PM, Brian E Carpenter wrote: >>> Agreed, but when it gets tricky is if there's disagreement between the RPC and the stream (or authors) about interpretation of the style guide. There's no doubt that having an RSE provides a definitive tiebreaker in such a case. >> >> "No doubt" overstates it a bit: it's not exactly that clear-cut, even in >> today's system. See, for example, RFC 4714 Section 3.3: >> >> >>>       In specific instances, where some or all of >>>       document text is the result of a careful negotiation of >>>       contributions (within or between working groups, reviewers, etc.), >>>       the technical publisher may be required to publish that text >>>       verbatim.  In the IETF standards process, verbatim publication may >>>       be requested by the IESG.  It is the expectation of the IETF >>>       community that this will not be done often. >> >> /a >> >> From nobody Sun Nov 29 14:31:17 2020 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 37B823A0762 for ; Sun, 29 Nov 2020 14:31:15 -0800 (PST) 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 VXsmxY6-Nagq; Sun, 29 Nov 2020 14:31:13 -0800 (PST) Received: from [192.168.1.101] (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 278863A02DC; Sun, 29 Nov 2020 14:31:13 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-421B8D6C-A9AB-4AD2-9DCC-673DD43F1C53 Content-Transfer-Encoding: 7bit From: Jay Daley Mime-Version: 1.0 (1.0) Date: Mon, 30 Nov 2020 11:31:10 +1300 Message-Id: <4B69280E-7B15-478E-AD71-7C6A184BF1C1@ietf.org> References: Cc: Christian Huitema , "Joel M. Halpern" , rfced-future@iab.org In-Reply-To: To: Brian E Carpenter X-Mailer: iPad Mail (18A8395) Archived-At: Subject: Re: [Rfced-future] Style guide and other non-strategic things ** Consensus check on part of Issue 12: Is the person an advisor (RSA) or an Executive Editor (RSE) ** 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, 29 Nov 2020 22:31:15 -0000 --Apple-Mail-421B8D6C-A9AB-4AD2-9DCC-673DD43F1C53 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 30/11/2020, at 9:36 AM, Brian E Carpenter = wrote: >=20 > =EF=BB=BFOn 29-Nov-20 19:47, Christian Huitema wrote: >>> On 11/28/2020 10:42 PM, Joel M. Halpern wrote: >>>=20 >>> Depending upon what you mean by "look exactly like" below, the=20 >>> statement is either irelevant or does not match what I have seen as=20 >>> existing practice. >>=20 >> I mean content and general organization. I do agree with you, Joel, that=20= >> the same style guide applies to all streams. >=20 > Agreed, but when it gets tricky is if there's disagreement between the RPC= and the stream (or authors) about interpretation of the style guide. There'= s no doubt that having an RSE provides a definitive tiebreaker in such a cas= e. If we have an RSA model, I think we'd have to specify who would act as ar= biter for style disagreements. This appears to still be conflating separate things: 0) Who decides what the style guide is; TBD 1) Who determines how the style guide should be interpreted? I believe everyone is agreed that this is the RPC on day-to-day basis. 2) In the event the authors disagree with the determination above, who chec= ks it and then tells anyone who disagrees with it that they need to accept i= t? What some people are proposing is that the stream manager does this rather t= han the RS[E/A].=20 3) What happens if the person(s) at 1) above disagrees with the decision at= 2) above, and in particular what does that mean for consistency if 2) above= is stream managers? If 2) is an RSE then nothing happens and we assume consistency is in place b= y virtue of having a single person making the decisions. If 2) is the strea= m managers then that can be fixed by giving the RPC (and anyone else?) the a= bility to appeal to 0) above for a consistency check. Jay --=20 Jay Daley IETF Executive Director >=20 > Brian >=20 >>=20 >> -- Christian Huitema >>=20 >>>=20 >>> We go to significant trouble to create and maintain a consistent look=20= >>> and feel across all RFCs. there is an argument that they should be=20 >>> more distinguished, as some people think / hope that would reduce the=20= >>> all too common confusions. (Of course, one would then want I-Ds to=20 >>> look more distinct as well.) >>>=20 >>> But untill and unless we agree as a community on making that change,=20 >>> our existing practice has been to work for and value such consistency. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 11/29/2020 1:36 AM, Christian Huitema wrote: >>>> On 11/28/2020 10:12 PM, Carsten Bormann wrote: >>>>=20 >>>>> On 2020-11-28, at 23:07, Eric Rescorla wrote: >>>>>> As I'm sure I've said before, from my perspective, the various=20 >>>>>> streams are >>>>>> customers of the RFC series, and ultimately it needs to serve their=20= >>>>>> needs. >>>>> Agree completely. >>>>>=20 >>>>> But the RFC series may actually be better able to serve their needs=20= >>>>> if there is a way to have actual push-back on some not-so-good ideas=20= >>>>> of a particular stream manager. >>>>=20 >>>>=20 >>>> I agree with EKR that having the RPC escalate "author disagreements"=20= >>>> to the stream manager would quickly resolve most of the issues. I am=20= >>>> not too concerned about "uniformity of the series" arguments, since=20 >>>> by definition research papers from the IRTF will not look exactly=20 >>>> like proposed standards from the IETF, or individual contributions in=20= >>>> the independent stream. If that's really becoming a problem, then the=20= >>>> "strategic" body looks like a good place to discuss it. >>>>=20 >>>> -- Christian Huitema >>>>=20 >>>>=20 >>=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail-421B8D6C-A9AB-4AD2-9DCC-673DD43F1C53 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    On 30/11/2020, at 9:36 AM, Brian E Carpenter <brian.e.carpenter@gmail= .com> wrote:

    =EF=BB=BFOn 29-Nov-20 19:47, Christian Huitema wrote:<= br>
    On 11/28/2020 10:42 PM, Joel M. Halpern w= rote:

    Depending= upon what you mean by "look exactly like" below, the
    sta= tement is either irelevant or does not match what I have seen as
    =
    existing practice.

    I= mean content and general organization. I do agree with you, Joel, that
    the same style guide app= lies to all streams.

    Agreed, b= ut when it gets tricky is if there's disagreement between the RPC and the st= ream (or authors) about interpretation of the style guide. There's no doubt t= hat having an RSE provides a definitive tiebreaker in such a case. If we hav= e an RSA model, I think we'd have to specify who would act as arbiter for st= yle disagreements.

    This appears t= o still be conflating separate things:

    0) Who decides wha= t the style guide is;

    TBD

    = 1)  Who determines how the style guide should be interpreted?

    I believe everyone is agreed that this is the RPC on day-to-= day basis.

    2)  In the event the authors disagr= ee with the determination above, who checks it and then tells anyone who dis= agrees with it that they need to accept it?

    What so= me people are proposing is that the stream manager does this rather than the= RS[E/A]. 

    3)  What happens if the person= (s) at 1) above disagrees with the decision at 2) above, and in particular w= hat does that mean for consistency if 2) above is stream managers?

    If 2) is an RSE then nothing happens and we assume consisten= cy is in place by virtue of having a single person making the decisions. &nb= sp;If 2) is the stream managers then that can be fixed by giving the RPC (an= d anyone else?) the ability to appeal to 0) above for a consistency check.

    Jay

    -- =
    Jay DaleyIETF Executive Director


      Brian

    <= blockquote type=3D"cite">
    -- Christian Huitema


    We go to significant trouble to create a= nd maintain a consistent look
    and feel across all RFCs.&n= bsp; there is an argument that they should be
    more distin= guished, as some people think / hope that would reduce the
    all too common confusions.  (Of course, one would then want I-Ds to <= /span>
    look more distinct as well.)

    =
    But untill and unless we agree as a community on making that change,=
    our existing practice has been to work for and value such= consistency.
    =

    Yours,
    = Joel

    On 11/29/2020 1:36 AM, Christian H= uitema wrote:
    =
    On 11/28/2020 10:1= 2 PM, Carsten Bormann wrote:

    On 2020-11-28, at 23:07, Eric Rescorla<ekr@rtfm.com>=   wrote:
    =
    As I'm sure I've= said before, from my perspective, the various
    <= blockquote type=3D"cite">streams are
    customers of the RFC series, and ultimately it nee= ds to serve their
    needs.
    Agree completely.

    But the RFC series may actually be better able to s= erve their needs
    if there is a way to have actual push-= back on some not-so-good ideas
    of a particular stream m= anager.


    I agree with EKR that having the R= PC escalate "author disagreements"
    to the stream manager would quickly resolve most of the iss= ues. I am
    not too c= oncerned about "uniformity of the series" arguments, since
    by definition research papers from th= e IRTF will not look exactly
    like proposed standards from the IETF, or individual contribution= s in
    the independe= nt stream. If that's really becoming a problem, then the
    "strategic" body looks like a good pl= ace to discuss it.
    =
    =
    -- Christian Huite= ma




    --
    Rfced-future mailing list
    <= span>Rfced-future@iab.org
    https://www.iab.org/mailman/listin= fo/rfced-future
    = --Apple-Mail-421B8D6C-A9AB-4AD2-9DCC-673DD43F1C53-- From nobody Sun Nov 29 19:32:16 2020 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 BDBD13A0DE2 for ; Sun, 29 Nov 2020 19:32:13 -0800 (PST) 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=comcast.net 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 v5E3JSsAQKLQ for ; Sun, 29 Nov 2020 19:32:12 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 E7B1B3A0D86 for ; Sun, 29 Nov 2020 19:32:11 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id jZkYknNKapzNLjZv8kGfD5; Mon, 30 Nov 2020 03:32:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1606707130; bh=Qd52tYl+Kc0iJ8ueaGvDVNQhK9NnME9hYbzR2OWxfxY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=vdKb3uogSOn3BZBLqJRDxpKogPVhDYzbaYfhfOVM0Lhynq3u4e91D/jvV/jEzgnVp rd16ZQRDIb/Q5C2x95hjNnF/QYpQywoaZdEH+y+SE7cDGfDcRXlGbX6bZ+zKPLpksk ucDctM/vl9M+o0jh3ZXAIJ3Z1OW7V+ctDteTG9S0IkrIALhHNYxafnbCB/VigOnBme 2MHfJa+gOtut/tklvjYoHc2vX8WF6rEqmyHUu/JbgLA/xiQsWael/x9Ib4wCCNuNtM 75qIatifndWj7tt7Qc+PXPTZvUSja5lkSjkFTI7/fdZtPOMY8lbRp9CzjgI59o1hpL vsz0r9eDnAZxQ== Received: from [192.168.1.23] ([108.28.189.254]) by resomta-ch2-10v.sys.comcast.net with ESMTPSA id jZuzkocPgTIAujZv0k9SzE; Mon, 30 Nov 2020 03:32:08 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedujedrudehledgheelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedtudenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpefoihgthhgrvghlucfuthflohhhnhhsuceomhhsthhjohhhnhhssegtohhmtggrshhtrdhnvghtqeenucggtffrrghtthgvrhhnpeejtdetvdfgkedtvdegudekvddvveevhefggfelgeevgfeggffftddutedvgfetvdenucffohhmrghinhepihgvthhfrdhorhhgpdifvggsvgigrdgtohhmnecukfhppedutdekrddvkedrudekledrvdehgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddrvdefngdpihhnvghtpedutdekrddvkedrudekledrvdehgedpmhgrihhlfhhrohhmpehmshhtjhhohhhnshestghomhgtrghsthdrnhgvthdprhgtphhtthhopegvgigvtggusehirggsrdhorhhgpdhrtghpthhtoheprhhftggvugdqfhhuthhurhgvsehirggsrdhorhhg X-Xfinity-VMeta: sc=0.00;st=legit To: rfced-future@iab.org, Cindy Morgan References: <160653974994.12259.12100973874618348178@ietfa.amsl.com> From: Michael StJohns Message-ID: Date: Sun, 29 Nov 2020 22:32:01 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <160653974994.12259.12100973874618348178@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] RFC Editor Future Development (rfcefdp) PROGRAM Virtual Meeting: 2020-12-18 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, 30 Nov 2020 03:32:14 -0000 Hi - Please make sure this gets added to the list of meetings at https://datatracker.ietf.org/meeting/upcoming.ics.   Or failing that, please include a .ics in the announcement or preferably both. While I'm on the subject, this is a Friday night during dinner for me, Friday/Saturday overnight for Europe and it looks like Friday morning for the Pacific.   That doesn't appear to make a lot of sense - was no earlier time during the week possible?  Or how would we know? We used to do this by Doodle poll but the last two times (I'm including the time we didn't end up meeting due to pushback by the participants shortly before the IETF meeting) the chairs have just appeared to pick a date and time without reaching out for our schedules.   I'm still waiting for a meeting time that's actually during my working day and during my working week. At this time I can't commit to the meeting - I'll try and see if I work around some already scheduled personal events. Later, Mike On 11/28/2020 12:02 AM, IAB Executive Administrative Manager wrote: > The RFC Editor Future Development (rfcefdp) Program will hold > a virtual interim meeting on 2020-12-18 from 00:00 to 01:30 Europe/Zurich (23:00 to 00:30 UTC on 2020-12-17). > > Agenda: > Continue on Issues 12, 24, 13. Maybe touch further on Issue 14. > > Information about remote participation: > https://cisco.webex.com/cisco/j.php?MTID=m46c39cb3ba692f4478c24819c0fbe54a > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From nobody Sun Nov 29 20:21:18 2020 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 1EA873A0E5F for ; Sun, 29 Nov 2020 20:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-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 GrOMDaQW2awz for ; Sun, 29 Nov 2020 20:21:12 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 1AEFE3A0E43 for ; Sun, 29 Nov 2020 20:21:11 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id h20so9783060qkk.4 for ; Sun, 29 Nov 2020 20:21:11 -0800 (PST) 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=1kku8wYCu29W/sJGasAE2zIwnD4pOzxNHMK7BceyNcU=; b=GSfpIGmW3+KEzpnQ3X66ukCBH3n2/ESyrRU8vcMmg4aqlFn4fjgjyCzxH2zXcPChC+ po0FMdTWgX9nnk3hoZuIcK6yDpvXMyEX9Y8MouRbKJkYd4KMtBDRf4gGPSLVc0GTYlsL O5Paqbno/UVY26GG+HU77Y1HzcXpKi7XJCQkceLX/DKXyMlxFWBFlfHt5dDT9pJ1zmsh JXrRfPWWTAiGzGIrAVS0t4suOj4Z4kQLI5kNJY5euQwyF664LD12bwYllHb75AuEBrNl BUwL8i0p2Kexdwc0JLKVjCyNBDeShufFVMruXsE0O6P6/xSA5OBnsR8R+R7gTIFUPlBR cGoQ== 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=1kku8wYCu29W/sJGasAE2zIwnD4pOzxNHMK7BceyNcU=; b=I/JIhDwPucJd/wvV9BENuSKwvyfxWdLDyMikZF/DLUB3kIcMzzOxUpTYKPN93DAaFj wbCKg8s8RQ0AnJy7ArloqL8aa4EXh2kofuyQkzfNFLKOxJxmD3uvnZvz6Mmj/2Uro1bt hA61pPjX1r8ZduXz3WI0OjoMy0t9RRNW99G+u5qlTm131a1071dlFk+r2U5CpzI5vjcT IM8aOjIamUEwk4AwQb0G43cKbjshevdVyQi7YChnrv0RzF+R6tfIhtV1dvIat8w1uZQz VofsT67fZwQThGkCggR1r0Ou9tEwmSToTD8HOmYnfW311RO+0q5kscaeJmUipNQGCZ49 nyfA== X-Gm-Message-State: AOAM532dLBKcM4vivR7XtUCAwlWfWBa2FpzEg7JWGU/A75Io9GqjESAi sYWLM5h4rxQoJ82NtSrzYsx3lV792692rgbt X-Google-Smtp-Source: ABdhPJxAbFb1BIORD+fW44+4/QJ3yMp1SXgPr9Ozu0+gkkQsAlQts+2tVG75gMNj1hv+4lY4F6m5Yg== X-Received: by 2002:a05:620a:164b:: with SMTP id c11mr20761250qko.203.1606710070355; Sun, 29 Nov 2020 20:21:10 -0800 (PST) Received: from [192.168.1.23] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id r1sm9223831qta.32.2020.11.29.20.21.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 29 Nov 2020 20:21:09 -0800 (PST) To: rfced-future@iab.org References: <5EE071CB-30CA-474F-BFA5-45129FFFFCBA@cisco.com> <3689021a-b3b2-0baa-7463-45b677c72846@joelhalpern.com> From: Michael StJohns Message-ID: <643805e0-cc17-45e8-c945-bc2c0ba88b8f@nthpermutation.com> Date: Sun, 29 Nov 2020 23:21:08 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <3689021a-b3b2-0baa-7463-45b677c72846@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] **Consensus check on part of Issue 13: Is decision making in the strategy body open to all?** 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, 30 Nov 2020 04:21:17 -0000 Hi Eliot - I align strongly with Joel's view below. I also don't believe that your third point is well stated - instead: I believe "that there is consensus that the strategic body engages with the community, solicits its input, allows for observation of the decision process, and provides documentation of such decisions".   E.g. how the IESG, IAB and LLC generally operate - can listen on the call, and might be able to ask questions at the end, but not be part of the discussion for decisions taken (at least unless asked by the strategic body). I do not believe there is consensus on "engage openly with the body" which I take to mean "everyone gets to participate as an equal and is a decision maker for the strategic body". I believe there is no consensus on the set of decision makers yet.   My personal belief follows Joel's statement:  "if this [strategic] body [open to everyone] owns the whole strategic task, I think what you describe is a recipe for failure over time". Mike On 11/27/2020 4:05 PM, Joel M. Halpern wrote: > I do not understand the third point below. > If the strategic body is open to everyone to participate in, then that > seems to be the answer to "how is it composed". > > With a stronger senior technical publishing advisor than we seem to be > moving towards, I can see how that can work.  But if this body owns > the whole strategic task, I think what you describe is a recipe for > failure over time. > > Sure, we can make it work for a while.  We are making the current > setup work for a while.  But our goal is a long term structure, and I > just don't see it working well.  Given the number of working groups I > have seen where strong differences in philosophy have practically > paralyzed the working group, combined with the strong differences in > philosophy I have seen in this group, I have trouble getting my head > around how this is expected to actually work. > > Having said that I will reiterate that having a means for community > participation that is a serious part of the process seems to me to be > a good thing.  I am not saying "go away and let the experts do this > behind closed doors." > > Yours, > Joel > > On 11/27/2020 10:39 AM, Eliot Lear wrote: >> Please let us know in within the next three weeks if you disagree >> with any of the following: >> >> • The chairs think that everybody agrees that there is some strategic >> body >> >> • The chairs think that strategic decisions get documented in RFCs >> >> • The chairs think that there is consensus that the strategic body is >> open to all to engage openly, and that meetings should be open, >> minuted, agendas posted.  This is not to say that there is consensus >> about how the strategic body is composed. >> >> These points obviously do not close Issue 13. >> >> > From nobody Sun Nov 29 20:46:34 2020 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 714B53A0EF3 for ; Sun, 29 Nov 2020 20:46:33 -0800 (PST) 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, 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=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 vGHecD2KUo98 for ; Sun, 29 Nov 2020 20:46:32 -0800 (PST) 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 CF0E73A0EF1 for ; Sun, 29 Nov 2020 20:46:31 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id v143so9812760qkb.2 for ; Sun, 29 Nov 2020 20:46:31 -0800 (PST) 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=kq3eSpWYK9nqL4v1uwrPFKcrYcLoXLZ/TaCypYpWIvs=; b=avqQE4YRAHVWu4+tZ3LD0LWCrnYCDF7wSSPL7gLgAJ0lQVGIsGNQmNza07hxJRMT+L aMV673W1NUkGzGzX2GzEQ6CI4Otu3V0WUtq9xWahB4/E1OsJA5po8fil7TvEkPErfm/G uVj6CqUal90gqpHUVUBxktX/SP9Qj308E77d3mUr2A29OTVP0/l1FvaPoqdOHsIWyeWB LhoclKedi8BUVY3bz1cmWTb9SEk3Vdvi9TRCCSrELjorFhSOBfZok928RYW7a7PYim4s YS8AzrDF3PP/Rzuq5vmFP2W7WmWgrrx2JGP6HCmLIQNotFCdwQ3IHjcId6JcbSek5uRh aniw== 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=kq3eSpWYK9nqL4v1uwrPFKcrYcLoXLZ/TaCypYpWIvs=; b=COck0dE4QqIrVQASxIgb+WmmKqLu4ili89hZmlsPmTNioaRO2P6NvtI44heEgCpIN4 ti+3/yvs0OpQdu7cuOJSYo5++Tv41lUQGoE2rZh/cNdVA6RCdGQEc+/UPz6XB+lzKzE6 ad+HN/K0XHZemN6oUwEiiYMsfuFhXgdkpjZ9Dul3l4+0nxltPEmRrYOHByXHSvYIeeQl LO8tAuCuO6I3Go/ekYST1SWlD05h0u+U+iR/EPDvDJ7sZDnVvKWu1rnIwtxx1WFvnH67 wg4VLV1W/gNj6upsEzmiCgp9mUJREcMmlk6y+nV2Uo0UpstXGWMwgbuqmDFfAetGgdR8 DaEw== X-Gm-Message-State: AOAM533gv05nDD8xHivZgtxub54l9hOKwtqtliut3PMcBObsgbByndq6 eYSKj+4de0LuPLuQgkZEYUWHoA== X-Google-Smtp-Source: ABdhPJyn2mzJUC/DtiKzl2qbLnfHht3Zp1pS44U/Emptn3V1Pw81rAPAPkVjWn3m2W+VDBshe+kNNQ== X-Received: by 2002:a05:620a:886:: with SMTP id b6mr19913541qka.427.1606711590564; Sun, 29 Nov 2020 20:46:30 -0800 (PST) Received: from [192.168.1.23] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id b17sm14308600qkl.123.2020.11.29.20.46.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 29 Nov 2020 20:46:29 -0800 (PST) To: rfced-future@iab.org, Cindy Morgan References: <160653974994.12259.12100973874618348178@ietfa.amsl.com> From: Michael StJohns Message-ID: <13c48f4a-0ada-d4ae-b8e1-118be9852fb8@nthpermutation.com> Date: Sun, 29 Nov 2020 23:46:28 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.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] RFC Editor Future Development (rfcefdp) PROGRAM Virtual Meeting: 2020-12-18 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, 30 Nov 2020 04:46:34 -0000 On 11/29/2020 10:32 PM, Michael StJohns wrote: > Hi - Please make sure this gets added to the list of meetings at > https://datatracker.ietf.org/meeting/upcoming.ics.   Or failing that, > please include a .ics in the announcement or preferably both. *sigh* For some reason, Thunderbird is not picking up this meeting from the .ics file.  I'm not sure why.   I manually downloaded the .ics and confirmed that the meeting is already there in the file.  So ignore the comment above. > > While I'm on the subject, this is a Friday night during dinner for me, > Friday/Saturday overnight for Europe and it looks like Friday morning > for the Pacific.   That doesn't appear to make a lot of sense - was no > earlier time during the week possible?  Or how would we know? *sigh* and I can't read.  This is Thursday night for me.  17 December.  So ignore the above. > > We used to do this by Doodle poll but the last two times (I'm > including the time we didn't end up meeting due to pushback by the > participants shortly before the IETF meeting) the chairs have just > appeared to pick a date and time without reaching out for our > schedules.   I'm still waiting for a meeting time that's actually > during my working day and during my working week. This still applies. > > At this time I can't commit to the meeting - I'll try and see if I > work around some already scheduled personal events. And this - some holiday related stuff is popping up at night. Mike > > Later, Mike > > > On 11/28/2020 12:02 AM, IAB Executive Administrative Manager wrote: >> The RFC Editor Future Development (rfcefdp) Program will hold >> a virtual interim meeting on 2020-12-18 from 00:00 to 01:30 >> Europe/Zurich (23:00 to 00:30 UTC on 2020-12-17). >> >> Agenda: >> Continue on Issues 12, 24, 13.  Maybe touch further on Issue 14. >> >> Information about remote participation: >> https://cisco.webex.com/cisco/j.php?MTID=m46c39cb3ba692f4478c24819c0fbe54a >> >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > > From nobody Mon Nov 30 00:19:34 2020 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 67E1B3A1107 for ; Mon, 30 Nov 2020 00:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 B_vkIQfNGQJP for ; Mon, 30 Nov 2020 00:19:30 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B85E3A107C for ; Mon, 30 Nov 2020 00:19:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2417; q=dns/txt; s=iport; t=1606724370; x=1607933970; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=TXhJXW/a8+k3Znm6BxuyvAMIkzZ4qVbqD294wVNQTas=; b=D2JjC+Tweb187c6D1gMUutfzT3WAwWIed3qCM+oQ9GB63rnaMz2JLkWZ zI/02bHd6qzNECBlGUKFxNiUIsWhvi2NsfxrLbOPuNrfVlEJlpl96IBhY UXiTSlsHQsxF7k0rB9iSFBHcjYTVup/cjwiHh2cRWk48BfHhvC44wnQla 8=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0CLBADbqcRf/xbLJq1iHQEBAQEJARIBBQUBQIFPg3UBI?= =?us-ascii?q?BKNcKRQBAQDAQEBCgMBAS8EAQGESgKCKiY4EwIDAQEBAwIDAQEBAQUBAQECA?= =?us-ascii?q?QYEcYVthXMGeRBRVwaDOQGDBqpoAVN0gTSFV4RbEDeBAYFTjAiCAIE4HIIoA?= =?us-ascii?q?YhygiwEnGCcCoJ6BIMZgTeWWAMfkmCPNLBqg2oCBAYFAhWBbSOBVzMaCBsVZ?= =?us-ascii?q?QGCPz0SGQ1YnBNAA2cCBgoBAQMJj3YBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,381,1599523200"; d="asc'?scan'208";a="31445429" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Nov 2020 08:19:26 +0000 Received: from [10.61.244.99] ([10.61.244.99]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AU8JOsX023834 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Nov 2020 08:19:26 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_827FA9B9-9EA0-492C-8266-F5946AAFF043"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 30 Nov 2020 09:19:23 +0100 In-Reply-To: <13c48f4a-0ada-d4ae-b8e1-118be9852fb8@nthpermutation.com> Cc: rfced-future@iab.org To: Michael StJohns References: <160653974994.12259.12100973874618348178@ietfa.amsl.com> <13c48f4a-0ada-d4ae-b8e1-118be9852fb8@nthpermutation.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.244.99, [10.61.244.99] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Meeting dates and doodles 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, 30 Nov 2020 08:19:32 -0000 --Apple-Mail=_827FA9B9-9EA0-492C-8266-F5946AAFF043 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Mike, Just on this: >>=20 >> We used to do this by Doodle poll but the last two times (I'm = including the time we didn't end up meeting due to pushback by the = participants shortly before the IETF meeting) the chairs have just = appeared to pick a date and time without reaching out for our schedules. = I'm still waiting for a meeting time that's actually during my working = day and during my working week. >=20 >=20 > This still applies. The goal here is to rotate times and to meet approximately every month, = as agreed. I wanted to hold true to that which is why I proposed just = a hair less a month after the previous meeting. You should expect the = next meeting to take place during the week of the 11th of January during = the morning hours, EST, afternoon hours Europe, evening hours in India, = and at inconvenient hours AU/NZ/CN/JP. Again, this is a hair less than = a full month, but again one full month falls on a weekend, and a holiday = weekend in the US. The following meeting would take place approximately the week of the = 15th of February during the morning hours in Europe, afternoon hours in = India, evening hours in AU/NZ/JP/CN, and inconvenient hours EST. This = might be a bit longer than four weeks, but evens spacing between the = previous meeting and the IETF. I will put out a doodle first for the January meeting and next for the = February meeting. Ok? Eliot --Apple-Mail=_827FA9B9-9EA0-492C-8266-F5946AAFF043 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/EqwsACgkQh7ZrRtnS ejOXSggArgLT8GTq7e1n1tFOmyX1vISetVmtXR68dQ3v1+FxBtZhyFeSkL3N14GU NnO9iviVyKk5tAn8JCQ5jmig5f9GtLKvf9Cu2lncXwv5dqBl9I0l8NLoq9BMzhPN GBRUVHPvdLGHJ5PRxahRIV6mA+cDcNFpdbnROULMvD78gOfGvBKDlLUmD4l6L1BH U/mKlQhxbFZ0s4x8v5ssgnbYOCKZKDz1L/G43WTOv+A9yWB3LIa6rB5srnd9BX4c yca9QVY8IfFw+3wbPlH19YCRM0zwgy5Ew3bi4LOr2+HLfH9GLuK2B5nRrhO+6752 djsKxTxbXPXldSxPW9SWDPaIAebnSw== =eVis -----END PGP SIGNATURE----- --Apple-Mail=_827FA9B9-9EA0-492C-8266-F5946AAFF043-- From nobody Mon Nov 30 10:38:05 2020 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 6D16E3A1038 for ; Mon, 30 Nov 2020 10:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-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 wKPEIYfN6vq0 for ; Mon, 30 Nov 2020 10:38:02 -0800 (PST) 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 12A0B3A103A for ; Mon, 30 Nov 2020 10:38:00 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id e60so8947893qtd.3 for ; Mon, 30 Nov 2020 10:38:00 -0800 (PST) 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=vs49YVKLskRRXKzHSUXtW3/xqZChrt2j/Q83DcU5CQk=; b=N+mHrT2GRAztYJPBJo4cNNTRwwohKbrqViuNsSjooYl+typA2HeIRncxQqPfq2Nbjy CHLiKN8Dn1BhxwNStt4G66R9SbxSeVXPAL/a5+R0lUhT6vj8N7V2yBA6nArngKMHuZ5+ kT/nw1Pm1AeYMlLq0HaK5OpMQpGjQD+RX8QEdtAEn+Ecznn/MZZmf67XRtj/P+D6Y5Su GuiandqI0nuCEEn94yGdiZKKbpuO/jYcrvX+78mAXalvWeBd7JbcaJQCwepP/qxtAaw5 gz0WhbWO+E6It0EtfPTQLcsbLqFerR8Nk4Vwxgc/HTzODPvm5tYLDan0UzTHRV3U7efb tJtg== 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=vs49YVKLskRRXKzHSUXtW3/xqZChrt2j/Q83DcU5CQk=; b=OWhy/SwEoTmnPNsDU098/gqLtX+E6ucxCqS0qKUnKeuKZ/sqhlUTAdwU+duasBCcHv rxR59eVDbcdOFUHCvkZbZz7lUxFRweRYd3JLsxXB6SESry7mdhoGrP5zSPgFaObAr7DK TLC3KrjwV9EhyJyoDnTN7gfNSIRxbi9vl2PFpXxTbh9eAlONuQe2K7owsk6O1Z5sSL7Q exE+e1NKHR1xfGZfaiXsQVjB+M7JWxuUEHejeVQRGTimMpcKlcUYVNicbkn0fSx+s9cA OFeumwGpgZJmIEvu9dMAqeiOPnfiAiGTAhaktmcbSXq8ywC0kx61R7QzBju1dBYmVmeZ UJxQ== X-Gm-Message-State: AOAM530+biFdcetmVwBJY6PZfxqC/SYoHrzT6fCVFtgSQYjsanbwKoEt Q3a0yxBcwFSj0C7te7ujN6x4WVMlFkUTnpNG X-Google-Smtp-Source: ABdhPJwRRhR92MFmUS1fZpdYl1rhbDCn1jfihniJlmFa6Twrq5yDr4h5LiXFtmFYIqR2jG4pfKmPSQ== X-Received: by 2002:aed:2a84:: with SMTP id t4mr23843664qtd.251.1606761479411; Mon, 30 Nov 2020 10:37:59 -0800 (PST) Received: from [192.168.1.23] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id z20sm17213807qtb.31.2020.11.30.10.37.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 Nov 2020 10:37:58 -0800 (PST) To: Eliot Lear Cc: rfced-future@iab.org References: <160653974994.12259.12100973874618348178@ietfa.amsl.com> <13c48f4a-0ada-d4ae-b8e1-118be9852fb8@nthpermutation.com> From: Michael StJohns Message-ID: <0ecdab62-9fa4-b7b7-8b03-03b6136ea612@nthpermutation.com> Date: Mon, 30 Nov 2020 13:37:57 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Meeting dates and doodles 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, 30 Nov 2020 18:38:03 -0000 On 11/30/2020 3:19 AM, Eliot Lear wrote: > Hi Mike, > > Just on this: > >>> We used to do this by Doodle poll but the last two times (I'm including the time we didn't end up meeting due to pushback by the participants shortly before the IETF meeting) the chairs have just appeared to pick a date and time without reaching out for our schedules. I'm still waiting for a meeting time that's actually during my working day and during my working week. >> >> This still applies. > > The goal here is to rotate times and to meet approximately every month, as agreed. This will be the I think the 6th meeting including the two at IETFs. I've lost track. Only one of which have been scheduled for a work time for me (e.g. during the previous virtual IETF which worked out to be about 9am for me) and two of which have been scheduled after midnight ( I'm including the Bangkok IETF one). This will be the second one scheduled during my nominal dinner time. Not generally a problem, but we're in the holiday season and doing what we can to deal with Covid distances. > I wanted to hold true to that which is why I proposed just a hair less a month after the previous meeting. You should expect the next meeting to take place during the week of the 11th of January during the morning hours, EST, afternoon hours Europe, evening hours in India, and at inconvenient hours AU/NZ/CN/JP. Do we actually have anyone participating from India or even Japan/China? I ran the numbers and 3PM EST looked like a time slot where no one had to be up after midnight nor up before 8am assuming the lack of those participants. I don't have a problem with sharing the pain if there are active participants from that region. (Jay - apologies if I've got you located in the wrong region - I *think* you're somewhere in Australia - not India?) > Again, this is a hair less than a full month, but again one full month falls on a weekend, and a holiday weekend in the US. > > The following meeting would take place approximately the week of the 15th of February during the morning hours in Europe, afternoon hours in India, evening hours in AU/NZ/JP/CN, and inconvenient hours EST. And depending on the time also inconvenient hours for PST. That would be the third time for inconvenient - e.g. post midnight hours - for me (5/27, IETF Bangkok virtual being the other two). Seems high for 8 meetings given that you seem to be slicing the world into 4 or 5 pieces. > This might be a bit longer than four weeks, but evens spacing between the previous meeting and the IETF. > > I will put out a doodle first for the January meeting and next for the February meeting. Ok? > > Eliot > > Later, Mike From nobody Mon Nov 30 10:46:21 2020 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 5E9CC3A104B for ; Mon, 30 Nov 2020 10:46:20 -0800 (PST) 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 2o4z6ezTTrZh; Mon, 30 Nov 2020 10:46:18 -0800 (PST) Received: from [192.168.1.101] (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 5FF113A0AC1; Mon, 30 Nov 2020 10:46:18 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-D734F0A4-B47D-4E3A-9FFC-00676182F10D Content-Transfer-Encoding: 7bit From: Jay Daley Mime-Version: 1.0 (1.0) Date: Tue, 1 Dec 2020 07:46:16 +1300 Message-Id: <05EEAB53-BD4B-4073-9FEA-CAAA83F350EE@ietf.org> References: <0ecdab62-9fa4-b7b7-8b03-03b6136ea612@nthpermutation.com> Cc: Eliot Lear , rfced-future@iab.org In-Reply-To: <0ecdab62-9fa4-b7b7-8b03-03b6136ea612@nthpermutation.com> To: Michael StJohns X-Mailer: iPad Mail (18B92) Archived-At: Subject: Re: [Rfced-future] Meeting dates and doodles 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, 30 Nov 2020 18:46:20 -0000 --Apple-Mail-D734F0A4-B47D-4E3A-9FFC-00676182F10D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 1/12/2020, at 7:38 AM, Michael StJohns wrote: >=20 > =EF=BB=BFOn 11/30/2020 3:19 AM, Eliot Lear wrote: >> Hi Mike, >>=20 >> Just on this: >>=20 >>>> We used to do this by Doodle poll but the last two times (I'm including= the time we didn't end up meeting due to pushback by the participants short= ly before the IETF meeting) the chairs have just appeared to pick a date and= time without reaching out for our schedules. I'm still waiting for a meet= ing time that's actually during my working day and during my working week. >>>=20 >>> This still applies. >>=20 >> The goal here is to rotate times and to meet approximately every month, a= s agreed. >=20 > This will be the I think the 6th meeting including the two at IETFs. I'v= e lost track. Only one of which have been scheduled for a work time for me (= e.g. during the previous virtual IETF which worked out to be about 9am for m= e) and two of which have been scheduled after midnight ( I'm including the B= angkok IETF one). This will be the second one scheduled during my nominal d= inner time. Not generally a problem, but we're in the holiday season and d= oing what we can to deal with Covid distances. >=20 >> I wanted to hold true to that which is why I proposed just a hair less a= month after the previous meeting. You should expect the next meeting to ta= ke place during the week of the 11th of January during the morning hours, ES= T, afternoon hours Europe, evening hours in India, and at inconvenient hours= AU/NZ/CN/JP. >=20 > Do we actually have anyone participating from India or even Japan/China? = I ran the numbers and 3PM EST looked like a time slot where no one had to b= e up after midnight nor up before 8am assuming the lack of those participan= ts. I don't have a problem with sharing the pain if there are active parti= cipants from that region. (Jay - apologies if I've got you located in the w= rong region - I *think* you're somewhere in Australia - not India?) Even simpler - New Zealand, as are Nevil and Brian. Jay --=20 Jay Daley IETF Executive Director >=20 >=20 >> Again, this is a hair less than a full month, but again one full month f= alls on a weekend, and a holiday weekend in the US. >>=20 >> The following meeting would take place approximately the week of the 15th= of February during the morning hours in Europe, afternoon hours in India, e= vening hours in AU/NZ/JP/CN, and inconvenient hours EST. >=20 > And depending on the time also inconvenient hours for PST. >=20 > That would be the third time for inconvenient - e.g. post midnight hours -= for me (5/27, IETF Bangkok virtual being the other two). Seems high for = 8 meetings given that you seem to be slicing the world into 4 or 5 pieces. >=20 >> This might be a bit longer than four weeks, but evens spacing between the= previous meeting and the IETF. >>=20 >> I will put out a doodle first for the January meeting and next for the Fe= bruary meeting. Ok? >>=20 >> Eliot >>=20 >>=20 > Later, Mike >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future >=20 --Apple-Mail-D734F0A4-B47D-4E3A-9FFC-00676182F10D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


    On 1/12/2020, at 7:38 AM, Mich= ael StJohns <msj@nthpermutation.com> wrote:

    =
    =EF=BB=BFOn 11/30/2020 3:19= AM, Eliot Lear wrote:
    Hi Mike,

    Just on this:

    =
    We used to do this= by Doodle poll but the last two times (I'm including the time we didn't end= up meeting due to pushback by the participants shortly before the IETF meet= ing) the chairs have just appeared to pick a date and time without reaching o= ut for our schedules.   I'm still waiting for a meeting time that'= s actually during my working day and during my working week.

    This still applies.

    The goal here is to rotate times and to meet appr= oximately every month, as agreed.

    This will be the I think  the 6th meeting including the two at IETFs= .  I've lost track.  Only one of which have been scheduled for a w= ork time for me (e.g. during the previous virtual IETF which worked out to b= e about 9am for me) and two of which have been scheduled after midnight ( I'= m including the Bangkok IETF one).  This will be the second one schedul= ed during my nominal dinner time.   Not generally a problem, but w= e're in the holiday season and doing what we can to deal with Covid distance= s.

     I wante= d to hold true to that which is why I proposed just a hair less a month afte= r the previous meeting.  You should expect the next meeting to take pla= ce during the week of the 11th of January during the morning hours, EST, aft= ernoon hours Europe, evening hours in India, and at inconvenient hours AU/NZ= /CN/JP.

    Do we actually have an= yone participating from India or even Japan/China?   I ran the num= bers and 3PM EST looked like a time slot where no one had to be up after mid= night  nor up before 8am assuming the lack of those participants. =   I don't have a problem with sharing the pain if there are active part= icipants from that region.   (Jay - apologies if I've got you loca= ted in the wrong region - I *think* you're somewhere in Australia - not Indi= a?)

    Even simpler - New Zeal= and, as are Nevil and Brian.

    Jay
    -- <= /span>
    Jay Da= ley
    IETF Executive Director


    &nb= sp;Again, this is a hair less than a full month, but again one full month fa= lls on a weekend, and a holiday weekend in the US.

    The following meeting would take place approximately the week of t= he 15th of February during the morning hours in Europe, afternoon hours in I= ndia, evening hours in AU/NZ/JP/CN, and inconvenient hours EST.

    And depending on the time also inconvenien= t hours for PST.

    That would be the third ti= me for inconvenient - e.g. post midnight hours - for me  (5/27, IETF Ba= ngkok virtual being the other two).   Seems high for  8 meeti= ngs given that you seem to be slicing the world into 4 or 5 pieces.
    This might be a bit longe= r than four weeks, but evens spacing between the previous meeting and the IE= TF.

    I will put out a doodle first for the= January meeting and next for the February meeting.  Ok?

    Eliot
    =

    Later, Mike


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

    = --Apple-Mail-D734F0A4-B47D-4E3A-9FFC-00676182F10D--