From nobody Mon Jun 1 11:42: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 AF1D13A1464 for ; Mon, 1 Jun 2020 11:42:47 -0700 (PDT) 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 zUBxTtX4q5xi for ; Mon, 1 Jun 2020 11:42:46 -0700 (PDT) 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 9D8C43A1428 for ; Mon, 1 Jun 2020 11:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7106; q=dns/txt; s=iport; t=1591036965; x=1592246565; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Erlidko9QbSlj6xod45WDsym0WA0o2TzUOXyjxcn8RI=; b=X29ygZVC+BZpyHudsB0i3V/EwVjoLgkvDKoNUTJIE/qBWjwN+QtcNe97 zGDXVFaEG1vq9XmAEPDNWWiLqGUIDDDnxwukqEbdAuXKET/04pSV0cbiM oSa2ikKaKrav90EdFkD7+2A6/+aNmX267FeJD9NRiHVgMTkYyiDp4YWE8 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D0AACYS9Ve/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGBeQQBAQsBgXKBeQEgEiyEJYkBiAuTZYYpgWgLAQEBDAEBLwQ?= =?us-ascii?q?BAYREAoInJTcGDgIDAQELAQEFAQEBAgEGBG2FZYVyAQEBAQIBDhVCFAULCxg?= =?us-ascii?q?VFQICVwYTFIMSgl0grit2gTKFUYUDgTgBjGCCAIE4HIIfLj6EBy1ZglUzgi0?= =?us-ascii?q?EoneQWIJhgnqVdR6CZokHhGiCfoVHhH6rDYNMAgQGBQIVgWkjgVYzGggbFTs?= =?us-ascii?q?qAYI+PhIZDZBMF44nPwMwNwIGAQcBAQMJjW8BAQ?= X-IronPort-AV: E=Sophos; i="5.73,461,1583193600"; d="scan'208,217"; a="26698507" 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; 01 Jun 2020 18:42:40 +0000 Received: from [10.61.209.159] ([10.61.209.159]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 051Ige4N015128 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Jun 2020 18:42:40 GMT From: Eliot Lear Message-Id: <86380D7A-0F7B-4A2D-99C6-42415EE6AD15@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_971F0E35-DC8A-4BD0-B247-175A11DC00EF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 1 Jun 2020 20:42:39 +0200 In-Reply-To: Cc: rfced-future@iab.org To: John C Klensin References: <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <59C37AD1-2458-40D8-976B-678680649F15@vigilsec.com> <3424f79d-72f2-4397-5cfe-c68f3f101953@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.209.159, [10.61.209.159] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Who has the authority? [On the question of a living series] 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, 01 Jun 2020 18:42:48 -0000 --Apple-Mail=_971F0E35-DC8A-4BD0-B247-175A11DC00EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To preface, to me I think this is just the right level of conversation = to be having. Please see below for one informational comment, a = suggestion, and a question or three: > On 1 Jun 2020, at 00:34, John C Klensin wrote: >=20 >=20 > I think it would be fine to put some or all of the stream > managers on the/an editorial board, especially if it were clear > that their role was to advocate for the requirements of their > particular streams. But, given the number of times in the last > decade or so when individuals in leadership roles have > demonstrated a lack of knowledge about what they don't know in > areas far removed from the networking skills for which they were > appointed, we'd best be such they cannot dominate the editorial > board either by outvoting everyone else or applying force of > personality and suggesting that, because of other roles, they > are naturally in charge. >=20 The informational point is this: we have a good many structures from = which to choose, only some of which we have explored. It will come down = to our problem statements/goals as to which fits best. As best we can, = my suggestion is that we keep things simple so that everyone understands = how things are supposed to work. For instance: One axis one thinks about is the speed with which decisions are made. = Mike raised concerns about decision paralysis, for instance. We have = certainly seen that happen in the past. On the other hand, stability = has a certain value. Where on the axis do we want to live, and how does = the model take that into account? Another axis one thinks about is how the RSE is accountable. Less = direct means that if there=E2=80=99s a problem, there is less ability to = seek redress. The most direct form is direct elections by some set of = individuals. Slightly less direct is the NOMCOM. Most indirect, would = be the stream managers, as John alludes. =20 Another axis is how often the RSE is re-appointed. The shorter the = period the more the overhead, but the longer the period the longer one = might need to wait if a change is to be sought. All of this side steps what the responsibilities of the RSE actually = are. Again, here we have freedom. We could say that we will not decide = any of those responsibilities, and leave that to those the community = appoints. We could provide a starter list of things we think are = important, and the committee to add/amend/delete. We could state = immutable principles, and let the committee fill in the gaps or balance = them off. This last one, by the way, is very close to what we did in = mtgvenue, and I think we are actually very close to being able to do = just that, if we were to choose this direction. Thoughts? Eliot --Apple-Mail=_971F0E35-DC8A-4BD0-B247-175A11DC00EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 To = preface, to me I think this is just the right level of conversation to = be having.  Please see below for one informational comment, a = suggestion, and a question or three:

On 1 Jun = 2020, at 00:34, John C Klensin <john-ietf@jck.com> wrote:


I think it would be fine to put = some or all of the stream
managers on the/an editorial = board, especially if it were clear
that their role was to = advocate for the requirements of their
particular streams. =  But, given the number of times in the last
decade or = so when individuals in leadership roles have
demonstrated = a lack of knowledge about what they don't know in
areas = far removed from the networking skills for which they were
appointed, we'd best be such they cannot dominate the = editorial
board either by outvoting everyone else or = applying force of
personality and suggesting that, because = of other roles, they
are naturally in charge.


The informational point is this: we have a good = many structures from which to choose, only some of which we have = explored.  It will come down to our problem statements/goals as to = which fits best.  As best we can, my suggestion is that we keep = things simple so that everyone understands how things are supposed to = work.  For instance:

One axis = one thinks about is the speed with which decisions are made.  Mike = raised concerns about decision paralysis, for instance.  We have = certainly seen that happen in the past.  On the other hand, = stability has a certain value.  Where on the axis do we want to = live, and how does the model take that into account?

Another axis one thinks about is how the RSE is = accountable.    Less direct means that if there=E2=80=99s a = problem, there is less ability to seek redress.  The most direct = form is direct elections by some set of individuals.  Slightly less = direct is the NOMCOM.  Most indirect, would be the stream managers, = as John alludes.
 
Another axis = is how often the RSE is re-appointed.  The shorter the period the = more the overhead, but the longer the period the longer one might need = to wait if a change is to be sought.

All of this side steps what the = responsibilities of the RSE actually are.  Again, here we have = freedom.  We could say that we will not decide any of those responsibilities, and leave that to = those the community appoints. We could provide a starter list of things = we think are important, and the committee to add/amend/delete.  We = could state immutable principles, and let the committee fill in the gaps = or balance them off.  This last one, by the way, is very close to = what we did in mtgvenue, and I think we are actually very close to being = able to do just that, if we were to choose this direction.

Thoughts?

Eliot

= --Apple-Mail=_971F0E35-DC8A-4BD0-B247-175A11DC00EF-- From nobody Mon Jun 1 12:16: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 3ED1F3A14D8 for ; Mon, 1 Jun 2020 12:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 6HXHWjtX_ZXW for ; Mon, 1 Jun 2020 12:16:19 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 C699C3A14DE for ; Mon, 1 Jun 2020 12:16:17 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id 205so10200607qkg.3 for ; Mon, 01 Jun 2020 12:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=9VRx10tc6HSC8VTXTs66Iyhf6N2uUwZUJ1ofDjFrQyc=; b=GTSaizr5vmLcoFOT+rkvcKFV6+5MGQI201eJGIaWGHMpLGR5a2+8jmPWi0l+OaFtfB 5SedlvL3uxyG1ADdn1zDXII+It4AE1s9bF+UIW3ea8BTnuaO/YqH68b2dudzExQAjioS y6mf11xF5cGLTZxUY9D/V8n4Q9a7GBzqqCaJcraVk9HBzMTCRAsR5pWFFuWslxqc30PY SjR/xRsvVQjWzbxcC7lvHfuah2MTYFTlo9sDIvfBEqNzqBhpO6GdtPyL0WbgPeBzC7bC MIl0eqCqhCXh9UBOm8233YOf4Q3u1qPKA19vJzumuNcQ7b6pW16VkaNvE/OV/S5OGLsr 8hQA== 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=9VRx10tc6HSC8VTXTs66Iyhf6N2uUwZUJ1ofDjFrQyc=; b=hWYMsMowwxKlbXNMhBGhumqYmOqMoqATIvbbbhfMplL5Y85FmVCHJloqqv//ZGGbQH syidzZ7TIekRLwGM1yI5CAoeMyNS1FwHkcRUBGjx+vzFJYE2FAsgtQ1v7GTk8ajOj54A BTtXHnsLgfgxnvZNNu4ABhXMdNPPZksD9wbYS8urL778Dp6eUSvLD9BCj8Wsz6DAk7Or qk8vCUijH7auP21D5W8CHnmuJFXgPppo7bcfiu3d1ejEyB3gR6o0KTqvXtZS0bxzs+9d IpwkL0OE1tqxpaqPn5+QM6d0pX2VqRmcZSNCjVx00H6I6Dy+UwNAF2lovbHq6SdJDPPO 3ppw== X-Gm-Message-State: AOAM530HwOV/UodFQFe+VBzwgHQkesASW94NGPNKNnVZlvcP8Qqch+IK oU+wtaeLJX8yWquZd2+Gj/ce896h7Dk= X-Google-Smtp-Source: ABdhPJxM9ElfnSU0EJwNt4UUlNbMD6yCwGSPmxpnsKuJnC9oXdxwgq0Z9olz/GFglHxcBXIISRxngw== X-Received: by 2002:a37:2702:: with SMTP id n2mr22143880qkn.5.1591038976121; Mon, 01 Jun 2020 12:16:16 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id h19sm128640qkl.49.2020.06.01.12.16.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 12:16:15 -0700 (PDT) To: rfced-future@iab.org References: <8B2B4794-D148-4EE7-BC05-4614E4E922E4@csperkins.org> <2F9B8AD6-25DB-4989-9355-C77025D739C6@vigilsec.com> <065D5755-1C98-458B-993A-700228EE2259@mnot.net> <59C37AD1-2458-40D8-976B-678680649F15@vigilsec.com> <3424f79d-72f2-4397-5cfe-c68f3f101953@gmail.com> <86380D7A-0F7B-4A2D-99C6-42415EE6AD15@cisco.com> From: Michael StJohns Message-ID: <4ab474ab-a7ed-00e2-c4c9-5dd690b03d33@nthpermutation.com> Date: Mon, 1 Jun 2020 15:16:15 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <86380D7A-0F7B-4A2D-99C6-42415EE6AD15@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] Who has the authority? [On the question of a living series] 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, 01 Jun 2020 19:16:21 -0000 On 6/1/2020 2:42 PM, Eliot Lear wrote: > Another axis one thinks about is how the RSE is accountable.    Less > direct means that if there’s a problem, there is less ability to seek > redress. Pure hyperbole and not even accurate, let alone precise. Accountability is built in to the RSE through the contract process.  The problem we had was not accountability for the RSE, but accountability for the RSOC and the accountability for the IAB.   In terms of the IAB I will note that not a single member of the IAB was retained from this last go around.     I have no idea how to impose accountability upon the RSOC. >  The most direct form is direct elections by some set of individuals. >  Slightly less direct is the NOMCOM.  Most indirect, would be the > stream managers, as John alludes. Actually, the most indirect is the current LLC -> IAB -> RSOC model.    The stream managers at least have some responsibility for editorial decisions related to their streams. I favor the RSE/LLC relationship as the means for RSE accountability because the LLC board collectively and the LLC itself are fiduciaries in the legal meaning.  I believe - perhaps naively - that ensuring contract decisions are made by them (against a well-written and fair contract) is the best way of preventing the failure modes that happened this last go around. And to be clear, I mean that they make the decisions and are responsible for the fallout from those decisions, both to the community and with respect to any legalities.  The IAB and IESG and IRTF and ISE  and for that matter any community member or special interest group can express their opinions, but the decisions would not be theirs. Later, Mike From nobody Tue Jun 2 01:19:17 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 92D7A3A0971; Tue, 2 Jun 2020 01:19:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rfced-future@iab.org, rfcefdp-chairs@ietf.org, lear@cisco.com, The IAB X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159108595502.5908.13588094218928356320@ietfa.amsl.com> Date: Tue, 02 Jun 2020 01:19:15 -0700 Archived-At: Subject: [Rfced-future] rfcefdp - New Meeting Session Request for IETF 108 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 08:19:16 -0000 A new meeting session request has just been submitted by Eliot Lear, a Chair of the rfcefdp working group. --------------------------------------------------------- Working Group Name: RFC Editor Future Development Area Name: Internet Architecture Board Session Requester: Eliot Lear Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: opsarea emu People who must be present: Eliot Lear Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jun 2 01:20:42 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 45CA93A09C0; Tue, 2 Jun 2020 01:20:40 -0700 (PDT) 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 fRO6pMm6BAVM; Tue, 2 Jun 2020 01:20:39 -0700 (PDT) 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 A74B63A09A2; Tue, 2 Jun 2020 01:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=928; q=dns/txt; s=iport; t=1591086039; x=1592295639; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=gGZsEEE9nll6WBwa3btF4bOG+ZX+kZmT4/ylDUBr9GA=; b=G6XDoRJzhgyGDa0uIsnwv5Npfoyl24LbYRsgB/7naDWuW6wB3tBs49PD aJPDW5Z+NZsPURhYqWpPihm80WuhLPjxyYnzQAHEpWQ39cfHragQmgNDu 5CcoxihYcrNSQ2fy36FzaHQGWY1KzrOgDuuHtGyThuNoMMSE3Ca8VnK62 c=; X-IPAS-Result: =?us-ascii?q?A0BpAQCNCtZe/xbLJq1lGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBSoNsASASLI0miA2bdwsBAQEMAQEvBAEBhEQCghslOBMCAwEBAQMCA?= =?us-ascii?q?wEBAQEFAQEBAgEGBG2FZYVyAQEBAQIBOj8FCwsSBi5JDhmDJoJdIK1EdIE0h?= =?us-ascii?q?VGFF4E4jGGCAIE4HIIfLj5rGQGDSU2CeoItBI5EI4lZmxKCYoJ7hzOOQh6CZ?= =?us-ascii?q?o1wjUREhEWmBYNMAgQGBQIVgWoigVYzGggbFWUBgj4+EhkNkFiOLwM/AzA3A?= =?us-ascii?q?gYIAQEDCY07AQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.73,463,1583193600"; d="scan'208";a="24388629" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Jun 2020 08:20:34 +0000 Received: from [10.61.209.225] ([10.61.209.225]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0528KYD3024115 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 2 Jun 2020 08:20:34 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: <159108595502.5908.13588094218928356320@ietfa.amsl.com> Date: Tue, 2 Jun 2020 10:20:33 +0200 Cc: The IAB Content-Transfer-Encoding: quoted-printable Message-Id: References: <159108595502.5908.13588094218928356320@ietfa.amsl.com> To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.209.225, [10.61.209.225] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] rfcefdp - New Meeting Session Request for IETF 108 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, 02 Jun 2020 08:20:40 -0000 We should expect this request to be amended as a new chair is added, and = as people inform me of conflicts. > On 2 Jun 2020, at 10:19, IETF Meeting Session Request Tool = wrote: >=20 >=20 >=20 > A new meeting session request has just been submitted by Eliot Lear, a = Chair of the rfcefdp working group. >=20 >=20 > --------------------------------------------------------- > Working Group Name: RFC Editor Future Development > Area Name: Internet Architecture Board > Session Requester: Eliot Lear >=20 >=20 > Number of Sessions: 1 > Length of Session(s): 100 Minutes > Number of Attendees: 50 > Conflicts to Avoid:=20 > Chair Conflict: opsarea emu >=20 >=20 >=20 >=20 >=20 >=20 >=20 > People who must be present: > Eliot Lear >=20 > Resources Requested: >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 >=20 From nobody Tue Jun 2 22:23:56 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 3C6583A0922 for ; Tue, 2 Jun 2020 22:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwNgBvfmuTQJ for ; Tue, 2 Jun 2020 22:23:54 -0700 (PDT) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 D1B103A091C for ; Tue, 2 Jun 2020 22:23:53 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id a10so423402uan.8 for ; Tue, 02 Jun 2020 22:23:53 -0700 (PDT) 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=LVgJci1YCcFWdfMEJVBZVEF9NSZveTuhLrUVlumQj8I=; b=thzv+CuBSCKXYUlGs0U1AA6ncQnMs+LhPahkKlkzMe3vjPqUk91GV6WPEJXsLduV35 etm5q+HcB8e9t/5ROqUxNYx/g6vBZUW3RAEtP5ijMABVqvSUVRdxDuyflRadn9jI4b/p qSxXj3k558ppIN2L2n+YM4fsmR2Ykrt2eBQobDTKawnuiFrWddqj1Ba9TT/HX9DSpgkL bilkeyoLNORwQxLpPkUutEAnzMLkGeUQHCSWdblyAFaBVzeKj7T7jFHdB8iar8X8a9A3 weIfYb5TT+54P+fHnVRaRtMGO02L3uY0YMd7mRMzotEfPNw/Q12UP+XUYWWy2x4EPLND eL8A== 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=LVgJci1YCcFWdfMEJVBZVEF9NSZveTuhLrUVlumQj8I=; b=Gd6FWOhg84uzuFb43ICQ08DVQO/5m4xTL2dC/CViWFtX9FPPnWYQtOeVa3WmvSCGtB yyhTvatxmTPc8cGqCaxYtyBorc7zK6O5MWlxg1wC5Y1AuT6/W5ZpeuKVFATbREe/DW+A HACbyLEMYFyCRbbWsdbq80bPSrR87Sraai1YhHtXik4621/V80XCYxnznddTYz18WlH8 0y8fm+rYOJ5sN9i11G1ceUWrVUH0UZ6vv5+t+Wjlp0suYYbeqW8JeUs9NSKfHNq3fwpf 5tiN4wUkVhJBhBHrOGOeKehYiMZrZED3mFJNbFGXFW/ly/GVZfsvnQbOFnHiJ8kjdDWO Jlxg== X-Gm-Message-State: AOAM530HERtjKBJeAOG2D4FbsOAE/JBCTBFflte5SnNUO6dGZhlRi+ZL D94uv/IuGPuXZP11rJTsi5GR5ACIyxUpXVX2TgErz4MabQQ= X-Google-Smtp-Source: ABdhPJzBNNPzzYskwsvtz9E2inwhv9KROVFsVqqyPKOfIfAnOqiGzmHCcsBHP0eqE9CUnONR485ufdalRQle9st6tuA= X-Received: by 2002:ab0:4873:: with SMTP id c48mr20451985uad.18.1591161832598; Tue, 02 Jun 2020 22:23:52 -0700 (PDT) MIME-Version: 1.0 From: Nevil Brownlee Date: Wed, 3 Jun 2020 17:23:26 +1200 Message-ID: To: rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000cff0fd05a7273b34" Archived-At: Subject: [Rfced-future] re "who decides" 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, 03 Jun 2020 05:23:55 -0000 --000000000000cff0fd05a7273b34 Content-Type: text/plain; charset="UTF-8" Thinking a bit more about an advisory board for the RSE (the "RSAB"), I liked Mike/s earlier idea of one selected by NomCom. How about this for a proposal: 1. The RSAB is advisory to the RSE, not an oversight or management committee. 2. Each of the Series Input Streams appoints an ex officio representative (non-voting). 3. The RSAB has 5 voting members, with staggered 3-year terms. 4. The voting members are selected by a NomCom, preferably an ISOC NomCom, and approved by the IAB. 5. The RSAB does policy stuff only; RPC contracts and performance are handled by our LLC. When suggestions for changes to the RFC Series arise, the RSE and RSAB will discuss them so as to achieve rough consensus within the RSAB. Any such consensus will be further discussed on the rfc-interest list, so as to reach a wider consensus within the IETF participants. (I use the term "voting" above only as a way to minimise demands from any of the Streams - we don't believe in voting!) This leave the question of "who selects the RSE, and how?" Maybe the RSAB could do it? Cheers, Nevil -- ----------------------------------- Nevil Brownlee, Taupo, NZ --000000000000cff0fd05a7273b34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thinking a bit more about an advisory board for the R= SE (the "RSAB"), I=C2=A0 liked Mike/s earlier idea of one selecte= d by NomCom.=C2=A0 How about this for a proposal:
1. The RSAB is = advisory to the RSE, not an oversight or management committee.
2.= Each of the Series Input Streams appoints an ex officio representative (no= n-voting).
3. The RSAB has 5 voting members, with staggered 3-yea= r terms.
4. The voting members are selected by a NomCom, preferab= ly an ISOC NomCom, and approved by the IAB.
5. The RSAB does poli= cy stuff only; RPC contracts and performance are handled by our LLC.
<= div>When suggestions for changes to the RFC Series arise, the RSE and RSAB = will discuss them so as to achieve rough consensus within the RSAB.=C2=A0 A= ny such consensus will be further discussed on the rfc-interest list, so as= to reach a wider consensus within the IETF participants.
(I use the term "voting" above only as a way to minimise demand= s from any of the Streams - we don't believe in voting!)
=
This leave the question of "who selects the RSE, = and how?"=C2=A0=C2=A0=C2=A0 Maybe the RSAB could do it?

=
Cheers, Nevil


--
----------= -------------------------
Nevil Brownlee, Taupo, NZ
--000000000000cff0fd05a7273b34-- From nobody Wed Jun 17 08:11:24 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 A6D113A07B7; Wed, 17 Jun 2020 08:11:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IAB Executive Administrative Manager To: "IETF Announcement List" Cc: rfc-interest@rfc-editor.org, rfced-future@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159240667857.3683.17444857051594857745@ietfa.amsl.com> Date: Wed, 17 Jun 2020 08:11:18 -0700 Archived-At: Subject: [Rfced-future] Brian Rosen to Serve as Additional RFC Editor Future Development Program Chair 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: Wed, 17 Jun 2020 15:11:19 -0000 The IAB has selected Brian Rosen to serve as an additional chair of the RFC Editor Future Development Program, joining current chair Eliot Lear. Together, the chairs will set the detailed agenda, manage the program, and call consensus among the participants. The program also has two liaisons from the IAB to assist with logistical matters, Wes Hardaker and Jared Mauch. Brian was selected based on strong community feedback and careful consideration by the IAB in order to provide the best candidate to help manage this group. The IAB thanks all of the candidates who were willing to serve. This was a difficult decision with many strong candidates. This program has completely open participation. To subscribe to the mailing list, please go to . From nobody Wed Jun 17 08:19: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 F0B8C3A0889 for ; Wed, 17 Jun 2020 08:19:53 -0700 (PDT) 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 vjng6DvFhUIj for ; Wed, 17 Jun 2020 08:19:52 -0700 (PDT) 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 2F3073A0855 for ; Wed, 17 Jun 2020 08:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1421; q=dns/txt; s=iport; t=1592407192; x=1593616792; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=2bztwyFGv2HZpIt4QnrrOZ3rwDqog3B8LdkNcndTeko=; b=IphQ5yzRxYxvrVqhw6NxvWIwD5Rci9rs+cl7rqUM7T8p9gQkMpTvKlW2 RJea4yO1rHNKUyTAhGzH5i6c/k0KJPoVzt80RXtIWfUh2BsSxeG2O83O8 nl+xsDo/wqnwEaiAHG/dMmxL8nvJjN79oIXgh0a2/WtBRwWhlACtJaRW5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyBQCaM+pe/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUoCgxdUASASLI0lh2Ilm3wLAQEBDAEBGAsMBAEBhEQCghs?= =?us-ascii?q?lOBMCAwEBCwEBBQEBAQIBBgRthVsMQgEQAYUeAQEBAQIBAQE4NAsFCwsYDCI?= =?us-ascii?q?nMBkUgxIBglwgD7YIdIE0hVGFFwaBOAGMeIIAgTgMEIFPUC4+glwBgWBNgnq?= =?us-ascii?q?CLQS0SYJkgwGLYIpAAx2CcIkbkmOsDoNOAgQGBQIVgWoigVYzGggbFTsqAYI?= =?us-ascii?q?+PhIZDY5ViE6FRD8DMDcCBggBAQMJhi+KXgEB?= X-IronPort-AV: E=Sophos;i="5.73,523,1583193600"; d="scan'208";a="27225029" 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; 17 Jun 2020 15:19:47 +0000 Received: from ams3-vpn-dhcp343.cisco.com (ams3-vpn-dhcp343.cisco.com [10.61.65.87]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 05HFJkmO023967 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Jun 2020 15:19:47 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: <159240667857.3683.17444857051594857745@ietfa.amsl.com> Date: Wed, 17 Jun 2020 17:19:46 +0200 Cc: Brian Rosen Content-Transfer-Encoding: quoted-printable Message-Id: <080FF9EA-603C-4EDE-9489-8A7384C8E200@cisco.com> References: <159240667857.3683.17444857051594857745@ietfa.amsl.com> To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.65.87, ams3-vpn-dhcp343.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] [rfc-i] Brian Rosen to Serve as Additional RFC Editor Future Development Program Chair 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, 17 Jun 2020 15:19:54 -0000 It is my great pleasure to welcome Brian as co-chair. Brian and I have = had a brief call and will communicate further on a proposed agenda for = IETF 108 and some proposed next steps early next week, after we confer = once more. Eliot > On 17 Jun 2020, at 17:11, IAB Executive Administrative Manager = wrote: >=20 > The IAB has selected Brian Rosen to serve as an additional chair of = the=20 > RFC Editor Future Development Program, joining current chair Eliot = Lear.=20 > Together, the chairs will set the detailed agenda, manage the program,=20= > and call consensus among the participants. The program also has two=20 > liaisons from the IAB to assist with logistical matters, Wes Hardaker=20= > and Jared Mauch. >=20 > Brian was selected based on strong community feedback and careful=20 > consideration by the IAB in order to provide the best candidate to = help=20 > manage this group. >=20 > The IAB thanks all of the candidates who were willing to serve. This = was=20 > a difficult decision with many strong candidates. >=20 > This program has completely open participation. To subscribe to the=20 > mailing list, please go to = . > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > https://www.rfc-editor.org/mailman/listinfo/rfc-interest From nobody Mon Jun 22 08:44: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 14A5D3A0DD8 for ; Mon, 22 Jun 2020 08:44:02 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 ExHaYww-wHry for ; Mon, 22 Jun 2020 08:44:00 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 4A99A3A0DDC for ; Mon, 22 Jun 2020 08:44:00 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id c16so4852569ioi.9 for ; Mon, 22 Jun 2020 08:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=o1idV2QsN21Aw8Vq2S92l8i2UghX3CESg0tQVvLgKgM=; b=eJe+S4Xk9RxnGm91j5K9rBqa40Iod34hz/I0688RKFShxjaYIGti0cxmc1gkNX5xLi yY/rhbRuHPjP0LUp59YxJ1UhIUDxiJ/I5+j2PG2iJgWhcMP47mL0QhgJ1f5+0hG9WJWf rsSq3CuvTYyJpEkQ4nTpfGCI5IjBKnfgAcXgxzF4t7cvlKYPwaVB/8K4B/DV/yCfAv2R 8aUWKwtWI7VPO4hCwEP+mvmattjY5BQ+LumUV4Y8HkWg8ZsFxtilkFt7o2g8kaVelQlv QGhAvW7NUcRiG6FgM5bDIFO0NssKbwqjsZoNOBwI779KLM9ksQezc+rIaMpXklfS22PY nMOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=o1idV2QsN21Aw8Vq2S92l8i2UghX3CESg0tQVvLgKgM=; b=LQ1PuGlm8Q725+DG6AgA82BwZYsmyk6M+sCoqi0BJo5haODXVgIVgrro0pv2/fM+wH NxQfhMpYmLjFIrDZcb3BRYrWRSFNsu6d6wn1bc6CCHiTtXD7FeG2XhiWrcyWrrC0b7sU sO28ANS/t6MUlRsHZxJiAid9PekOQHo3cUqNSo9vYXRU75ntHnJ6kMFoRKtBWNmgSZ8U DfjhiLzvVucWYcSmOejiVefBqm2h3mi6hWa5ZRRBVUIjgb2KoLTotBHdvqZyIXozg0dR aNqkEkncho/5NQ2+a7WqZ9kikwEWkEYE8/fRh1Wem5itC0kQOzQ4qLU+TLsZG8ICJ3th GnDg== X-Gm-Message-State: AOAM531yZ0lltxzWaSE24zAdjBOEQQfmpjHv4y8F5352fCcJrALYkYkD 9p/+FeEM+y1A7t9B5l44jdz5GnR5NWc= X-Google-Smtp-Source: ABdhPJyXGkfGaVVN2wUOmVLiQs4/85VS2R2GtVhYof/sQIG7PQ0rZCHFaWAnPWl6VzIAGwZodABR2A== X-Received: by 2002:a05:6602:1647:: with SMTP id y7mr19828159iow.75.1592840638788; Mon, 22 Jun 2020 08:43:58 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id v17sm8011356iln.67.2020.06.22.08.43.56 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jun 2020 08:43:57 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> Date: Mon, 22 Jun 2020 11:43:55 -0400 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Rfced-future] Scope and IETF 108 proposals 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, 22 Jun 2020 15:44:02 -0000 Hello all First of all, I am honored and delighted that the IAB chose me to = co-chair this group. I think this work is critical to the IETF, and I = look forward to working with you all to make it successful. =20 Eliot and I have been talking about scope. I=E2=80=99m a believer in = limiting scope as a primary way to make sure we can finish in a = reasonable time: unlimited scope projects finish in infinite time. Of = course, the converse is not always true, but the narrower the scope = generally helps to focus effort and get projects finished in reasonable = time. We would like to propose that we, for now, limit our scope to the RSE = role, process and oversight, and not consider the RFC series itself in = scope. That means accepting the reality that things like what the = series is for, and who owns it remain undefined. We=E2=80=99ve managed = to work with that ambiguity for a long time, and we think we can define = the RSE role, process and oversight well enough without fixing those = issues. =20 We don=E2=80=99t propose that this scope limit is necessarily permanent: = if it gets in our way, we can revisit it, and if we finish the RSE = issues quickly enough and there is desire to work on series issues, we = can do that. But for now, we propose to limit our scope. As we complete = the structural work, we can choose to delegate the evolution of the = series or portions of it to that structure, or we can take up that work = here ourselves. This is a proposal. We=E2=80=99ll look for consensus on this proposal. = If we don=E2=80=99t have consensus, we=E2=80=99ll deal with the wider = scope. Your comments would be appreciated. We have also been discussing what our agenda for IETF 108 should be. We = would like to have a series of questions that focus our discussions at = the meeting. In some cases we could have consensus on answers, but in = most, we just hope to get a sense of where the workgroup is a the = present time. Our list of questions is: 1. Should the RSE be a hired employee or a contracted entity? 2. Who hires/contracts the RSE? 3. For the purposes of day to day management, to whom does the RSE = report? 4. Is there some group that oversees the RSE? 5. If the answer to 4 is yes, how is the board constituted? 6. Who defines the process that the RSE follows? This group? The = Board? The RSE defines it themselves? 7. Can the RSE decide to not publish a document one of the stream = editors forwards to it? If so, on what grounds? We want to know from you is: are these the right questions? Are there = work group members who would be willing to make straw-man proposals that = could be presented and discussed at the meeting? Brian= From nobody Mon Jun 22 09:12: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 017E83A0EAC for ; Mon, 22 Jun 2020 09:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 CxU1ivMgMlVe for ; Mon, 22 Jun 2020 09:12:34 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 8B94E3A0EAB for ; Mon, 22 Jun 2020 09:12:34 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id j80so4684616qke.0 for ; Mon, 22 Jun 2020 09:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=WAsKTRSIIOylswDiYvK16Klv5sABXFGntY/bL/OlTac=; b=P+sVxwjvnYQyAuAInLyU9PqajBryScRRiWdkDU+9Swut2r55BSmAkvFhl9qwRD8Ik8 4ZsQS6wNkIX6iPemJ9o75EpvwL7Tbf4N7W+ym+aV25ahMiDoi+h7XF9GAsuTxBy41j10 yN02OXWVQES3yuUujy+Tle5GozPfS+mpBOfgrIXPjBVyLPpOhgL3t27KfQguneQJCBWy Xc7cOQsi68l+8RuM31nQ9JBJvw2a5hg+UzBtY0yVgNbqwMJ1XG+D5OKAR5WfOqgMFTYZ kn+zbDU6h/75pAKGOqgzmLeoGk5a/apfoApM+EOi+eZGGCWLWkPuUwJxZXg54l8XmmRE 0mMA== 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=WAsKTRSIIOylswDiYvK16Klv5sABXFGntY/bL/OlTac=; b=DU5PLPP2ANsPo6xMRiTV7+DP8QLIy09FJiBt9PTx4gw1GAsowengvfqIaAUQK/wGot TwCqnV257rwmrtL+5jNPkbmLsEByGi4+cbKBED9CVnCcoYlLFahaLjcHVhSPWHLCivD8 MP4LGPx3xPYwZVuFeOi8IFuOHgw3sEhHnKPizl2P+nkk7lZIlIzzFd0l6oFGlE8jiwWt i5NLMGdfmuFAXFI4WjLbtqqGYOU0VBcYdif7Fvpk8A495TkpX6EDK7t8rl2LCheqB9b9 J16/zdTDNXr1LV+QJMlNxHi5Mgdz25ulv6m7foR+Rf4lnYcL2YC4w3IoJkedBsOfGao8 OblA== X-Gm-Message-State: AOAM533sI0B2kacyZWl6gw2gnvH9bP+LpHMlgcjzEp3q0CwSHM9R5h7L nlOysqMd6KwkYpXYj3VYNG4XQw7rp+AOgg== X-Google-Smtp-Source: ABdhPJyLNOfsXVzeHaiSbmJSbMLlOowtykOD4zsUvy5TFEaOhOZwCs6JB1huEx/6dirAgCI1cNwdTw== X-Received: by 2002:a37:7383:: with SMTP id o125mr14672216qkc.228.1592842353003; Mon, 22 Jun 2020 09:12:33 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id p80sm3152047qke.19.2020.06.22.09.12.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Jun 2020 09:12:32 -0700 (PDT) To: rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> From: Michael StJohns Message-ID: <2ecc7fee-25ef-e4ff-a994-c3fb874a0bf3@nthpermutation.com> Date: Mon, 22 Jun 2020 12:12:31 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 22 Jun 2020 16:12:36 -0000 Hi Brian - welcome.   Comments in line. On 6/22/2020 11:43 AM, Brian Rosen wrote: > > Our list of questions is: > 1. Should the RSE be a hired employee or a contracted entity? Trivial question.  Either is a reasonable approach, but hired employee generally means some sort of full time engagement.  In this case, the RSE has generally been a 1/2 time commitment.  Its unclear if this will change anytime soon. > 2. Who hires/contracts the RSE? Default: LLC board or a business organization under the LLC board.  I think any argument to the contrary would have to be exceedingly strong.  If we move this to a much more independent organization with a broader focus, then going back to ISOC as the hiring entity might be a good choice. > 3. For the purposes of day to day management, to whom does the RSE report? The RSE reports to themselves on an day-to-day basis.  This is not a position that requires managerial injection on other than the big things - e.g. contract formation and contractual compliance.   In other words, the question assumes that the RSE requires day to day oversight, and that's a push-poll formulation. > 4. Is there some group that oversees the RSE? See above, but the answer as asked is no.  There is some group that works WITH the RSE to oversee the RFC series.  That group does not have management oversight over the RSE contract or the RSE. > 5. If the answer to 4 is yes, how is the board constituted? As I suggested - stream managers plus some number of community selected folks who are acceptable to the RSE (e.g. actually have something useful in the publication space to say ). > 6. Who defines the process that the RSE follows? This group? The Board? The RSE defines it themselves? Poorly framed.    In the final analysis, the process is what the RSE contract says - it legally can't be any other way.   The input to the contract may include (directly or indirectly) community input, LLC input, board (5) input, or stream manager either through discussion, or the promulgation of RFCs that change the standards for what the RFC series is and how RFCs are published. Continuing that - the general formulation for contractors in the US is that you can tell them what to do, but not how to do it. That translates into specifying what we want as a result, and letting the RSE figure out how (e.g. the "process" or at least one piece of the process) to get us there. > 7. Can the RSE decide to not publish a document one of the stream editors forwards to it? If so, on what grounds? AIRC, there is only one stream editor - the ISE.  The rest are stream managers.  E.g. the others don't execute any editorial control over the content they forward - all that happens in the WGs and LC process. In any event, the answer is yes, and the ISE gave the best example - a document that requires too much editing by the RPC to bring it to publication standards.  The ISE case was a non-native English author and syntax and structure that was non-standard English.   There may be other reasons.  In any event, this is not a "never publish the document" but "this document in its current state does not meet the standards of the series".  As I suggested previously, this may be better handled as an RSE recommending and the RFC Editorial Board deciding rather than just the RSE doing this unilaterally. > > We want to know from you is: are these the right questions? Are there work group members who would be willing to make straw-man proposals that could be presented and discussed at the meeting? Already done.    I was told it was too early to be coming up with proposals for how the management worked.   Maybe we're there now? One possibly important question:  What do we want the RSE to do?   I *think* that's a key question.   For me "husband and evolve the RFC series as an internationally relevant series of publications of technology and standards" or something along those lines.   Very high level statement of what we (I) want vs "publish 1000 RFCs a year". Later, Mike > > Brian From nobody Mon Jun 22 09:18: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 760C23A0EF3 for ; Mon, 22 Jun 2020 09:18:37 -0700 (PDT) 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 AOrqP8M4wui9 for ; Mon, 22 Jun 2020 09:18:36 -0700 (PDT) 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 AAB533A0EF0 for ; Mon, 22 Jun 2020 09:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3007; q=dns/txt; s=iport; t=1592842715; x=1594052315; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=qzS9xLCDnpn2qYLL4DeHIPxCvC/yMNnwnD0xeS5ByLE=; b=RcBe2R4RiB7MywRSv22V9aAD+kZQfchC/7+RTPh5p+GIfowbBMEMPZWM TCCHtmeZ/ai8aLLMa8rX98yZtmaKCw8WjEAidRj/E8t0/GoHhIvJ6ohHu e2F87Gc6cvCCcEYbc9/ZYkx/+6mrZNYn5gXfO9Tj8lnQfIbwatTgD1Oe1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAQAa2fBe/xbLJq1mGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBSoEjgQeBQwEgEiyNJYgMk2yIEgsBAQEMAQEvBAE?= =?us-ascii?q?BhEcCgiwlOBMCAwEBCwEBBQEBAQIBBgRthWeFcgEBAQECAXkFCwsEFC5XBhO?= =?us-ascii?q?DJoJdILYKdIE0hVGFKoE4jH2CAIERJxyCHy4+gQSHAIItBKQIkEuCZIMClic?= =?us-ascii?q?DHZ57rCSDTwIEBgUCFYFqIoFWMxoIGxVlAYI+PhIZDY42jjE/AzA3AgYIAQE?= =?us-ascii?q?DCZBkAQE?= X-IronPort-AV: E=Sophos; i="5.75,267,1589241600"; d="scan'208,217"; a="27282417" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jun 2020 16:18:31 +0000 Received: from dhcp-10-61-111-164.cisco.com (dhcp-10-61-111-164.cisco.com [10.61.111.164]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 05MGIUaJ015551 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Jun 2020 16:18:31 GMT From: Eliot Lear Message-Id: <5E418BC0-6E1B-470D-894D-DF6DD947614A@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_61E67CC6-296B-4DB1-9962-D15FD28DD539" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 22 Jun 2020 18:18:29 +0200 In-Reply-To: <2ecc7fee-25ef-e4ff-a994-c3fb874a0bf3@nthpermutation.com> Cc: rfced-future@iab.org To: Michael StJohns References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <2ecc7fee-25ef-e4ff-a994-c3fb874a0bf3@nthpermutation.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.111.164, dhcp-10-61-111-164.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 22 Jun 2020 16:18:38 -0000 --Apple-Mail=_61E67CC6-296B-4DB1-9962-D15FD28DD539 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 22 Jun 2020, at 18:12, Michael StJohns = wrote: >=20 >> 7. Can the RSE decide to not publish a document one of the stream = editors forwards to it? If so, on what grounds? >=20 > AIRC, there is only one stream editor - the ISE. The rest are stream = managers. =20 Good catch. s/stream editor/stream managers/ Sorry about that. Eliot= --Apple-Mail=_61E67CC6-296B-4DB1-9962-D15FD28DD539 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 22 Jun 2020, at 18:12, Michael StJohns <msj@nthpermutation.com> wrote:

7. = Can the RSE decide to not publish a document one of the stream editors = forwards to it?  If so,  on what grounds?

AIRC, there is only one stream editor - the ISE.  The = rest are stream managers. =  

Good catch.  s/stream = editor/stream managers/

Sorry about that.

Eliot
= --Apple-Mail=_61E67CC6-296B-4DB1-9962-D15FD28DD539-- From nobody Mon Jun 22 10:36: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 2E9603A1003 for ; Mon, 22 Jun 2020 10:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBSqOBGYwnhd for ; Mon, 22 Jun 2020 10:36:52 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B173A1001 for ; Mon, 22 Jun 2020 10:36:52 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id c3so17489864wru.12 for ; Mon, 22 Jun 2020 10:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4mW2fVQHfT0JwXvphPpko3ZLci4qqyM4Y5j8qLIJVsA=; b=Wz31TlUCOGdb4tI7MeeOZDRUtvwlO3Q385wonO0bwIHlF4npfJVWZxotmq3QyqNcV8 AAIpZifeIpRpm11EPu+mWb/3yZWmjC3mipb4HP0G0yyjtW8izsxzTG7DUG+tLBBTmKwd heG+x1/RXTqBbsXEJnh49A36mXmE1b/hG8kaO0uof/+SmyxrpJ0OMUd/yVMuiPg+rJ08 qbq4bNO/ToHxEvrg/LdAQO/N/dksH4So7xghpVRjdbcLe+Mgop8ugKETszdc9CnIAFg9 uD3RP4MlcG/A4bM6PZugZeaT/DBXEx+bZCI1QizSOkfy7j0vManT6ZVJ+KUvTMkTQVUb DBYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4mW2fVQHfT0JwXvphPpko3ZLci4qqyM4Y5j8qLIJVsA=; b=PAKSJ8+eFefBngoRI28TuiJE5vBB9yREHeO3mc9y7kvE+kS7Lcdz2dynWWqH2dGkCU sKS/aCZmiAIZn0MaO0OAnhTSZmU17+XvMHFe/5w8Q87+EvnMMKV0A9g9NSjHfw9bL+lT NugOr3aUUtYEGpBq94ggLQokv6DVQ8C2Qjio6d4j2fgvlE0rNuKJPb/2OGDhZfm91t/k joZt7K388URs4u3a9F24zOJ7NDE8pf/zYSk2PNbf7eZ8UhWay2xyuSlLExAw4/Y66Q5s 2VUYf9q4teXo0u+ySpHEuYDb3+OeKaUnTtXPYn1IvXRPoqbgTrQRMHyI07C7dHcL11gr GDDw== X-Gm-Message-State: AOAM530Yfgw20PERLhMhW6Kbav90wquCutbHvjIXYE9mKfp/wAxc0YXT mBhLvQbn5bT7UWXR6vb8+7E= X-Google-Smtp-Source: ABdhPJxlLWapLkbQiVps0PPg4CCXkLoNCgQKx49Ntq4pWEEyVCE4olzFPcGg3hyBoqgrv6JXfatnCQ== X-Received: by 2002:a5d:5084:: with SMTP id a4mr20772426wrt.416.1592847410770; Mon, 22 Jun 2020 10:36:50 -0700 (PDT) Received: from ?IPv6:2601:647:5a00:ef0b:f409:9511:c586:b2d6? ([2601:647:5a00:ef0b:f409:9511:c586:b2d6]) by smtp.gmail.com with ESMTPSA id t5sm260012wmj.37.2020.06.22.10.36.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jun 2020 10:36:49 -0700 (PDT) From: Bob Hinden Message-Id: <0589E223-719E-4BCB-BCCD-C3C3306517B8@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_451AA626-5BAF-4535-9FDA-E1E3969CADC0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Mon, 22 Jun 2020 10:36:41 -0700 In-Reply-To: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> Cc: Bob Hinden , rfced-future@iab.org To: Brian Rosen References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 22 Jun 2020 17:36:54 -0000 --Apple-Mail=_451AA626-5BAF-4535-9FDA-E1E3969CADC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, Thanks for taking on this role. My answer to your questions below. Bob > Our list of questions is: > 1. Should the RSE be a hired employee or a contracted entity? I don=E2=80=99t think that is the right question. There are two = parts, should the RSE be an individual or say a group, and how should = they be employed. I think the RSE should be an individual, not a group. How they are employed is a separate question and will depend on the = person. The LLC could hire them as a full or part time employee, or the = LLC could hire them as a contractor. > 2. Who hires/contracts the RSE? LLC. No other group in the IETF has the ability to hire/contract, as = far as I can tell. > 3. For the purposes of day to day management, to whom does the RSE = report? It=E2=80=99s a senior leadership position, so essentially they report to = the community. Like other senior IETF roles. > 4. Is there some group that oversees the RSE? What Mike St.Johns said. I think that is about right. > 5. If the answer to 4 is yes, how is the board constituted? ditto > 6. Who defines the process that the RSE follows? This group? The = Board? The RSE defines it themselves? I think the start point is RFC 8728 and RFC 8729. Perhaps the question = should be what needs to change. > 7. Can the RSE decide to not publish a document one of the stream = editors forwards to it? If so, on what grounds? Yes, if there are serious problems with a document. But I like the = idea Mike St. Johns proposed about having the RFC Editorial Board be = involved in this and not having the RSE doing it in isolation. >=20 > We want to know from you is: are these the right questions? Are there = work group members who would be willing to make straw-man proposals that = could be presented and discussed at the meeting? >=20 > Brian > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_451AA626-5BAF-4535-9FDA-E1E3969CADC0 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl7w7CkACgkQrut0EXfn u6gUJQf/aJkWGmieLxT5XsHf75vI+hw007o6M2wKtEh+uFrHpS6pC+uOf+6ibi7Z 6L4uZWtPQwcMx/JsT+iFaocbLZeIMgV1g9E1K7l8qa7lzfZBHu2qf6WJFBHBi/Kh pa+wETbojIG5XGp52pl8XyUiYbWcf+UUN/dY2flEalGBmgBIBfOg5IlWZ9KOSPAG YqqVWfzooSHJvlfr3cPZcj7PFzJ8OfKIs134oYosJ+nnyfSKUCTtuOWthk+kVBFE 4DpzKbOQf5zegq5JAyBgmF1c03zF4uExpsOB3flJgC5rFt3y0Ez6AW1Iid1M6fpD fz+jiZGSaqg0jwFVytksSNVh/q9w+g== =DKmG -----END PGP SIGNATURE----- --Apple-Mail=_451AA626-5BAF-4535-9FDA-E1E3969CADC0-- From nobody Mon Jun 22 10:44: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 EA5BE3A1030 for ; Mon, 22 Jun 2020 10:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 h-Qv29Zfmwba for ; Mon, 22 Jun 2020 10:44:54 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ACC73A0CE2 for ; Mon, 22 Jun 2020 10:44:52 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 05MHinUV003787; Mon, 22 Jun 2020 18:44:49 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BE6C222044; Mon, 22 Jun 2020 18:44:49 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id A914622042; Mon, 22 Jun 2020 18:44:49 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.26.18]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 05MHimNt015467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Jun 2020 18:44:49 +0100 Reply-To: From: "Adrian Farrel" To: "'Bob Hinden'" , "'Brian Rosen'" Cc: References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <0589E223-719E-4BCB-BCCD-C3C3306517B8@gmail.com> In-Reply-To: <0589E223-719E-4BCB-BCCD-C3C3306517B8@gmail.com> Date: Mon, 22 Jun 2020 18:44:48 +0100 Organization: Old Dog Consulting Message-ID: <02a401d648bc$d39b4c30$7ad1e490$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIfX7vfh4YEKFq4ndL/BmmpAFaeUAFUjaPxqEgVRIA= Content-Language: en-gb X-Originating-IP: 84.93.26.18 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-25498.001 X-TM-AS-Result: No--2.985-10.0-31-10 X-imss-scan-details: No--2.985-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25498.001 X-TMASE-Result: 10--2.984500-10.000000 X-TMASE-MatchedRID: pBwXUM+nCwvxIbpQ8BhdbPHkpkyUphL9vjcFGi2OgBRa1yhTwm1zub51 zIfS792kVfiIwM4NygZ41wL4k6dmGWsUzPai/rPyXTubK8QEAhlox+gm2/PqIPXwfuDL3qUMo8W MkQWv6iUD0yuKrQIMCOYv5V7WeGfs0C1sQRfQzEHEQdG7H66TyMdRT5TQAJnAYzDVtOJWuMYAGK dWQygZ8bZ8MQz80aXdKeQYfB3az1Yl4nVYwIRGQa1+3JijYrAOMqmhG/M0o4/0MHwzu2JowBZt/ 2+KOWzz X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 22 Jun 2020 17:44:56 -0000 >> 2. Who hires/contracts the RSE? > > LLC. No other group in the IETF has the ability to hire/contract, > as far as I can tell. Which might mean that this was the wrong question, too. It could be "Who recruits/interviews/selects/appoints the RSE?" Cheers, Adrian From nobody Mon Jun 22 10:59:47 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 E04363A1048 for ; Mon, 22 Jun 2020 10:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_BL=0.001, RCVD_IN_MSPIKE_L4=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 wS4pXM_pI0NA for ; Mon, 22 Jun 2020 10:59:44 -0700 (PDT) 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 7227E3A1047 for ; Mon, 22 Jun 2020 10:59:42 -0700 (PDT) Received: from xse236.mail2web.com ([66.113.196.236] helo=xse.mail2web.com) by mx165.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jnQjE-000lLx-C1 for rfced-future@iab.org; Mon, 22 Jun 2020 19:59:36 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 49rHDd1qjVz9xn for ; Mon, 22 Jun 2020 10:57:21 -0700 (PDT) Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jnQh7-0000yu-4L for rfced-future@iab.org; Mon, 22 Jun 2020 10:57:21 -0700 Received: (qmail 24252 invoked from network); 22 Jun 2020 17:57:20 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.64]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 22 Jun 2020 17:57:20 -0000 To: Brian Rosen , rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> 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: <865134be-6baa-8b66-f55d-487419e4571b@huitema.net> Date: Mon, 22 Jun 2020 10:57:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.196.236 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.236/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.236/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0f6LF1GdvkEexklpcFpSF5apSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjRzgyua+oKUgQGcbmeu+KPhY RkpFG1KU35iPF8F1Y4jETrkNSwhl3IWIVwBJUAvoQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuE1/kfoVSTvW73WxnprP91bu42Vki7412dpbhrD2d47zbC3VvU djSCswikK/licfX+oIF6uBSWByrPG2Vxuo/vVPllrFEbCkMryfcYCsgMUJObfBQoU3roWy2GH1DY sAiH3gousbgNfxi2R3uFLvZP/HBXvrLBlKCVRjjdPbjQ4HnBNho1Lszw5OO01yYoll8q2UgzFF+j HNSbIoW1Q++Wvj3dKxLhoxcmaInYbR5vlqFg3eKzPG9E5MikC2dVXWcpK172i/E5sOgbaCtBiSIx 1XwCY8vmv+JqOVJamBHfOGVwjn7Xut/lXagsodd5qqODTFiwcpU4fyz75jxpU98RPGiH1Wgh6RAe nBR+licROGZNFSBymhtbd6ygEffuU1+3geyC5iskgZbtXyitbf1Dvgq9Owpvh+OYxxykI1afwELQ H50sZPeDQaETTMuyQC0ZlUoLzgtoIWNmtGwUoVDvSHuXCC1A5Cukky0WFo38JXT3Y80OmAux3oN1 3+ztUzneCQi7ficg1GX0SNTSj3/4ML83o7TP54FLJfg9sR3SxHJVz0Qum36wvBsfbevBOItK4fiS orMqdhGmNUTs/DGDx4W+axx2DzNv8BNlsyaVn+VjCox4g140hAB3wbR7F6IN3UVkhX78ZcdZtWJt ri4lXS4599fEDT1GENo62d+DqD+gavEa4Cf1ILpAKBLSDHQENgjpXL2y/ONOC04/YEfTu1ss+n2f fnQxt6aJ7klZab8CvOT2YjlrAxveXsTwUzCTkiX4qyX2d5a1xbDejUjyqRVeiJQ5XjnH4gzAuCMQ 8aUxL7hrJSk60SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 22 Jun 2020 17:59:46 -0000 On 6/22/2020 8:43 AM, Brian Rosen wrote: > Hello all > > First of all, I am honored and delighted that the IAB chose me to co-ch= air this group. I think this work is critical to the IETF, and I look fo= rward to working with you all to make it successful. =20 > > Eliot and I have been talking about scope. I=E2=80=99m a believer in l= imiting scope as a primary way to make sure we can finish in a reasonable= time: unlimited scope projects finish in infinite time. Of course, the = converse is not always true, but the narrower the scope generally helps t= o focus effort and get projects finished in reasonable time. > > We would like to propose that we, for now, limit our scope to the RSE r= ole, process and oversight, and not consider the RFC series itself in sco= pe. That means accepting the reality that things like what the series is= for, and who owns it remain undefined. We=E2=80=99ve managed to work wi= th that ambiguity for a long time, and we think we can define the RSE rol= e, process and oversight well enough without fixing those issues. =20 > > We don=E2=80=99t propose that this scope limit is necessarily permanent= : if it gets in our way, we can revisit it, and if we finish the RSE issu= es quickly enough and there is desire to work on series issues, we can do= that. But for now, we propose to limit our scope. As we complete the st= ructural work, we can choose to delegate the evolution of the series or p= ortions of it to that structure, or we can take up that work here ourselv= es. > > This is a proposal. We=E2=80=99ll look for consensus on this proposal.= If we don=E2=80=99t have consensus, we=E2=80=99ll deal with the wider s= cope. Your comments would be appreciated. > > We have also been discussing what our agenda for IETF 108 should be. W= e would like to have a series of questions that focus our discussions at = the meeting. In some cases we could have consensus on answers, but in mo= st, we just hope to get a sense of where the workgroup is a the present t= ime. > > Our list of questions is: > 1. Should the RSE be a hired employee or a contracted entity? > 2. Who hires/contracts the RSE? > 3. For the purposes of day to day management, to whom does the RSE repo= rt? > 4. Is there some group that oversees the RSE? > 5. If the answer to 4 is yes, how is the board constituted? > 6. Who defines the process that the RSE follows? This group? The Boar= d? The RSE defines it themselves? I think that particular question is not well framed, but I also think there is a need for some oversight. Nobody should be set up as some kind of king. Take the example of evolving the format of the RFC series, which falls neatly into the RFC responsibility. The experience shows that such changes affect how the RFC are produced and how they are consumed. Suppose that the RFC editor proposes a change that makes RFC harder to write, because in his or her opinion it will make them easier to read by some of the target audience. There are bound to be a variety of opinions about whether the change is right or not. How do we achieve consensus? How do we gauge consensus? Is there an appeals process? If that's the kind of questions that you have in mind by stating "process that the RFC follows", then yes I believe it is in scope. But maybe we need to clarify a bit. > 7. Can the RSE decide to not publish a document one of the stream edito= rs forwards to it? If so, on what grounds? > > We want to know from you is: are these the right questions? Are there = work group members who would be willing to make straw-man proposals that = could be presented and discussed at the meeting? -- Christian Huitema From nobody Tue Jun 23 04:49: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 EEF853A0E78 for ; Tue, 23 Jun 2020 04:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=hapsB0l5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DSvoW5hz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAfFjr7BqcSK for ; Tue, 23 Jun 2020 04:49:33 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151EA3A0D56 for ; Tue, 23 Jun 2020 04:49:32 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 5ABCC9DE for ; Tue, 23 Jun 2020 07:49:32 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 23 Jun 2020 07:49:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=2ctpJC1 HPs/dzO/BbXhstSnkPRivUseZ3lIij21+m08=; b=hapsB0l5hYEnnIyxiNt/bo3 InxwNm2/0zfX09P7FbPY/c3Hhp75lbJhaF2wDBNpXOwjlE9RwDoG1TCPpJc5d0r7 Vq7io2MXE2jgcU0OQ1E961t+giTFxcVlbb1YTOx8F8v1lSOMW3A018ZBkNzBT08g UGBUs7OegqPr0S4HhZRFY/qnGyi5ZHisGbFSnlqlghIgqkx0MO7jL/ZMzFtMcKkk sMWkyshNgqzJBFzLV31Nkg8voxx/NsghEBZ2U13BeNEk9dERfjO0vhH1QV0Jx03g KruVnhrYc3b9C0zk0gIEqQeUZt4rTCuhRhsnz2WPL7F7y9pTYq3azi6WmdUvUeA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=2ctpJC 1HPs/dzO/BbXhstSnkPRivUseZ3lIij21+m08=; b=DSvoW5hzMFDHbt7ARD7LrJ Dj5JzC9Wk6w2dPQeElvy6yZcw7RrBojzdrRDB+tVHfwR9XPZPzYkB3mjj1TRIv1f JVeepiwVrPIY6gUf7B8mzfpTJWpPhRD0Qhmy/9YrJMx4mDecQ8YcO96kwg8y0V9j AZYQ7v3ffp98LpBDdKauY4WJ4UAxKdbo6CozRFvTJqmLyNHwlytgUeSI0bfmfrvO IuyEbsvU5sBu+XDOu0qnc+wpPWZ2ayWL58UYM/lcRgXfOpjTpDGsnxFGc2s7uF2q 28+f/z7qKlaLF1nfYhuMGlPw/f/hx5yB0irb4k8xxwWXBof2QeO3lHkyR/jqrr+g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekhedgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedvudeuieehgf dvheeuueejjeeuudfgiefgveetfeelteeffffgtdejjefgueduvdenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrg hilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A8279180091; Tue, 23 Jun 2020 07:49:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-565-g8923300-fm-idx2020-20200622.001-g89233000 Mime-Version: 1.0 Message-Id: <8026b1b2-9c99-4129-ba6e-fb013878809b@dogfood.fastmail.com> In-Reply-To: <2ecc7fee-25ef-e4ff-a994-c3fb874a0bf3@nthpermutation.com> References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <2ecc7fee-25ef-e4ff-a994-c3fb874a0bf3@nthpermutation.com> Date: Tue, 23 Jun 2020 21:49:10 +1000 From: "Bron Gondwana" To: rfced-future@iab.org Content-Type: multipart/alternative; boundary=927f0b9eec1044c88ee6e889f3cab3b7 Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 23 Jun 2020 11:49:35 -0000 --927f0b9eec1044c88ee6e889f3cab3b7 Content-Type: text/plain On Tue, Jun 23, 2020, at 02:12, Michael StJohns wrote: > > 3. For the purposes of day to day management, to whom does the RSE report? > The RSE reports to themselves on an day-to-day basis. This is not a > position that requires managerial injection on other than the big things > - e.g. contract formation and contractual compliance. In other words, > the question assumes that the RSE requires day to day oversight, and > that's a push-poll formulation. This is a very narrow definition of "management" that pretty much reads as "the RSE doesn't need micro-management so they don't need management". A manager is also someone who advocates for their managees and provides a human connection which is somewhat important here. If we treat management as purely "contractual compliance" of the "you hit the RSE with a stick when they don't meet their SLA" variety, that's not a very good management structure. Who does the RSE tell that they're sick and taking a couple of days off to recover? Who do they check in with when they have an issue or dispute with someone else in the organisation, and want support or even just a second opinion? Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --927f0b9eec1044c88ee6e889f3cab3b7 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, Jun 23, 2020, at 02:12, Michael StJohns wrote:
=
> 3. For the purposes of day to day management, to who= m does the RSE report?
The RS= E reports to themselves on an day-to-day basis.  This is not a = ;
position that requires mana= gerial injection on other than the big things 
- e.g. contract formation and contractual complianc= e.   In other words, 
the question assumes that the RSE requires day to day oversight,= and 
that's a push-poll= formulation.
This is a very narrow definiti= on of "management" that pretty much reads as "the RSE doesn't need micro= -management so they don't need management".  A manager is also some= one who advocates for their managees and provides a human connection whi= ch is somewhat important here.  If we treat management as purely "c= ontractual compliance" of the "you hit the RSE with a stick when they do= n't meet their SLA" variety, that's not a very good management structure= .

Who does the RSE tell that they're sick and taking a co= uple of days off to recover?  Who do they check in with when they h= ave an issue or dispute with someone else in the organisation, and want = support or even just a second opinion?

Bron.

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


--927f0b9eec1044c88ee6e889f3cab3b7-- From nobody Tue Jun 23 04:55:20 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 9A3193A187D for ; Tue, 23 Jun 2020 04:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=k7AbY4Fk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kFGNAFcs Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3qlCxDDwbMP for ; Tue, 23 Jun 2020 04:55:18 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EB0C3A187C for ; Tue, 23 Jun 2020 04:55:18 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 8B49CA13 for ; Tue, 23 Jun 2020 07:55:17 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 23 Jun 2020 07:55:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=ptJkFX0 5+3qd4R0pelC7vNiso1dDY77UJUJECoF4LSg=; b=k7AbY4FkRO2xUQKaFxXIVP0 wk59znG2DcFDFz6Qge3B8Epm9QHzker9Lmq80rFaXDiQy+42vHlZJUP+w1aiD62/ AXPlKV8BGDXW0eQslqrct6LgKoE+9rHuiCETDPzN0fDV7JILb1QtQwoaUNwOC5NW Sd/bitvnhcO1WRl4/sGng4FOPdUs0ifvu4AkQLq8mYOlPkxn/qho7sxD+hQ8skW3 1ZRfJVMolFP6u8j4yatABjT5WYtL8IVwxn8WVisaQNEn+RM9+y0C87FErCSOdjnD PuaLRllRNsnDHjPQkJdgdHRe5gal7gzD4t/NiSsWJPbCWKweoHofymBD3tfkShw= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=ptJkFX 05+3qd4R0pelC7vNiso1dDY77UJUJECoF4LSg=; b=kFGNAFcsiJz8Xak0jVgiw3 g+8fTfj+aoiLhW/SNdLatOwrDXpsoS/3gkZHOLosC4uvdTGNqBf2g6CnAjJS3jOy cZcCWfEm9bxHKaiNyaS6lTL2e2twM3P5m5dAKqKfMaAnPM/GLNGL1+0U2ah+3HVz y0vmmdauIQnxoLztPfRtAbGrq5qmYA47vdZ1FKSAetWJu42BZKrbHyo7C1W+2vc9 JFFNawxZC8neT3kU7LC8zsFpNwmkMp2FFbq1Y4V7PVO7Q0I9i004pvz9d6URnYQV Z1J2riKuYdgoYwONhaZjpTv3puFCVsWAqcll9YbbVC++/oACla5otz9LiPlPEPOw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekhedgudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedvudeuieehgf dvheeuueejjeeuudfgiefgveetfeelteeffffgtdejjefgueduvdenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrg hilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DF546180091; Tue, 23 Jun 2020 07:55:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-565-g8923300-fm-idx2020-20200622.001-g89233000 Mime-Version: 1.0 Message-Id: <19ca95e4-b0d7-4860-94b2-d79416921113@dogfood.fastmail.com> In-Reply-To: <2ecc7fee-25ef-e4ff-a994-c3fb874a0bf3@nthpermutation.com> References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <2ecc7fee-25ef-e4ff-a994-c3fb874a0bf3@nthpermutation.com> Date: Tue, 23 Jun 2020 21:54:55 +1000 From: "Bron Gondwana" To: rfced-future@iab.org Content-Type: multipart/alternative; boundary=2867f45d24bd40668409e836c570e137 Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 23 Jun 2020 11:55:20 -0000 --2867f45d24bd40668409e836c570e137 Content-Type: text/plain Yikes - I find myself replying to this a second time! On Tue, Jun 23, 2020, at 02:12, Michael StJohns wrote: > > Our list of questions is: > > 1. Should the RSE be a hired employee or a contracted entity? > > Trivial question. Either is a reasonable approach, but hired employee > generally means some sort of full time engagement. In this case, the > RSE has generally been a 1/2 time commitment. Its unclear if this will > change anytime soon. Hiring part time employees is totally a thing everwhere I've been. 2 days/week, 3 days/week, whatever. I don't think the idea that it's not a 100% FTE role excludes it from being an employee role. But... clearly this is not a trivial question because... > > 6. Who defines the process that the RSE follows? This group? The Board? The RSE defines it themselves? > > Poorly framed. In the final analysis, the process is what the RSE > contract says - it legally can't be any other way. The input to the > contract may include (directly or indirectly) community input, LLC > input, board (5) input, or stream manager either through discussion, or > the promulgation of RFCs that change the standards for what the RFC > series is and how RFCs are published. Continuing that - the general > formulation for contractors in the US is that you can tell them what to > do, but not how to do it. That translates into specifying what we want > as a result, and letting the RSE figure out how (e.g. the "process" or > at least one piece of the process) to get us there. You clearly pre-suppose the answer to question 1 in your answer to question 7! This question can be raised up a level to "we don't have a contract yet, who's gonna set the terms". I can see the argument for: if the answer to 1 is contractor, then the answer is "whoever writes the contract", which then makes this question: "Who decides what's in the contract? This group? The Board? The RSE writes it themselves?". It's still a necessary question in that framing. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --2867f45d24bd40668409e836c570e137 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Yikes - I find myself replying to this a second time!
<= /div>

On Tue, Jun 23, 20= 20, at 02:12, Michael StJohns wrote:
> Our list of = questions is:
> 1. Should = the RSE be a hired employee or a contracted entity?

Trivial= question.  Either is a reasonable approach, but hired employee&nbs= p;
generally means some sort = of full time engagement.  In this case, the 
RSE has generally been a 1/2 time commitment.&= nbsp; Its unclear if this will 
change anytime soon.

Hiring part tim= e employees is totally a thing everwhere I've been.  2 days/week, 3= days/week, whatever.  I don't think the idea that it's not a 100% = FTE role excludes it from being an employee role.

But... = clearly this is not a trivial question because...

> 6. Who defines the process = that the RSE follows?  This group?  The Board?  The RSE d= efines it themselves?

Poorly framed.    In= the final analysis, the process is what the RSE 
contract says - it legally can't be any other = way.   The input to the 
contract may include (directly or indirectly) community input= , LLC 
input, board (5) = input, or stream manager either through discussion, or 
the promulgation of RFCs that change the= standards for what the RFC 
series is and how RFCs are published. Continuing that - the general=  
formulation for contra= ctors in the US is that you can tell them what to 
do, but not how to do it. That translates int= o specifying what we want 
as a result, and letting the RSE figure out how (e.g. the "process" o= r 
at least one piece of= the process) to get us there.

You clearly p= re-suppose the answer to question 1 in your answer to question 7!

This question can be raised up a level to "we don't have a cont= ract yet, who's gonna set the terms".

I can see the argum= ent for: if the answer to 1 is contractor, then the answer is "whoever w= rites the contract", which then makes this question: "Who decides what's= in the contract?  This group?  The Board?  The RSE write= s it themselves?".  It's still a necessary question in that framing= .

Bron.

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


--2867f45d24bd40668409e836c570e137-- From nobody Tue Jun 23 08:36:26 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 D5D8F3A0F48 for ; Tue, 23 Jun 2020 08:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 bxPEHGQ57AVT for ; Tue, 23 Jun 2020 08:36:23 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 9FA793A0FB8 for ; Tue, 23 Jun 2020 08:36:15 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id o38so7024625qtf.6 for ; Tue, 23 Jun 2020 08:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=97BjVUQPVuCoupWJGUMJwiFnOy3bq7Ucum9nMIbA1bg=; b=ZB9m2qqm5yIW/3a9QSKDK5PZm+HNzF/0yhz9KnH3mN5fsoJ86TfVY/yYG2ouvWDjuV cO4jgVIWoRhzxJUxmVSYTr/5x5YGF5WH3FcEsBHrb7/F/f5PfRnmOY5ezVGleQjh9XqV hjb3K5YsMmk5/0POlt9Ow1vKgCIVUnln2hKMKU89QaEURsCGFrPbxIRw8DiYu6P0Ellf hrVvotjniultgf7/WoAO2V8ll7vgzIQBftsdHe6uicb0MXi+jEdiv0JC5oVhrEQh0NNj lf/KBiROXq0m2z0IK+1vdNj9JqRv+IiXXXOFjhGse866uJU6N4UjGaJ0nKXFUwVWxaQf SD3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=97BjVUQPVuCoupWJGUMJwiFnOy3bq7Ucum9nMIbA1bg=; b=FaB3qtSLxq99hpSsk8wtOD+oiLFnT1CEJtUqdznED9d1bs5x7cxSROh8L2o3rseQvv Wie0+6q+S18tajJeGgM2+KhbQzpXFTbvT8pODFLK6Mc9NePgGkr+yQYTSeyo1JNwCUk6 pU81Dp/UyysyhLTOYtsYhDbfysAMXhAvh0ENFD+xypcYsUh2viqNY9XcEW8/45LxjDij K0HKz/2aIBq8JrltXGvfiOsFwd8re+jZTaVBbWKmxoMTfNrRkMCbQmm7Ln1Xz9o3dddM n8CpGKitMPKj5H260f6Vhn6dBJziPRIgADPfTBQS9tN6X8H7bm5Jk81tFFG/o9S/Nk3O 0QAw== X-Gm-Message-State: AOAM531WvI9Pro2qfkalKWnTE1SJQE6kpfWblBiArFMkrPlcDv5UHQdW kbLCsqnDD4jsqhbH5/WGr5GjWgUS2quXbw== X-Google-Smtp-Source: ABdhPJzaKdB2C7a6ftCW14b7+N+1e5NS3/J+c8vcqnvycpJABBdh2rIRtQwTT27APpCQaxB6Xx3h6g== X-Received: by 2002:aed:3883:: with SMTP id k3mr6653188qte.365.1592926574219; Tue, 23 Jun 2020 08:36:14 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id d2sm854415qti.62.2020.06.23.08.36.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jun 2020 08:36:13 -0700 (PDT) To: rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <2ecc7fee-25ef-e4ff-a994-c3fb874a0bf3@nthpermutation.com> <8026b1b2-9c99-4129-ba6e-fb013878809b@dogfood.fastmail.com> From: Michael StJohns Message-ID: <580f6254-32a0-a839-8db6-de83d7715cc1@nthpermutation.com> Date: Tue, 23 Jun 2020 11:36:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <8026b1b2-9c99-4129-ba6e-fb013878809b@dogfood.fastmail.com> Content-Type: multipart/alternative; boundary="------------BB18947ADD1BCFF4C14DFD8A" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 23 Jun 2020 15:36:25 -0000 This is a multi-part message in MIME format. --------------BB18947ADD1BCFF4C14DFD8A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 6/23/2020 7:49 AM, Bron Gondwana wrote: > On Tue, Jun 23, 2020, at 02:12, Michael StJohns wrote: >> > 3. For the purposes of day to day management, to whom does the RSE >> report? >> The RSE reports to themselves on an day-to-day basis.  This is not a >> position that requires managerial injection on other than the big things >> - e.g. contract formation and contractual compliance.   In other words, >> the question assumes that the RSE requires day to day oversight, and >> that's a push-poll formulation. > > This is a very narrow definition of "management" that pretty much > reads as "the RSE doesn't need micro-management so they don't need > management".  A manager is also someone who advocates for their > managees and provides a human connection which is somewhat important > here.  If we treat management as purely "contractual compliance" of > the "you hit the RSE with a stick when they don't meet their SLA" > variety, that's not a very good management structure.. > > Who does the RSE tell that they're sick and taking a couple of days > off to recover?  Who do they check in with when they have an issue or > dispute with someone else in the organisation, and want support or > even just a second opinion? Contractor vs employee differences.   The RSE generally has tasks and the contract spells out things like what happens in "unforeseeable circumstances" such as getting sick.  Since the RSE has in the past been about 50% FTE, sliding things a few days or even a week is rarely going to be a critical hit to the process. Contractors don't have managers in the same way that employees do.  They have points of contact, and an entity that holds the other end of the contract.  At one point in my career, I held something north of 30 contracts and I *never* ever felt the need to call up one of my contractors and explain what they needed to do that day.   Had I tried, the contracting officer and the contract POC would have been within their rights to slap me down hard. The RSE has to be thinking about more than a single person's  (or even a designated small group's) opinion and paying attention to broader things than "a [single] human connection".  I'm not sure if you've ever met any of the former RSEs, but I was honored to be a friend and colleague to each of them (and in one case was their "contracting entity" for a period of time).  None of them ever had a problem connecting with the IETF collectively or individually, nor did any of them require anyone to advocate for them - they were perfectly capable of doing that for themselves with very good results. If all you want is a task rabbit in the RSE role, you could make a case along the lines you've sketched, but I think hiring plug replaceable RSEs would be a Bad Idea (tm). Later, Mike > > Bron. > > -- >   Bron Gondwana, CEO, Fastmail Pty Ltd >   brong@fastmailteam.com > > > --------------BB18947ADD1BCFF4C14DFD8A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/23/2020 7:49 AM, Bron Gondwana wrote:
On Tue, Jun 23, 2020, at 02:12, Michael StJohns wrote:
> 3. For the purposes of day to day management, to whom does the RSE report?
The RSE reports to themselves on an day-to-day basis.  This is not a 
position that requires managerial injection on other than the big things 
- e.g. contract formation and contractual compliance.   In other words, 
the question assumes that the RSE requires day to day oversight, and 
that's a push-poll formulation.

This is a very narrow definition of "management" that pretty much reads as "the RSE doesn't need micro-management so they don't need management".  A manager is also someone who advocates for their managees and provides a human connection which is somewhat important here.  If we treat management as purely "contractual compliance" of the "you hit the RSE with a stick when they don't meet their SLA" variety, that's not a very good management structure..

Who does the RSE tell that they're sick and taking a couple of days off to recover?  Who do they check in with when they have an issue or dispute with someone else in the organisation, and want support or even just a second opinion?

Contractor vs employee differences.   The RSE generally has tasks and the contract spells out things like what happens in "unforeseeable circumstances" such as getting sick.  Since the RSE has in the past been about 50% FTE, sliding things a few days or even a week is rarely going to be a critical hit to the process.

Contractors don't have managers in the same way that employees do.  They have points of contact, and an entity that holds the other end of the contract.  At one point in my career, I held something north of 30 contracts and I *never* ever felt the need to call up one of my contractors and explain what they needed to do that day.   Had I tried, the contracting officer and the contract POC would have been within their rights to slap me down hard.

The RSE has to be thinking about more than a single person's  (or even a designated small group's) opinion and paying attention to broader things than "a [single] human connection".  I'm not sure if you've ever met any of the former RSEs, but I was honored to be a friend and colleague to each of them (and in one case was their "contracting entity" for a period of time).  None of them ever had a problem connecting with the IETF collectively or individually, nor did any of them require anyone to advocate for them - they were perfectly capable of doing that for themselves with very good results. 

If all you want is a task rabbit in the RSE role, you could make a case along the lines you've sketched, but I think hiring plug replaceable RSEs would be a Bad Idea (tm).

Later, Mike



Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd




--------------BB18947ADD1BCFF4C14DFD8A-- From nobody Tue Jun 23 15:48: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 98F993A0C06 for ; Tue, 23 Jun 2020 15:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 EZXGRu01Szi4 for ; Tue, 23 Jun 2020 15:48:51 -0700 (PDT) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 E93CB3A0C04 for ; Tue, 23 Jun 2020 15:48:50 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id ne5so119154pjb.5 for ; Tue, 23 Jun 2020 15:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=4WGttqofilPOy49UFEZWx1BKGOLOhLPA8wkHbFlPoGw=; b=PiBFeS63KYyZ+Tjij2y7P0YDLg2abjm9ENN6/I//R9GAzcrU3xTLBmhmQgh6cjfyK5 QbtWUDOrEbfdhlyrEYIJEM+17EwgBfj9hMuc3Db5NdYl65zGsbGU3vo5hEo0M/zAg8Ju SbnH/h/+jsXJZHyd2JzQlRG1Efe59IkA9gNl9mwbVYteKs/FU5R9m6ZQby3z1D6ZHYO1 3b3bqjvTE0i3dKHgJFUnwiHkZYgPxGo9o6rJSv5uBFH+6Y0BoLq3HkOLIQjTCSam5eBp 5au6D6xN+0ryxNeHifAqftTfdoyCcGxpcC+5mXC1+OGP1Fbm0Gm12/8szFbyDsIflXk6 iSMQ== 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=4WGttqofilPOy49UFEZWx1BKGOLOhLPA8wkHbFlPoGw=; b=BojxVCgm4rCZF4oSMo+mCbGQuw2+rQgf/CQBNNp3uzIjd/bmhrDGDCERARWahxHI+U Sf8RMrX6FYc1rVeVuQRN9WSfPsTUpuSTckpGEROObHpsFoXuL9SJ0yMeol0FFkCQkyyf 2yIgSfSK2sa84kSvbC/ojflLD5++VuMf9EE5LqPAk4ULChLRC8Z9lAiotM/Eo3OZDjcY WBmjhLufEbgkdPGZXLU+Yl+uWTKL2q+eadZ7MfBX5DnfdOdR/IIa4uw9rjXerrPWXkvM oyTmJFQciDwNZPTVhCIeej2lol0WpMdAOMkljQvLuPPN7YHfJ1UfZkxhNjhiSZ4McS3O Oyog== X-Gm-Message-State: AOAM530IN5UAs3VR+s+Qc1JrZ+I9Mm5Fc1nXw4wugcfd3I6yPo2OYshg ZDGy79YTFzh0hr02QsQoUJKCqn6S X-Google-Smtp-Source: ABdhPJxMoWw/EEyGCd0NT4tNLesrcHBYJCH+8CLEOJtdvFzeAz1HMF/xZmE8NLMTKJUqUIFwnW9jvw== X-Received: by 2002:a17:902:70ca:: with SMTP id l10mr23812476plt.31.1592952529845; Tue, 23 Jun 2020 15:48:49 -0700 (PDT) Received: from [192.168.178.30] ([118.149.66.243]) by smtp.gmail.com with ESMTPSA id 23sm18022977pfy.199.2020.06.23.15.48.47 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2020 15:48:48 -0700 (PDT) To: rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> From: Brian E Carpenter Message-ID: <470f1ef0-1355-60ce-c987-9c8ae9a9cedc@gmail.com> Date: Wed, 24 Jun 2020 10:48:44 +1200 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: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 23 Jun 2020 22:48:53 -0000 Hi, Welcome Brian R. I've intentionally answered below without reading the resulting thread. (= I will shortly proceed to read the thread.) On 23-Jun-20 03:43, Brian Rosen wrote: > Hello all >=20 > First of all, I am honored and delighted that the IAB chose me to co-ch= air this group. I think this work is critical to the IETF, and I look fo= rward to working with you all to make it successful. =20 =2E..critical to the IRTF and the RFC-consuming community too. This is no= t just an IETF effort. >=20 > Eliot and I have been talking about scope. I=E2=80=99m a believer in l= imiting scope as a primary way to make sure we can finish in a reasonable= time: unlimited scope projects finish in infinite time. Of course, the = converse is not always true, but the narrower the scope generally helps t= o focus effort and get projects finished in reasonable time. >=20 > We would like to propose that we, for now, limit our scope to the RSE r= ole, process and oversight, and not consider the RFC series itself in sco= pe. That means accepting the reality that things like what the series is= for, and who owns it remain undefined. We=E2=80=99ve managed to work wi= th that ambiguity for a long time, and we think we can define the RSE rol= e, process and oversight well enough without fixing those issues.=20 I fully understand the desire to limit the scope. I do however still beli= eve that without having a common view of the underlying principles of the= series, we'll have trouble reaching a common view of the RSE role. Hence= , section 3.1 of https://tools.ietf.org/html/draft-carpenter-rfc-principl= es-01, which is of course open to comments and disagreements. >=20 > We don=E2=80=99t propose that this scope limit is necessarily permanent= : if it gets in our way, we can revisit it, and if we finish the RSE issu= es quickly enough and there is desire to work on series issues, we can do= that. But for now, we propose to limit our scope. As we complete the st= ructural work, we can choose to delegate the evolution of the series or p= ortions of it to that structure, or we can take up that work here ourselv= es. >=20 > This is a proposal. We=E2=80=99ll look for consensus on this proposal.= If we don=E2=80=99t have consensus, we=E2=80=99ll deal with the wider s= cope. Your comments would be appreciated. >=20 > We have also been discussing what our agenda for IETF 108 should be. W= e would like to have a series of questions that focus our discussions at = the meeting. In some cases we could have consensus on answers, but in mo= st, we just hope to get a sense of where the workgroup is a the present t= ime. >=20 > Our list of questions is: > 1. Should the RSE be a hired employee or a contracted entity? It's a detail. The important aspect IMHO is what section 3.2 of my draft = says: The RFC Series Editor, while paid to serve the community, is a member of the same professional peer group as IAB members, IESG members, IETF and IRTF group chairs, and other experienced members of the technical community, each with their own distinct professional skills. > 2. Who hires/contracts the RSE? Again, it should be a detail, but I think we should argue the pros and co= ns of 3 options: - ISOC (because this isn't an IETF function) - IETF LLC (because they are handy and own the RPC contracts) - NewOrg (a dedicated entity for the RFC Series) > 3. For the purposes of day to day management, to whom does the RSE repo= rt? I think the answer is nobody, except for whatever is legally and financia= lly required as a result of the answer to the previous question. > 4. Is there some group that oversees the RSE? I believe that our experience with the IAOC and RSOC has shown our incomp= etence at "oversight" (where "our" means the pool of engineers we usually= call on for such jobs). But we must have some form of community responsi= bility. So yes. > 5. If the answer to 4 is yes, how is the board constituted? To a first approximation, a board such as Mike St Johns proposed seems co= rrect. > 6. Who defines the process that the RSE follows? This group? The Boar= d? The RSE defines it themselves? As today, the RSE defines general policy, subject to Board approval. Only= the Board should no longer be the IAB, but the one in point 5. The IAB C= harter will need an update. The RSE should define their own process details autonomously. But of cour= se, as today, the RSE may choose to appoint an advisory group. > 7. Can the RSE decide to not publish a document one of the stream edito= rs forwards to it? If so, on what grounds? I think we already discussed that enough to see that there's a split of o= pinion. My personal opninion is no, the stream manager can insist, but in= such a case the RSE may include a disclaimer of their own choice. Missing question: 8. To what extent does the RSE have direct control over the RPC and RFC P= ublisher entities, which are under contract to the LLC? I can see a wide range of answers to this, ranging from simple persuasion= to full control, somewhat linked to question 2 above. >=20 > We want to know from you is: are these the right questions? Are there = work group members who would be willing to make straw-man proposals that = could be presented and discussed at the meeting? I'm willing to update the relevant bits of draft-carpenter-rfc-principles= , or hand them over to this group as a separate draft, if preferred. I do= n't plan to attend the meeting if it's in the Madrid timezone. Regards Brian C > Brian >=20 From nobody Tue Jun 23 16:03: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 57EBD3A0C1D for ; Tue, 23 Jun 2020 16:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyhc_5Q-JMRr for ; Tue, 23 Jun 2020 16:03:28 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F143A0C15 for ; Tue, 23 Jun 2020 16:03:28 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id d66so132757pfd.6 for ; Tue, 23 Jun 2020 16:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=gyXsnZxcs0XBL6jAMJBAg4ErzehHoPiF9gDKzlOxxq4=; b=TdEhFp1IOx/dGvCfbABkEV2PiBfZ2Dbm5k+FZu/0o6ZEYUaiygujCDO3wFOWc5gkU6 K9cv0uea+mQrzTLiMNnp401wuGvJzX8K9Mzb0gHz3aalH4crv7AfR+czeV9ZycqAc/O3 7lnrfjpcW8QkU09teQRcvZkIYpIPJNtJpsiLpDgyYLQ/naIEBEy5W6TaNUFFhvz3edUz Ex9tbhti/KYC8K9zQba2AMO897lGvhbPU7yKRkeIDvipnIJYS4FmuVkJvO1DnMIlHYix 7PYa1HMehsCUUbWldAOB0y1rZgYGE+CYMvBv6jSl0sg1MU3NOiic0Za8JRwyalU7fb3V 5wVQ== 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=gyXsnZxcs0XBL6jAMJBAg4ErzehHoPiF9gDKzlOxxq4=; b=H09cofb2XpiTIPhgd87KP419R5c0k+slm7cv3S1gm2rIGes9xb/YPjzyN5ro1r+1+g LH4Q3Q1MzsXwo2HGk0ddHTXdRn5uQNeXjxhW42xRsBWXzOX3/itjLLidqWSmmqiQugk4 Eg6AWjQJijk1eEGyn1n6rBbBRvKvb7ULnoDa6JpvOxJ+PqdavczyEREOO8VZGkDGPE67 aBLVu6RTSR0cetRHa8nXIUytioZi3w5pFV+Lm+moORrVNedX+ZoCkzmjGbjvHjawlwB9 abg4FYehDnnz1RS6wKl7YmFgOd9dOEVRbwJeRmq+JbZ1ah0t/W3k3Ck3BbFZsDknHKST eC5A== X-Gm-Message-State: AOAM530X7JirG86EUfpPooif2RE+DdVeKc9pRdGbGDgw4QEHYnyyyTCa WB1NY700cGi2479sE5kBj91JK7e7 X-Google-Smtp-Source: ABdhPJwAE6PJM1MibMOZGoXvgM6OsRJZubOv8KxaXQVRfy7mUd6fu4qUJG7Y+YDtUy/HpFmpReqHvQ== X-Received: by 2002:a62:3c3:: with SMTP id 186mr26380639pfd.119.1592953407123; Tue, 23 Jun 2020 16:03:27 -0700 (PDT) Received: from [192.168.178.30] ([118.149.66.243]) by smtp.gmail.com with ESMTPSA id c8sm3431963pjn.16.2020.06.23.16.03.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2020 16:03:26 -0700 (PDT) To: Nevil Brownlee , rfced-future@iab.org References: From: Brian E Carpenter Message-ID: <3cfe7fa6-3031-fd50-a271-37f5d636729c@gmail.com> Date: Wed, 24 Jun 2020 11:03:20 +1200 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] re "who decides" 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, 23 Jun 2020 23:03:29 -0000 Hi Nevil, Sorry to be slow responding but real life intervened. Mainly I agree, exc= ept as noted below. On 03-Jun-20 17:23, Nevil Brownlee wrote: > Thinking a bit more about an advisory board for the RSE (the "RSAB"), I= =C2=A0 liked Mike/s earlier idea of one selected by NomCom.=C2=A0 How abo= ut this for a proposal: > 1. The RSAB is advisory to the RSE, not an oversight or management comm= ittee. I think (see my previous note) that the community will expect some sort o= f responsibility of the RSE *to* the board, so I think it has to be a bit= stronger than "advisory" but less than what we have seen from the RSOC. = I happen to think that "approval of general policy" as currently defined = as the IAB's responsibility is about right. (And of course *disapproval* = of general policy would typically trigger a discussion that could lead to= the RSE's resignation.) > 2. Each of the Series Input Streams appoints an ex officio representati= ve (non-voting). > 3. The RSAB has 5 voting members, with staggered 3-year terms. > 4. The voting members are selected by a NomCom, preferably an ISOC NomC= om, and approved by the IAB. > 5. The RSAB does policy stuff only; RPC contracts and performance are h= andled by our LLC. Agreed, but there is a related question of what happens if the RSE is dis= satisfied with the RPC performance. > When suggestions for changes to the RFC Series arise, the RSE and RSAB = will discuss them so as to achieve rough consensus within the RSAB.=C2=A0= Any such consensus will be further discussed on the rfc-interest list, s= o as to reach a wider consensus within the IETF participants. =2E.. and the IRTF and the RFC-using community, as far as practicable. > (I use the term "voting" above only as a way to minimise demands from a= ny of the Streams - we don't believe in voting!) >=20 > This leave the question of "who selects the RSE, and how?"=C2=A0=C2=A0=C2= =A0 Maybe the RSAB could do it? Once all this is in running order, yes. Bootstrapping is a bit more trick= y. Regards Brian >=20 > Cheers, Nevil >=20 >=20 > --=20 > ----------------------------------- > Nevil Brownlee, Taupo, NZ >=20 From nobody Tue Jun 23 16:15: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 5F7B13A0C07 for ; Tue, 23 Jun 2020 16:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dAbKnJ9C48y for ; Tue, 23 Jun 2020 16:15:15 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8C03A0C33 for ; Tue, 23 Jun 2020 16:15:11 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id 35so150984ple.0 for ; Tue, 23 Jun 2020 16:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=77pAmCIpFfNDJpvWBiXpN0XAAmNyERaWNYHyZ0JS+ok=; b=YHT+DUbdxZwAiXEllHr7uCASb362amL6dCvojWBf/Sb0rlkWEKc0oldCVq5is+eEDj XaOX0POwMb0ZIV3Pj6cYypWkFo8PQIhr9TqspqH+39rM+8foB6N7JNWneuZQCU6H5OiH tCtcA8bfZt9CCN+teHILylqFCJmYUDwH0vnxhkaqyVgKDWUwxnFCU/WnuJZtPn8tGYNY sWqvaAX6NWqCB+cU2r00aL9mArAjX87OdafQEMGea72wGQKI7lg8gBwH25qdl9KfgwAf dCD41TiMN0rTJhI215Ny+KF05okZiK9RrrVU3lGWCk/prsufAPAsiaS/w0Q7GsxhgyV+ CStQ== 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=77pAmCIpFfNDJpvWBiXpN0XAAmNyERaWNYHyZ0JS+ok=; b=W7AqQfOpm6tjnAYvM77Uwn4TzmzOxhURBfxZjcKkhRdEoswUJt+llHJE4BEQFyJEos fnvYiRiw7LXpLEeQe8uRt9Vm2KyrPs61SKmYZYKXBnEteKR9DQJfynMT/FNkru8UCiIf CL+5XKIDKpPDGE3M9qkVFf14ZzWibeWQ+E8wgB53rOYa+5EOK1n5eC1HJdHcPemvmFaR sYI7FUUFh1N08ZK//eHOT8rc2fQPNHHaX4NPhzqF3eVWug3TA3X5uN5isyMVioR60SLS 1oXRscDm2Sm8w2bDsNxia7CZGvngn7pB6P9qnpQ/RUF290zhNwtyTCQlljwGVrwvOF4h blUg== X-Gm-Message-State: AOAM532f0kfn/PmOKFbLJY6ZVaVmmN+f/VRMjrDVFMr2/7PbpWWeggW1 IlFosGPWRewbX/ZvgPKWKI4qgQty X-Google-Smtp-Source: ABdhPJyIHPbh9tIujRJ6Hx3lcOCHEM4UB/qc1Y/vQzuHWr6soS4S1twBm3MR0u/PftE7FDIIr0WbGg== X-Received: by 2002:a17:902:bb8b:: with SMTP id m11mr25291661pls.183.1592954110640; Tue, 23 Jun 2020 16:15:10 -0700 (PDT) Received: from [192.168.178.30] ([118.149.66.243]) by smtp.gmail.com with ESMTPSA id e124sm17623198pfh.140.2020.06.23.16.15.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2020 16:15:09 -0700 (PDT) To: Michael StJohns , rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <2ecc7fee-25ef-e4ff-a994-c3fb874a0bf3@nthpermutation.com> <8026b1b2-9c99-4129-ba6e-fb013878809b@dogfood.fastmail.com> <580f6254-32a0-a839-8db6-de83d7715cc1@nthpermutation.com> From: Brian E Carpenter Message-ID: Date: Wed, 24 Jun 2020 11:15:04 +1200 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: <580f6254-32a0-a839-8db6-de83d7715cc1@nthpermutation.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 23 Jun 2020 23:15:17 -0000 below... On 24-Jun-20 03:36, Michael StJohns wrote: > On 6/23/2020 7:49 AM, Bron Gondwana wrote: >> On Tue, Jun 23, 2020, at 02:12, Michael StJohns wrote: >>> > 3. For the purposes of day to day management, to whom does the RSE = report? >>> The RSE reports to themselves on an day-to-day basis.=C2=A0 This is n= ot a=C2=A0 >>> position that requires managerial injection on other than the big thi= ngs=C2=A0 >>> - e.g. contract formation and contractual compliance.=C2=A0=C2=A0 In = other words,=C2=A0 >>> the question assumes that the RSE requires day to day oversight, and=C2= =A0 >>> that's a push-poll formulation. >> >> This is a very narrow definition of "management" that pretty much read= s as "the RSE doesn't need micro-management so they don't need management= ".=C2=A0 A manager is also someone who advocates for their managees and p= rovides a human connection which is somewhat important here.=C2=A0 If we = treat management as purely "contractual compliance" of the "you hit the R= SE with a stick when they don't meet their SLA" variety, that's not a ver= y good management structure.. >> >> Who does the RSE tell that they're sick and taking a couple of days of= f to recover?=C2=A0 Who do they check in with when they have an issue or = dispute with someone else in the organisation, and want support or even j= ust a second opinion? >=20 > Contractor vs employee differences.=C2=A0=C2=A0 The RSE generally has t= asks and the contract spells out things like what happens in "unforeseeab= le circumstances" such as getting sick.=C2=A0 Since the RSE has in the pa= st been about 50% FTE, sliding things a few days or even a week is rarely= going to be a critical hit to the process. >=20 > Contractors don't have managers in the same way that employees do.=C2=A0= They have points of contact, and an entity that holds the other end of t= he contract.=C2=A0 At one point in my career, I held something north of 3= 0 contracts and I *never* ever felt the need to call up one of my contrac= tors and explain what they needed to do that day.=C2=A0=C2=A0 Had I tried= , the contracting officer and the contract POC would have been within the= ir rights to slap me down hard. >=20 > The RSE has to be thinking about more than a single person's=C2=A0 (or = even a designated small group's) opinion and paying attention to broader = things than "a [single] human connection".=C2=A0 I'm not sure if you've e= ver met any of the former RSEs, but I was honored to be a friend and coll= eague to each of them (and in one case was their "contracting entity" for= a period of time).=C2=A0 None of them ever had a problem connecting with= the IETF collectively or individually, nor did any of them require anyon= e to advocate for them - they were perfectly capable of doing that for th= emselves with very good results.=C2=A0 >=20 > If all you want is a task rabbit in the RSE role, you could make a case= along the lines you've sketched, but I think hiring plug replaceable RSE= s would be a Bad Idea (tm). Right. That's why I suspect that legally speaking this will be a contract= ed role rather than an at-will employee role, and it will not be a role w= here counting hours per week or PTO will be appropriate. You cannot buy R= SE services by the square cubit. But as Mike originally said, and so did = I, it's a detail. It does seem to me that the RSOC got this wrong and we = must avoid making the same mistake. Let's get the bigger questions settle= d - what is the RSE role and how does the RSE answer to the community as = a whole? Regards Brian C From nobody Tue Jun 23 16:19: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 316F53A0C2F for ; Tue, 23 Jun 2020 16:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZT5-awaxHHdU for ; Tue, 23 Jun 2020 16:19:02 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2B03A0C2D for ; Tue, 23 Jun 2020 16:19:02 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id BA9A325D8B; Tue, 23 Jun 2020 16:19:00 -0700 (PDT) From: Wes Hardaker To: Brian Rosen Cc: rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> Date: Tue, 23 Jun 2020 16:19:00 -0700 In-Reply-To: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> (Brian Rosen's message of "Mon, 22 Jun 2020 11:43:55 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 23 Jun 2020 23:19:03 -0000 Brian Rosen writes: > 1. Should the RSE be a hired employee or a contracted entity? > 2. Who hires/contracts the RSE? > 3. For the purposes of day to day management, to whom does the RSE report? [no hats, since I haven't asked what others think about this subject] One additional detail that I'd love to hear about related to the above three questions: what are we going to do about contract temporal terms, renewals, etc? The discussions about the above are great, but regardless of the model chosen: there will always the need to specify an appointment length and what renewal terms might be (with the caveat that an appointment length "until death or they quit", like the U.S. supreme court may remove the need for a renewal clause). Since this issue is one of the reasons why this group was formed, it sure seems like it should be on the agenda (again: IMHO). -- Wes Hardaker USC/ISI From nobody Tue Jun 23 16:27:47 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 5DA973A0C2B for ; Tue, 23 Jun 2020 16:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.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 QbY2fcAWq2eF for ; Tue, 23 Jun 2020 16:27:42 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 2968C3A0BD8 for ; Tue, 23 Jun 2020 16:27:41 -0700 (PDT) Received: (qmail 9210 invoked from network); 23 Jun 2020 23:27:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=23ef.5ef28fec.k2006; bh=8VU1AZA+lG7G82pjvc/1IKL0EXlf+o61fkTQNrWbkGE=; b=GUNShBn6Yi0JHNeAtpQmI8MKEUSgl3e+p7xsWHK0Ec0VM14QdBnUrn0P0aLHOxSgJKKD7VpPGQJQMgS/IgAgw7At8G3DIqFFhYKj56TKSGyzRxZLoYoGsx04AgQrOJbsdHJBhdMa0CFCpipvbSFZSlGccz7N3UT+iFofx6DPCmyD4HDML2D1wYpp9YRVxgiBL3kLmJmzfyulDWMpV36QBw4eUtPnnd/jR7pzPvrKUs8A7TvAwWnvZJ3QHMy+1czH Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 23 Jun 2020 23:27:40 -0000 Received: by ary.qy (Postfix, from userid 501) id F2CCB1B5D423; Tue, 23 Jun 2020 19:27:42 -0400 (EDT) Date: 23 Jun 2020 19:27:42 -0400 Message-Id: <20200623232742.F2CCB1B5D423@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: brong@fastmailteam.com In-Reply-To: <19ca95e4-b0d7-4860-94b2-d79416921113@dogfood.fastmail.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 23 Jun 2020 23:27:44 -0000 In article <19ca95e4-b0d7-4860-94b2-d79416921113@dogfood.fastmail.com> you write: >> > 1. Should the RSE be a hired employee or a contracted entity? >Hiring part time employees is totally a thing everwhere I've been. 2 days/week, 3 days/week, >whatever. I don't think the idea that it's not a 100% FTE role excludes it from being an employee >role. Agreed. I'm a contractor but I were hired for a larger role without a definite end-date, I'd think about being an employee. Half-time employees certainly are common here in the U.S. I suggest we strike this question as a detail the LLC can deal with if and when it arises. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Jun 23 16:48: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 CF8773A0C78 for ; Tue, 23 Jun 2020 16:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1apSi2NXADo for ; Tue, 23 Jun 2020 16:48:10 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBAC3A0C73 for ; Tue, 23 Jun 2020 16:48:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 81E0BBE24 for ; Wed, 24 Jun 2020 00:48:07 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rufGlzKEf96o for ; Wed, 24 Jun 2020 00:48:05 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 94E42BE3E for ; Wed, 24 Jun 2020 00:48:05 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1592956085; bh=lqLeWlSVkxhK9ylYXPd2QOeD4lfgc75cKG/M+Vj+6S0=; h=To:References:From:Subject:Date:In-Reply-To:From; b=hs+MT/av0yTabpUvaVPDH4jZXGjU8xi4EJyN/v4Farsxju3FdOokgeyPvnAXxj/Ho d0rbEtRrmx38hWPDnQ+oCVILk9TEwV7MEsdHRrzTmNfYceRWOq3Oe588Q9ufSXf7HD pzEPKWXzDZDp1SV3y7TCUj1nqEbpXlVBxCkyO2IU= To: rfced-future@iab.org References: <20200623232742.F2CCB1B5D423@ary.qy> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <021e051b-c5a3-fdb2-1b24-61c20a37fb25@cs.tcd.ie> Date: Wed, 24 Jun 2020 00:48:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200623232742.F2CCB1B5D423@ary.qy> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qWpfxjUcRyjAdeYnUCCaM33MMBgSJEuUh" Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 23 Jun 2020 23:48:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qWpfxjUcRyjAdeYnUCCaM33MMBgSJEuUh Content-Type: multipart/mixed; boundary="lhD3Z9ks0TlDnzxip1ZA6yY29mwjmlp2H"; protected-headers="v1" From: Stephen Farrell To: rfced-future@iab.org Message-ID: <021e051b-c5a3-fdb2-1b24-61c20a37fb25@cs.tcd.ie> Subject: Re: [Rfced-future] Scope and IETF 108 proposals References: <20200623232742.F2CCB1B5D423@ary.qy> In-Reply-To: <20200623232742.F2CCB1B5D423@ary.qy> --lhD3Z9ks0TlDnzxip1ZA6yY29mwjmlp2H Content-Type: multipart/mixed; boundary="------------0773A6D7CBF031A7AD8220E9" Content-Language: en-US This is a multi-part message in MIME format. --------------0773A6D7CBF031A7AD8220E9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Not just answering John, but more generally... On 24/06/2020 00:27, John Levine wrote: > Agreed. I'm a contractor but I were hired for a larger role without a > definite end-date, I'd think about being an employee. Half-time employ= ees > certainly are common here in the U.S. >=20 > I suggest we strike this question as a detail the LLC can deal with if > and when it arises. I don't think this is the first thing to try figure out, but... I do not like the idea of the RSE being an employee. I'm convinced it would be a bad plan if we decided that in general it is better for the RSE to be an employee. Deciding that the RSE can never be an employee would be almost as bad. Where I live, an RSE-as-employee would mean that, were the RSE re-appointed twice to the role, then that person would have the job indefinitely, until the job role is done away with via redundancy. IMO that's a fine bit of labour law, but not what we want for this role. And in case it's not clear, the problem is: if we did decide that the RSE has to be an employee, then we would be restricting our choices to people who live in places with (what I perceive to be) less desirable labour laws. I think this means we ought not try answer this question now. First decide who picks and why, then do that, and only then figure out what kind of contract makes sense. Perhaps the one bit of this question we could answer now might be to conclude: "we do not want to limit the kind of contractual arrangement between the LLC and RSE - the LLC ought figure out whatever kind of contract meets the needs of the community." (Or something like that.) Cheers, S. PS: I'm also kind of allergic to the LLC building up it's headcount - that ought not be a goal. --------------0773A6D7CBF031A7AD8220E9 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------0773A6D7CBF031A7AD8220E9-- --lhD3Z9ks0TlDnzxip1ZA6yY29mwjmlp2H-- --qWpfxjUcRyjAdeYnUCCaM33MMBgSJEuUh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl7ylLQACgkQWrL68XsX K+oWxA//fPAEyLL68SUu4sU2Ope9S06R8mIjcXm8CJpNSKT1tYXh1U+aKF439Bp3 qU4y2dUl20VZCilE0vo9gHKt8eC8/VejuUz3oON68EqPzsGTf7S1LUbmO5cZAafP 1A8RJlDsjtG2fc3+B4u+Fzw6bGGzCJgbIaJgNmxsfzcexRG1TI5xKqtae/YEFeks SMX/nakwFwaqygovwDujMvz6GFhuIb3BFLCUItc3FEaiw4SAc9q5hZe02Pus4cO7 L3tNj6gLTT8FzEMMtH7iw5efX1TqZTAaAwlbe9LWOpwddLcJfkNlhBLiDaYNBqmw FSUM2UtEU2xw6Wk9ZTLL4NxZODxXyc5+gHNpSQDgetZxTz5qs5iTktYk1gsBkXrO vcBgI+4/mwjliVmN4WnZEzX7m8Trqtl9nTkqtbERqUyJPPKOmoQi1BxnWtTR4VY+ 4F1DA4JM7HAsy6LxEenjhf+Cs09fj9Azu6HqJWI06cIT/vfH2WoS4zRYGO245Or2 5tJQd7x/3iRYBVfqlYSvMcyI0hNofvmWLjWaDadvCk2v1qKRmxq+Y6oaITfVdBOp F0kVmsDNOTi8h8mL/xu2e4r8nGyC+l4tzur6vouwgYfwwSvXYDPQxYWUxSCiIAkc 5wwIfLPPEfceIUhkL7Iq33vzRh1cZYP3v1JTMmWC7KxyIDwm5yY= =Il3I -----END PGP SIGNATURE----- --qWpfxjUcRyjAdeYnUCCaM33MMBgSJEuUh-- From nobody Tue Jun 23 18:30: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 9F7DB3A0D5B for ; Tue, 23 Jun 2020 18:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10jYfuNJZfLw; Tue, 23 Jun 2020 18:30:46 -0700 (PDT) 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 313B53A0D56; Tue, 23 Jun 2020 18:30:46 -0700 (PDT) From: Jay Daley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_164419BD-4113-4D2C-A875-741F90224A93" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 24 Jun 2020 13:30:44 +1200 In-Reply-To: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> Cc: rfced-future@iab.org To: Brian Rosen References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 24 Jun 2020 01:30:50 -0000 --Apple-Mail=_164419BD-4113-4D2C-A875-741F90224A93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian > On 23/06/2020, at 3:43 AM, Brian Rosen wrote: >=20 > Hello all >=20 > First of all, I am honored and delighted that the IAB chose me to = co-chair this group. I think this work is critical to the IETF, and I = look forward to working with you all to make it successful. =20 >=20 > Eliot and I have been talking about scope. I=E2=80=99m a believer in = limiting scope as a primary way to make sure we can finish in a = reasonable time: unlimited scope projects finish in infinite time. Of = course, the converse is not always true, but the narrower the scope = generally helps to focus effort and get projects finished in reasonable = time. >=20 > We would like to propose that we, for now, limit our scope to the RSE = role, process and oversight, and not consider the RFC series itself in = scope. That means accepting the reality that things like what the = series is for, and who owns it remain undefined. We=E2=80=99ve managed = to work with that ambiguity for a long time, and we think we can define = the RSE role, process and oversight well enough without fixing those = issues. =20 >=20 > We don=E2=80=99t propose that this scope limit is necessarily = permanent: if it gets in our way, we can revisit it, and if we finish = the RSE issues quickly enough and there is desire to work on series = issues, we can do that. But for now, we propose to limit our scope. As = we complete the structural work, we can choose to delegate the evolution = of the series or portions of it to that structure, or we can take up = that work here ourselves. >=20 > This is a proposal. We=E2=80=99ll look for consensus on this = proposal. If we don=E2=80=99t have consensus, we=E2=80=99ll deal with = the wider scope. Your comments would be appreciated. Unless I=E2=80=99ve missed it, I don=E2=80=99t believe there has been = any clear problem statement, which I would suggest should be a = pre-requisite before moving to design a framework for the solution. My summary of the high-level problem statement is 1. We do not have a strategy for the RFC series. 2. We do not have a process for creating a strategy for the RFC series. = =20 3. We do not have a "process for determining how well the series is = meeting its objectives and serving the wide variety of audiences it is = intended to serve" [1] Point 2 seems to be the one that all of the proposed solutions revolve = around. It is clearly within the purview of the RSE to establish the = process for creating a strategy [2] but unfortunately my involvement = began too late to analyse why that either didn=E2=80=99t happen or did = happen but was unsuccessful. While this is a sensitive topic, it needs = to be tackled without getting personal to only pull out the elements = necessary to understand if there is a structural issue that requires a = structural solution or something else Jay [1] = https://mailarchive.ietf.org/arch/msg/rfced-future/2PpDfGNyICpimKbpaLIsBQw= Ybrc/ [2] https://tools.ietf.org/html/rfc8728#section-2.1 >=20 > We have also been discussing what our agenda for IETF 108 should be. = We would like to have a series of questions that focus our discussions = at the meeting. In some cases we could have consensus on answers, but = in most, we just hope to get a sense of where the workgroup is a the = present time. >=20 > Our list of questions is: > 1. Should the RSE be a hired employee or a contracted entity? > 2. Who hires/contracts the RSE? > 3. For the purposes of day to day management, to whom does the RSE = report? > 4. Is there some group that oversees the RSE? > 5. If the answer to 4 is yes, how is the board constituted? > 6. Who defines the process that the RSE follows? This group? The = Board? The RSE defines it themselves? > 7. Can the RSE decide to not publish a document one of the stream = editors forwards to it? If so, on what grounds? >=20 > We want to know from you is: are these the right questions? Are there = work group members who would be willing to make straw-man proposals that = could be presented and discussed at the meeting? >=20 > Brian > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_164419BD-4113-4D2C-A875-741F90224A93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Brian

On 23/06/2020, at 3:43 AM, = Brian Rosen <br@brianrosen.net> wrote:

Hello = all

First of all, I am honored and = delighted that the IAB chose me to co-chair this group.  I think = this work is critical to the IETF, and I look forward to working with = you all to make it successful.  

Eliot = and I have been talking about scope.  I=E2=80=99m a believer in = limiting scope as a primary way to make sure we can finish in a = reasonable time: unlimited scope projects finish in infinite time. =  Of course, the converse is not always true, but the narrower the = scope generally helps to focus effort and get projects finished in = reasonable time.

We would like to propose = that we, for now, limit our scope to the RSE role, process and = oversight, and not consider the RFC series itself in scope.  That = means accepting the reality that things like what the series is for, and = who owns it remain undefined.  We=E2=80=99ve managed to work with = that ambiguity for a long time, and we think we can define the RSE role, = process and oversight well enough without fixing those issues.  

We don=E2=80=99t propose that this scope limit = is necessarily permanent: if it gets in our way, we can revisit it, and = if we finish the RSE issues quickly enough and there is desire to work = on series issues, we can do that.  But for now, we propose to limit = our scope. As we complete the structural work, we can choose to delegate = the evolution of the series or portions of it to that structure, or we = can take up that work here ourselves.

This = is a proposal.  We=E2=80=99ll look for consensus on this proposal. =  If we don=E2=80=99t have consensus, we=E2=80=99ll deal with the = wider scope.  Your comments would be appreciated.

Unless = I=E2=80=99ve missed it, I don=E2=80=99t believe there has been any clear = problem statement, which I would suggest should be a pre-requisite = before moving to design a framework for the solution.

My summary of the high-level problem statement = is

1.  We do not have a = strategy for the RFC series.

2. =  We do not have a process for creating a strategy for the RFC = series.  

3.  We do not = have a "process for determining how well the series is meeting its = objectives and serving the wide variety of audiences it is intended to = serve" [1]

Point 2 seems to be the = one that all of the proposed solutions revolve around.  It is = clearly within the purview of the RSE to establish the process for = creating a strategy [2] but unfortunately my involvement began too late = to analyse why that either didn=E2=80=99t happen or did happen but was = unsuccessful.  While this is a sensitive topic, it needs to be = tackled without getting personal to only pull out the elements necessary = to understand if there is a structural issue that requires a structural = solution or something else

Jay

<= br class=3D"">


We have also = been discussing what our agenda for IETF 108 should be.  We would = like to have a series of questions that focus our discussions at the = meeting.  In some cases we could have consensus on answers, but in = most, we just hope to get a sense of where the workgroup is a the = present time.

Our list of questions is:
1. Should the RSE be a hired employee or a contracted = entity?
2. Who hires/contracts the RSE?
3. = For the purposes of day to day management, to whom does the RSE = report?
4. Is there some group that oversees the RSE?
5. If the answer to 4 is yes, how is the board = constituted?
6. Who defines the process that the RSE = follows?  This group?  The Board?  The RSE defines it = themselves?
7. Can the RSE decide to not publish a = document one of the stream editors forwards to it?  If so,  on = what grounds?

We want to know from you is: = are these the right questions?  Are there work group members who = would be willing to make straw-man proposals that could be presented and = discussed at the meeting?

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

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

= --Apple-Mail=_164419BD-4113-4D2C-A875-741F90224A93-- From nobody Tue Jun 23 18:46:41 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 B11CB3A0403 for ; Tue, 23 Jun 2020 18:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=fugue-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 e_DMequ623W4 for ; Tue, 23 Jun 2020 18:46:37 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 65C4F3A0433 for ; Tue, 23 Jun 2020 18:46:37 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id v19so462362qtq.10 for ; Tue, 23 Jun 2020 18:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=bxrvlQVQyOgd9Ese8oN6fy0Tu0WJpPu0ncw0U7jSVHs=; b=0+gxVu3z2P+IMKnC4wK81toOq0d97yHB+rchlePuocaM9FH5jjteUDn2Choiu5frJX cPtLWIh6vQWuyMCnSUUs2/PK6G4o2ilnuglJSoaRcwmNXeGH0xHLViaZ+tTqxzSyWxe3 dwAaw7dINk1IGriS1HnB1m6EsO41IYxJFOV0NYCAUjfukihpMRApCar53P4q1pCOax2o uA2xBm4DLgcTp6OlOPQ8yWquUzaS9M4lij2Wl9Txxs6GMNAkobAQ8wG9J8qAw+y47wiV nnHS+El8QB9FUdDExnHC9t8PuUmO5JLdgPG5eDs+woTn9VT6OC5Y1S6HqKaTpDoTUpk4 ueRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=bxrvlQVQyOgd9Ese8oN6fy0Tu0WJpPu0ncw0U7jSVHs=; b=QIiCkdiN+2l47JNbbWKNHu/wUBsgCuqzWCquaGevhuol+/TYHTTzpB4W6N/qWUnc1J rX6BcsLqVLdtj6RLJ6p9SyVaGA6mCzAKYYGoxkwZXYbhbU9nujT0WOwTFXtL2YsHaHG3 pQiBPY4Ob58l/Q41upy1XHRzTh40KZPOg89oNfjjxP3w6bVFfcwtTz2lmAdpUL/OH5OE l/MkVH9x5QrZ1qwoSHe/czySRl4LI7buhoQCirI9Qs9O+X50iMnEWoEnxUyAHWsMviQM OrxWA1hw+H9LSI0Wt6qDtJU1LSgdI1Oc8I9eqh617pGNj/eUTj9k5tn9pYv3H9+fRe2m GtqA== X-Gm-Message-State: AOAM530SDmbbbBsrOSYUffY+UhDvQkngCNim9RfcYDGJqSu/uc1ICO+T UPekjnDjoE/Ncc0JtVjDD6Zl2A== X-Google-Smtp-Source: ABdhPJzhzGbgHV/45RKYDTpfNBG64fT7STAKerLu1tLODdcYj/8/JhYgtFf89MoX2DSanrevn9sA7w== X-Received: by 2002:ac8:498c:: with SMTP id f12mr717861qtq.63.1592963196365; Tue, 23 Jun 2020 18:46:36 -0700 (PDT) Received: from ?IPv6:2601:18b:300:36ee:55c1:4b81:4d89:d420? ([2601:18b:300:36ee:55c1:4b81:4d89:d420]) by smtp.gmail.com with ESMTPSA id j16sm2112639qtn.91.2020.06.23.18.46.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jun 2020 18:46:35 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-52A64ED5-683C-4C26-94B5-660D5DD990B5 Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Tue, 23 Jun 2020 21:46:34 -0400 Message-Id: <52EC9ADD-2D8B-4B0A-BB56-A1A1FE8362AE@fugue.com> References: Cc: Brian Rosen , rfced-future@iab.org In-Reply-To: To: Jay Daley X-Mailer: iPhone Mail (18A5301q) Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 24 Jun 2020 01:46:40 -0000 --Apple-Mail-52A64ED5-683C-4C26-94B5-660D5DD990B5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Point 3 seems to imply that there is some =E2=80=9Cwe=E2=80=9D that could ha= ve consensus on where the series is meeting its objectives. This might sound= like a nit, but I suspect there is a wide diversity of opinion on this topi= c.=20 > On Jun 23, 2020, at 21:30, Jay Daley wrote: >=20 > =EF=BB=BFBrian >=20 >>> On 23/06/2020, at 3:43 AM, Brian Rosen wrote: >>>=20 >>> Hello all >>>=20 >>> First of all, I am honored and delighted that the IAB chose me to co-cha= ir this group. I think this work is critical to the IETF, and I look forwar= d to working with you all to make it successful. =20 >>>=20 >>> Eliot and I have been talking about scope. I=E2=80=99m a believer in li= miting scope as a primary way to make sure we can finish in a reasonable tim= e: unlimited scope projects finish in infinite time. Of course, the convers= e is not always true, but the narrower the scope generally helps to focus ef= fort and get projects finished in reasonable time. >>>=20 >>> We would like to propose that we, for now, limit our scope to the RSE ro= le, process and oversight, and not consider the RFC series itself in scope. = That means accepting the reality that things like what the series is for, a= nd who owns it remain undefined. We=E2=80=99ve managed to work with that am= biguity for a long time, and we think we can define the RSE role, process an= d oversight well enough without fixing those issues. =20 >>>=20 >>> We don=E2=80=99t propose that this scope limit is necessarily permanent:= if it gets in our way, we can revisit it, and if we finish the RSE issues q= uickly enough and there is desire to work on series issues, we can do that. = But for now, we propose to limit our scope. As we complete the structural w= ork, we can choose to delegate the evolution of the series or portions of it= to that structure, or we can take up that work here ourselves. >>>=20 >>> This is a proposal. We=E2=80=99ll look for consensus on this proposal. = If we don=E2=80=99t have consensus, we=E2=80=99ll deal with the wider scope= . Your comments would be appreciated. >>=20 >> Unless I=E2=80=99ve missed it, I don=E2=80=99t believe there has been any= clear problem statement, which I would suggest should be a pre-requisite be= fore moving to design a framework for the solution. >>=20 >> My summary of the high-level problem statement is >>=20 >> 1. We do not have a strategy for the RFC series. >>=20 >> 2. We do not have a process for creating a strategy for the RFC series. = =20 >>=20 >> 3. We do not have a "process for determining how well the series is meet= ing its objectives and serving the wide variety of audiences it is intended t= o serve" [1] >>=20 >> Point 2 seems to be the one that all of the proposed solutions revolve ar= ound. It is clearly within the purview of the RSE to establish the process f= or creating a strategy [2] but unfortunately my involvement began too late t= o analyse why that either didn=E2=80=99t happen or did happen but was unsucc= essful. While this is a sensitive topic, it needs to be tackled without get= ting personal to only pull out the elements necessary to understand if there= is a structural issue that requires a structural solution or something else= >>=20 >> Jay >>=20 >> [1] https://mailarchive.ietf.org/arch/msg/rfced-future/2PpDfGNyICpimKbpa= LIsBQwYbrc/ >> [2] https://tools.ietf.org/html/rfc8728#section-2.1 >>=20 >>=20 >>=20 >> We have also been discussing what our agenda for IETF 108 should be. We w= ould like to have a series of questions that focus our discussions at the me= eting. In some cases we could have consensus on answers, but in most, we ju= st hope to get a sense of where the workgroup is a the present time. >>=20 >> Our list of questions is: >> 1. Should the RSE be a hired employee or a contracted entity? >> 2. Who hires/contracts the RSE? >> 3. For the purposes of day to day management, to whom does the RSE report= ? >> 4. Is there some group that oversees the RSE? >> 5. If the answer to 4 is yes, how is the board constituted? >> 6. Who defines the process that the RSE follows? This group? The Board?= The RSE defines it themselves? >> 7. Can the RSE decide to not publish a document one of the stream editors= forwards to it? If so, on what grounds? >>=20 >> We want to know from you is: are these the right questions? Are there wo= rk group members who would be willing to make straw-man proposals that could= be presented and discussed at the meeting? >>=20 >> Brian >> --=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 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail-52A64ED5-683C-4C26-94B5-660D5DD990B5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Point 3 seems to imply tha= t there is some =E2=80=9Cwe=E2=80=9D that could have consensus on where the s= eries is meeting its objectives. This might sound like a nit, but I suspect t= here is a wide diversity of opinion on this topic. 

On Jun 23, 2020, at 21:30, Jay Daley <ja= y@ietf.org> wrote:

=EF=BB=BFBrian

On 23/06/2020, at 3:43 AM, Brian Rosen= <br@brianrosen.net&g= t; wrote:

Hello all

First of all, I am honored a= nd delighted that the IAB chose me to co-chair this group.  I think thi= s work is critical to the IETF, and I look forward to working with you all t= o make it successful.  

Eliot and I have b= een talking about scope.  I=E2=80=99m a believer in limiting scope as a= primary way to make sure we can finish in a reasonable time: unlimited scop= e projects finish in infinite time.  Of course, the converse is not alw= ays true, but the narrower the scope generally helps to focus effort and get= projects finished in reasonable time.

We would= like to propose that we, for now, limit our scope to the RSE role, process a= nd oversight, and not consider the RFC series itself in scope.  That me= ans accepting the reality that things like what the series is for, and who o= wns it remain undefined.  We=E2=80=99ve managed to work with that ambig= uity for a long time, and we think we can define the RSE role, process and o= versight well enough without fixing those issues.  

We don=E2=80=99t propose that this scope limit is necessarily perm= anent: if it gets in our way, we can revisit it, and if we finish the RSE is= sues quickly enough and there is desire to work on series issues, we can do t= hat.  But for now, we propose to limit our scope. As we complete the st= ructural work, we can choose to delegate the evolution of the series or port= ions of it to that structure, or we can take up that work here ourselves.
This is a proposal.  We=E2=80=99ll look for c= onsensus on this proposal.  If we don=E2=80=99t have consensus, we=E2=80= =99ll deal with the wider scope.  Your comments would be appreciated.

Unless I= =E2=80=99ve missed it, I don=E2=80=99t believe there has been any clear prob= lem statement, which I would suggest should be a pre-requisite before moving= to design a framework for the solution.

My summary of the high-level problem statement is

=
1.  We do not have a strategy for the RFC series.
=
2.  We do not have a process for creating a s= trategy for the RFC series.  

3. &n= bsp;We do not have a "process for determining how well the series is meeting= its objectives and serving the wide variety of audiences it is intended to s= erve" [1]

Point 2 seems to be the one th= at all of the proposed solutions revolve around.  It is clearly within t= he purview of the RSE to establish the process for creating a strategy [2] b= ut unfortunately my involvement began too late to analyse why that either di= dn=E2=80=99t happen or did happen but was unsuccessful.  While this is a= sensitive topic, it needs to be tackled without getting personal to only pu= ll out the elements necessary to understand if there is a structural issue t= hat requires a structural solution or something else
Jay

[1]  https://mailarchive.ietf.org/arch/msg/rfced-future/= 2PpDfGNyICpimKbpaLIsBQwYbrc/



We have also been discussing what our agenda for IETF 108 should be.  = ;We would like to have a series of questions that focus our discussions at t= he meeting.  In some cases we could have consensus on answers, but in m= ost, we just hope to get a sense of where the workgroup is a the present tim= e.

Our list of questions is:
1. S= hould the RSE be a hired employee or a contracted entity?
2. W= ho hires/contracts the RSE?
3. For the purposes of day to day m= anagement, to whom does the RSE report?
4. Is there some group= that oversees the RSE?
5. If the answer to 4 is yes, how is t= he board constituted?
6. Who defines the process that the RSE f= ollows?  This group?  The Board?  The RSE defines it themselv= es?
7. Can the RSE decide to not publish a document one of the= stream editors forwards to it?  If so,  on what grounds?

We want to know from you is: are these the right questi= ons?  Are there work group members who would be willing to make straw-m= an proposals that could be presented and discussed at the meeting?

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

-- 
Jay Da= ley
IETF Executive Director
jay@ietf.org

--
Rfced-future mailing listRfced-future@iab.org
https://www.iab.org/mailman/list= info/rfced-future
= --Apple-Mail-52A64ED5-683C-4C26-94B5-660D5DD990B5-- From nobody Tue Jun 23 20:11:35 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 EADBB3A03F2 for ; Tue, 23 Jun 2020 20:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 fT-ZDLBjiQ7U for ; Tue, 23 Jun 2020 20:11:33 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 59E803A03F3 for ; Tue, 23 Jun 2020 20:11:33 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id r18so654568pgk.11 for ; Tue, 23 Jun 2020 20:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TfoveOEIEaZVLCFoK/QJTjXdylJbOsoVrr3SgS3nhPM=; b=kBii1kvZ1M2OjAqs6FM3EPddaapOwguAk6vfszmwBcuHpJOTzoAex1CRUB6yU2glqL x16Y4xTHR93Uszn4EohpbE7BRqb27ZFQMa5xA94oHc89QlAsCvmeWGwGkYgDw0jvUamR QptZf3TCK3SX7YsfsFTIIu20eBMoa5mI+LPX5yZTn1C7dqyEsPDNWD/S71dNSpCZ69LQ wTsw99Ug4hiTQuKiUD4ZY0sT6b9BDkOaC+bw4uyu+XU6i7+955cGfuVtI1Mhv7hnOJX1 N3wS8ku61SOjrON86ehWmXetXYnwhQkxesiADzy5wb7/+UH0WF+vpoeg4zUTzS9L1Pmf Px3Q== 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=TfoveOEIEaZVLCFoK/QJTjXdylJbOsoVrr3SgS3nhPM=; b=YCgbCzcobGO7pEDGwn2Z/yk1RTS9iUD2Lmwo4MFUZc1guuUaTCdSnl+jVKvHricwtS iU+zxY9foy4kmJ0blnqKh57PFoOvyUIy+ykY5D0rJvqs9wnM4UncI9Q0NF/nqbPo7kv+ ZU8kQ3jagrYzXjCsCkP5OJisE1HMDH3pJb6SJYnUiOKD4AMX1dPHJ3eyVaVc4/+MHLS8 M14IfqlRmXFh8loFm98x6oDNWGO4NS70XBpUijOtIx6NV1ZoL6ebbeOGQJgi+/2wJpKd sO+GPHM0WJlxGaNXW2t5grZzu18el9r1R69I7s2P/Ve8429IcSEAIqXckxeM9R2IZ9GX pdhg== X-Gm-Message-State: AOAM531MqBBJKBYWsuUiDA5FFS3Is4wJvr8bw2f9WCAZdIojHJOWkbqN ZzpCzyeoz7BwCs4G3ufwBo69Td1N X-Google-Smtp-Source: ABdhPJxb4lL/pjt+jeczK5z5un+Nh+BpZqxqDRUXkyKa/JnqU1L8InFbE7qBlYwz5bs+clVUUoKSXg== X-Received: by 2002:a63:214d:: with SMTP id s13mr19126015pgm.277.1592968292553; Tue, 23 Jun 2020 20:11:32 -0700 (PDT) Received: from [192.168.178.30] ([118.149.66.243]) by smtp.gmail.com with ESMTPSA id 140sm18453182pfv.38.2020.06.23.20.11.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2020 20:11:31 -0700 (PDT) To: Jay Daley , Brian Rosen Cc: rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> From: Brian E Carpenter Message-ID: <4fa9d924-060b-471a-63e2-b0253cd508bd@gmail.com> Date: Wed, 24 Jun 2020 15:11:26 +1200 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] Scope and IETF 108 proposals 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, 24 Jun 2020 03:11:35 -0000 On 24-Jun-20 13:30, Jay Daley wrote: > Brian >=20 >> On 23/06/2020, at 3:43 AM, Brian Rosen > wrote: >> >> Hello all >> >> First of all, I am honored and delighted that the IAB chose me to co-c= hair this group. =C2=A0I think this work is critical to the IETF, and I l= ook forward to working with you all to make it successful. =C2=A0 >> >> Eliot and I have been talking about scope. =C2=A0I=E2=80=99m a believe= r in limiting scope as a primary way to make sure we can finish in a reas= onable time: unlimited scope projects finish in infinite time. =C2=A0Of c= ourse, the converse is not always true, but the narrower the scope genera= lly helps to focus effort and get projects finished in reasonable time. >> >> We would like to propose that we, for now, limit our scope to the RSE = role, process and oversight, and not consider the RFC series itself in sc= ope. =C2=A0That means accepting the reality that things like what the ser= ies is for, and who owns it remain undefined. =C2=A0We=E2=80=99ve managed= to work with that ambiguity for a long time, and we think we can define = the RSE role, process and oversight well enough without fixing those issu= es. =C2=A0 >> >> We don=E2=80=99t propose that this scope limit is necessarily permanen= t: if it gets in our way, we can revisit it, and if we finish the RSE iss= ues quickly enough and there is desire to work on series issues, we can d= o that. =C2=A0But for now, we propose to limit our scope. As we complete = the structural work, we can choose to delegate the evolution of the serie= s or portions of it to that structure, or we can take up that work here o= urselves. >> >> This is a proposal. =C2=A0We=E2=80=99ll look for consensus on this pro= posal. =C2=A0If we don=E2=80=99t have consensus, we=E2=80=99ll deal with = the wider scope. =C2=A0Your comments would be appreciated. >=20 > Unless I=E2=80=99ve missed it, I don=E2=80=99t believe there has been a= ny clear problem statement, which I would suggest should be a pre-requisi= te before moving to design a framework for the solution. That's really why I started on draft-carpenter-rfc-principles. I don't se= e it as a problem statement, though. The RFC Series doesn't have an exist= ential problem; what it has is a lack of clearly written principles. > My summary of the high-level problem statement is >=20 > 1. =C2=A0We do not have a strategy for the RFC series. >=20 > 2. =C2=A0We do not have a process for creating a strategy for the RFC s= eries. =C2=A0 >=20 > 3. =C2=A0We do not have a "process for determining how well the series = is meeting its objectives and serving the wide variety of audiences it is= intended to serve" [1] Sure. But that has always been assumed to be part of the RSE's job. Our j= ob here, as I understand it, is to define the RSE's role and how they are= appointed. > Point 2 seems to be the one that all of the proposed solutions revolve = around. =C2=A0It is clearly within the purview of the RSE to establish th= e process for creating a strategy [2] but unfortunately my involvement be= gan too late to analyse why that either didn=E2=80=99t happen or did happ= en but was unsuccessful. =C2=A0While this is a sensitive topic, it needs = to be tackled without getting personal to only pull out the elements nece= ssary to understand if there is a structural issue that requires a struct= ural solution or something else IMNSHO the main challenges were (a) the job of overseeing the xml2rfcv3 i= ntroduction became rather all-consuming; (b) the RSOC fell into the same = micro-management trap as the IAOC did; and possibly (c) the IAB didn't ac= t like the kind of advisory board that the RSE (like any series editor) n= eeds. Regards Brian C >=20 > Jay >=20 > [1] =C2=A0https://mailarchive.ietf.org/arch/msg/rfced-future/2PpDfGNyIC= pimKbpaLIsBQwYbrc/ > [2] =C2=A0https://tools.ietf.org/html/rfc8728#section-2.1 >=20 >=20 >> >> We have also been discussing what our agenda for IETF 108 should be. =C2= =A0We would like to have a series of questions that focus our discussions= at the meeting. =C2=A0In some cases we could have consensus on answers, = but in most, we just hope to get a sense of where the workgroup is a the = present time. >> >> Our list of questions is: >> 1. Should the RSE be a hired employee or a contracted entity? >> 2. Who hires/contracts the RSE? >> 3. For the purposes of day to day management, to whom does the RSE rep= ort? >> 4. Is there some group that oversees the RSE? >> 5. If the answer to 4 is yes, how is the board constituted? >> 6. Who defines the process that the RSE follows? =C2=A0This group? =C2= =A0The Board? =C2=A0The RSE defines it themselves? >> 7. Can the RSE decide to not publish a document one of the stream edit= ors forwards to it? =C2=A0If so, =C2=A0on what grounds? >> >> We want to know from you is: are these the right questions? =C2=A0Are = there work group members who would be willing to make straw-man proposals= that could be presented and discussed at the meeting? >> >> Brian >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 > --=C2=A0 > Jay Daley > IETF Executive Director > jay@ietf.org >=20 >=20 From nobody Tue Jun 23 20:17: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 F177C3A0528 for ; Tue, 23 Jun 2020 20:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62wX9REHkMXz for ; Tue, 23 Jun 2020 20:17:49 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3083A0486 for ; Tue, 23 Jun 2020 20:17:49 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id e9so668860pgo.9 for ; Tue, 23 Jun 2020 20:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=hxbY8HsJdpT10TQ0goFM9MZ8bSDWUbMlCCee49Gd/xU=; b=oqxNE4h9nkWkUNSLBUP2xii8ZoQJH5wt8IDq2r0VNWe+TogbKf9uLtavsIf6xeMcVL tSGtwEEMVuoKZc+SbMtrOPRkHZ0+sIawlKPNvBy9JOhfOLepfY99BGN5BYYetHMZEwY9 EhsCIZMNgDQJ0Kv8RWVEIS5wgTx2pgcgT3Ag+hYZOatfCU2kWT+3ntCs/ADEan6L8fAc Qt4DuGyTHHD9w+qdx/NIlFA+MUF2+aPL3y/mLCwbPGZdBBLwW6HOcjRrGLeFqcL6QWm9 An962/ivVBYtCW7HoSl2I0u+FQ3aMxwG9u1PChiJ8Gh80dPhDbkcOs3URYaoGaIS+ULr gTTw== 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=hxbY8HsJdpT10TQ0goFM9MZ8bSDWUbMlCCee49Gd/xU=; b=eRWU38BG44H7gkmr6v1Oauk+uzScSoq7GlZ4RADnRdpM1eKcbVTdIIKJ6BN7Izz8X9 Y4MEgIur92chtx2/1gZM7PCuFD9CNIz4NR5M0W1YP59kis7x14emubO4HcTT1aBFIZqL p4lSPJIVabwjioAZKb1gn+MwYWvfOyvGtz63xe+0qPUdiE5CNHmC1XmHzvsJwiOcLcYC rF7pMiLtWrJwux+sGhIHhmcV2jBn3gtR7Y6vCJ4hCwymRkVWg2BnVKnr7qJCh/gD2F4/ 6YeZnt4cZVO1sy8IcGpQLhbwU0AgPDD1HDStBpNoJ+zPoBsSkK6UYn0qfT2ClD21wbF6 AZ6w== X-Gm-Message-State: AOAM533hcC9xHgl8X8gPK2MxLI6Rol5218riGZ85iaGx2PZDhk7VoXU7 Q9y0j/Fy5d9rFlM1yvythjFRZTD2 X-Google-Smtp-Source: ABdhPJybMKfwJNRHnTJUxn9qBRJTn46YtGYUzCZM59aUiLVBBgTGiLW5wuX8LwCnpDLM75HNOo8sgQ== X-Received: by 2002:a65:6714:: with SMTP id u20mr13901191pgf.121.1592968668823; Tue, 23 Jun 2020 20:17:48 -0700 (PDT) Received: from [192.168.178.30] ([118.149.66.243]) by smtp.gmail.com with ESMTPSA id h3sm18279927pfr.2.2020.06.23.20.17.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2020 20:17:48 -0700 (PDT) To: Stephen Farrell , rfced-future@iab.org References: <20200623232742.F2CCB1B5D423@ary.qy> <021e051b-c5a3-fdb2-1b24-61c20a37fb25@cs.tcd.ie> From: Brian E Carpenter Message-ID: Date: Wed, 24 Jun 2020 15:17:42 +1200 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: <021e051b-c5a3-fdb2-1b24-61c20a37fb25@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 24 Jun 2020 03:17:51 -0000 On 24-Jun-20 11:48, Stephen Farrell wrote: > > Hiya, > > Not just answering John, but more generally... > > On 24/06/2020 00:27, John Levine wrote: >> Agreed. I'm a contractor but I were hired for a larger role without a >> definite end-date, I'd think about being an employee. Half-time employees >> certainly are common here in the U.S. >> >> I suggest we strike this question as a detail the LLC can deal with if >> and when it arises. > > I don't think this is the first thing to try figure > out, but... I do not like the idea of the RSE being > an employee. I'm convinced it would be a bad plan if > we decided that in general it is better for the RSE to > be an employee. Deciding that the RSE can never be an > employee would be almost as bad. > > Where I live, an RSE-as-employee would mean that, were > the RSE re-appointed twice to the role, then that person > would have the job indefinitely, until the job role is > done away with via redundancy. IMO that's a fine bit of > labour law, but not what we want for this role. > > And in case it's not clear, the problem is: if we did > decide that the RSE has to be an employee, then we would > be restricting our choices to people who live in places > with (what I perceive to be) less desirable labour > laws. > > I think this means we ought not try answer this question > now. First decide who picks and why, then do that, and > only then figure out what kind of contract makes sense. > > Perhaps the one bit of this question we could answer now > might be to conclude: "we do not want to limit the kind > of contractual arrangement between the LLC and RSE - the > LLC ought figure out whatever kind of contract meets the > needs of the community." (Or something like that.) Indeed. The universe of possibilities is wider than just employee versus contractor. Just to invent another one, imagine that a large university decides it would be a Good Thing to have a faculty member do the job, for a few years, as long as the university is compensated accordingly. That isn't far-fetched, but it really is a detail in the big picture. Brian C > > Cheers, > S. > > PS: I'm also kind of allergic to the LLC building up it's > headcount - that ought not be a goal. > > > From nobody Tue Jun 23 23:52: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 6526E3A0BCC for ; Tue, 23 Jun 2020 23:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-rAKGOHMcXH for ; Tue, 23 Jun 2020 23:52:03 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id C46B43A0BCA for ; Tue, 23 Jun 2020 23:51:58 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.180.17]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 05O6pcIB012851 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jun 2020 23:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1592981511; x=1593067911; i=@elandsys.com; bh=SzYCB4iLgcsxC6yt7fMJaninEiCDGUpIFR/9Pk07T9c=; h=Date:To:From:Subject:In-Reply-To:References; b=Mi6WDstwEtx8a8INYKHAIWdluTNIsOSVZSUM3wk86NLEwBiCKVSv/puUh2YjMKx1j S3XMPUAsL7MzGYcLCVrdfdftqOKujF2y1VTsaYqq9OV8k/ZhDW9zD5F4Pdtnkxi6a7 q9Lj8fLYp+em4FeeSg6n9aZs+3zHFHq+fkZBqRNo= Message-Id: <6.2.5.6.2.20200623233718.07fe0c38@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 23 Jun 2020 23:50:54 -0700 To: Brian Rosen , rfced-future@iab.org From: S Moonesamy In-Reply-To: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 24 Jun 2020 06:52:06 -0000 Hi Brian, At 08:43 AM 22-06-2020, Brian Rosen wrote: >First of all, I am honored and delighted that the IAB chose me to >co-chair this group. I think this work is critical to the IETF, and >I look forward to working with you all to make it successful. I would like to congratulate you on your appointment. >We have also been discussing what our agenda for IETF 108 should >be. We would like to have a series of questions that focus our >discussions at the meeting. In some cases we could have consensus >on answers, but in most, we just hope to get a sense of where the >workgroup is a the present time. > >Our list of questions is: >1. Should the RSE be a hired employee or a contracted entity? >2. Who hires/contracts the RSE? >3. For the purposes of day to day management, to whom does the RSE report? Question 3 is about "day to day management". In general, an employee/contracted entity is not managed on a day to day basis if he/she is not in a junior position. I suggest removing the first part in that question. Regards, S. Moonesamy From nobody Wed Jun 24 00:54: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 E47823A0C43 for ; Wed, 24 Jun 2020 00:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=UgaASq2B; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aPEjQNh1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCi2yfpCZ4Ia for ; Wed, 24 Jun 2020 00:54:23 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660C43A0C49 for ; Wed, 24 Jun 2020 00:54:23 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id BB4D65C00C1 for ; Wed, 24 Jun 2020 03:54:22 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 24 Jun 2020 03:54:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=E2DTper3HWW1XkLnClaBR1z5JKkCMds Ifb4MvG18eX0=; b=UgaASq2B9iF96aakIT0tR62Ib0tk/uAX1sOT345kG2EDzYl Pim4VM7gmunmo6UuYaiUeUe723xHFJB55yRjga4lj2r51xz13fRguCDZiggUVMkQ cEIyXdDSMP0R1Es0pjXyLH5WMJ40kyvwfpsDhEiAhRp0+xb8Dq3jNiq3UjjVrNtB vGUyC4CgM7pULjPkdK34eqLTGaZXKDuwN8FQaf9c6Xq6msuN5AjQq/bKHH/uDTyX WJq9DDSESMHxAbD2NMXW045s2azmoLzxe2VgcurKZ4eQUlqJ30a4lcWE+W4f7ZpT REUtQZV9VV8MlAzpnqCoP3IDKEOnrESWyCDg0bQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=E2DTpe r3HWW1XkLnClaBR1z5JKkCMdsIfb4MvG18eX0=; b=aPEjQNh18Y8SbE6OzBYHB7 hapG7MZBj5an2st9ixdiKWvGnoQVqyHnDlswe9ZfdbJ10DqweRbyzxre533sz81Y wD74jxgySNZrWRxWEnK7FThev7G6+9pIu/D7RnIprWVjMwRapzHYN1NAKwisa9V2 QkrKG5zctorMo183rEzNixMXznCgY2cSluzTORTvDUSDzFs7tGhgpf4xMxY1CPNW ARKo5rECSaqIO5pe5nTIMy7JS2I7OltQZNbjxPo6aDdE6WwmZLR5mESY40Tcv/O3 m8sTdTDtGXcK5qmTgwrwv/DkRB6ZuAM07/bMGgdPjEyRXysrxMhFZrCxS+Dk/+1A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekiedguddviecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfe ekvefhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnh gvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5710BE0121; Wed, 24 Jun 2020 03:54:22 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-543-gda70334-fm-20200618.004-gda703345 Mime-Version: 1.0 Message-Id: <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> In-Reply-To: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> Date: Wed, 24 Jun 2020 17:54:01 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 24 Jun 2020 07:54:31 -0000 On Tue, Jun 23, 2020, at 01:43, Brian Rosen wrote: > 1. Should the RSE be a hired employee or a contracted entity? I have a third option, inspired in part by Jay's abstraction (paraphrased: "we need a process for setting RFC Series strategy"). This is the same comment I made at one of the recent interim meetings. I also owe part of this insight to the RSOC who had the insight to separate the strategic and operational functions of the RSE role. We don't need a single person (or contracted entity, if that includes more than one person) to be given the task of determining strategy. If we need a strategy to serve our community, then maybe that community should setting and owning that strategy. Not indirectly, via an appointed custodian, but directly. I've watched the discussion here and observed that there is a lot of depth when it comes to questions at the strategic level. I think that we've all be consciously holding back, but when I look at things like draft-carpenter-rfc-principles I can't help but see an attempt to formulate strategy (as opposed to process for strategy). FWIW, I think that's OK, because the shape of a process has an effect on strategy. Setting strategy is different than execution of the same. I've thoughts on that, but they are less well formed. That is a place where expert outside help might be good. There are likely areas in which we develop strategic blind spots as a result of developing strategy in this way. I would contend that this is more readily identified when open participation is permitted than when a single individual is given exclusive responsibility for the task. There are likely other adjustments required to compensate for the effect of the wisdom of crowds as well. I just wanted to float this. I know that it probably opens up a whole bunch of different questions than those that our chairs have provided us. But after I recognized that I was assuming the RSE to be a single entity, I just can't stop seeing how pervasive that assumption is. We don't have to accept that assumption into our design. From nobody Wed Jun 24 08:17: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 49BD63A0F19 for ; Wed, 24 Jun 2020 08:17:44 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 xinOzcRSwcdN for ; Wed, 24 Jun 2020 08:17:42 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE953A0EE6 for ; Wed, 24 Jun 2020 08:17:42 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id y2so2566313ioy.3 for ; Wed, 24 Jun 2020 08:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=9Rj/5Cw1v7UKrNZUgn8C3wY4HCR/oqm+e1zeYuG5ZyA=; b=NSujclYLFqH3f07dGhvSfsKXGQew4fLDPNHvQ5NHk2lQ/q4xdtzA7Ew3kFool9jJVk nMK2R90mRHJ4MxL08tIxKd7V0hy33G7VTsZPjprJY0r0bSQxqHFb1DzdDxrQqGj+aHFx YEedJKxu2eZ/QwGxrfC7pGABAZMYsd8iToW04MSzXUdnrp7G9DsyDTIbVQpj4r8ouvIk QCriqQA3+EVETjlrq60/rWQTVWUycbSIj86qJdFAVi/squmLTOPlKFr0OoBvvRSX6zqI EVFE6XJQHcyw5EFdRG3/Y9IDoBrVkir9C0YGejHRra3gyS1sF+fqrf3qufMIonaAkYK5 /VnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=9Rj/5Cw1v7UKrNZUgn8C3wY4HCR/oqm+e1zeYuG5ZyA=; b=ds7mt93JaQ6YCbC6/nzjA3G6rMgR5IeO3eRapd4IUBj49J1mCsffgs6YAaNlDSQq/E U2btg3Qwea5+YDsz98oPGB6Rp41L9nbbE5I9aBDb3Z563UQzHlGj8FS9kCtcaTAEqRXy zOVYkIUtzvAcDFkZA5YcCUr7b5hqyagR6BlTkRcQJvTsQri/gbIkfOJw9epCbkOVC5K1 ys8FoENRDjrauLZZ4gp8WzLz84HKfnX/SSi92EZVQbz4ZB/jKBD+PQ5uRIf3Zo+dhXcD nIbFnJ8RzRrTUOsgwQdT1dEes3g6dyuGKRk8N20Vu/QmNONRNYs3tCEBa2JnGLXO6020 9LLw== X-Gm-Message-State: AOAM530wOEDtezkNRynuaj4DCVyqMj2F4RG52DLfg0GumvceEzeLfA1R wvbNSW67ILyue49jE18JbbHrm0imXFQ= X-Google-Smtp-Source: ABdhPJy1HfLBaqNUPY5/PgBTYv/+sTAuu25iJ/lYXSW+b6aiD5fZGiUUG59k7libsKjgAEEXncUXeA== X-Received: by 2002:a5e:dc46:: with SMTP id s6mr16807598iop.189.1593011861302; Wed, 24 Jun 2020 08:17:41 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id w18sm11782333ili.19.2020.06.24.08.17.40 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2020 08:17:40 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 24 Jun 2020 11:17:38 -0400 References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> To: rfced-future@iab.org In-Reply-To: <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 24 Jun 2020 15:17:44 -0000 We appreciate all the thoughtful comments we have seen so far. Skipping, for the moment, the scope proposal and concentrating on the = questions: 1. Should the RSE be a hired employee or a contracted entity? Many commenters think this is a detail, but needs to be decided. We can = likely wrap this up quickly, and probably on-list. There are those who = just say =E2=80=9Ccontract=E2=80=9D, some that say =E2=80=9Coh, part = time employee is fine=E2=80=9D and others that say, =E2=80=9Cjust leave = it up to the entity in question 2=E2=80=9D. Please offer your thoughts = on this if you haven=E2=80=99t already. =20 2. Who hires/contracts the RSE? Also seems like we can likely wrap this up quickly on-list. I sense the = current direction is the LLC. Brian offered some options. If you think = it should be some entity other than the LLC, please speak up. 3. For the purposes of day to day management, to whom does the RSE = report? Most commenters seem to think this is not a good question because the = answer is: they don=E2=80=99t need day to day management. Bron thought = everyone needs =E2=80=9Csome=E2=80=9D management even if it=E2=80=99s = =E2=80=9CI=E2=80=99m sick and won=E2=80=99t be working for a few = days=E2=80=9D. Whatever the answer to 2 is, there is some management = there, but probably there is more to be considered. Let=E2=80=99s keep = discussing this a bit. 4. Is there some group that oversees the RSE? This seems to be answered in the affirmative. If you disagree, please = speak up. 5. If the answer to 4 is yes, how is the board constituted? Most commenters liked Michael=E2=80=99s suggestion. If you disagree, = please speak up. 6. Who defines the process that the RSE follows? This group? The = Board? The RSE defines it themselves? Here we have a lot of different opinions, and we probably need to spend = some time at the meeting discussing this. The question of strategy = before process came up which we also need to figure out. 7. Can the RSE decide to not publish a document one of the stream = editors forwards to it? If so, on what grounds? I sense that we=E2=80=99re close on this, but details matter. I sense = that there is support to allow the RSE to hold up a document if the RSE = doesn=E2=80=99t feel that it is readable, but that that control is = fairly limited. =20 There were a couple of other suggested questions: A. What do we want the RSE to do? =20 B. Is the RSE an individual or a group? C. Who recruits/interviews/selects/appoints the RSE? D. What should the appointment length/renewal terms be? Several commenters said things along the lines of =E2=80=9Cpoorly worded = question=E2=80=9D. Other than the above, please suggest actual rewrites = of the question that would be better in your opinion. Brian From nobody Wed Jun 24 13:52:41 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 4CB823A1175 for ; Wed, 24 Jun 2020 13:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ie3XJQtEHXiH for ; Wed, 24 Jun 2020 13:52:38 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 6896D3A116F for ; Wed, 24 Jun 2020 13:52:38 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id t6so2037001pgq.1 for ; Wed, 24 Jun 2020 13:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=aUt2CsQNvYItLmavfG+6VOqaXG/9zusHZihkQp7EN2I=; b=eo0RAmnni75acpwy2aCjLLlpQxNqNOngK9tqLoJRyYwvZsFqDNp7wSehAAJ74dB0pQ sTtrLVZ+OiZ3GR8e7tfpnzdT714gWtbk0SfTCDjm35RLpiiOqZJuRtaQHc3sNq0wET5Z vmgw6lqjuOegXP8h2onubXAiumlLkWzESyuyNuqw9WfeszpFUc5f5y4n6YsqnKbGf0FV 1lD5OauL8jJEVmEqM64blpaJ8T60j9jvOGRsEwcJ4EEi5BX8mxZlDAt5c+UDZHq7lnJc dtMN/kawYlmEfbv03yVaTlN+04N8UY8rXvfyFeYgFWUmGbUINqqL67oDkko7MOq1TmJN B9tw== 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=aUt2CsQNvYItLmavfG+6VOqaXG/9zusHZihkQp7EN2I=; b=l0rWDBgVexUfJE0GABf7mv8GVTmSmzqXK7EYlb23QzEE72ylImRMz7xTE/PHzgCjNT 7jcvszCtnDBxe0C98AHSgwmJzNmFO8fv9EhkCZSEr6yfCd6ezxD5XQqQRwREqMnAsPB2 mWCBdWfHeSvFmv4xTHkrWlt78LwWpaWDmLVz3bp8bZl1X2nKmn7azbsxGxuZsbrWukNa JqjEWXlQfpik6ZZ3aKFGlVeKTTx+mL9fCxo69sKRl5rC+UFa8il+uWuDW6TExWbe7V1R 4JhiqHOaJDP5m2X9QDGqKq8Y3W6tH9vp1vWCN18LiDuuVx/tUq7WT+TgxQMaqewRUfZd TYJQ== X-Gm-Message-State: AOAM5333HFaP3zOmmqEMe+LZeIADTmqAdlh1yEtZsDOHksSbS2RoOew/ YHa7E+NY6BOFLwCHqh7FaNBAkbzL X-Google-Smtp-Source: ABdhPJxW7npI+Rzn9ishBovyY8dAEGjwBue4Q/mY3wfBd3awxZeHvv6YMAy+lANtGRZZFJgliAJ+Ug== X-Received: by 2002:a05:6a00:14d4:: with SMTP id w20mr31939737pfu.279.1593031957479; Wed, 24 Jun 2020 13:52:37 -0700 (PDT) Received: from [192.168.178.20] (235.209.69.111.dynamic.snap.net.nz. [111.69.209.235]) by smtp.gmail.com with ESMTPSA id p19sm20859591pff.116.2020.06.24.13.52.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2020 13:52:36 -0700 (PDT) To: Brian Rosen , rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> From: Brian E Carpenter Message-ID: Date: Thu, 25 Jun 2020 08:52:33 +1200 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: 7bit Archived-At: Subject: [Rfced-future] "oversees" [was Scope and IETF 108 proposals] 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, 24 Jun 2020 20:52:39 -0000 On 25-Jun-20 03:17, Brian Rosen wrote: ... > 4. Is there some group that oversees the RSE? > This seems to be answered in the affirmative. If you disagree, please speak up. I'm allergic to "oversees" and "oversight" since we have running code proof that we are incompetent at it, and our attempts have decayed into micro-management. So I think the consensus position is more like: The RSE is responsible to the community, and there is a community group to which the RSE answers. Brian C From nobody Wed Jun 24 13:59: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 E45683A1183 for ; Wed, 24 Jun 2020 13:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQCSp-OHLvbY for ; Wed, 24 Jun 2020 13:59:34 -0700 (PDT) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82AA3A1180 for ; Wed, 24 Jun 2020 13:59:32 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id b92so1745903pjc.4 for ; Wed, 24 Jun 2020 13:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=g74qLymw62XPehEhE/7ZHLnvjPt2N5tunQfcoeCESE4=; b=lMOpIyE433eaNYKQaY2QkYh9AoLqc8mAs0iSSaZ/ieLInQHjQ6FZ72uFLc2CU+z/0W oxUtBdjK1Cn2d9b6AD48zbCUT+kIUZZMTRnRz0Is+OfQjiRX7rpSJAnxClC6nLdbsQIF 1QJIUYq4eS9W92wAyX3jCp90QWAJMXhK5vGrWGxqtdxvCRzT6QyyDa5/gIyEfzSmK6NT nCjG2oNF71tBQjNye7j23XUq7+44c41V25GcTD2FpmMDGIsoJ00TXPIwPmjg3hbJv1hK CCbX+QCuiMGGPziuU3Do8FVEGBlDXnwWdv86XFPnsAAyXpHCqK+sfB/E3zhXeHWBMQ1k LtCw== 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=g74qLymw62XPehEhE/7ZHLnvjPt2N5tunQfcoeCESE4=; b=h+PLCefGg9SCM+BeF6g6OCBL6kVjoI2jVsUNTpaD4cwshTHN23oevcmrF0uUs9w+Fs cF+Ze13tZGxpyH7obeffvd2hMHWOpSymDtkAIEOlWV//6DOQukY9dXT4vNehDPgvK3pb gVbD92QfrRcYZU9BYfAmEPpoI+0rYhjanRWagjiH3XBWrQOb3GlpcG9H2OwVo4ry9Nbs ZjrRMJxJp71iTGuGNpVOHqGAUChfQF1QLt9VVd/0MX6gFLai4WK+ClxcysTqAaJaKxGE SbzHH7pBR/H3xDnuiDbAvNwiX+I/uaxUopMQsyTnwCFDVwEpqMtfkXS+h/4ga3WTemsR LkBw== X-Gm-Message-State: AOAM531LKU2oD/gM8HB8UjqKl6bmAgTkT38orgdU7crOumI/9rqRTQva 3FVG18K/Zhrtse2fbjdNUYubX7xo X-Google-Smtp-Source: ABdhPJziejv7fY3qRj/UJ2VGCK/xqhaLflS+vomop1in810UsWjvOczCA9JUG5WJpWkDEWQc4nMt5w== X-Received: by 2002:a17:90a:4a6:: with SMTP id g35mr30263357pjg.155.1593032371932; Wed, 24 Jun 2020 13:59:31 -0700 (PDT) Received: from [192.168.178.20] (235.209.69.111.dynamic.snap.net.nz. [111.69.209.235]) by smtp.gmail.com with ESMTPSA id f207sm5711057pfa.107.2020.06.24.13.59.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2020 13:59:31 -0700 (PDT) To: Brian Rosen , rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> From: Brian E Carpenter Message-ID: Date: Thu, 25 Jun 2020 08:59:28 +1200 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: [Rfced-future] hiring [Scope and IETF 108 proposals] 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, 24 Jun 2020 20:59:36 -0000 On 25-Jun-20 03:17, Brian Rosen wrote: > 1. Should the RSE be a hired employee or a contracted entity? > Many commenters think this is a detail, but needs to be decided. =20 I think it should *not* be decided in advance. I think it should be decid= ed according to the individual circumstances of a particular nominee for = the job. So yes, see next question... > We can likely wrap this up quickly, and probably on-list. There are th= ose who just say =E2=80=9Ccontract=E2=80=9D, some that say =E2=80=9Coh, p= art time employee is fine=E2=80=9D and others that say, =E2=80=9Cjust lea= ve it up to the entity in question 2=E2=80=9D. Please offer your thought= s on this if you haven=E2=80=99t already. =20 >=20 > 2. Who hires/contracts the RSE? > Also seems like we can likely wrap this up quickly on-list. I sense th= e current direction is the LLC. Brian offered some options. If you thin= k it should be some entity other than the LLC, please speak up. By default, it would be the LLC, certainly. A much wider question would b= e whether a new entity should be considered, let's call it the RFC Founda= tion for the sake of argument, but I think that is clearly out of scope f= or this group. Brian C From nobody Wed Jun 24 14:10: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 A974B3A1191 for ; Wed, 24 Jun 2020 14:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdQcvhikAc8O for ; Wed, 24 Jun 2020 14:10:04 -0700 (PDT) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 636FE3A1190 for ; Wed, 24 Jun 2020 14:10:04 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id m2so1770319pjv.2 for ; Wed, 24 Jun 2020 14:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=o8u1NpIUig1Tgil0i/afQHRb5Y8L2is4kouU0lDnYus=; b=QtKLPm7PYawVNN39E+2iw8hL8ZevVuON1d+5V/DolggMQWgH5OHu5yNfzCxLGga3Ps Ho4oXzURURMNv+jKpSlVW/jH0Iiz6UMsZo7w5EvfuLSzLBdDI5Toa+W/xIKtY4qLnQFn YwZsEqywaE9ijuRQfqH3LP+DYr+URXSbVDrGvhYLAnf7Ibi5Py5i54UmY67YOAW8DpDX AAOG/j6mjLnbKA9jP15Sc6AXzKBkyOtE2XrEQDvIydJh+HvuV0Ncd+GNkGkUKaliK2iG zGBVEDT2RX/ixrAsgVWVtqk2F8OH2bqTXDBNJIWHMS86NlHh9LYs3CF/2KisTdyNDBeH Jqlw== 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:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=o8u1NpIUig1Tgil0i/afQHRb5Y8L2is4kouU0lDnYus=; b=RiaQF+WU8WjUFtAIbZEHbGDg4kMKM5YLwHbnLjDcathtmtMGJTAwSfk/08VhaGb+ET NEqVP2TWUKuL7k8LOxgcRuPfRbQgYNJrmHyhi3Y0R6f9PzhPd6Elosfp7vIiwelxKR6K ficiCUT/UL5J4NvskCJ2ay8cmH1vSdUg8yiQao5W/5p9Lx/tb6WLglJWVyhjlft/Gw4A teJ8M0hfEOy9inZrHpvzCpj8lCZtYcwvWf8C7no9lMw1EIsdq+40ngFJ7+PvyGG7AEPW 8w0JqhxOo6eFmfA94yINeKEx3rAxe2FXuElmMLx/bY9mb1h9v+UXV7lGCB8Ha73kx6gJ HO5g== X-Gm-Message-State: AOAM530r2lepBXHn9GJ3Y8TycpnxxGcbTFoGMUbToZOpCALteTU9shRX tXNkmM2rmdb5mgINYe+KTLJsD3N4 X-Google-Smtp-Source: ABdhPJy7foCqKOuhAOP+ofINnd1BIxYqxvjc7bIxUxGwCr1jtMrakXKS1EkrXQbt0NY9jyldrxb64g== X-Received: by 2002:a17:90a:cc18:: with SMTP id b24mr30574774pju.118.1593033003534; Wed, 24 Jun 2020 14:10:03 -0700 (PDT) Received: from [192.168.178.20] (235.209.69.111.dynamic.snap.net.nz. [111.69.209.235]) by smtp.gmail.com with ESMTPSA id z19sm5222825pjn.55.2020.06.24.14.10.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2020 14:10:02 -0700 (PDT) To: Martin Thomson References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> From: Brian E Carpenter Cc: rfced-future@iab.org Message-ID: <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> Date: Thu, 25 Jun 2020 09:09:59 +1200 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: <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 24 Jun 2020 21:10:06 -0000 On 24-Jun-20 19:54, Martin Thomson wrote: > On Tue, Jun 23, 2020, at 01:43, Brian Rosen wrote: >> 1. Should the RSE be a hired employee or a contracted entity? > > I have a third option, inspired in part by Jay's abstraction (paraphrased: "we need a process for setting RFC Series strategy"). This is the same comment I made at one of the recent interim meetings. I also owe part of this insight to the RSOC who had the insight to separate the strategic and operational functions of the RSE role. > > We don't need a single person (or contracted entity, if that includes more than one person) to be given the task of determining strategy. If we need a strategy to serve our community, then maybe that community should setting and owning that strategy. Not indirectly, via an appointed custodian, but directly. I don't understand how that would work in the absence of a group and a group leader to determine what the community is (since it's not the IETF) and what the community's rough consensus is. Who would they be? In my book, the RSE and the RFC Series Board. But yes, there are two roles here, if not three: 1. The policy/strategy lead, including determining community consensus. 2. The technical lead, at least until the v3 transition is truly complete. 3?. Operations lead, in so far as that isn't the LLC's job. > I've watched the discussion here and observed that there is a lot of depth when it comes to questions at the strategic level. I think that we've all be consciously holding back, but when I look at things like draft-carpenter-rfc-principles I can't help but see an attempt to formulate strategy (as opposed to process for strategy). FWIW, I think that's OK, because the shape of a process has an effect on strategy. Sure, but that draft is just me waffling as background for defining the RSE role. > Setting strategy is different than execution of the same. Absolutely. We should certainly discuss whether we expect one person to handle all these roles. Brian C > I've thoughts on that, but they are less well formed. That is a place where expert outside help might be good. > > There are likely areas in which we develop strategic blind spots as a result of developing strategy in this way. I would contend that this is more readily identified when open participation is permitted than when a single individual is given exclusive responsibility for the task. There are likely other adjustments required to compensate for the effect of the wisdom of crowds as well. > > I just wanted to float this. I know that it probably opens up a whole bunch of different questions than those that our chairs have provided us. But after I recognized that I was assuming the RSE to be a single entity, I just can't stop seeing how pervasive that assumption is. We don't have to accept that assumption into our design. > From nobody Wed Jun 24 14:21: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 79EAC3A119B for ; Wed, 24 Jun 2020 14:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mL4_Iw_3TuW for ; Wed, 24 Jun 2020 14:21:29 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 17EB83A119A for ; Wed, 24 Jun 2020 14:21:28 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id v13so3345548otp.4 for ; Wed, 24 Jun 2020 14:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=AaP+KClfEWTq1pdHLmWb9qvTlg8wW9W8P1i8VWYOCBY=; b=NasIq599YtUPk55zBW8D1kj0Dduos0RKb/06GTHHRtqJUKQU30q1ZZJQg42FRc0M7e gurc0Nu5CKuJlAEEf+53bmWrG0qPcfI+VRS2O6LOeEqRd3iXrpf6cRnd4CrqrGxHVReL z6uSV8TSmDMJ8Rgzzk127FM8vN12zjhCyVras= 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:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AaP+KClfEWTq1pdHLmWb9qvTlg8wW9W8P1i8VWYOCBY=; b=uihcycSqez8oEorrMiNdLQkgw2AsxwBmWUD+cT22TqUCpK4PtoosaMvGOboxcTCwas boIAdCbSDr/t5BZwUCABENloWOISUoHrZ3sb95CXOHAf3Nk27wzJ+bcoQ3fReuxZ73QR Ewt2PZAwkjoHGIVEy0xeJM6O8snrwkwFsKvyOkOGTgw5pZ/fvqhunfROs29M5meZq7xa pXQtBW2mOUx+IML7tAncjzONEkHbWCbBoxBXCgQaovomicaPTNn45t5TimMeMTl/In+o zUHsGyV2eXgZ1s42utwSb4SIcXCLAPPgIxtEFV0qEtIO27F+da7mt+AKqVPBcs9WDRiE X1kA== X-Gm-Message-State: AOAM5309TOki2lPEiqMsFJIyIKiLyFiD4nIae5ECbq59tHTBsw1lP/Hz EClwemJDh/27lYEG/gkj7v0kig== X-Google-Smtp-Source: ABdhPJxqISzL1cMwfeMZoR9wvt/CJRtY3nqW9ldiMnbMDOQtsB4t7iUvXQAUzdWs0w2Ll2mvKSHw8A== X-Received: by 2002:a4a:2f15:: with SMTP id p21mr13876786oop.20.1593033687790; Wed, 24 Jun 2020 14:21:27 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id d25sm1136905ote.59.2020.06.24.14.21.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jun 2020 14:21:27 -0700 (PDT) To: Brian E Carpenter , Brian Rosen , rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> From: Peter Saint-Andre Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= mQINBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABtCdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT6JAlQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekLkCDQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAYkCPAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: Date: Wed, 24 Jun 2020 15:21:26 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] "oversees" [was Scope and IETF 108 proposals] 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, 24 Jun 2020 21:21:31 -0000 [ no hats ] On 6/24/20 2:52 PM, Brian E Carpenter wrote: > On 25-Jun-20 03:17, Brian Rosen wrote: > .... >> 4. Is there some group that oversees the RSE? >> This seems to be answered in the affirmative. If you disagree, please speak up. > > I'm allergic to "oversees" and "oversight" since we have running code proof that we are incompetent at it, and our attempts have decayed into micro-management. I've seen this claim several times; can you provide evidence for it? Peter From nobody Wed Jun 24 15: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 AF5D93A11B3 for ; Wed, 24 Jun 2020 15:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 m0chrofvMYpA for ; Wed, 24 Jun 2020 15:21:16 -0700 (PDT) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03E93A11B1 for ; Wed, 24 Jun 2020 15:21:16 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id m2so1903319pjv.2 for ; Wed, 24 Jun 2020 15:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:subject:date:message-id:mime-version :content-transfer-encoding:content-language:thread-index; bh=qjt2w/rvYBp+TXQtlq1xHpjRLmcpqwWgx0Oj3a67Ink=; b=FRn2ciTaMlgHZNpQS9JYORYhXok+3++cDLEqIwEsjz3PZI907TcX4f7HJTmfh54Cgc sjGj72t9h7kSyokfSnhon2gDl97BEzXMhjcnunKUFFqdNaJ4V+sbepUYEC81cRL1dt8w m4rpi9FBwKEfKOlLv5eOpqb520iPdqs+d5/CvQX0U2lPxeiaPbAVqKryuwEAsWEjbSsL uye+a+GRHkLeW2CkMEIWx79R1if9Ww47exsQv4B3qT7cmluFyCOBRWmBcC2HzUqyxo2I TEHXIC/ei+G6pvcGv7tNThti2fLleOsBIV7r9WIVCEgr3bRAXR4lPZokae0NoG4fHj5P FSvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=qjt2w/rvYBp+TXQtlq1xHpjRLmcpqwWgx0Oj3a67Ink=; b=lGoxJnS9mUSKAVqtZixDgFNpCafNTCCZWLrQY6dhM85JkeXp/lwKmO0TKzk9BcESju 7xE7aNJdqRvgENyor/y2tloeyPeQ/mi68FhEvPa9aEYa4WkidagOqtxk1d2hW6cYxVD2 otnndi85M0N8u0kCYqALy32p2iyl6Qm3z0jfTUe6sQz5p88wyqCMQPvobPd2qRuKxJxU VYeQNFAyFdW36c04OsMyRK84VUdUtGyv0cu4DmUCzP+bsPUGNCSUFzYfLDdm/ys0AKPe pCOJllWLUq2HK9+i23JFIb1xxvnfppems45g+KPh8s9EX3WyMEwFkpm8UWQBojN84oM3 THxQ== X-Gm-Message-State: AOAM530Hu8d2vDYQQXMxbJRO777YRTJHkVA7MtvPWTjIln35r1M4NWK8 fJ+URgX32DM5D/CvBVo8cjY= X-Google-Smtp-Source: ABdhPJyEDzIKL2L9hwmQM2d0P4mdqgpJRvOyaWxGWS8zJ8KtrJIe7JuP5LLNzFKR3TR+vpAIM0dUNQ== X-Received: by 2002:a17:90a:f996:: with SMTP id cq22mr4603316pjb.208.1593037276235; Wed, 24 Jun 2020 15:21:16 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id b3sm20351492pft.127.2020.06.24.15.21.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2020 15:21:15 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Peter Saint-Andre'" , "'Brian E Carpenter'" , "'Brian Rosen'" , Date: Wed, 24 Jun 2020 15:21:14 -0700 Message-ID: <001401d64a75$c6708420$53518c60$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdZKdcW831KhkO6qTqiRYq08jbh6CA== Archived-At: Subject: [Rfced-future] Scope 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, 24 Jun 2020 22:21:18 -0000 Can we talk about the role of RSE of completing the move from txt to xml. Including the transition from v2 to v3 and managing the gathering of and responding to feedback from RFC users, once we have a stable situation? Is that an RSE function, and can it be done with the resources estimated If so? Is this in scope? From nobody Wed Jun 24 15:37: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 3BF803A11BC for ; Wed, 24 Jun 2020 15:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, 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 qILwwQQt8BXS for ; Wed, 24 Jun 2020 15:37:01 -0700 (PDT) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912B73A11BB for ; Wed, 24 Jun 2020 15:37:00 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 05OMavmd007017; Wed, 24 Jun 2020 23:36:57 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DC7522203B; Wed, 24 Jun 2020 23:36:56 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id C79832203A; Wed, 24 Jun 2020 23:36:56 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.26.18]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 05OMatVI003080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 Jun 2020 23:36:56 +0100 Reply-To: From: "Adrian Farrel" To: "'Brian Rosen'" Cc: Date: Wed, 24 Jun 2020 23:36:54 +0100 Organization: Old Dog Consulting Message-ID: <05ed01d64a77$f6cf6940$e46e3bc0$@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: AdZKd9cOWT9MtpyESOiPe9njIv9XdQ== Content-Language: en-gb X-Originating-IP: 84.93.26.18 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-25502.003 X-TM-AS-Result: No--6.271-10.0-31-10 X-imss-scan-details: No--6.271-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25502.003 X-TMASE-Result: 10--6.270900-10.000000 X-TMASE-MatchedRID: RSMWFfuXjag+D3J+ThgLRp00SCdpx1uvi+TAnPnbttjLkl8e9W70i+mW pqKXmZL5r8LPT7YEIHZyDJ5eR7262mJQK9wIJ221zniFfjFXqM7dOKPIz0+bToB4XybRlTmEE+E VwCB2XWkN3YZLVs0RTb+LR20OeUVYyQWMBUbcSBkK4MBRf7I7pgKflB9+9kWV9fB+4MvepQyjxY yRBa/qJeHvPwwcLlxnDV8DVAd6AO/dB/CxWTRRu25FeHtsUoHuLOIKCuE/YBKgLDB5/akv99VI9 0AjPMVRVH+a9dtwvkxLDBwYotNgRw== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Rfced-future] Hires/contracts/selects/nominates/appoints 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, 24 Jun 2020 22:37:03 -0000 Hi Brian, > 2. Who hires/contracts the RSE? > Also seems like we can likely wrap this up quickly on-list. I sense = the current > direction is the LLC. Brian offered some options. If you think it = should be > some entity other than the LLC, please speak up. I tried before but maybe got lost in the noise. I think the question as phrased has ambiguities. Hires !=3D Contracts I have no issue with the LLC holding the contract and even doing any = necessary contract negotiation. But: - who writes the job spec and sets out the fundamentals of the contract? - who reviews the applications? - who short-lists? - who interviews? - who comes up with a preferred candidate? - who ratifies that candidate? All of that MIGHT [RFC6919] be covered by the term "Hires" in which case = (and meaning no offence to the LLC) I don't think the LLC has the = necessary experience to perform the task. Cheers, Adrian From nobody Wed Jun 24 15:49: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 23C773A11C4 for ; Wed, 24 Jun 2020 15:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 Hqwr_E6ojU7u for ; Wed, 24 Jun 2020 15:49:13 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79CB53A11C1 for ; Wed, 24 Jun 2020 15:49:13 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id c75so3602860ila.8 for ; Wed, 24 Jun 2020 15:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=osQDzadnauA0Zfu2RZYMT746b+AvjjiJwGKZgskY7/g=; b=kqWJaspWRheC/NiizXTSoFTZ/dRfXRgdfEFP0/vc+HuXJEg/JAQVMfj8Rvx95gQE48 Ao9TO8BI4BqLviqI8+ZKoLwMHCrUpsX8pVc1QLSJOjKR49fjvrPFb7E1e/tfduSiKuIa +RQdOl+v4TMeAGD8mU6FRi8ZRDPuUk8t0YknZ6L37Is4vNt7CUGoz5SKLBoFVWjfvnZV mi/v22ld/zVGIL8nXa0dKodBsJWAMsUgKkPhK1QP4XrG1DT19XtkHKCRROeuXzIAx4If vRWyL6KUKCd8s71WQstRD0lDuACJrxAwO/w1AoKrCZ5q9g+1Ci7fgT39LtSbEZ6udnoX P35w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=osQDzadnauA0Zfu2RZYMT746b+AvjjiJwGKZgskY7/g=; b=tIZFn0uBsVwwtdNKzfvzgqONtvG9uGFIzMV+KOPUxl6fznM/+QD65BxT8OD+iRYSz8 P7ETymIJJJdo4mP2u0vUtmu68XoUp5kuWouLyrpfrJm63+DR0aJ6NUIcZYStIrRK6lEy hLV0gVhacj3hAdrhCCGio2GyCXVvc8HRcDolYKN2aI95e3xWEFmfhomMkNlMI6TyzQcq UWYYg0sp1eRx6/z513smEg6UodKlXTMK4TzkA8vHwT12qgVv1vBxKk8/KYtq7nzNDlhY KhMzDYGM4X3zRd9uOluVJAZmRPfqJT5rfXBy0GbVCMBTM7ZSKh+GavVrvKQbJqKPREbo LO3Q== X-Gm-Message-State: AOAM530UgGX4i7DMATkofhGTw0PDwzqU7d6dCgU6/+343xjO0TQ1xxsI JESbVWG2/dn651mQLQL70X2FMQYvO/8= X-Google-Smtp-Source: ABdhPJxk6MyO6CXRPORYyteSWeHiAkCk2mIuHxBy0HwI/JIMEbyJIwJporgONztVjMapqfMKpsiiiQ== X-Received: by 2002:a92:508:: with SMTP id q8mr29329940ile.298.1593038952620; Wed, 24 Jun 2020 15:49:12 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id c5sm12410259ioq.9.2020.06.24.15.49.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2020 15:49:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Brian Rosen In-Reply-To: <05ed01d64a77$f6cf6940$e46e3bc0$@olddog.co.uk> Date: Wed, 24 Jun 2020 18:49:10 -0400 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <7042366D-5CA7-44DB-919B-6BB054356E6F@brianrosen.net> References: <05ed01d64a77$f6cf6940$e46e3bc0$@olddog.co.uk> To: Adrian Farrel X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Hires/contracts/selects/nominates/appoints 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, 24 Jun 2020 22:49:15 -0000 In the additional questions: C. Who recruits/interviews/selects/appoints the RSE? > On Jun 24, 2020, at 6:36 PM, Adrian Farrel = wrote: >=20 > Hi Brian, >=20 >> 2. Who hires/contracts the RSE? >> Also seems like we can likely wrap this up quickly on-list. I sense = the current >> direction is the LLC. Brian offered some options. If you think it = should be >> some entity other than the LLC, please speak up. >=20 > I tried before but maybe got lost in the noise. >=20 > I think the question as phrased has ambiguities. >=20 > Hires !=3D Contracts >=20 > I have no issue with the LLC holding the contract and even doing any = necessary contract negotiation. >=20 > But: > - who writes the job spec and sets out the fundamentals of the = contract? > - who reviews the applications? > - who short-lists? > - who interviews? > - who comes up with a preferred candidate? > - who ratifies that candidate? >=20 > All of that MIGHT [RFC6919] be covered by the term "Hires" in which = case (and meaning no offence to the LLC) I don't think the LLC has the = necessary experience to perform the task. >=20 > Cheers, > Adrian >=20 From nobody Wed Jun 24 15:56: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 1D6B13A11C8 for ; Wed, 24 Jun 2020 15:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P87q8xs4Aa6n; Wed, 24 Jun 2020 15:56:10 -0700 (PDT) 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 0217C3A11C5; Wed, 24 Jun 2020 15:56:09 -0700 (PDT) From: Jay Daley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A6C3EB5B-86A1-425C-94D4-71B09C60B58A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 25 Jun 2020 10:56:07 +1200 In-Reply-To: <7042366D-5CA7-44DB-919B-6BB054356E6F@brianrosen.net> Cc: Adrian Farrel , rfced-future@iab.org To: Brian Rosen References: <05ed01d64a77$f6cf6940$e46e3bc0$@olddog.co.uk> <7042366D-5CA7-44DB-919B-6BB054356E6F@brianrosen.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Hires/contracts/selects/nominates/appoints 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, 24 Jun 2020 22:56:12 -0000 --Apple-Mail=_A6C3EB5B-86A1-425C-94D4-71B09C60B58A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 25/06/2020, at 10:49 AM, Brian Rosen wrote: >=20 > In the additional questions: > C. Who recruits/interviews/selects/appoints the RSE? This is currently specified in RFC 8728 section 3.1 Just a reminder that there is no documented statement that explains why = that existing process needs to be replaced. Jay >=20 >> On Jun 24, 2020, at 6:36 PM, Adrian Farrel = wrote: >>=20 >> Hi Brian, >>=20 >>> 2. Who hires/contracts the RSE? >>> Also seems like we can likely wrap this up quickly on-list. I sense = the current >>> direction is the LLC. Brian offered some options. If you think it = should be >>> some entity other than the LLC, please speak up. >>=20 >> I tried before but maybe got lost in the noise. >>=20 >> I think the question as phrased has ambiguities. >>=20 >> Hires !=3D Contracts >>=20 >> I have no issue with the LLC holding the contract and even doing any = necessary contract negotiation. >>=20 >> But: >> - who writes the job spec and sets out the fundamentals of the = contract? >> - who reviews the applications? >> - who short-lists? >> - who interviews? >> - who comes up with a preferred candidate? >> - who ratifies that candidate? >>=20 >> All of that MIGHT [RFC6919] be covered by the term "Hires" in which = case (and meaning no offence to the LLC) I don't think the LLC has the = necessary experience to perform the task. >>=20 >> Cheers, >> Adrian >>=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future >=20 --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_A6C3EB5B-86A1-425C-94D4-71B09C60B58A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 25/06/2020, at 10:49 AM, Brian Rosen <br@brianrosen.net> = wrote:

In the additional questions:
C. Who = recruits/interviews/selects/appoints the RSE?

This = is currently specified in RFC 8728 section 3.1

Just a reminder that there is no documented = statement that explains why that existing process needs to be = replaced.

Jay


On Jun = 24, 2020, at 6:36 PM, Adrian Farrel <adrian@olddog.co.uk>= wrote:

Hi Brian,

2. Who hires/contracts = the RSE?
Also seems like we can likely wrap this up = quickly on-list.  I sense the current
direction is = the LLC.  Brian offered some options.  If you think it should = be
some entity other than the LLC, please speak up.

I tried before but maybe got lost = in the noise.

I think the question as = phrased has ambiguities.

Hires !=3D = Contracts

I have no issue with the LLC = holding the contract and even doing any necessary contract = negotiation.

But:
- who = writes the job spec and sets out the fundamentals of the contract?
- who reviews the applications?
- who = short-lists?
- who interviews?
- who comes = up with a preferred candidate?
- who ratifies that = candidate?

All of that MIGHT [RFC6919] be = covered by the term "Hires" in which case (and meaning no offence to the = LLC) I don't think the LLC has the necessary experience to perform the = task.

Cheers,
Adrian


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


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

= --Apple-Mail=_A6C3EB5B-86A1-425C-94D4-71B09C60B58A-- From nobody Wed Jun 24 16:15:06 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 651343A1221 for ; Wed, 24 Jun 2020 16:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYtg_ambxufI for ; Wed, 24 Jun 2020 16:14:57 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568073A1209 for ; Wed, 24 Jun 2020 16:14:53 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id b5so1997722pfp.9 for ; Wed, 24 Jun 2020 16:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=XdazGneCud80nwuOM683zXhtZoOSBa8j6+3/DT7sO5I=; b=ZzMnPRzwm/e7okqVjkjZFJRBLod20GxWKAh8RlaN2yHqaY8B8rRyvy+cULwqsdQ3LC LnxTLPXljCyLED4nZskrUQV9LHNGD2Q7z9Q2rMg3rePd33e3NnytmUmd21pybU8SUyzf WILeNgKqliaGy5x776qURxqWdSO2nddPFkuHG7N8Kw7qUQ07puRok+4VpOcqOARp+Q3G fqsbh0lwe3DinHB0ncujKYUrrmAsQlj+eAfyzsZY9YvVDI6T53eLmNr54RHTKosZV60V S0Kvmtra1nlKdUt2RPxVqi3/H1SoIjtc8FfLTnAy4nrg4l62ryFhiKo+SprN2W5mNE4s H31Q== 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=XdazGneCud80nwuOM683zXhtZoOSBa8j6+3/DT7sO5I=; b=p4cfCdcoZ5fmh0R5VE/KQ5khNf0ZEK3nYvpq3koTlFz5o2SA27KIfD9QgtzAaBuK2U d41jXlUWxLjqn0howNJamMars2wAoxDE2YXyGoghz9HQ9NehyXXWjc+PkAuY66VMz0A9 WyvRjjLy0bEgQZ7i+d8ruqwbSkWy5lHwXeXN9LNvpIMw8hc6SMiu8QOlxMDTSWqrPC8i viw6rbmqJZKxcCXQVGQYpTZ05VR17fFxKx8RREJwJPVUUq/9+txPr6lGiXtrc6Msfu8n sj93h1eg1RbRKf5ORKk6wAkNDgUhC/HGmxPGY3l5wzyttAzoc7iH634W9AXUOJ7mEHYY 2uuQ== X-Gm-Message-State: AOAM533ki8BCyjqiyWqMlhPcxBfHIwouNSGshxEGAi3QLB14c0qgK8m4 g6l1NT+jEDjozdjt36JoXi0tSq2f X-Google-Smtp-Source: ABdhPJzuwCwc6xIYDadXsr9C+dXhepQonpV5GEO7lHPrzID8mXM+dzqgOEeVx2lvR+fBb/SGTTy4lw== X-Received: by 2002:a65:4bc8:: with SMTP id p8mr23691653pgr.418.1593040492545; Wed, 24 Jun 2020 16:14:52 -0700 (PDT) Received: from [192.168.178.20] (235.209.69.111.dynamic.snap.net.nz. [111.69.209.235]) by smtp.gmail.com with ESMTPSA id y69sm22026953pfg.207.2020.06.24.16.14.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2020 16:14:51 -0700 (PDT) To: Peter Saint-Andre , Brian Rosen , rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> From: Brian E Carpenter Message-ID: Date: Thu, 25 Jun 2020 11:14:48 +1200 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: 7bit Archived-At: Subject: Re: [Rfced-future] "oversees" [was Scope and IETF 108 proposals] 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, 24 Jun 2020 23:15:05 -0000 On 25-Jun-20 09:21, Peter Saint-Andre wrote: > [ no hats ] > > On 6/24/20 2:52 PM, Brian E Carpenter wrote: >> On 25-Jun-20 03:17, Brian Rosen wrote: >> .... >>> 4. Is there some group that oversees the RSE? >>> This seems to be answered in the affirmative. If you disagree, please speak up. >> >> I'm allergic to "oversees" and "oversight" since we have running code proof that we are incompetent at it, and our attempts have decayed into micro-management. > > I've seen this claim several times; can you provide evidence for it? Just the entire history of IASA version 1 and the IAOC doing the work itself instead of overseeing the execution of the work. So far, the LLC Board is doing much better, because it's constituted as a Board. Also of course the recent history of the RSOC that led to Heather's resignation. Engineers are bad at overseeing non-engineering activities; we meddle in things we are no good at. (I don't except myself from that statement, since I was IETF Chair at the time that IASA was set up, and I know that I got far too interested in stuff that shouldn't have been my business.) Regards Brian From nobody Wed Jun 24 16:43: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 185843A11F4 for ; Wed, 24 Jun 2020 16:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=ScjKOtMv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GP7zQ6PR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7K7bwsLJU2Y for ; Wed, 24 Jun 2020 16:43:24 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6DB63A11F9 for ; Wed, 24 Jun 2020 16:43:24 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 0C47B9DA for ; Wed, 24 Jun 2020 19:43:23 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 24 Jun 2020 19:43:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=OZL5PH6HAEbodELjsBckw0fkIq7zk+Q JfSJewR48R7Q=; b=ScjKOtMvCQJNv9JV8xZ2K3ExEtUyqnq0CsIIBj2fattt9oB bD45xpGqRPZKrrn606N6TVaIxzpL0kTVgCjTisuVa32djM/mxctpMvIA/cVF3KNy WZ334Ot3k2q3fOXjB4eW6qhdkySh+inoSz8tDY+4CxF6ryStS1uwcI2mGYFftygK QzdjzrxDRN3l9ctjn3VXxTyhTbNV38t8ZqW8ctWZgzwL6zl1mQtmlcMYXBpHMhH7 S+bGKjDJDg3gbLLSwRQh2zfKHqF6jBJ6zo/oCrz25twt1SBxdbOg5ms5ekAQX9JM kyXqPbxOP44A4TYecmK2DfY9Rh8gWRaKAqsrQXQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=OZL5PH 6HAEbodELjsBckw0fkIq7zk+QJfSJewR48R7Q=; b=GP7zQ6PRJx91Tr6z7mRt2q wO0whmYdQNFF/6r9aKaLqnDSVJQO9xzPT0MSs2rZG1cRFNy1p2EBdLrb5Z7Vrx3p VZQYsP6tNvvSLgsWcbBSBMkuVYWWSLdrnOWdq16CB8QcizIFF3tzD3Rk47uwmLh7 XACXLxCQO0s1uQ/SEAo8WAruojVoc4glJxst3FJIwb80zv/uqucVPNTJYReSgydi zrxTCnG2KgfBxujJX7XsAhREXyDeb2v8GQr4G5TCdo+yzFLCT/NSYQHkCe6UjJQ7 N0TxU/qKozcFRlItIiVhypEe9dyDLdXX2Z1KgJUv73FJxi44vqazbEnObrlPhJfw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekkedgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 694EFE00A8; Wed, 24 Jun 2020 19:43:23 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-543-gda70334-fm-20200618.004-gda703345 Mime-Version: 1.0 Message-Id: <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> In-Reply-To: <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> Date: Thu, 25 Jun 2020 09:43:04 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 24 Jun 2020 23:43:34 -0000 On Thu, Jun 25, 2020, at 07:09, Brian E Carpenter wrote: > On 24-Jun-20 19:54, Martin Thomson wrote: > > We don't need a single person (or contracted entity, if that includes more than one person) to be given the task of determining strategy. If we need a strategy to serve our community, then maybe that community should setting and owning that strategy. Not indirectly, via an appointed custodian, but directly. > > I don't understand how that would work in the absence of a group and a > group leader to determine what the community is (since it's not the > IETF) and what the community's rough consensus is. Who would they be? > In my book, the RSE and the RFC Series Board. I don't think that is necessarily the case. The process that we're following has the same requirements and challenges. It has leadership. Two leaders in fact, which is more than twice as good as relying on a single person. It has open participation. (I don't know what RFC Series Board is, but it implies a closed group, just as RSE implies an individual.) Speaking strictly about strategy, the structure of what we have here is just about as good as we will get in all the ways that matter. From nobody Wed Jun 24 18:54: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 446A53A1229 for ; Wed, 24 Jun 2020 18:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.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 wQEJGFBrq1YM for ; Wed, 24 Jun 2020 18:53:57 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 53C3F3A1228 for ; Wed, 24 Jun 2020 18:53:57 -0700 (PDT) Received: (qmail 90871 invoked from network); 25 Jun 2020 01:53:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=162f4.5ef403b2.k2006; bh=mXI3I11/VT167lHRTLzJNqzbt2Ih1ay/ff7MoW5ZOJE=; b=fIsj/iHtm81l/f3/tC+lFQSdgiWW9JtEMz1Br0F8aL33WZfjKK5tAkqmLouWxN83wfeT319WgAp6DHjnQkcyFSpe9TYcwzoggK0JIBEGAEOasjvLhRKa9elp54i0lSLYBhdgJxOphcHb/CKr7Yc4N4SXAxDd+K4kMvQrlw8zuF31LGq9E1KjJ1lvHPFA2pYGaKEtyzAf4gyq7/eyG9fSRUD9LIKjCPIu0w5HtemwL6VhgmXa6THpWYjnuhLbp+ZF Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 25 Jun 2020 01:53:54 -0000 Received: by ary.qy (Postfix, from userid 501) id F0E991BAABD9; Wed, 24 Jun 2020 21:53:53 -0400 (EDT) Date: 24 Jun 2020 21:53:53 -0400 Message-Id: <20200625015353.F0E991BAABD9@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: LMM@acm.org In-Reply-To: <001401d64a75$c6708420$53518c60$@acm.org> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Scope 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, 25 Jun 2020 01:53:59 -0000 In article <001401d64a75$c6708420$53518c60$@acm.org> you write: >Can we talk about the role of RSE of completing the move from txt to xml. >Including the transition from v2 to v3 and managing the gathering of >and responding to feedback from RFC users, once we have a stable situation? I really hope that will be done before there's another RSE. We've produced 136 XML RFCs. The process is working pretty smoothly now. There are certainly loose ends to be cleaned up, like finalizing and documenting the changes to the V3 XML grammar since RFC 7991. I send a poll every month to RFC authors and shepherds. I suppose I could put the results somewhere but they're not very surprising. Most people are happy, a few have minor process suggestions. From nobody Wed Jun 24 19:20:46 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 4CC013A1234 for ; Wed, 24 Jun 2020 19:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5zUZnsFS0pi for ; Wed, 24 Jun 2020 19:20:42 -0700 (PDT) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825DC3A0D42 for ; Wed, 24 Jun 2020 19:20:42 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id cm23so2386715pjb.5 for ; Wed, 24 Jun 2020 19:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=7UpxiKC6eNok+xyjHOCVjHFXDCDY89GJh2Jenc3wkJ8=; b=jbcX4+TCc9JFr5uEZ73urMoI2qWyEPOR4iyH+n66Wj6lPqCflZLlBaOLdh0kErK7Sa GGT4ldBQu5nsnDSJ52LUXYL8U5ThOGp8tB7JPQrAoihnLAqZQutbaYTsNnTAhfnB6s5d 408AzOr0Sltl2dVxRhMAq7gT7F6isFcHwWtMPX9uJIXTtFXcbH8FLFNKtCmwy9Fg4B0x 9Pvh3wQIYv2nnAGHKsAfW6aLBosJOLTBt+kpxf82Gjc33b1nFGgLB6M9jXa7O4V6TbEl XO0M1zn+/72BePKpVR1OPYKEfofPpAszgBTbhOHJOer3urkT7P9Tnfwv/0VF5HDKuXFw oxbw== 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=7UpxiKC6eNok+xyjHOCVjHFXDCDY89GJh2Jenc3wkJ8=; b=l3I2iqd/Zc3MV9G96NeEf3wGA/ouj1ehUV0jv+2BMjwaEEzQt5hFOPP+1zjhCghzsp OuGAPVY7J02582Am/xCMGdEgDmCXhvx6GVFRZfZXahxDth8dRH37uB3J+ETUOBmbmNi1 MGUCACaMpu5zwPy/e3auZ0MSohPe887ZRDAiZagiSVVZ4ZO30mP7JpjSDcbVmhZbytqo RTsrbAVf3HCEtq9sR6Wk+A+Gj3xSAN9zyw9kX3+gyM0WGM4AVEcA06APAb+lf08AYWrz IOvoCjXUVY9cp5HYB8WG6xztcePh5iMTGTA0j3q7hUheUuVsfSj5mRYUMoGwZQK5gyvh Kvfw== X-Gm-Message-State: AOAM530HA6XJ2PkTIRIDnB5m2mupj9n8JhHIU/CVJN1QEP3QImyhJW2y KwqACyE+93EZkbcgmeY6HmyxUFmn X-Google-Smtp-Source: ABdhPJy/JAlyoScswrWzba+DEMbUZGLZ3PrSr/RTlx6uzlFLh2TH2m7if5aQpUGen9F5EKX5wZr+LQ== X-Received: by 2002:a17:90a:f309:: with SMTP id ca9mr735310pjb.113.1593051641745; Wed, 24 Jun 2020 19:20:41 -0700 (PDT) Received: from [192.168.178.20] (235.209.69.111.dynamic.snap.net.nz. [111.69.209.235]) by smtp.gmail.com with ESMTPSA id h6sm2491353pfo.123.2020.06.24.19.20.40 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2020 19:20:41 -0700 (PDT) To: rfced-future@iab.org References: <05ed01d64a77$f6cf6940$e46e3bc0$@olddog.co.uk> <7042366D-5CA7-44DB-919B-6BB054356E6F@brianrosen.net> From: Brian E Carpenter Message-ID: Date: Thu, 25 Jun 2020 14:20:38 +1200 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] Hires/contracts/selects/nominates/appoints 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, 25 Jun 2020 02:20:44 -0000 On 25-Jun-20 10:56, Jay Daley wrote: >=20 >=20 >> On 25/06/2020, at 10:49 AM, Brian Rosen > wrote: >> >> In the additional questions: >> C. Who recruits/interviews/selects/appoints the RSE? >=20 > This is currently specified in RFC 8728 section 3.1 >=20 > Just a reminder that there is no documented statement that explains why= that existing process needs to be replaced. Well, just to be clear, my firm assumption is the RSOC will be abolished = as result of our endeavours here. If not, we might as well give up now. More later, I'm in a rush right now. Brian >=20 >> >>> On Jun 24, 2020, at 6:36 PM, Adrian Farrel > wrote: >>> >>> Hi Brian, >>> >>>> 2. Who hires/contracts the RSE? >>>> Also seems like we can likely wrap this up quickly on-list. =C2=A0I = sense the current >>>> direction is the LLC. =C2=A0Brian offered some options. =C2=A0If you= think it should be >>>> some entity other than the LLC, please speak up. >>> >>> I tried before but maybe got lost in the noise. >>> >>> I think the question as phrased has ambiguities. >>> >>> Hires !=3D Contracts >>> >>> I have no issue with the LLC holding the contract and even doing any = necessary contract negotiation. >>> >>> But: >>> - who writes the job spec and sets out the fundamentals of the contra= ct? >>> - who reviews the applications? >>> - who short-lists? >>> - who interviews? >>> - who comes up with a preferred candidate? >>> - who ratifies that candidate? >>> >>> All of that MIGHT [RFC6919] be covered by the term "Hires" in which c= ase (and meaning no offence to the LLC) I don't think the LLC has the nec= essary experience to perform the task. >>> >>> Cheers, >>> Adrian >>> >> >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >> >=20 > --=C2=A0 > Jay Daley > IETF Executive Director > jay@ietf.org >=20 >=20 From nobody Wed Jun 24 20:00: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 2CA693A1246 for ; Wed, 24 Jun 2020 20:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWBuMBsqfLkk for ; Wed, 24 Jun 2020 20:00:42 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 8514A3A0A6A for ; Wed, 24 Jun 2020 20:00:42 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id n23so4820797ljh.7 for ; Wed, 24 Jun 2020 20:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NJDRMAoql+dDm1CrB6zTi61QPHZV1o5637e/1gfy+YQ=; b=HGQdN5xsm6sNHo4wJ52hxLufEYu9KqbRvpO99Kozi/cv5ysZ+D98txa/8/pD3gV/m7 ZktIi7XZ9FAPyYH+e8ERBBeHL37MQ5hGx97wc5+wT0L0aRJ94BJ9RwXLyluu5qouqlxi /mqFTZoDMvr/0P3+fpHg1KCv4Xn5PhF2HF0UolWzn/nUGnVQTjvCjQxqtYLkyCQBlt4P mha6u8bfa+RHv0LYEvE1cSiXCwhJc5poi4cjsRs9dyk+iY+v6lHRFB/cFYZZsJarU8Z0 KkyZk/gp2mRttRdsq0nS9O2055YGyZ5prrC26NFfPGFm6y1Op+pL64uPFzsf66ceLkLH D0NQ== 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=NJDRMAoql+dDm1CrB6zTi61QPHZV1o5637e/1gfy+YQ=; b=htImjZbH8XscYwV5uiarAJYg7nCfwFLt1tX1RAwuRJNJu5yDThDmdGUZIlQaM6juC+ zQsIQUg6uenClIheJUEo9671m7RAJBEj2b/OEJ7UiliCIgBYevSFlq4z/Y29zzcDDyxu qy33QhI0tR7L1k1CRUvdNEt10qqxGidKQJhLar/wk9Il8FBH9fh1nB7fBLWoHkM8OUA0 ZS+r4D9vpNDTi28H4YQso+XwBCBR3MNI8Y6rdmhKaeqPmJxX4WVJBYiFAgbPQKy230ZS utNiWFtBrdWtHmWU4BScJ9rk8BolrZp0LtxHI3nUIym+5rEVyWvAyE4Dj7JpTa4Yo+RD XsUg== X-Gm-Message-State: AOAM532xfvQg6nODJE3+EMbY01YlvvCulZiXQI3Mnre+6DK1BUKPsRDj /5K5OdSVy7G4J/3lqI4ASnEStU9PTb6bLklCBG1Yww== X-Google-Smtp-Source: ABdhPJywl/LN75JF5NStjdqziI6yGeINW+yfPO6vMcrGAVFfVWHUpKvtHAvNbufSZrdhlJ8COpysu8ZuAVmbFS2f/Nw= X-Received: by 2002:a05:651c:1044:: with SMTP id x4mr14606202ljm.409.1593054040522; Wed, 24 Jun 2020 20:00:40 -0700 (PDT) MIME-Version: 1.0 References: <05ed01d64a77$f6cf6940$e46e3bc0$@olddog.co.uk> <7042366D-5CA7-44DB-919B-6BB054356E6F@brianrosen.net> In-Reply-To: From: Eric Rescorla Date: Wed, 24 Jun 2020 20:00:04 -0700 Message-ID: To: Brian E Carpenter Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000003199ab05a8dfcc83" Archived-At: Subject: Re: [Rfced-future] Hires/contracts/selects/nominates/appoints 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, 25 Jun 2020 03:00:44 -0000 --0000000000003199ab05a8dfcc83 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 24, 2020 at 7:20 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 25-Jun-20 10:56, Jay Daley wrote: > > > > > >> On 25/06/2020, at 10:49 AM, Brian Rosen br@brianrosen.net>> wrote: > >> > >> In the additional questions: > >> C. Who recruits/interviews/selects/appoints the RSE? > > > > This is currently specified in RFC 8728 section 3.1 > > > > Just a reminder that there is no documented statement that explains why > that existing process needs to be replaced. > > Well, just to be clear, my firm assumption is the RSOC will be abolished > as result of our endeavours here. If not, we might as well give up now. > That seems like a pretty big assumption. I mean, that might be the outcome, but there's nothing in the charter that pre-decides that. -Ekr --0000000000003199ab05a8dfcc83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jun 24, 2020 at 7:20 PM Brian= E Carpenter <brian.e.car= penter@gmail.com> wrote:
On 25-Jun-20 10:56, Jay Daley wrote:
>
>
>> On 25/06/2020, at 10:49 AM, Brian Rosen <br@brianrosen.net <mailto:br@brianrosen.net>&g= t; wrote:
>>
>> In the additional questions:
>> C. Who recruits/interviews/selects/appoints the RSE?
>
> This is currently specified in RFC 8728 section 3.1
>
> Just a reminder that there is no documented statement that explains wh= y that existing process needs to be replaced.

Well, just to be clear, my firm assumption is the RSOC will be abolished as= result of our endeavours here. If not, we might as well give up now.

That seems like a pretty big assumption. I m= ean, that might be the outcome, but there's nothing in the charter that= pre-decides that.

-Ekr
--0000000000003199ab05a8dfcc83-- From nobody Wed Jun 24 20:17: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 756B73A1248 for ; Wed, 24 Jun 2020 20:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 TnHyVpPthygH for ; Wed, 24 Jun 2020 20:16:57 -0700 (PDT) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 09EEF3A1246 for ; Wed, 24 Jun 2020 20:16:57 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id dr13so4481386ejc.3 for ; Wed, 24 Jun 2020 20:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=GTDdaZKP9vyefII5wdk+a7Ty5hD4izFbd7OZ74gdqjA=; b=Bfp4CpTooAmcenxM7XXani2hESYvnwk/e2rfEXR1zt9CS+/khtjCVs3FptXSa/qkCe Zfoh3nSMJztYBv358sT+aVsHfVCVHSzDi7IafuuVIyBvPivwZCvdrO301yI5hV8cyoJT tGpUulJtkGM6zikgeaoym30CsyaIwsazN8umYTLI96KjCkyMy8wtWFWCdMUkQ+XZQxXf /2sDV2BgR1rLHLUUj/+8HxkP/t23k/DamzybjcW+GDbWiLlhwq2rcZhs/5jxmIMKAWBm wcEj4Kdmc5jIDOXa4cX6TcMbfmr1+azua142YnSOCaDTCoU+TnNb33BxarVrgta8kPWz imIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=GTDdaZKP9vyefII5wdk+a7Ty5hD4izFbd7OZ74gdqjA=; b=piUf1t2mrKYguk15ksUouDfxay7kWm2yZGkZK+uyKc1dLQ01PtDH6EabotseL4aCSv n7s0nSP5PlA0Srl9xuCZztBbGoWPdswhJK6rr+QC6dv/TJOFTtQqYtYWM+Mynd2caHsN BAnkkGbamYlwcpDtlDWcqFHJxuzgVLX0UtGIONLzkSV1ztmDA+Eb8Y8bEzLctLoB7o5Q k5iN7cnPdZCyfSeWBGjgXM44xXEXLKVDW/g9U0fK8uMCJ3TdMR2z4FBtO7qza9xgAIWC GhrwVYrV9d+sp7w2Vyq1s06omFb4QUvfxY5KAhT6vST/KEShf3m/o11xIa8bDxy7DhBu ja1Q== X-Gm-Message-State: AOAM531md2AxTZWHOMMNRa0jZ6JMaahHt7ghbTKBnqXEwDUu1h/iyrgn NBre1w9WOeC0yLb/x9wnje4UV0eY9+K2 X-Google-Smtp-Source: ABdhPJzEmQBD7dxajNmAxXyMf5OYvzjALiYlUnEOsZFwxEM/UW2kL/MHyi63hSwU2trIZrTGKAHh2Q== X-Received: by 2002:a17:906:848b:: with SMTP id m11mr11861860ejx.10.1593055015184; Wed, 24 Jun 2020 20:16:55 -0700 (PDT) Received: from [192.168.1.7] (184-99-75-59.boid.qwest.net. [184.99.75.59]) by smtp.googlemail.com with ESMTPSA id l3sm6382387edr.14.2020.06.24.20.16.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jun 2020 20:16:54 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: rfced-future@iab.org References: <05ed01d64a77$f6cf6940$e46e3bc0$@olddog.co.uk> <7042366D-5CA7-44DB-919B-6BB054356E6F@brianrosen.net> Organization: http://SoftwareAndServices.NET Message-ID: Date: Wed, 24 Jun 2020 21:16:52 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EEED0862A851ED8582108FDD" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Hires/contracts/selects/nominates/appoints 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, 25 Jun 2020 03:16:59 -0000 This is a multi-part message in MIME format. --------------EEED0862A851ED8582108FDD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 6/24/20 8:20 PM, Brian E Carpenter wrote: > > Well, just to be clear, my firm assumption is the RSOC will be abolished as result of our endeavours here. If not, we might as well give up now. > > More later, I'm in a rush right now. > > Brian A very clear goal. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------EEED0862A851ED8582108FDD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 6/24/20 8:20 PM, Brian E Carpenter wrote:

Well, just to be clear, my firm assumption is the RSOC will be abolished as result of our endeavours here. If not, we might as well give up now.

More later, I'm in a rush right now.

    Brian

A very clear goal.


--
Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135
--------------EEED0862A851ED8582108FDD-- From nobody Wed Jun 24 21:24:44 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 A542A3A1273; Wed, 24 Jun 2020 21:24:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: lflynn@amsl.com, The IAB , rfcefdp-chairs@ietf.org, rfced-future@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159305908260.9610.11888188607448766671@ietfa.amsl.com> Date: Wed, 24 Jun 2020 21:24:42 -0700 Archived-At: Subject: [Rfced-future] rfcefdp - Update to a Meeting Session Request for IETF 108 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: Thu, 25 Jun 2020 04:24:43 -0000 An update to a meeting session request has just been submitted by Liz Flynn, on behalf of the rfcefdp working group. --------------------------------------------------------- Working Group Name: RFC Editor Future Development Area Name: Internet Architecture Board Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: opsarea emu tls quic httpbis secdispatch saag dprive masque dnsop lake wpack People who must be present: Eliot Lear Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jun 24 22:14: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 BB7AE3A00DF for ; Wed, 24 Jun 2020 22:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 TGNJ5I9AzCih for ; Wed, 24 Jun 2020 22:14:23 -0700 (PDT) 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 AD63F3A00D3 for ; Wed, 24 Jun 2020 22:14:23 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id t6so2785466pgq.1 for ; Wed, 24 Jun 2020 22:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fivn5moDW5ek6fDTCk6GwOAkJmAJX+RaZoaWByKHfCo=; b=rCJywE7yzwTcva0m8EgL52aDs04BWywK5Hfy6sapjbjrCzoLzob4JerSEJPScWa8Iq IIMMeB54lgwDBOCm2xioh1vxWTX5CFY8IcET8oDQOefcmwiISGvwx8gPAHvpZbGm4Abe 5ganzDU7ucA0ePZph5A0SvTKYduk8F4q0SFYRviVaR2jA2q23hzGxqLzFASTFUVnE/4a ilzjxhSlPlQkAn5Tfe5J+vNaLe0m0cuG8gt+Z+Qe34tPcom/MFlKW2/z0Z+LuppVuZ/y L+L5kqxnKFftsQunSx1F3CA/kDmzan1P3iyX4fuExmZAi793JbkkQfVSy5le5mw2CY4f EyPg== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=fivn5moDW5ek6fDTCk6GwOAkJmAJX+RaZoaWByKHfCo=; b=J4wbcxBIvtxfUZ1yjFFcfS8ERIv8laoqOfZhjb5y/you2IjMr/ji+7zYMbvxK49ExQ 88/PGRd/EiK5IqCaCrCa1GKmn7fU9F6Z2gtmGKBhpBXJuJo7bYPbtB7e6LmpndW4BBDb 1Zh5GmILbwHG5pS/HfUchw0avSYN7Ct59HYGGNWFZ8hliCZw7IkPpFhXo+4Kv+OmgGhw BxkeYzwbItwXxXRIV1FVZKMpWd8wA5dGZ3cN61vLurBbMKY8uihv5oVvUuKMXKDyLK2v ggcQeQlX8XorcOxsusCl9e+FSt2Y7+g1DlpL4qt6RjC1PwshhSjh9X3FMsltafCE99bQ TJvQ== X-Gm-Message-State: AOAM533AdNpf4LhMyemyi+fzikkNUu474UbyELOSvTmkfUN7Exnln1tQ GFARL1jBrQT8yrCXdCiKl/Q3Rp5k X-Google-Smtp-Source: ABdhPJz5Ndu09tLWNH4n0/1uHdyVciXt+ioxNMmbr3gGBGBWiP4MoIjMcDaP6N/BRLuLtWWYP7uokg== X-Received: by 2002:a63:5623:: with SMTP id k35mr26271181pgb.325.1593062062743; Wed, 24 Jun 2020 22:14:22 -0700 (PDT) Received: from [192.168.178.20] (235.209.69.111.dynamic.snap.net.nz. [111.69.209.235]) by smtp.gmail.com with ESMTPSA id t2sm4244536pja.1.2020.06.24.22.14.21 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2020 22:14:22 -0700 (PDT) To: rfced-future@iab.org References: <05ed01d64a77$f6cf6940$e46e3bc0$@olddog.co.uk> <7042366D-5CA7-44DB-919B-6BB054356E6F@brianrosen.net> From: Brian E Carpenter Organization: University of Auckland Message-ID: <25746739-da9b-121d-8057-39f30e855173@gmail.com> Date: Thu, 25 Jun 2020 17:14:20 +1200 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] Hires/contracts/selects/nominates/appoints 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, 25 Jun 2020 05:14:28 -0000 On 25-Jun-20 14:20, Brian E Carpenter wrote: > On 25-Jun-20 10:56, Jay Daley wrote: >> >> >>> On 25/06/2020, at 10:49 AM, Brian Rosen > wrote: >>> >>> In the additional questions: >>> C. Who recruits/interviews/selects/appoints the RSE? >> >> This is currently specified in RFC 8728 section 3.1 >> >> Just a reminder that there is no documented statement that explains wh= y that existing process needs to be replaced. >=20 > Well, just to be clear, my firm assumption is the RSOC will be abolishe= d as result of our endeavours here. If not, we might as well give up now.= Let me expand on that. Also, please understand that I am not criticising = the RSOC members, any more than we criticised the IAOC members for the wa= y the IAOC got locked into micro-management. Both those committees were s= et up with the best intentions, but I'm afraid they were set up to fail. = One of the reasons is that as I already said once today, engineers are ba= d at overseeing non-engineering tasks and have a tendency to get bogged d= own in details. We've made a serious effort to avoid that problem in the = LLC/LLC Board setup, and we need to do the same for the RFC Series. As fa= r as I can see, having the LLC in charge of performance-based contracts f= or RFC production and publishing services takes away all that side of thi= ngs from the RSOC, and that's a good thing. So (whatever RFC 8728 says) a= large part of the RSOC's job has simply gone away. What remains is the part that visibly went dramatically wrong and led to = Heather's resignation, i.e. selection and "oversight" of the RSE. RFC8728 says: =20 > 3.1. RFC Series Oversight Committee (RSOC) >=20 > The IAB is responsible for the oversight of the RFC Series... I believe this statement (copied from RFC6635) has caused us tremendous t= rouble. It's not at all what the IAB charter (BCP39, aka RFC2850) says: > The IAB must approve the appointment of an organization to > act as RFC Editor and the general policy followed by the RFC Editor.= That's all that is sanctioned by a BCP and it doesn't say "oversight". In= delegating responsibility to the RSOC, the IAB also annexed some territo= ry: "oversight of the RFC Series". That's a big deal and it is (IMHO) the= crux of the matter. I think the events of the last year or so show that = we need to walk this back. One way is to simply remove all reference to t= he RFC Series from the IAB charter, and therefore abolish the RSOC. Then = constitute a separate Editorial Board for the RFC Series, along the lines= that Mike proposed, answering to the community. Alternatively, walk back the IAB to its chartered role, but reduced to al= low for the fact that contracting for the production and publishing servi= ces is now LLC business. Something like: > The IAB must approve the appointment of a person to > act as RFC Series Editor and the general policy followed by the RFC = Series Editor. By the nature of things, that also leads to abolishing the RSOC. Personally, I much prefer a new, independent Board because I'd like to se= e the IAB able to focus exclusively on, er, Internet Architecture. In any case the statement in the IAB charter cannot be taken too seriousl= y any more. It was drafted to take account of current reality in early 20= 00. I certainly expect this group to propose *major* changes to RFC8728 and a= relatively minor change to the IAB Charter. Regards Brian C >=20 > More later, I'm in a rush right now. >=20 > Brian >=20 >=20 >> >>> >>>> On Jun 24, 2020, at 6:36 PM, Adrian Farrel > wrote: >>>> >>>> Hi Brian, >>>> >>>>> 2. Who hires/contracts the RSE? >>>>> Also seems like we can likely wrap this up quickly on-list. =C2=A0I= sense the current >>>>> direction is the LLC. =C2=A0Brian offered some options. =C2=A0If yo= u think it should be >>>>> some entity other than the LLC, please speak up. >>>> >>>> I tried before but maybe got lost in the noise. >>>> >>>> I think the question as phrased has ambiguities. >>>> >>>> Hires !=3D Contracts >>>> >>>> I have no issue with the LLC holding the contract and even doing any= necessary contract negotiation. >>>> >>>> But: >>>> - who writes the job spec and sets out the fundamentals of the contr= act? >>>> - who reviews the applications? >>>> - who short-lists? >>>> - who interviews? >>>> - who comes up with a preferred candidate? >>>> - who ratifies that candidate? >>>> >>>> All of that MIGHT [RFC6919] be covered by the term "Hires" in which = case (and meaning no offence to the LLC) I don't think the LLC has the ne= cessary experience to perform the task. >>>> >>>> Cheers, >>>> Adrian >>>> >>> >>> --=20 >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >>> >> >> --=C2=A0 >> Jay Daley >> IETF Executive Director >> jay@ietf.org >> >> >=20 From nobody Thu Jun 25 01:27: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 538F03A086D for ; Thu, 25 Jun 2020 01:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=csperkins.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ucmYlh62yQ9 for ; Thu, 25 Jun 2020 01:27:08 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2: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 411653A0812 for ; Thu, 25 Jun 2020 01:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=rkGNUwir4+J8awcshhhayqd8dIwn1r2/wdPPaVJHpkE=; b=qN8ajpT5IaOrHipwuJ93v8YDVw jvuzVCpfnhlye5xM9xZDtI84GSuZI/2B5M6yii1R0SzacSZq/KgaiuCWUH+ziRKSD3d8qj4kFUPXz A5sw9CY3EVKTXiAwqKsVaUItv84iT8BLv3bbWqUWqIox7izVpwgI6uVP6dXJ7HxrmAglEJBj38HoJ h4T9/uEsb2qVTaf5NJX6t6WP9yrbAbdZgi7Dk1wddRXcpGbnq3OQy1eVmLZBkfUA3iIwGfdLOnJza CUZ5+yrclOKRGa9XA2TirP8wOZToA8SrS5Fn3MjrFQCiICVaj9GvxaloDEZkDrphniqGL4G/8YqLY 2drnDqwA==; Received: from [81.187.2.149] (port=47634 helo=[192.168.0.80]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1joNDu-00009x-Am; Thu, 25 Jun 2020 09:27:06 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Colin Perkins In-Reply-To: Date: Thu, 25 Jun 2020 09:27:03 +0100 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> To: Brian Rosen X-Mailer: Apple Mail (2.3445.104.14) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 25 Jun 2020 08:27:10 -0000 [As an individual] > On 24 Jun 2020, at 16:17, Brian Rosen wrote: >=20 > We appreciate all the thoughtful comments we have seen so far. >=20 > Skipping, for the moment, the scope proposal and concentrating on the = questions: > 1. Should the RSE be a hired employee or a contracted entity? > Many commenters think this is a detail, but needs to be decided. We = can likely wrap this up quickly, and probably on-list. There are those = who just say =E2=80=9Ccontract=E2=80=9D, some that say =E2=80=9Coh, part = time employee is fine=E2=80=9D and others that say, =E2=80=9Cjust leave = it up to the entity in question 2=E2=80=9D. Please offer your thoughts = on this if you haven=E2=80=99t already. =20 I=E2=80=99m not sure I have sufficient knowledge of employment law = around the world to state an opinion. Certainly the implications of the = different choices seem to vary depending where the RSE is located. That = suggests that the right answer might depend on circumstances. > 2. Who hires/contracts the RSE? > Also seems like we can likely wrap this up quickly on-list. I sense = the current direction is the LLC. Brian offered some options. If you = think it should be some entity other than the LLC, please speak up. I agree the employment/contracting relationship should be with the LLC. The question of who interviews/appoints the RSE is much harder, and = perhaps more interesting. > 3. For the purposes of day to day management, to whom does the RSE = report? > Most commenters seem to think this is not a good question because the = answer is: they don=E2=80=99t need day to day management. Bron thought = everyone needs =E2=80=9Csome=E2=80=9D management even if it=E2=80=99s = =E2=80=9CI=E2=80=99m sick and won=E2=80=99t be working for a few = days=E2=80=9D. Whatever the answer to 2 is, there is some management = there, but probably there is more to be considered. Let=E2=80=99s keep = discussing this a bit. The RSE should be considered a reasonably senior role, so close = day-to-day supervision seems unnecessary. Most senior roles have some = management and reporting chain though, and I expect the same would be = true of the RSE. > 4. Is there some group that oversees the RSE? > This seems to be answered in the affirmative. If you disagree, please = speak up. I agree there should be some oversight. > 5. If the answer to 4 is yes, how is the board constituted? > Most commenters liked Michael=E2=80=99s suggestion. If you disagree, = please speak up. Michael summarised his proposal as "stream managers plus some number of = community selected folks who are acceptable to the RSE=E2=80=9D. I agree = that giving the stream managers a role makes sense. I also agree that = having community selected members is a good idea, but I don=E2=80=99t = agree that being "acceptable to the RSE=E2=80=9D should be a criteria. = Having person being overseen approve members of the oversight committee = does not lead to effective oversight. What sort of oversight is envisaged will likely affect the structure of = the board, and whether a new board is needed or if the oversight can be = conducted by an existing body.=20 > 6. Who defines the process that the RSE follows? This group? The = Board? The RSE defines it themselves? > Here we have a lot of different opinions, and we probably need to = spend some time at the meeting discussing this. The question of = strategy before process came up which we also need to figure out. I=E2=80=99m not sure this is a well-defined question, since it assumes = there=E2=80=99s a singular process.=20 > 7. Can the RSE decide to not publish a document one of the stream = editors forwards to it? If so, on what grounds? > I sense that we=E2=80=99re close on this, but details matter. I sense = that there is support to allow the RSE to hold up a document if the RSE = doesn=E2=80=99t feel that it is readable, but that that control is = fairly limited. =20 I=E2=80=99d argue that the RSE should be able to push back, perhaps = quite strongly, and say =E2=80=9Cthis is too poorly written to = publish=E2=80=9D, but ultimately the RSE should not have a veto on = editorial grounds. I=E2=80=99d argue that the RSE does not have the right to veto = publication on technical grounds. If they object on such grounds they = can comment, and appeal against publication, in the same way as any = other member of the community, but have no special right as RFC Editor. I=E2=80=99d argue that there should be a policy defining what is = inappropriate content for the RFC series (e.g., hate speech, obscenity, = indecency, etc.), how it should be handled, and when/if the RSE can = refuse publication on such grounds. That seems like something to be = agreed between the RSE and the community in some consensus document. There will certainly be legal restrictions on what the RFC series can = publish. The community needs to understand those.=20 > There were a couple of other suggested questions: > A. What do we want the RSE to do? =20 > B. Is the RSE an individual or a group? > C. Who recruits/interviews/selects/appoints the RSE? > D. What should the appointment length/renewal terms be? >=20 > Several commenters said things along the lines of =E2=80=9Cpoorly = worded question=E2=80=9D. Other than the above, please suggest actual = rewrites of the question that would be better in your opinion. >=20 > Brian >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Colin Perkins https://csperkins.org/ From nobody Thu Jun 25 01:30: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 A5FEC3A0803 for ; Thu, 25 Jun 2020 01:30:15 -0700 (PDT) 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 wMT7E2qyCV4o for ; Thu, 25 Jun 2020 01:30:14 -0700 (PDT) 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 E77483A07CB for ; Thu, 25 Jun 2020 01:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2971; q=dns/txt; s=iport; t=1593073814; x=1594283414; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=jRXJThifzzwAV030dffSQhvs41hU0Vm4/nqpR3WBZS0=; b=OzFqhk2Ymj5vAoBCWhfP1YousBLFCNysV7BEJXpW5jA95UQKHxpPYRUL UDuA5nYNAcUKsqred3NXPt83uG31pwE1j4JZ++kRQQ97AuS14SUpzCpQZ NSpe2btbFJaVMYM+UD0UiJKrwaSBbArkRic3/3g2HSmTBpNlvZ0Pw3uC0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAQAzX/Re/xbLJq1mGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAYIKgSOCSgEgEiyEJIkBiA6TbYgUCwEBAQwBAS8EAQG?= =?us-ascii?q?ERwKCGiU4EwIDAQELAQEFAQEBAgEGBG2FZ4VyAQEBAwEjVgULCwQKCioCAlc?= =?us-ascii?q?GExSDEoJdILZRdoEyhVGFDoE4jH6CAIE4HIIfLj6BBIZNM4ItBLRqgmWDA5Y?= =?us-ascii?q?vAx2RDY12rDqDTwIEBgUCFYFqIoFWMxoIGxVlAYI+PhIZDY4qDAuOJj8DMDc?= =?us-ascii?q?CBgEHAQEDCZFTAQE?= X-IronPort-AV: E=Sophos; i="5.75,278,1589241600"; d="scan'208,217"; a="27424017" 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; 25 Jun 2020 08:30:09 +0000 Received: from [10.61.216.251] ([10.61.216.251]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 05P8U9b4028804 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Jun 2020 08:30:09 GMT From: Eliot Lear Message-Id: <07E40575-360B-436F-B16F-5B15D0578803@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_787D5839-CD05-402E-BDDD-25E51C63B878" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 25 Jun 2020 10:30:08 +0200 In-Reply-To: Cc: Brian Rosen , rfced-future@iab.org To: Colin Perkins References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.216.251, [10.61.216.251] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 25 Jun 2020 08:30:16 -0000 --Apple-Mail=_787D5839-CD05-402E-BDDD-25E51C63B878 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Colin > On 25 Jun 2020, at 10:27, Colin Perkins wrote: >=20 > Michael summarised his proposal as "stream managers plus some number = of community selected folks who are acceptable to the RSE=E2=80=9D. I = agree that giving the stream managers a role makes sense. I also agree = that having community selected members is a good idea, but I don=E2=80=99t= agree that being "acceptable to the RSE=E2=80=9D should be a criteria. = Having person being overseen approve members of the oversight committee = does not lead to effective oversight. I am going to hazard a guess, and Mike should feel free to correct me, = that he did not mean for the RSE to choose those who would themselves = oversee the role. I would agree with you that that seems somewhat = circular. Eliot --Apple-Mail=_787D5839-CD05-402E-BDDD-25E51C63B878 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Colin

On 25 Jun 2020, at 10:27, Colin Perkins = <csp@csperkins.org> wrote:

Michael summarised his proposal = as "stream managers plus some number of community selected folks who are = acceptable to the RSE=E2=80=9D. I agree that giving the stream managers = a role makes sense. I also agree that having community selected members = is a good idea, but I don=E2=80=99t agree that being "acceptable to the = RSE=E2=80=9D should be a criteria. Having person being overseen approve = members of the oversight committee does not lead to effective = oversight.

I= am going to hazard a guess, and Mike should feel free to correct me, = that he did not mean for the RSE to choose those who would themselves = oversee the role.  I would agree with you that that seems somewhat = circular.

Eliot

= --Apple-Mail=_787D5839-CD05-402E-BDDD-25E51C63B878-- From nobody Thu Jun 25 01:44: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 736A83A0874 for ; Thu, 25 Jun 2020 01:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_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=csperkins.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71OfOGve984D for ; Thu, 25 Jun 2020 01:44:04 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2: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 968F53A0872 for ; Thu, 25 Jun 2020 01:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=DRJz4Nz12+9snEeUnxodt98B2O5rck8n2hCetcOZl+I=; b=nNmZfhWMcItuIGcJS99pWhIWOh wJUOpuE5nuroARaWyyymLcjOSTzCeMQIFV0p53jSbO4d0xRW2sd9PS6Ih432o2q6L3Qj7O6D+h4Se Ze4MjbiwqtTBnWDBRe7GZV7TXIQKLB3qtpEWUzoFOIrhu/Aq0ZFpBzLAlOwK6wiC6bhuVMj6XNuN0 r68BN1ymlGlIMFadliObrMKFFQ+YAdxlsGgiejO1+bo7sAn9TrSfWWFNUlr8EjyTyC3L+Mx4bsRZJ D/USiHW/jaWncfdvtiV8LDzKY/e92rXl55lPYBavpM/tSK2BUvZ/9tkpbdxVEkPArgvC5GDD9EaDQ NMMxjY2g==; Received: from [81.187.2.149] (port=32825 helo=[192.168.0.80]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1joNUI-0003g1-DQ; Thu, 25 Jun 2020 09:44:02 +0100 From: Colin Perkins Message-Id: <278D6E58-8937-4F34-B95A-9ED6F66A0649@csperkins.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_0AB02586-9C6F-4BD6-9004-7992F9C23E01" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Thu, 25 Jun 2020 09:43:58 +0100 In-Reply-To: <07E40575-360B-436F-B16F-5B15D0578803@cisco.com> Cc: Brian Rosen , rfced-future@iab.org To: Eliot Lear References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <07E40575-360B-436F-B16F-5B15D0578803@cisco.com> X-Mailer: Apple Mail (2.3445.104.14) X-BlackCat-Spam-Score: 14 Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 25 Jun 2020 08:44:07 -0000 --Apple-Mail=_0AB02586-9C6F-4BD6-9004-7992F9C23E01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 25 Jun 2020, at 09:30, Eliot Lear wrote: >> On 25 Jun 2020, at 10:27, Colin Perkins > wrote: >>=20 >> Michael summarised his proposal as "stream managers plus some number = of community selected folks who are acceptable to the RSE=E2=80=9D. I = agree that giving the stream managers a role makes sense. I also agree = that having community selected members is a good idea, but I don=E2=80=99t= agree that being "acceptable to the RSE=E2=80=9D should be a criteria. = Having person being overseen approve members of the oversight committee = does not lead to effective oversight. >=20 > I am going to hazard a guess, and Mike should feel free to correct me, = that he did not mean for the RSE to choose those who would themselves = oversee the role. I would agree with you that that seems somewhat = circular. I expect so =E2=80=93 I agree Mike's more detailed proposal is clearer = than his summary here. Having re-read the detailed proposal, there are many aspects I disagree = with, along with some potentially good ideas. At this stage, though, it = doesn=E2=80=99t seem that we have agreement on what type of oversight is = needed, or what are the problems with the existing oversight mechanism, = so it seems premature to be designing an alternative. --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_0AB02586-9C6F-4BD6-9004-7992F9C23E01 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 25 Jun 2020, at 09:30, Eliot Lear <lear@cisco.com> wrote:
On 25 Jun 2020, at 10:27, Colin Perkins = <csp@csperkins.org> wrote:

Michael summarised his proposal = as "stream managers plus some number of community selected folks who are = acceptable to the RSE=E2=80=9D. I agree that giving the stream managers = a role makes sense. I also agree that having community selected members = is a good idea, but I don=E2=80=99t agree that being "acceptable to the = RSE=E2=80=9D should be a criteria. Having person being overseen approve = members of the oversight committee does not lead to effective = oversight.

I= am going to hazard a guess, and Mike should feel free to correct me, = that he did not mean for the RSE to choose those who would themselves = oversee the role.  I would agree with you that that seems somewhat = circular.

I = expect so =E2=80=93 I agree Mike's more detailed proposal is clearer = than his summary here.

Having = re-read the detailed proposal, there are many aspects I disagree with, = along with some potentially good ideas. At this stage, though, it = doesn=E2=80=99t seem that we have agreement on what type of oversight is = needed, or what are the problems with the existing oversight mechanism, = so it seems premature to be designing an alternative.

-- 
Colin Perkins
https://csperkins.org/




= --Apple-Mail=_0AB02586-9C6F-4BD6-9004-7992F9C23E01-- From nobody Thu Jun 25 01:58:47 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 385F13A0884; Thu, 25 Jun 2020 01:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, 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 OkkICUou8Y3e; Thu, 25 Jun 2020 01:58:44 -0700 (PDT) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E953A3A0882; Thu, 25 Jun 2020 01:58:42 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 05P8weGt027930; Thu, 25 Jun 2020 09:58:40 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2A4E322072; Thu, 25 Jun 2020 09:58:40 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 1541A22074; Thu, 25 Jun 2020 09:58:40 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.26.18]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 05P8wdB6000363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Jun 2020 09:58:39 +0100 Reply-To: From: "Adrian Farrel" To: "'Jay Daley'" , "'Brian Rosen'" Cc: References: <05ed01d64a77$f6cf6940$e46e3bc0$@olddog.co.uk> <7042366D-5CA7-44DB-919B-6BB054356E6F@brianrosen.net> In-Reply-To: Date: Thu, 25 Jun 2020 09:58:37 +0100 Organization: Old Dog Consulting Message-ID: <066a01d64ace$d1669e10$7433da30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKIiNTCwpzrfl4xna5KqnLdyeDKSgNRpdseASuLSfinYJ87QA== Content-Language: en-gb X-Originating-IP: 84.93.26.18 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-25502.006 X-TM-AS-Result: No--4.754-10.0-31-10 X-imss-scan-details: No--4.754-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25502.006 X-TMASE-Result: 10--4.754500-10.000000 X-TMASE-MatchedRID: X4bcv0S75KnxIbpQ8BhdbPHkpkyUphL90R9O7UrrGaOHvxzu1FG4kb6S cpwFQjm9PfcPfsnNQUPglAEj1nfd8v+t69FNoOHHC/N7ukLndIA0AJe3B5qfBlY9yet6QEd8/WI NYVnxXirJdqlSG6VS2tvCl4EpmmZJjJBSOECLn6q6C8mlSPMNl54oEP/S42Q2ebe1tfR6Tkgg38 xtfHH5LUw1PNUciM5AivBWmLyjpzZPUvyn109llzKVTrGMDe/DKBYAgX/yWDwpyO+RqTc8rgKJH 9OQtm+kgJvVWlJ+UT9iBXGM4LktlVvLEDLz4/18zNIobH2DzGHiXOoSlo9AtUl/J9Ro+MABViZb Q7nUFDWalsTE3endacAywyAvyBa5SSOWVJeuO1A5f9Xw/xqKXcidYBYDjITpi2QFaYS1v20qtq5 d3cxkNXRcsnIv8tAuepTLkkBzJcmL0zJ+DSiB5Tu3L1WRpMQHvv9Hp1oD6Dqaop79nMvpV/o+LY bXIdlieesBRL6sosokaXG43vVQHfO/X9Lsr3+3p8i26iGCN+fD/c2Y8mxrik1Z+dSdugwvIEkRm WEtatBDDKa3G4nrLQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Hires/contracts/selects/nominates/appoints 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, 25 Jun 2020 08:58:46 -0000 >> C. Who recruits/interviews/selects/appoints the RSE? > > This is currently specified in RFC 8728 section 3.1 > > Just a reminder that there is no documented statement that explains why that existing process needs to be replaced. Just cos it is in an RFC doesn't mean it can't be changed. Our charter is: | This program is intended to foster discussion and consensus on | potential changes to the RFC Editor model. Discussion of changes | to how the RFC Editor function is managed, staffed, and overseen | are all within scope. After the group has come to rough consensus, | it will document its output in one or more RFCs. I read that as meaning that discussing this point is within scope. The lack of a "documented statement" explaining why change is necessary is a good observation. Change for the sake of change can lead to risky outcomes. On the other hand, exploring the current process and its results and stresses could lead us to determine that there is a need for change. We might end up with a statement that "the process for selecting and hiring the RSE is as described in Section 3.1 of RFC 8728." But we might now. As has been pointed out (plenty) if what we do results in the RSOC going away or changing considerably, then that section of that RFC will not hold. But in any case, and to reiterate, what we are doing is looking at the process and responsibilities. Saying that they are already documented in an existing RFC is useful historical information, but does not dictate our discussions of the future, nor preform our consensus. Thanks, Adrian From nobody Thu Jun 25 02:33: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 9A8523A08A5 for ; Thu, 25 Jun 2020 02:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YnMykWjykDE for ; Thu, 25 Jun 2020 02:33:36 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 2051E3A08A2 for ; Thu, 25 Jun 2020 02:33:30 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.29.82]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 05P9XA0d007017 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jun 2020 02:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1593077604; x=1593164004; i=@elandsys.com; bh=hhSd1lrBTRtVRLUT0vC3h+l5pmU9YGQWopNgvH8gj/E=; h=Date:To:From:Subject:In-Reply-To:References; b=bFzsYrgWPgyvsmspHesjJw082n+DuhfaiBmJEkK+uRYbk7HOokyHn6p5VM3vc8EE5 avPCEvfTGfy6Yb8KceoByGTzjKCt4q64NHftqciUHgv1YYMzvWkfvKL33EF/jYDaSS mRNxSL7Xxdt+fUSfVpmEuItXBUXTeLj5qfol3Gdk= Message-Id: <6.2.5.6.2.20200625010100.0d621478@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 25 Jun 2020 02:18:11 -0700 To: Brian E Carpenter , Peter Saint-Andre , rfced-future@iab.org From: S Moonesamy In-Reply-To: References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Rfced-future] "oversees" [was Scope and IETF 108 proposals] 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, 25 Jun 2020 09:33:42 -0000 Hi Brian, Peter, At 04:14 PM 24-06-2020, Brian E Carpenter wrote: >On 25-Jun-20 09:21, Peter Saint-Andre wrote: > > I've seen this claim several times; can you provide evidence for it? > >Just the entire history of IASA version 1 and the IAOC doing the >work itself instead of overseeing the execution of the work. So far, >the LLC Board is doing much better, because it's constituted as a >Board. Also of course the recent history of the RSOC that led to >Heather's resignation. Engineers are bad at overseeing >non-engineering activities; we meddle in things we are no good at. >(I don't except myself from that statement, since I was IETF Chair >at the time that IASA was set up, and I know that I got far too >interested in stuff that shouldn't have been my business.) The IAOC membership included the following: IETF Chair IAB Chair, Internet Society CEO If what Brian mentioned is correct, it would mean that the persons in those positions did not understand the meaning of overseeing the execution of the IASA work. If the RSOC did not do its work correctly, it would mean that the IAB appointed the wrong people. One of the differences between the [IA,RS]OC and the LLC Board is that the latter is a legal entity. I doubt that setting up a legal entity would solve a "meddling" problem. Peter asked for evidence. There isn't any information to substantiate an assertion that the RSOC were not fulfilling the role it was assigned. However, there is one matter; it is usually known as soft skills. Regards, S. Moonesamy From nobody Thu Jun 25 04:23: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 C72D73A0943 for ; Thu, 25 Jun 2020 04:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoK68cY1uwq8; Thu, 25 Jun 2020 04:23:20 -0700 (PDT) Received: from [192.168.1.49] (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 358DF3A093A; Thu, 25 Jun 2020 04:23:20 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-5562ACE1-83C6-4CC3-9537-8B61B19EB46C Content-Transfer-Encoding: 7bit From: Jay Daley Mime-Version: 1.0 (1.0) Date: Thu, 25 Jun 2020 23:23:18 +1200 Message-Id: References: <066a01d64ace$d1669e10$7433da30$@olddog.co.uk> Cc: Brian Rosen , rfced-future@iab.org In-Reply-To: <066a01d64ace$d1669e10$7433da30$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: iPad Mail (17F80) Archived-At: Subject: Re: [Rfced-future] Hires/contracts/selects/nominates/appoints 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, 25 Jun 2020 11:23:22 -0000 --Apple-Mail-5562ACE1-83C6-4CC3-9537-8B61B19EB46C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 25/06/2020, at 8:58 PM, Adrian Farrel wrote: >=20 > =EF=BB=BF >>=20 >>> C. Who recruits/interviews/selects/appoints the RSE? >>=20 >> This is currently specified in RFC 8728 section 3.1 >>=20 >> Just a reminder that there is no documented statement that explains why > that existing process needs to be replaced. >=20 > Just cos it is in an RFC doesn't mean it can't be changed. >=20 > Our charter is: > | This program is intended to foster discussion and consensus on > | potential changes to the RFC Editor model. Discussion of changes > | to how the RFC Editor function is managed, staffed, and overseen > | are all within scope. After the group has come to rough consensus, > | it will document its output in one or more RFCs. >=20 > I read that as meaning that discussing this point is within scope. >=20 > The lack of a "documented statement" explaining why change is necessary is= a > good observation. Change for the sake of change can lead to risky outcomes= . > On the other hand, exploring the current process and its results and > stresses could lead us to determine that there is a need for change. >=20 > We might end up with a statement that "the process for selecting and hirin= g > the RSE is as described in Section 3.1 of RFC 8728." But we might now. As > has been pointed out (plenty) if what we do results in the RSOC going away= > or changing considerably, then that section of that RFC will not hold. >=20 > But in any case, and to reiterate, what we are doing is looking at the > process and responsibilities. Saying that they are already documented in a= n > existing RFC is useful historical information, but does not dictate our > discussions of the future, nor preform our consensus. I hope it is clear that=E2=80=99s not what I meant. And in case my pushing o= f this point is giving the impression that I favour the status quo, I should= be clear that I have no view one way or the other.=20 What I was trying to say is that a lot of work has gone into answering some o= f these questions already documented as community consensus and I would sugg= est that means that a clear reason needs to be given as to why a change is n= eeded. Even now the only explanation I=E2=80=99ve heard as to why a structur= al change is needed is because there is a view that that any community body c= harged with oversight will inevitably get too far into the details and inter= fere with the autonomy of the role, which I find a particularly weak argumen= t. In fact there=E2=80=99s nothing I=E2=80=99ve heard about the history to d= ate, which is what is driving all of this, that could not be equally explain= ed by a breakdown between people, as by a breakdown of the structure.=20 Jay --=20 Jay Daley IETF Executive Director > Thanks, > Adrian >=20 --Apple-Mail-5562ACE1-83C6-4CC3-9537-8B61B19EB46C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On 25/06/2020, at 8:58 PM, Adr= ian Farrel <adrian@olddog.co.uk> wrote:

=EF=BB=BF
C. Who recruits/interviews/selects/appoints th= e RSE?
<= /span>
This is currently spe= cified in RFC 8728 section 3.1

Just a rem= inder that there is no documented statement that explains why
that existing process needs to be replaced.
<= /span>
Just cos it is in an RFC doesn't mean it can't be changed.

Our charter is:
| This progr= am is intended to foster discussion and consensus on
| poten= tial changes to the RFC Editor model.  Discussion of changes
= | to how the RFC Editor function is managed, staffed, and overseen
| are all within scope.  After the group has come to rough= consensus,
| it will document its output in one or more RFC= s.

I read that as meaning that discussing t= his point is within scope.

The lack of a "d= ocumented statement" explaining why change is necessary is a
good observation. Change for the sake of change can lead to risky outcomes.=
On the other hand, exploring the current process and its re= sults and
stresses could lead us to determine that there is a= need for change.

We might end up with a st= atement that "the process for selecting and hiring
the RSE i= s as described in Section 3.1 of RFC 8728." But we might now. As
<= span>has been pointed out (plenty) if what we do results in the RSOC going a= way
or changing considerably, then that section of that RFC w= ill not hold.

But in any case, and to reite= rate, what we are doing is looking at the
process and respon= sibilities. Saying that they are already documented in an
ex= isting RFC is useful historical information, but does not dictate our=
discussions of the future, nor preform our consensus.

I hope it is clear that=E2=80=99s not w= hat I meant. And in case my pushing of this point is giving the impression t= hat I favour the status quo, I should be clear that I have no view one way o= r the other. 

What I was trying to say is that= a lot of work has gone into answering some of these questions already docum= ented as community consensus and I would suggest that means that a clear rea= son needs to be given as to why a change is needed. Even now the only explan= ation I=E2=80=99ve heard as to why a structural change is needed is because t= here is a view that that any community body charged with oversight will inev= itably get too far into the details and interfere with the autonomy of the r= ole, which I find a particularly weak argument. In fact there=E2=80=99s noth= ing I=E2=80=99ve heard about the history to date, which is what is driving a= ll of this, that could not be equally explained by a breakdown between peopl= e, as by a breakdown of the structure. 

Jay

-- 
Jay Daley
IETF Executive Director
=
Thanks,Adrian

= --Apple-Mail-5562ACE1-83C6-4CC3-9537-8B61B19EB46C-- From nobody Thu Jun 25 04:45: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 CD1213A0926 for ; Thu, 25 Jun 2020 04:45:42 -0700 (PDT) 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=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 0oHri2ddN6Vn for ; Thu, 25 Jun 2020 04:45:37 -0700 (PDT) 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 60F4A3A0958 for ; Thu, 25 Jun 2020 04:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1924; q=dns/txt; s=iport; t=1593085537; x=1594295137; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=MswJZJ+pfwv6M0JLax67J02girLFoleG6OZIQF2sBsc=; b=GeQ1/Vpl120PnbF8SQ8o9MqKk4iPJxkm/J4p8+D26kDoT2UVOVrPH3eQ PApMx7OaY03TzYGtYiy35GMFWmVHOWpeJ70NPkn4qDnLFrWOT8EorIZgd S+Xz1rzq/NpmORbp7Kbwxz6iuwmRAVBCEmY8lbxtnwFI72PZPlIOq332B 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BoAAAujfRe/xbLJq1lGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIFKgSNSgXgBIBIsjSWHaSWTbYgUCwEBAQw?= =?us-ascii?q?BAS8EAQGERwKCHyU4EwIDAQELAQEFAQEBAgEGBG2FZ4VyAQEBAwF5BQsLBAE?= =?us-ascii?q?TLlcGExSDEoJdIK5bdIE0hVGFEIE4jH6CAIE4DBCCTT6IBIItBLRqgmWDA5Y?= =?us-ascii?q?vAx2RDY12rDqDTwIEBgUCFYFqIoFWMxoIGxVlAYI+PhIZDZxnPwMwNwIGCAE?= =?us-ascii?q?BAwmRUwEB?= X-IronPort-AV: E=Sophos; i="5.75,279,1589241600"; d="scan'208,217"; a="27431435" 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; 25 Jun 2020 11:45:33 +0000 Received: from [10.61.216.251] ([10.61.216.251]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 05PBjVK7027781 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Jun 2020 11:45:33 GMT From: Eliot Lear Message-Id: <02338057-A77D-458C-88D4-32911AC58F0B@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_60C5676E-4EDA-4607-BAB4-5630C920DBF9" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 25 Jun 2020 13:45:31 +0200 In-Reply-To: Cc: Adrian Farrel , rfced-future@iab.org, Brian Rosen To: Jay Daley References: <066a01d64ace$d1669e10$7433da30$@olddog.co.uk> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.216.251, [10.61.216.251] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] Hires/contracts/selects/nominates/appoints 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, 25 Jun 2020 11:45:43 -0000 --Apple-Mail=_60C5676E-4EDA-4607-BAB4-5630C920DBF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Jay, > On 25 Jun 2020, at 13:23, Jay Daley wrote: >=20 >=20 > What I was trying to say is that a lot of work has gone into answering = some of these questions already documented as community consensus and I = would suggest that means that a clear reason needs to be given as to why = a change is needed. --Apple-Mail=_60C5676E-4EDA-4607-BAB4-5630C920DBF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Jay,

On 25 Jun 2020, at 13:23, Jay Daley <jay@ietf.org> = wrote:


What I was trying to say is that a lot of work has gone into = answering some of these questions already documented as community = consensus and I would suggest that means that a clear reason needs to be = given as to why a change is needed.

= --Apple-Mail=_60C5676E-4EDA-4607-BAB4-5630C920DBF9-- From nobody Thu Jun 25 04:55:20 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 A1FC23A0963 for ; Thu, 25 Jun 2020 04:55:19 -0700 (PDT) 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=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 VK4W6DCmMAug for ; Thu, 25 Jun 2020 04:55:17 -0700 (PDT) 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 55DB13A0964 for ; Thu, 25 Jun 2020 04:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2744; q=dns/txt; s=iport; t=1593086117; x=1594295717; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=oSjhc+1olVJAsVz/Wa2oK2txC7oTDeFyuFgDA4kKKg4=; b=i4j/xJMp5UTp7YND/+NuXtNmzBdVw8qvtxPFcyg4xAJxmC5c4FwZ8sNr NiSqo/YZDu5mdEyRp7BvvvBr6IEZCDsenSjf52P54buwC3ngzybWzGcnE RCqIUh1i/2yfBpKe27B9We7Cgw5N+BSG91gOPnDjkc6TVXxXsYUpzcp7F I=; X-IPAS-Result: =?us-ascii?q?A0B1AADyj/Re/xbLJq1fGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBggqBI1KBeAEgEiyEMIkBiBGTbYgUCwEBAQwBAS8EAQGERwKCJ?= =?us-ascii?q?CU4EwIDAQEBAwIDAQEBAQUBAQECAQYEbYVnhW4BAQEDASNWBQsLBBQqAgJXB?= =?us-ascii?q?hMUgxKCXSCsDHaBMoVRhRiBOIx+ggCBOByCTT6HUTOCLQSkH5BPgmWDBJYzA?= =?us-ascii?q?x2RD417rEGDUAIEBgUCFYFqIoFWMxoIGxVlAYI+PhIZDZxmPwMwNwIGAQcBA?= =?us-ascii?q?QMJkRkBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos; i="5.75,279,1589241600"; d="scan'208,217"; a="24994589" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Jun 2020 11:55:13 +0000 Received: from [10.61.216.251] ([10.61.216.251]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 05PBtCJm030329 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Jun 2020 11:55:13 GMT From: Eliot Lear Message-Id: <6EB6D191-C012-4DA4-A5E7-9F372A22E82F@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7B577D04-7D51-4C78-9C7A-53D88E01BA3A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 25 Jun 2020 13:55:12 +0200 In-Reply-To: Cc: adrian@olddog.co.uk, rfced-future@iab.org, Brian Rosen To: Jay Daley References: <066a01d64ace$d1669e10$7433da30$@olddog.co.uk> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.216.251, [10.61.216.251] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] Hires/contracts/selects/nominates/appoints 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, 25 Jun 2020 11:55:20 -0000 --Apple-Mail=_7B577D04-7D51-4C78-9C7A-53D88E01BA3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [second try] > On 25 Jun 2020, at 13:23, Jay Daley wrote: >=20 >=20 > What I was trying to say is that a lot of work has gone into answering = some of these questions already documented as community consensus and I = would suggest that means that a clear reason needs to be given as to why = a change is needed. I firmly believe this group should articulate the reasons for is = decisions. However, I do not think that necessarily means that we have = to address the previous consensus. We can do that, but we needn=E2=80=99t= . But more on this in a bit. Eliot --Apple-Mail=_7B577D04-7D51-4C78-9C7A-53D88E01BA3A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [second try]

On 25 Jun 2020, at 13:23, Jay = Daley <jay@ietf.org> = wrote:


What I was trying to say is that a lot of work has gone into = answering some of these questions already documented as community = consensus and I would suggest that means that a clear reason needs to be = given as to why a change is needed.


I firmly = believe this group should articulate the reasons for is decisions. =  However, I do not think that necessarily means that we have to = address the previous consensus.  We can do = that, but we needn=E2=80=99t.

But more on this in a bit.

Eliot


= --Apple-Mail=_7B577D04-7D51-4C78-9C7A-53D88E01BA3A-- From nobody Thu Jun 25 05:09: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 BCA203A0972; Thu, 25 Jun 2020 05:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 t0Fe-XOQjLgA; Thu, 25 Jun 2020 05:09:01 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3E83A0971; Thu, 25 Jun 2020 05:08:59 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 05PC8uTA032317; Thu, 25 Jun 2020 13:08:56 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3F8042204E; Thu, 25 Jun 2020 13:08:56 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id 2A23022042; Thu, 25 Jun 2020 13:08:56 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.26.18]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 05PC8tFb010928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Jun 2020 13:08:55 +0100 Reply-To: From: "Adrian Farrel" To: "'Jay Daley'" Cc: "'Brian Rosen'" , References: <066a01d64ace$d1669e10$7433da30$@olddog.co.uk> In-Reply-To: Date: Thu, 25 Jun 2020 13:08:53 +0100 Organization: Old Dog Consulting Message-ID: <068201d64ae9$65e61060$31b23120$@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: AQInILpaBPAwTidb8UQkmgM9jcjo8wGppVIFqDo/5RA= Content-Language: en-gb X-Originating-IP: 84.93.26.18 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-25502.007 X-TM-AS-Result: No--15.579-10.0-31-10 X-imss-scan-details: No--15.579-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25502.007 X-TMASE-Result: 10--15.579100-10.000000 X-TMASE-MatchedRID: gTucSmrmRMPxIbpQ8BhdbPHkpkyUphL9Ap+UH372RZVPvOpmjDN2kvpB HONPDWjKglywce3zy9tz9cj+XykevDLBSw8W4H2lLFqCUQ7xhcxMhH/KpYxyu6Y3y6dPFN/1jxg UEedJtNOlWSLovaX8yjAzpfFt8UMXBGjU6Ie7CGr60EgrqEjg32QBrQiRNt2I0MT4bYTRBTeF77 Xmf2kukVbuCABTdWVsAFBl9K22/FtkC6HMwfW/fnCO70QAsBdCASgfMLib25BYbPLopoBzQnjfi o/wQASev2nT42YUCSglYXMGMiHztANfHGumqsgfMpVOsYwN78OCF6GkB9h+DyvFSzw3D/Z+LM6N l+xx99ACDWQoRBOiAJnH8mBjP74nwFnvFCLI96oJGwniUXM+MxoHDks9/wM4p1jAaY8d/ZYI1bT aDMsQuyUC2vJYt/yEBrApPpprBkQisBXuM4t3RCQ7ls378/zHhU4TAl+1SpeXJOFraUQmtdiz+Z vdXgkB4abhlPGWj/kSDc//XUC7ph/A/E10d0syoxjrap5AGQsXyU2Cxtlxb4pc3JtqeiRP73+IF r8vZsXA5i7Eceu50vwnQWYq1wbMp3qd6i/vHtBBJn3aDIQ2uOs7wmCOBe+2DO+DX+rUwfbGS79z P+fUazdQQL8a25bg7uysMSfhqoRXDwaouY0y7p4CIKY/Hg3AWQy9YC5qGvybk3ZgcwPRvwzKt8/ 2P4LV33fj+sMArfOEbaqKQSlAZXhhA6E+bZjFl3Jq2AT5zkQBSvpuvu7TMLwn0/xWk1x6YbrSAY 72oB4= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Hires/contracts/selects/nominates/appoints 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, 25 Jun 2020 12:09:03 -0000 >> But in any case, and to reiterate, what we are doing is looking at = the >> process and responsibilities. Saying that they are already documented = in an >> existing RFC is useful historical information, but does not dictate = our >> discussions of the future, nor preform our consensus. > > I hope it is clear that=E2=80=99s not what I meant. Well, it wasn't to me. But I accept what you say below. > And in case my pushing of this point is giving the impression that I=20 > favour the status quo, I should be clear that I have no view one way > or the other.=20 Fair enough. > What I was trying to say is that a lot of work has gone into answering > some of these questions already documented as community consensus It is true that a lot of work and discussion went into this in the past. = But while RFC 8728 was worked on by a WG it is only an editorial update = of RFC 6635 and does not have IETF consensus. Furthermore, RFC 6635 = (published in 2012) is an IAB document and does not have IETF consensus. = And RFC 5620 (published in 2009) that was replaced by RFC 6635 was also = an IAB document and did not have IETF consensus. So, yes, a lot of work was done and that certainly attempted to bring = the community along with the decisions. But, no, none of this is = documented as community consensus. > and I would suggest that means that a clear reason needs to be given > as to why a change is needed. I agree. We should understand both why we need to make a change and what = the desired outcomes are. > Even now the only explanation I=E2=80=99ve heard > as to why a structural change is needed is because there is a view = that > that any community body charged with oversight will inevitably get too > far into the details and interfere with the autonomy of the role, = which > I find a particularly weak argument.=20 It is possible (although maybe hard to believe) that people are trying = to be delicate. Certainly, no one wants to point fingers. But let's = phrase it this way... We screwed up. The fact that an RSE that the community thought was doing = a fine job, felt that the only recourse left was to resign, is a massive = failing. I would argue that the processes in place should not have let = things get to that situation: they should have detected the conflicts = sooner, voiced them properly, established whether there was a failure of = delivery, of recruitment, of management, or of agreement with strategy, = and they should have worked for resolution. It is unclear whether a structural change is needed so that doesn't = happen again. But I see nothing that suggests it would not happen again = without change. Whether the change is minor (such as watch the watchmen = [pardon the gender specificity]), more significant (like how the = watchmen are appointed), or more fundamental (like a change in = structure) can be debated. > In fact there=E2=80=99s nothing I=E2=80=99ve heard about the history = to date, which > is what is driving all of this, that could not be equally explained by > a breakdown between people, as by a breakdown of the structure.=20 That last point bothers me. It is possible that you and I are hearing = different versions of history: history is very subjective and we learn = it from our echo chambers. But please don't misread the level of = distress in some quarters of the community about how we got here and why = we even need this program. (On the flip side, I would cheerfully concede = that the bulk of the community simply want accessible RFCs published in = a readable format in a timely manner.) Best, Adrian From nobody Thu Jun 25 05:37: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 90CA43A0A19 for ; Thu, 25 Jun 2020 05:36:48 -0700 (PDT) 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 vUYSsar5WtoQ for ; Thu, 25 Jun 2020 05:36:47 -0700 (PDT) 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 0F6883A0997 for ; Thu, 25 Jun 2020 05:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1671; q=dns/txt; s=iport; t=1593088607; x=1594298207; h=from:content-transfer-encoding:mime-version:subject: message-id:date:to; bh=5thLCWr3ypnqlZpSTipk/Hoa01bs0AGvbSHzJpvlvFI=; b=WgAGaNWcImRUyyEeYXCxzJ88fFF2WvYwlUXegMmBWVi2R46eqyTliLX+ wj7HD29bN2TOIim5QLkzdOout+bNiUJMoNTBdTx3mzQHdfKXDHgycCUJZ iICMvoGXPsTWilaiWkzXFD31LATicWlc/krHdwPSQu8AbhN/VfCwhAZdt A=; X-IPAS-Result: =?us-ascii?q?A0B7BgBCmfRe/xbLJq1VCoEJhTcBIBKEXIkBpBELAQEBD?= =?us-ascii?q?AEBLwQBAYZtJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgRthWeGGIELAiYCgQ2DC?= =?us-ascii?q?4J9n2OOEHaBMoVRhROBDiqMfoIAgTgcgh+EfHqCRzOCLQS0boJlgwSWMwMdk?= =?us-ascii?q?Q+Ne6xBg1ACBAYFAhWBaiKBVjMaCBsVZQGCPz0SGQ2cZj8DZwIGAQcBAQMJk?= =?us-ascii?q?RkBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.75,279,1589241600"; d="scan'208";a="24996286" 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; 25 Jun 2020 12:36:43 +0000 Received: from [10.61.216.251] ([10.61.216.251]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 05PCagDZ007237 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 25 Jun 2020 12:36:43 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.80.23.2.2\)) Message-Id: Date: Thu, 25 Jun 2020 14:36:42 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.216.251, [10.61.216.251] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] On problem statements and solutions, and incremental progress 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, 25 Jun 2020 12:36:59 -0000 The chairs are trying to identify points of agreement from which to move = forward. The point has been made that we still do not have a clear = problem statement. I would disagree and say that quite the opposite is = the case: we have identified a number of sets of goals. We now need to = organize a bit more around those goals, find out which ones there is = consensus to satisfy and which ones there is not. In his message for = the both of us, Brian tried to establish a starting point in the = solution space that allows for discussion of which goals are met. We = expect this dialog to go on for a bit. If people would like we could start a map that indicates the goals, and = then have discussion on which we think are met by concrete structures. Also, it is more than likely that in the ensuing discussion, we will = consider some of the events of last year. We simply cannot ignore what = led us to this point - it is the proverbial elephant in the room. In so = doing, the goal is to learn from the experience, not relive it. It may = help to have a crisp somewhat-objective* summary that provides light = without too much heat. That=E2=80=99s a difficult task. Would people = like that done? It would take some time, and we=E2=80=99d like this not = to stop incremental progress on at least building a skeleton approach to = build out. The value of such a summary is that it may help us delineate = what we think what processes are appropriate to address, as opposed to = which are not. Eliot *We all have our perspectives, and it is a foregone conclusion that no = two people will completely agree on such a summary.= From nobody Thu Jun 25 12:39: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 DA3D53A0E44 for ; Thu, 25 Jun 2020 12:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gzanOR1isyw; Thu, 25 Jun 2020 12:39:16 -0700 (PDT) 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 4849B3A0FF2; Thu, 25 Jun 2020 12:39:15 -0700 (PDT) From: Jay Daley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_525369BB-77C5-4C81-AC0B-0D9ADC7260E8" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 26 Jun 2020 07:39:13 +1200 In-Reply-To: <068201d64ae9$65e61060$31b23120$@olddog.co.uk> Cc: rfced-future@iab.org, Brian Rosen To: Adrian Farrel References: <066a01d64ace$d1669e10$7433da30$@olddog.co.uk> <068201d64ae9$65e61060$31b23120$@olddog.co.uk> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Hires/contracts/selects/nominates/appoints 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, 25 Jun 2020 19:39:20 -0000 --Apple-Mail=_525369BB-77C5-4C81-AC0B-0D9ADC7260E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26/06/2020, at 12:08 AM, Adrian Farrel wrote: >=20 >>> But in any case, and to reiterate, what we are doing is looking at = the >>> process and responsibilities. Saying that they are already = documented in an >>> existing RFC is useful historical information, but does not dictate = our >>> discussions of the future, nor preform our consensus. >>=20 >> I hope it is clear that=E2=80=99s not what I meant. >=20 > Well, it wasn't to me. But I accept what you say below. >=20 >> And in case my pushing of this point is giving the impression that I=20= >> favour the status quo, I should be clear that I have no view one way >> or the other.=20 >=20 > Fair enough. >=20 >> What I was trying to say is that a lot of work has gone into = answering >> some of these questions already documented as community consensus >=20 > It is true that a lot of work and discussion went into this in the = past. But while RFC 8728 was worked on by a WG it is only an editorial = update of RFC 6635 and does not have IETF consensus. Furthermore, RFC = 6635 (published in 2012) is an IAB document and does not have IETF = consensus. And RFC 5620 (published in 2009) that was replaced by RFC = 6635 was also an IAB document and did not have IETF consensus. >=20 > So, yes, a lot of work was done and that certainly attempted to bring = the community along with the decisions. But, no, none of this is = documented as community consensus. Ah, my mistake - thank you for explaining that. >=20 >> and I would suggest that means that a clear reason needs to be given >> as to why a change is needed. >=20 > I agree. We should understand both why we need to make a change and = what the desired outcomes are. >=20 >> Even now the only explanation I=E2=80=99ve heard >> as to why a structural change is needed is because there is a view = that >> that any community body charged with oversight will inevitably get = too >> far into the details and interfere with the autonomy of the role, = which >> I find a particularly weak argument.=20 >=20 > It is possible (although maybe hard to believe) that people are trying = to be delicate. Certainly, no one wants to point fingers. But let's = phrase it this way... >=20 > We screwed up. The fact that an RSE that the community thought was = doing a fine job, felt that the only recourse left was to resign, is a = massive failing. I would argue that the processes in place should not = have let things get to that situation: they should have detected the = conflicts sooner, voiced them properly, established whether there was a = failure of delivery, of recruitment, of management, or of agreement with = strategy, and they should have worked for resolution. That is a great problem statement. >=20 > It is unclear whether a structural change is needed so that doesn't = happen again. But I see nothing that suggests it would not happen again = without change. Whether the change is minor (such as watch the watchmen = [pardon the gender specificity]), more significant (like how the = watchmen are appointed), or more fundamental (like a change in = structure) can be debated. >=20 >> In fact there=E2=80=99s nothing I=E2=80=99ve heard about the history = to date, which >> is what is driving all of this, that could not be equally explained = by >> a breakdown between people, as by a breakdown of the structure.=20 >=20 > That last point bothers me. It is possible that you and I are hearing = different versions of history: history is very subjective and we learn = it from our echo chambers. But please don't misread the level of = distress in some quarters of the community about how we got here and why = we even need this program. (On the flip side, I would cheerfully concede = that the bulk of the community simply want accessible RFCs published in = a readable format in a timely manner.) I don=E2=80=99t mean to belittle the concerns that people have about = what has happened, only separate out the distress from the facts, which = I think your problem statement above has done very well. Jay >=20 > Best, > Adrian >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_525369BB-77C5-4C81-AC0B-0D9ADC7260E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 26/06/2020, at 12:08 AM, Adrian Farrel <adrian@olddog.co.uk>= wrote:

But in any case, and to reiterate, what we are doing is = looking at the
process and responsibilities. Saying that = they are already documented in an
existing RFC is useful = historical information, but does not dictate our
discussions= of the future, nor preform our consensus.

I hope it is clear that=E2=80=99s not what I meant.

Well, it wasn't to me. But I = accept what you say below.

And in case my pushing of this point is giving = the impression that I
favour the status quo, I should be = clear that I have no view one way
or the other.

Fair enough.

What I was trying to say = is that a lot of work has gone into answering
some of = these questions already documented as community consensus

It is true that a lot of work and = discussion went into this in the past. But while RFC 8728 was worked on = by a WG it is only an editorial update of RFC 6635 and does not have = IETF consensus. Furthermore, RFC 6635 (published in 2012) is an IAB = document and does not have IETF consensus. And RFC 5620 (published in = 2009) that was replaced by RFC 6635 was also an IAB document and did not = have IETF consensus.

So, yes, a lot of work = was done and that certainly attempted to bring the community along with = the decisions. But, no, none of this is documented as community = consensus.

Ah, my mistake - thank you for explaining = that.


and I would suggest that means that a clear reason needs to = be given
as to why a change is needed.

I agree. We should understand = both why we need to make a change and what the desired outcomes are.

Even now = the only explanation I=E2=80=99ve heard
as to why a = structural change is needed is because there is a view that
that any community body charged with oversight will = inevitably get too
far into the details and interfere with = the autonomy of the role, which
I find a particularly weak = argument.

It is possible = (although maybe hard to believe) that people are trying to be delicate. = Certainly, no one wants to point fingers. But let's phrase it this = way...

We screwed up. The fact that an RSE = that the community thought was doing a fine job, felt that the only = recourse left was to resign, is a massive failing. I would argue that = the processes in place should not have let things get to that situation: = they should have detected the conflicts sooner, voiced them properly, = established whether there was a failure of delivery, of recruitment, of = management, or of agreement with strategy, and they should have worked = for resolution.

That is a great problem statement.


It is unclear whether a = structural change is needed so that doesn't happen again. But I see = nothing that suggests it would not happen again without change. Whether = the change is minor (such as watch the watchmen [pardon the gender = specificity]), more significant (like how the watchmen are appointed), = or more fundamental (like a change in structure) can be debated.


In fact there=E2=80=99s = nothing I=E2=80=99ve heard about the history to date, which
is what is driving all of this, that could not be equally = explained by
a breakdown between people, as by a breakdown = of the structure.

That last = point bothers me. It is possible that you and I are hearing different = versions of history: history is very subjective and we learn it from our = echo chambers. But please don't misread the level of distress in some = quarters of the community about how we got here and why we even need = this program. (On the flip side, I would cheerfully concede that the = bulk of the community simply want accessible RFCs published in a = readable format in a timely manner.)

I = don=E2=80=99t mean to belittle the concerns that people have about what = has happened, only separate out the distress from the facts, which I = think your problem statement above has done very well.

Jay


Best,
Adrian

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

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

= --Apple-Mail=_525369BB-77C5-4C81-AC0B-0D9ADC7260E8-- From nobody Thu Jun 25 12:57:47 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 D2D923A100D; Thu, 25 Jun 2020 12:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id albwffLrkT3s; Thu, 25 Jun 2020 12:57:30 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6793A1014; Thu, 25 Jun 2020 12:57:29 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.29.82]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 05PJvHAu008506 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jun 2020 12:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1593115049; x=1593201449; i=@elandsys.com; bh=t7j93RHH1sSCnDcz4nbWDxcP9wMndq2WGmwQX9yH+E8=; h=Date:To:From:Subject:In-Reply-To:References; b=lhMe5saqV/8ho+qn80K3o6VGsxSdR12MnQCrL/LbwndeTs30f0WQWG4c9inMi/9NL Wsp6kie9oEpgZsmNtBfFT9X6ZHAoafanOO982WheV4wjR8ui7e5F9tVd+YrOv9wggT Z2mMA4555RdHhdZ3L+588l13vOTO8zBcIPrKMWF8= Message-Id: <6.2.5.6.2.20200625105710.106494b8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 25 Jun 2020 12:25:57 -0700 To: Jay Daley , rfced-future@iab.org From: S Moonesamy In-Reply-To: References: <066a01d64ace$d1669e10$7433da30$@olddog.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Rfced-future] Hires/contracts/selects/nominates/appoints 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, 25 Jun 2020 19:57:46 -0000 Dear Mr Daley, At 04:23 AM 25-06-2020, Jay Daley wrote: >What I was trying to say is that a lot of work has gone into >answering some of these questions already documented as community >consensus and I would suggest that means that a clear reason needs >to be given as to why a change is needed. Even now the only >explanation I've heard as to why a structural change is needed is >because there is a view that that any community body charged with >oversight will inevitably get too far into the details and interfere >with the autonomy of the role, which I find a particularly weak >argument. In fact there's nothing I've heard about the history to >date, which is what is driving all of this, that could not be >equally explained by a breakdown between people, as by a breakdown >of the structure. I'll disclose that I am a member of the ISEB. I took at the RFC which was published for informational purposes. The document included a change to describe the relationship between the IETF Administration Limited Liability Company (IETFALLC) and the RFC Series Oversight Committee (RSOC). It is not a community consensus document. There is also the following: "For this type of responsibility, the RSE cooperates closely with the community, and operates under oversight of the RSOC: thus, ultimately, under oversight of the IAB." The IAB/RSOC/IETFALLC were unable to ensure the stability of the RFC Editor function. The IAB ended up being held accountable for that. Based on the past mailing list discussions, I would say that the persons who commented were not receptive to the comments from the RSOC. During an IETF meeting, the description of the model (or structure) was that of a complex system or device whose internal workings are hidden or not readily understood. I was a bit surprised to hear that there wasn't any formal Stream coordination. Does the RSE discuss with the RSOC or the IAB to clarify a significant issue? Is it that useful to have that number of entities for the RFC Editor? Regards, S. Moonesamy From nobody Thu Jun 25 15:54: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 275BC3A0CCC; Thu, 25 Jun 2020 15:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVbgLSROf4Cs; Thu, 25 Jun 2020 15:54:47 -0700 (PDT) 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 DC6C13A081D; Thu, 25 Jun 2020 15:54:46 -0700 (PDT) From: Jay Daley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_49A4547E-4C57-4CD9-8C8D-A42DED238705" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 26 Jun 2020 10:54:44 +1200 In-Reply-To: Cc: rfced-future@iab.org To: Eliot Lear References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] On problem statements and solutions, and incremental progress 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, 25 Jun 2020 22:54:49 -0000 --Apple-Mail=_49A4547E-4C57-4CD9-8C8D-A42DED238705 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26/06/2020, at 12:36 AM, Eliot Lear = wrote: >=20 > The chairs are trying to identify points of agreement from which to = move forward. The point has been made that we still do not have a clear = problem statement. I would disagree and say that quite the opposite is = the case: we have identified a number of sets of goals. We now need to = organize a bit more around those goals, find out which ones there is = consensus to satisfy and which ones there is not. In his message for = the both of us, Brian tried to establish a starting point in the = solution space that allows for discussion of which goals are met. We = expect this dialog to go on for a bit. >=20 > If people would like we could start a map that indicates the goals, = and then have discussion on which we think are met by concrete = structures. >=20 > Also, it is more than likely that in the ensuing discussion, we will = consider some of the events of last year. We simply cannot ignore what = led us to this point - it is the proverbial elephant in the room. In so = doing, the goal is to learn from the experience, not relive it. It may = help to have a crisp somewhat-objective* summary that provides light = without too much heat. That=E2=80=99s a difficult task. Would people = like that done? It=E2=80=99s important that any new structure does not lead to the same = problems as the structure it replaces and the best way to ensure that is = to have a framework that any proposed new structure can be assessed = against. Perhaps tackling it that way - by directly asking for elements = of an assessment framework - can get the result while avoiding the pain. Jay > It would take some time, and we=E2=80=99d like this not to stop = incremental progress on at least building a skeleton approach to build = out. The value of such a summary is that it may help us delineate what = we think what processes are appropriate to address, as opposed to which = are not. >=20 > Eliot > *We all have our perspectives, and it is a foregone conclusion that no = two people will completely agree on such a summary. > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_49A4547E-4C57-4CD9-8C8D-A42DED238705 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 26/06/2020, at 12:36 AM, Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:

The = chairs are trying to identify points of agreement from which to move = forward.  The point has been made that we still do not have a clear = problem statement.  I would disagree and say that quite the = opposite is the case: we have identified a number of sets of goals. =  We now need to organize a bit more around those goals, find out = which ones there is consensus to satisfy and which ones there is not. =  In his message for the both of us, Brian tried to establish a = starting point in the solution space that allows for discussion of which = goals are met.  We expect this dialog to go on for a bit.

If people would like we could start a map that = indicates the goals, and then have discussion on which we think are met = by concrete structures.

Also, it is more = than likely that in the ensuing discussion, we will consider some of the = events of last year. We simply cannot ignore what led us to this point - = it is the proverbial elephant in the room.  In so doing, the goal = is to learn from the experience, not relive it.  It may help to = have a crisp somewhat-objective* summary that provides light without too = much heat.  That=E2=80=99s a difficult task.  Would people = like that done?

It=E2=80=99s important that any new structure does = not lead to the same problems as the structure it replaces and the best = way to ensure that is to have a framework that any proposed new = structure can be assessed against.  Perhaps tackling it that way - = by directly asking for elements of an assessment framework - can get the = result while avoiding the pain.

Jay

 It would take some = time, and we=E2=80=99d like this not to stop incremental progress on at = least building a skeleton approach to build out. The value of such a = summary is that it may help us delineate what we think what processes = are appropriate to address, as opposed to which are not.
Eliot
*We all have our perspectives, and it is = a foregone conclusion that no two people will completely agree on such a = summary.
--
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

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

= --Apple-Mail=_49A4547E-4C57-4CD9-8C8D-A42DED238705-- From nobody Thu Jun 25 16:44:53 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 28DDA3A107B for ; Thu, 25 Jun 2020 16:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQxN_qoeTlxn for ; Thu, 25 Jun 2020 16:44:50 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97693A1053 for ; Thu, 25 Jun 2020 16:44:50 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id z5so4105173pgb.6 for ; Thu, 25 Jun 2020 16:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bvkrYwb1MrXSSQMYGXMhxIVrzgw3ZznZdATNNg0kVzY=; b=gI5sPjrC1hyK35sO3KW0uioRS1QijmqsmlLitkUevm9yhsLKPeriKFZRBsQWS6UDtf PXeYO5cyokUqPTdbl9SCEEZ6xzW/vkE+Jyo2EjHx9YUFqjTgJWAJ/DVrXWOB6nzpF1Wp ZmGevECEdAGDrJG9ZTVUgBNOY772ky9JpMkqrjF7+5CixPA1BYolokEdmJGVqPMcJ3R5 ZlRbxqUXbJ1j6b8WzXl6S8w5uUpl1ueUnNa8ACJQLz5Sn5TH0evwJsXxL491pZEjepYf Ygr43GK2zH7D55f3xbVqAhKkWWnzVwwe/NBq4tPKKJ65qHVeTgVmrt9wSk8Ggz2191W9 1E/g== 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=bvkrYwb1MrXSSQMYGXMhxIVrzgw3ZznZdATNNg0kVzY=; b=M2uycb22tHONNjZjlIyUIMybbu7YHZf6RyKFwIEbl6HyxGTPvH2hfbHUKmgMGIkZzn h11yWeXxDwkMOmo5fiKdvKd05izRI1mg0d4wAXz5zvq9CDqxcdc71iyRnCLn3SJ3f0Hc KFQHHgXbPZwuHko0KLEAQ6Yf4P1Ql/VvgB2mOqAjlwhVkedZbB8jsWdavvZWdBFXGJE7 GHd4QZ74epJ/C2cWYhSGKgwgS9++luUV6F6frtYq13XeIAJYM7H+X/pVtu3uQy4f12m/ sTBW0u2hUnzokAN7KSkH+c7cSw5i9e8fg07v/9BNq7txCYHN+aDbzHHJ9KBq+MJDaiwQ JWUQ== X-Gm-Message-State: AOAM533Hn31krfrm23Bl4zNrqSONWxkSSj/S8n1KwsKtPp5aam3yY38+ X7ZwrKhQkdDTvTTf67huPNCspr/a X-Google-Smtp-Source: ABdhPJz4kk4VX2/GlnoqqPbOpvRT7CRUDrVpjClFZKpVcclPzpyr7FtdiXfJWb4mEOos3OOzER8qBw== X-Received: by 2002:a63:ff52:: with SMTP id s18mr287201pgk.203.1593128689767; Thu, 25 Jun 2020 16:44:49 -0700 (PDT) Received: from [192.168.178.20] (235.209.69.111.dynamic.snap.net.nz. [111.69.209.235]) by smtp.gmail.com with ESMTPSA id s36sm20855850pgl.35.2020.06.25.16.44.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2020 16:44:49 -0700 (PDT) To: Colin Perkins , Brian Rosen Cc: rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> From: Brian E Carpenter Message-ID: <289efd0c-a645-3ff9-242f-cbd0548cfbd8@gmail.com> Date: Fri, 26 Jun 2020 11:44:46 +1200 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: [Rfced-future] Publication vetos [Scope and IETF 108 proposals] 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, 25 Jun 2020 23:44:52 -0000 On 25-Jun-20 20:27, Colin Perkins wrote: =2E.. >> 7. Can the RSE decide to not publish a document one of the stream edit= ors forwards to it? If so, on what grounds? >> I sense that we=E2=80=99re close on this, but details matter. I sense= that there is support to allow the RSE to hold up a document if the RSE = doesn=E2=80=99t feel that it is readable, but that that control is fairly= limited. =20 >=20 > I=E2=80=99d argue that the RSE should be able to push back, perhaps qui= te strongly, and say =E2=80=9Cthis is too poorly written to publish=E2=80= =9D, but ultimately the RSE should not have a veto on editorial grounds. I think it's a bit more subtle. The pushback, when it happens, is more li= ke "this is too poorly written for the RPC to be able to copy-edit it eff= ectively". In other words, the authors need to get it turned into compreh= ensible, if faulty, English. It's a case that amounts to a failure by the= stream manager - such a draft should never have got near the RFC Editor = in the first place. So this really is an RPC issue, not an RSE issue. =20 > I=E2=80=99d argue that the RSE does not have the right to veto publicat= ion on technical grounds. If they object on such grounds they can comment= , and appeal against publication, in the same way as any other member of = the community, but have no special right as RFC Editor. Agreed. Except possibly the right to include a disclaimer.=20 > I=E2=80=99d argue that there should be a policy defining what is inappr= opriate content for the RFC series (e.g., hate speech, obscenity, indecen= cy, etc.), how it should be handled, and when/if the RSE can refuse publi= cation on such grounds. That seems like something to be agreed between th= e RSE and the community in some consensus document. Sure, so not an issue for this group, except to note it. > There will certainly be legal restrictions on what the RFC series can p= ublish. The community needs to understand those. Ditto. Regards Brian C From nobody Thu Jun 25 17:02: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 AA02C3A1078 for ; Thu, 25 Jun 2020 17:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1j1DEsuYG95 for ; Thu, 25 Jun 2020 17:02:17 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 71E193A106E for ; Thu, 25 Jun 2020 17:02:17 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id s14so3545198plq.6 for ; Thu, 25 Jun 2020 17:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=QmuyTIetmpi3KW6RZ5/+yO06/DcdzWN9NE130TIccyg=; b=cOW6BLwAvfKrtSqtAbwdWhi1n5p7PYtgrxMQdWkcdrcF0wx9tg2YFFs7q1sijszO7I 738nblvVf+VccyXcf9mrBbVX/UOZJSWbfmwCpyzLKOHRj3lAHXsTojWB6V4eUd6L5KIJ edkVVC+zAxywE7ZtXy17hp0UwVwKoieS86fx/EHH5zJf/4PxaBZp1Pej4O6WbXGLKxEv vTP1mVCvsVL03JZcpQsrd5WH57hf07ZEnjyw7cayqE1Y330JPkElc/c9NypyotTErctx uua34HBxZa9As0ZZmDX5a5eStv5AzxUTxEh27rkExIN4FUkZgPVKU2G4o7iaIUi9Ujt1 cxWg== 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=QmuyTIetmpi3KW6RZ5/+yO06/DcdzWN9NE130TIccyg=; b=lI0MRtG4BADU4WRi42Pk/5QEn7+yEZXFQRV1m/pwSZnOVQzMya8iaK0rWM0TSU0/iJ ilPBUzf11jghNz1rAiy+5ugwzr3WZehYs4+mxOfVfAeiSH6boKC/CiQ4pMDftTGtNtYQ xwRA1iMUmp4NPUTgAMbUhuAxOPczv/K1AP3gSsIL8LsN/C7QUHHbM5vUIHKP0+33K1WT kWr022jN6aye+1y9xFhoCOSMktws9Qjrwg5ox4IaqPrQRSAAQ/lgcfGr8OTtSI+hb+ux E3eQn5133NqwK2CQqUZKJkU3EY9BdUwq9fbJyyY7p5+511KjvrCEahbumj2IULEOg0OH R98Q== X-Gm-Message-State: AOAM53049Hu9hF1POqBXNQte9ALSEJbNrH2kmkScTSogFsCdlhNt/3ru x2JGLdmkBdNLa12K/0cGFHP5e0n8 X-Google-Smtp-Source: ABdhPJx90rnGz65hOeEOtjKAptgYYAWyBwUL3baDfeZd7cOR+zC9KBWkVISn3VlXjGXGjyx2hR9Mqg== X-Received: by 2002:a17:90a:65c5:: with SMTP id i5mr495594pjs.155.1593129736593; Thu, 25 Jun 2020 17:02:16 -0700 (PDT) Received: from [192.168.178.20] (235.209.69.111.dynamic.snap.net.nz. [111.69.209.235]) by smtp.gmail.com with ESMTPSA id u200sm8511075pfc.43.2020.06.25.17.02.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2020 17:02:15 -0700 (PDT) To: S Moonesamy , Peter Saint-Andre , rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <6.2.5.6.2.20200625010100.0d621478@elandnews.com> From: Brian E Carpenter Message-ID: Date: Fri, 26 Jun 2020 12:02:13 +1200 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: <6.2.5.6.2.20200625010100.0d621478@elandnews.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] "oversees" [was Scope and IETF 108 proposals] 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, 26 Jun 2020 00:02:19 -0000 On 25-Jun-20 21:18, S Moonesamy wrote: > Hi Brian, Peter, > At 04:14 PM 24-06-2020, Brian E Carpenter wrote: >> On 25-Jun-20 09:21, Peter Saint-Andre wrote: >>> I've seen this claim several times; can you provide evidence for it? >> >> Just the entire history of IASA version 1 and the IAOC doing the >> work itself instead of overseeing the execution of the work. So far, >> the LLC Board is doing much better, because it's constituted as a >> Board. Also of course the recent history of the RSOC that led to >> Heather's resignation. Engineers are bad at overseeing >> non-engineering activities; we meddle in things we are no good at. >> (I don't except myself from that statement, since I was IETF Chair >> at the time that IASA was set up, and I know that I got far too >> interested in stuff that shouldn't have been my business.) > > The IAOC membership included the following: > > IETF Chair > IAB Chair, > Internet Society CEO > > If what Brian mentioned is correct, it would mean that the persons in > those positions did not understand the meaning of overseeing the > execution of the IASA work. I think we very quickly started suffering from the problems that the LLC structure was designed to solve, but at the time the priority was to get the work of the IETF Secretariat under the IETF's own control. If that meant getting directly involved, so be it. Before the IAD was employed, the IETF Chair was effectively acting as line manager for the Secretariat staff, and believe me, the IAOC/IAD structure was a major improvement on that within a couple of weeks. All the same, you are correct, right from the start the IAOC did not limit itself to oversight. As I said, engineers love to meddle. > If the RSOC did not do its work > correctly, it would mean that the IAB appointed the wrong > people. No, I think the problem was that we set up a two-headed management structure, with both the RSOC and the RSE believing they were in charge. We need to avoid that problem this time around. > One of the differences between the [IA,RS]OC and the LLC > Board is that the latter is a legal entity. I doubt that setting up > a legal entity would solve a "meddling" problem. I think we have running code proof that it has already done so. I see things working more smoothly than before, and the LLC Board is sticking to its role. > Peter asked for evidence. There isn't any information to > substantiate an assertion that the RSOC were not fulfilling the role > it was assigned. However, there is one matter; it is usually known > as soft skills. Sure. But even that can't help when there is real ambiguity about the chain of responsibility. Regards Brian C From nobody Fri Jun 26 00:24: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 EF8BF3A11A5 for ; Fri, 26 Jun 2020 00:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD_kP95S6pRX for ; Fri, 26 Jun 2020 00:24:46 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78CD3A11A4 for ; Fri, 26 Jun 2020 00:24:45 -0700 (PDT) Received: from [IPv6:2a00:ac00:0:35:2c56:4e30:d5ea:77a4] (unknown [IPv6:2a00:ac00:0:35:2c56:4e30:d5ea:77a4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 8D16F616F89; Fri, 26 Jun 2020 10:24:35 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1593156275; bh=Fqtze5mGeavDgoa4NjjiLLGbYo3ip4t/ohLaVo6JKbE=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=J3BK5XGWCrmoiOL1SiUb/hXPW0K1yKl9gy/U9hKkkX5oLWY3VpwxOrskoCBi+XBul o4RMYX+eKWRiHQlopN7XUpfJ7YCUcgTx3lCv2mdx/1e7dobDFScpGPoVoIJsqgdoP/ 4kfCUqy/SWmKd7h3bf5r+aFVBrje8r6xVHFkmvUo= From: Lars Eggert Message-Id: <1EE5DD6A-BC32-49B0-8769-299A1D7C6968@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_91BD0AEF-A852-495D-86A3-42E8204300DF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 26 Jun 2020 10:24:32 +0300 In-Reply-To: <289efd0c-a645-3ff9-242f-cbd0548cfbd8@gmail.com> Cc: Colin Perkins , Brian Rosen , rfced-future@iab.org To: Brian E Carpenter References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <289efd0c-a645-3ff9-242f-cbd0548cfbd8@gmail.com> X-MailScanner-ID: 8D16F616F89.A2B4F X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Rfced-future] Publication vetos [Scope and IETF 108 proposals] 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, 26 Jun 2020 07:24:47 -0000 --Apple-Mail=_91BD0AEF-A852-495D-86A3-42E8204300DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2020-6-26, at 2:44, Brian E Carpenter = wrote: > The pushback, when it happens, is more like "this is too poorly = written for the RPC to be able to copy-edit it effectively". In other = words, the authors need to get it turned into comprehensible, if faulty, = English. It's a case that amounts to a failure by the stream manager - = such a draft should never have got near the RFC Editor in the first = place. So this really is an RPC issue, not an RSE issue. +1 I was only stream manager for six years or so, but I cannot recall = *ever* hearing of such a case, on any stream. That puts this into the = "can be dealt with by sane people if it should ever occur" bucket, in = other words, I don't think it's worthwhile to come up with policy here. Lars --Apple-Mail=_91BD0AEF-A852-495D-86A3-42E8204300DF 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl71orAACgkQVLXDCb9w wVdyOxAAz7BQtVcWQp0dbFMdyE5o1MuI3meGRJhxLUzRNFd5KIFqqiigMPaDjQ63 Pua0i4si/U6uQ1d2q/4ewq++CCHoEa+GsqtBziUmcQj54QH59q4iYMzCXZF0Z1lK 82MKAeFaQKawmr8aduorhOLDOicLkPy1sBO3AnoVHRhLBSB/+tO7K2tp1ZVVASM2 3pjiZMDR54Vc1hKwkekkS/yUIWqrziQrrBh4lgfmOk2EKdmlxqQfnTtEJ/qKLRse VADZ8yEuo7dUtuXolovizz/iC3xpuWNtoee0sEUK5w0A6MO8koddnJb0euZb9nKQ PehKgrzFINd8nBZ3iJIoL5benY1JTr2DIxaplVzuKz0yvKjmYkibVjilNcjdTpMu l/ZginHufULYt8YbX0Q0Ey6Up1D8aszmgcmgEUaasBUNoKem3RdYSdAoI2NRcGK4 eIbQtwMINCdtwwpSHxo9GWSeR5OdwAfopIX1J8qHpSAMih96scfM/cSza/pwAmxe 9rSZ9TPYI+lFbVXRGqN54ZZ3Slk/E3SG0OXQ6gdv302s4c+1R5dZiT0hPzIeVZir glt0P2OuHxP8oL1Vnzv28XApt8eAgTz3j7qqiPUSbA6PF7PKrqhV9dIcyjysgYLX hVvTTbLowDvrEmM90X62ZpYh6180XdjxpxQjETCzr76WxBvdDIQ= =oFiZ -----END PGP SIGNATURE----- --Apple-Mail=_91BD0AEF-A852-495D-86A3-42E8204300DF-- From nobody Fri Jun 26 06:43: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 063693A0BF7 for ; Fri, 26 Jun 2020 06:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhR4Pj35ZNEc for ; Fri, 26 Jun 2020 06:43:54 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1FD3A0A5F for ; Fri, 26 Jun 2020 06:43:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A70B3300B33 for ; Fri, 26 Jun 2020 09:43:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XarKhNgsK7KD for ; Fri, 26 Jun 2020 09:43:49 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id B5DFE300B21; Fri, 26 Jun 2020 09:43:49 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <289efd0c-a645-3ff9-242f-cbd0548cfbd8@gmail.com> Date: Fri, 26 Jun 2020 09:43:51 -0400 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <289efd0c-a645-3ff9-242f-cbd0548cfbd8@gmail.com> To: Brian Carpenter X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Rfced-future] Publication vetos [Scope and IETF 108 proposals] 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, 26 Jun 2020 13:43:56 -0000 > On Jun 25, 2020, at 7:44 PM, Brian E Carpenter = wrote: >=20 > On 25-Jun-20 20:27, Colin Perkins wrote: > ... >>> 7. Can the RSE decide to not publish a document one of the stream = editors forwards to it? If so, on what grounds? >>> I sense that we=E2=80=99re close on this, but details matter. I = sense that there is support to allow the RSE to hold up a document if = the RSE doesn=E2=80=99t feel that it is readable, but that that control = is fairly limited. =20 >>=20 >> I=E2=80=99d argue that the RSE should be able to push back, perhaps = quite strongly, and say =E2=80=9Cthis is too poorly written to = publish=E2=80=9D, but ultimately the RSE should not have a veto on = editorial grounds. >=20 > I think it's a bit more subtle. The pushback, when it happens, is more = like "this is too poorly written for the RPC to be able to copy-edit it = effectively". In other words, the authors need to get it turned into = comprehensible, if faulty, English. It's a case that amounts to a = failure by the stream manager - such a draft should never have got near = the RFC Editor in the first place. So this really is an RPC issue, not = an RSE issue. My understanding is that the PRC is very reluctant to send back = documents. In my opinion, the RSE needs to help set the expectations = for both the stream managers and the RPC. >=20 >> I=E2=80=99d argue that the RSE does not have the right to veto = publication on technical grounds. If they object on such grounds they = can comment, and appeal against publication, in the same way as any = other member of the community, but have no special right as RFC Editor. >=20 > Agreed. Except possibly the right to include a disclaimer.=20 This overlaps with the above point. The distinction between editorial = and technical can be blurred if one is trying to block a document. >=20 >> I=E2=80=99d argue that there should be a policy defining what is = inappropriate content for the RFC series (e.g., hate speech, obscenity, = indecency, etc.), how it should be handled, and when/if the RSE can = refuse publication on such grounds. That seems like something to be = agreed between the RSE and the community in some consensus document. >=20 > Sure, so not an issue for this group, except to note it. +1 >=20 >> There will certainly be legal restrictions on what the RFC series can = publish. The community needs to understand those. >=20 > Ditto. +1 Russ From nobody Fri Jun 26 06:46: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 5F5B43A0C21 for ; Fri, 26 Jun 2020 06:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9CrU5_FPDJ8 for ; Fri, 26 Jun 2020 06:46:09 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6403A09AD for ; Fri, 26 Jun 2020 06:46:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8C91E300B33 for ; Fri, 26 Jun 2020 09:46:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sis8Vum5uuEx for ; Fri, 26 Jun 2020 09:46:04 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 8E42B300A01; Fri, 26 Jun 2020 09:46:04 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <1EE5DD6A-BC32-49B0-8769-299A1D7C6968@eggert.org> Date: Fri, 26 Jun 2020 09:46:06 -0400 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <5D065568-D5DD-4376-B176-9388CBF3EA57@vigilsec.com> References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <289efd0c-a645-3ff9-242f-cbd0548cfbd8@gmail.com> <1EE5DD6A-BC32-49B0-8769-299A1D7C6968@eggert.org> To: Lars Eggert X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Rfced-future] Publication vetos [Scope and IETF 108 proposals] 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, 26 Jun 2020 13:46:11 -0000 > On Jun 26, 2020, at 3:24 AM, Lars Eggert wrote: >=20 > On 2020-6-26, at 2:44, Brian E Carpenter = wrote: >> The pushback, when it happens, is more like "this is too poorly = written for the RPC to be able to copy-edit it effectively". In other = words, the authors need to get it turned into comprehensible, if faulty, = English. It's a case that amounts to a failure by the stream manager - = such a draft should never have got near the RFC Editor in the first = place. So this really is an RPC issue, not an RSE issue. >=20 > +1 >=20 > I was only stream manager for six years or so, but I cannot recall = *ever* hearing of such a case, on any stream. That puts this into the = "can be dealt with by sane people if it should ever occur" bucket, in = other words, I don't think it's worthwhile to come up with policy here. Yes, this has happened. It is infrequent, but we have seen a few = documents where the list of questions from the RPC was longer than the = Internet-Draft. Russ From nobody Fri Jun 26 10:37: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 A5B2C3A0C10 for ; Fri, 26 Jun 2020 10:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWc63X3-xEA0 for ; Fri, 26 Jun 2020 10:37:16 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:0:35:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A5CD3A0C0B for ; Fri, 26 Jun 2020 10:37:12 -0700 (PDT) Received: from [IPv6:2a00:ac00:0:35:293e:7be3:c794:4918] (unknown [IPv6:2a00:ac00:0:35:293e:7be3:c794:4918]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 68DEF610885; Fri, 26 Jun 2020 20:37:06 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1593193026; bh=FsTZjYJ7LS+Os9aXRrqGOEdJ9lmRXACnXVvLwCDwV34=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=Ud0TOHTz7Ljg3MfRy1GTcqArjWiHWCt7gJNKGm9ZFKk0YFpaWdHFy7obpSJmLHWt+ 2k1HDAxlPlm0EGTItxK+47r+WbT4BYCb+EE173oZE/2/jGxXHvLwR14Itn2HT6lMJO UDW2z4JDCML1XZCJi5rxapwFEaMJAiBr6XgEVoEU= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Lars Eggert Mime-Version: 1.0 (1.0) Date: Fri, 26 Jun 2020 20:37:03 +0300 Message-Id: References: <5D065568-D5DD-4376-B176-9388CBF3EA57@vigilsec.com> Cc: rfced-future@iab.org In-Reply-To: <5D065568-D5DD-4376-B176-9388CBF3EA57@vigilsec.com> To: Russ Housley X-MailScanner-ID: 68DEF610885.A416D X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Rfced-future] Publication vetos [Scope and IETF 108 proposals] 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, 26 Jun 2020 17:37:25 -0000 Your memory is better than mine :-) But was there ever any contention as to what the right thing to do would be?= My meta point is that I see this effort drifting in a direction where super-= detailed =E2=80=9Cguidance=E2=80=9D is desired/proposed, which I am not sure= is going to be all that helpful down the road. This particular discussion is an example of that. Even without an explicit v= eto right, an RSE can escalate to =E2=80=9Cif you make me publish this, I wi= ll walk=E2=80=9D. On the flip side, if an RSE uses an explicit veto right an= d the broader community disapproves, they can get that RSE fired. There are implicit checks and balances in place that force everyone to find m= utual agreeable solutions, without us defining an awful lot of detailed poli= cy. --=20 Sent from a mobile device; please excuse typos. > On Jun 26, 2020, at 16:46, Russ Housley wrote: >=20 > Yes, this has happened. It is infrequent, but we have seen a few document= s where the list of questions from the RPC was longer than the Internet-Draf= t. From nobody Fri Jun 26 13:11:26 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 CF45C3A0C33 for ; Fri, 26 Jun 2020 13:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkKvzdRJfn-F for ; Fri, 26 Jun 2020 13:11:23 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 6D2233A0954 for ; Fri, 26 Jun 2020 13:11:23 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id j12so5071923pfn.10 for ; Fri, 26 Jun 2020 13:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/09v+OrXvnJUdyVJIRXBh3dHVB3bHvjsdY5HOkYsrw8=; b=EIRG8q3gjpcjmPWiDln6e6ONE0d6Cl64udR5LrnD2St9Dv6hcCvzu3wD+E+e+oYnkZ iOHwx146AgIIhCDs9LWspxVNJ3FYXaE/lsO5bwtjKXfx/z8bEiYV2FtIRmgBGJOYHVvv eBdcZzwmFOty5t+JJfb5COIrzjqbrWffBVlp4HU5iPGZGCTxbvLj5FfMgcpuTEQ1X/Lg bVve+jFwUb3niJrTvvELtVCxrdZqqqoMpx+U3VDO/NYCmMSf1CaMhqjcdi21mIvOjB/I b8ItsdvScX+NEhXZ5SFGPp2b+qgjYwwN6HOvBi87ufFDvZj/tFMMaK0+CQW4TgHJwyKl NWpg== 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=/09v+OrXvnJUdyVJIRXBh3dHVB3bHvjsdY5HOkYsrw8=; b=Rb0Rcp/EN6egtpOfbJw5zzRPY8lCCOJUyhwxAZI3+bQVCzuGYcGijLZNKRsSWhZmw9 bnK+x5G9XIFqSst0CL1f5Kfuc+VGSSL1dCYRoi/FhKOaBV1awUOFU/bzaBYwVFabf+6E LlQiGB+CcM5kCuQKPw2WACy2s5iXK4uPQTctlpoh6sohSlFDoLFoZCKP1wgtc7Mdyytn LQs4m2hVGgMJ8s5u3aImHLqZcixDEhBHoqfpJzZ4p6Q3r61PN4hDFWUydgq5HddjKLzX zMJ1RhAHaBUJbVVBFvesvzBwGoxRfrGiN+IiEY8JqDg0LiPjFxKhmAk7zfYC8amtZcoA HrtA== X-Gm-Message-State: AOAM533Rp00P9RkY1EMe99zmNQIEgG6+P8pCQwrx/c4sBcEOmUhWbdh6 jW3wonOSlldzRlV6GAH0heX0F4MeN5U= X-Google-Smtp-Source: ABdhPJzLJqefzSK3RueRcPnMCzhdcaIyGCSIEzABXeBlmBz3UnoPPaQBNblyXuZJleMvQEbcoQikIw== X-Received: by 2002:a63:3d85:: with SMTP id k127mr354691pga.29.1593202282397; Fri, 26 Jun 2020 13:11:22 -0700 (PDT) Received: from [192.168.178.20] (203.90.69.111.dynamic.snap.net.nz. [111.69.90.203]) by smtp.gmail.com with ESMTPSA id t24sm23298744pgm.10.2020.06.26.13.11.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 13:11:21 -0700 (PDT) To: Russ Housley Cc: rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <289efd0c-a645-3ff9-242f-cbd0548cfbd8@gmail.com> From: Brian E Carpenter Message-ID: <2f1b297b-ace5-e307-b9ec-0112d9179102@gmail.com> Date: Sat, 27 Jun 2020 08:11:17 +1200 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] Publication vetos [Scope and IETF 108 proposals] 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, 26 Jun 2020 20:11:25 -0000 On 27-Jun-20 01:43, Russ Housley wrote: >=20 >=20 >> On Jun 25, 2020, at 7:44 PM, Brian E Carpenter wrote: >> >> On 25-Jun-20 20:27, Colin Perkins wrote: >> ... >>>> 7. Can the RSE decide to not publish a document one of the stream ed= itors forwards to it? If so, on what grounds? >>>> I sense that we=E2=80=99re close on this, but details matter. I sen= se that there is support to allow the RSE to hold up a document if the RS= E doesn=E2=80=99t feel that it is readable, but that that control is fair= ly limited. =20 >>> >>> I=E2=80=99d argue that the RSE should be able to push back, perhaps q= uite strongly, and say =E2=80=9Cthis is too poorly written to publish=E2=80= =9D, but ultimately the RSE should not have a veto on editorial grounds. >> >> I think it's a bit more subtle. The pushback, when it happens, is more= like "this is too poorly written for the RPC to be able to copy-edit it = effectively". In other words, the authors need to get it turned into comp= rehensible, if faulty, English. It's a case that amounts to a failure by = the stream manager - such a draft should never have got near the RFC Edit= or in the first place. So this really is an RPC issue, not an RSE issue. >=20 > My understanding is that the PRC is very reluctant to send back documen= ts. In my opinion, the RSE needs to help set the expectations for both t= he stream managers and the RPC. Yes, certainly. We don't want the RPC to be put in such a situation. >> >>> I=E2=80=99d argue that the RSE does not have the right to veto public= ation on technical grounds. If they object on such grounds they can comme= nt, and appeal against publication, in the same way as any other member o= f the community, but have no special right as RFC Editor. >> >> Agreed. Except possibly the right to include a disclaimer.=20 >=20 > This overlaps with the above point. The distinction between editorial = and technical can be blurred if one is trying to block a document. It can be. But there is a big difference between the RFC Editor saying "w= e cannot determine whether this text means 1 or 0, please clarify" and "w= e think this text means 0 and we think it should mean 1". The former is e= ditorial but the latter is an attempt to override the stream. Brian >> >>> I=E2=80=99d argue that there should be a policy defining what is inap= propriate content for the RFC series (e.g., hate speech, obscenity, indec= ency, etc.), how it should be handled, and when/if the RSE can refuse pub= lication on such grounds. That seems like something to be agreed between = the RSE and the community in some consensus document. >> >> Sure, so not an issue for this group, except to note it. >=20 > +1 >=20 >> >>> There will certainly be legal restrictions on what the RFC series can= publish. The community needs to understand those. >> >> Ditto. >=20 > +1 >=20 > Russ >=20 > . >=20 From nobody Fri Jun 26 13:19: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 40A303A0C33 for ; Fri, 26 Jun 2020 13:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKzsS98gHSim for ; Fri, 26 Jun 2020 13:19:01 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986273A08FB for ; Fri, 26 Jun 2020 13:19:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 26918300B58 for ; Fri, 26 Jun 2020 16:18:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uSuleo44kTz0 for ; Fri, 26 Jun 2020 16:18:57 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 99CDB300A01; Fri, 26 Jun 2020 16:18:57 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <2f1b297b-ace5-e307-b9ec-0112d9179102@gmail.com> Date: Fri, 26 Jun 2020 16:18:58 -0400 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <457F51C1-994A-47BE-9D35-222BEDBE30C0@vigilsec.com> References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <289efd0c-a645-3ff9-242f-cbd0548cfbd8@gmail.com> <2f1b297b-ace5-e307-b9ec-0112d9179102@gmail.com> To: Brian Carpenter X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Rfced-future] Publication vetos [Scope and IETF 108 proposals] 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, 26 Jun 2020 20:19:03 -0000 > On Jun 26, 2020, at 4:11 PM, Brian E Carpenter = wrote: >=20 > On 27-Jun-20 01:43, Russ Housley wrote: >>=20 >>=20 >>> On Jun 25, 2020, at 7:44 PM, Brian E Carpenter = wrote: >>>=20 >>> On 25-Jun-20 20:27, Colin Perkins wrote: >>> ... >>>>> 7. Can the RSE decide to not publish a document one of the stream = editors forwards to it? If so, on what grounds? >>>>> I sense that we=E2=80=99re close on this, but details matter. I = sense that there is support to allow the RSE to hold up a document if = the RSE doesn=E2=80=99t feel that it is readable, but that that control = is fairly limited. =20 >>>>=20 >>>> I=E2=80=99d argue that the RSE should be able to push back, perhaps = quite strongly, and say =E2=80=9Cthis is too poorly written to = publish=E2=80=9D, but ultimately the RSE should not have a veto on = editorial grounds. >>>=20 >>> I think it's a bit more subtle. The pushback, when it happens, is = more like "this is too poorly written for the RPC to be able to = copy-edit it effectively". In other words, the authors need to get it = turned into comprehensible, if faulty, English. It's a case that amounts = to a failure by the stream manager - such a draft should never have got = near the RFC Editor in the first place. So this really is an RPC issue, = not an RSE issue. >>=20 >> My understanding is that the PRC is very reluctant to send back = documents. In my opinion, the RSE needs to help set the expectations = for both the stream managers and the RPC. >=20 > Yes, certainly. We don't want the RPC to be put in such a situation. >=20 >>>=20 >>>> I=E2=80=99d argue that the RSE does not have the right to veto = publication on technical grounds. If they object on such grounds they = can comment, and appeal against publication, in the same way as any = other member of the community, but have no special right as RFC Editor. >>>=20 >>> Agreed. Except possibly the right to include a disclaimer.=20 >>=20 >> This overlaps with the above point. The distinction between = editorial and technical can be blurred if one is trying to block a = document. >=20 > It can be. But there is a big difference between the RFC Editor saying = "we cannot determine whether this text means 1 or 0, please clarify" and = "we think this text means 0 and we think it should mean 1". The former = is editorial but the latter is an attempt to override the stream. I understand the point, and I agree with it. Content should fall = squarely on the shoulders of stream managers. Russ From nobody Fri Jun 26 13:32:28 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 D00923A0C61 for ; Fri, 26 Jun 2020 13:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGYtmvYgQqnB for ; Fri, 26 Jun 2020 13:32:23 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id 81D233A0C55 for ; Fri, 26 Jun 2020 13:32:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 9EE9139F09D6 for ; Fri, 26 Jun 2020 16:32:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5n6VEvsHL1pL for ; Fri, 26 Jun 2020 16:32:21 -0400 (EDT) Received: from [192.168.50.224] (173-166-5-67-newengland.hfc.comcastbusiness.net [173.166.5.67]) by sobco.sobco.com (Postfix) with ESMTPSA id 90CFE39F09C2 for ; Fri, 26 Jun 2020 16:32:21 -0400 (EDT) From: "Scott O. Bradner" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) Date: Fri, 26 Jun 2020 16:32:20 -0400 References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <289efd0c-a645-3ff9-242f-cbd0548cfbd8@gmail.com> <2f1b297b-ace5-e307-b9ec-0112d9179102@gmail.com> To: rfced-future@iab.org In-Reply-To: <2f1b297b-ace5-e307-b9ec-0112d9179102@gmail.com> Message-Id: <2D9BFFE1-D707-477A-B453-1C87F6CDD0C9@sobco.com> X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [Rfced-future] Publication vetos [Scope and IETF 108 proposals] 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, 26 Jun 2020 20:32:28 -0000 > On Jun 26, 2020, at 4:11 PM, Brian E Carpenter = wrote: >>>=20 >>>> I=E2=80=99d argue that the RSE does not have the right to veto = publication on technical grounds. If they object on such grounds they = can comment, and appeal against publication, in the same way as any = other member of the community, but have no special right as RFC Editor. >>>=20 >>> Agreed. Except possibly the right to include a disclaimer.=20 >>=20 >> This overlaps with the above point. The distinction between = editorial and technical can be blurred if one is trying to block a = document. >=20 > It can be. But there is a big difference between the RFC Editor saying = "we cannot determine whether this text means 1 or 0, please clarify" and = "we think this text means 0 and we think it should mean 1". The former = is editorial but the latter is an attempt to override the stream. of course, this is coming that Jon did - but it is not all that likely = that the IETF (or whomever) will hire another Jon to take this role Scott= From nobody Fri Jun 26 14:09: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 3E9D93A0C80 for ; Fri, 26 Jun 2020 14:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 SKsoicJdkS8I for ; Fri, 26 Jun 2020 14:09:12 -0700 (PDT) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 A72CB3A0C7C for ; Fri, 26 Jun 2020 14:09:12 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id cv18so1829476pjb.1 for ; Fri, 26 Jun 2020 14:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=g6loBcQxP9sWntxFqncJORihDpM3oZSP2+DLEoeTtFQ=; b=ipk5EAakCrIgQoGMdtUML0zdbhR8DgIjQPeq/p0w3fl+hgB3YFTXYgjR9Ta5cKOs1T uha+PTqGfFyuk6V3ru0We1VeEPsRgd/l20qcX3yGHwcbHzPxOGah1nIcwW8BCvEf7STD 20Bt6XgR9E/+nC4wE/Z1rsMFoXnFsZzcXnWC+uHl67MZH5G7A2PF7XbvTHB+B4Bn/zRA CqBQvcpecbJ5V9caaLLK4DaMJ1l721539tKIWWDDEyvLrt5te0fpXdIUbbDK+w1W8KjR 3tZuukJvUYohWG1bAvK1uSCw2igxVutzDcqXCh+r2zanBcuCosLyR36JQAZGMz4WXmM5 7lrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=g6loBcQxP9sWntxFqncJORihDpM3oZSP2+DLEoeTtFQ=; b=eTl+/Z9GE8ZLByH+T1GQ02CeysFBhjtksDVkL2UKp9Gez0RASspR0HoYCDSSfuHUf9 CNaoPbYzoJgyjksVFq2UpU2amNxFrG6vYn2DqOSIHiPD+JlGNoksoA6KR5u9Ya6Bpj3t DRiZc2yaT0Yc6ROWIP+MKMjAbt322LwnhbQrKsI/6cywyMaadV/5NKRcg4mgBPKijjW2 sBYwEjwvCs+EFZxK/3BL1j8gLPVmZCBQ0eig+tbBWUpcwJBVx3DuSyR90XK4eorpvcmD 0YzqcPK0tZE7QVSXNSQFhdyRMrLOJl3i4QyF/aHiyd4Xdti2p1Rg+EEZn98WHkdTTQFa +utA== X-Gm-Message-State: AOAM5322tJkvE9JBIea1KBGrjBtx/HQLISi2WsOgLhynok+emDi8PxuE aL01iVRp4cVY2ym/YZCmVv0= X-Google-Smtp-Source: ABdhPJwKfYaQ3UrinzyxAQ3MqIS5fw0/l2L1o/xKPTEvFy9ZoqMzBfHuqE/kKTZJkGrf+HJmgS7MVg== X-Received: by 2002:a17:90a:c28c:: with SMTP id f12mr5485516pjt.224.1593205751801; Fri, 26 Jun 2020 14:09:11 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id y10sm27991336pfq.34.2020.06.26.14.09.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 14:09:10 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Russ Housley'" , "'Brian Carpenter'" Cc: References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <289efd0c-a645-3ff9-242f-cbd0548cfbd8@gmail.com> <2f1b297b-ace5-e307-b9ec-0112d9179102@gmail.com> <457F51C1-994A-47BE-9D35-222BEDBE30C0@vigilsec.com> In-Reply-To: <457F51C1-994A-47BE-9D35-222BEDBE30C0@vigilsec.com> Date: Fri, 26 Jun 2020 14:09:10 -0700 Message-ID: <01fb01d64bfe$09dc3090$1d9491b0$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIfX7vfh4YEKFq4ndL/BmmpAFaeUADfEvEOAPIg4FICzLTcXgBh0gxCAhNRZggCkTyBhQIsYCbhp/qpjxA= Archived-At: Subject: Re: [Rfced-future] Publication vetos [Scope and IETF 108 proposals] 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, 26 Jun 2020 21:09:15 -0000 I think if you're trying to come up with a job description for the RSE, and you want it to be someone you can hire, the more skills and tasks = and decision responsibilities you add, the harder it will be to find = someone who would take such a job or contract. >From that perspective, having the ability to resign in disgust is not a = job perquisite. So what if the relationship between the RSE and the various streams were = to change, To reduce the complexity of the task to either saying "Yes, this meets = the RFC Editor publication guidelines" or "No, it does not", with some but not = necessarily exhaustive reasons why. It could even be a TL;DR kind of review; specs that are = hundreds of pages are impossible to review.=20 Call this the RED: RFC Editor Decision. Streams can submit documents and request "No RED" and have their = document published as an RFC with a disclaimer written by the RFC editor inserted. Otherwise, the RFC will get published as is or sent back to the stream. This moves the task so that it is clear that the RFC editor doesn't have a place for technical decisions, that the responsibility for insuring clarity of the ideas goes to the streams and not the RFC Editor. More like technical journal publishing and less like book or magazine publishing. It avoids the situation where the RFC editor corrects something that seems grammatical, but winds up choosing the wrong fix. Might need to have an automated step to handle "Note to RFC Editor" = text. -- https://LarryMasinter.net https://going-remote.info From nobody Fri Jun 26 20:01: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 1DF4F3A097F for ; Fri, 26 Jun 2020 20:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1J_wFGSde0o for ; Fri, 26 Jun 2020 20:01:37 -0700 (PDT) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 51AF93A097B for ; Fri, 26 Jun 2020 20:01:37 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id s18so6513035vsi.6 for ; Fri, 26 Jun 2020 20:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=er4kgAjF5Bnvdko8AH8Xqv+9e+IVQs2HN4Bq3BmVRuU=; b=EBWQw0osc/ruVBpIM6I4/UtCWxPkqWUub4qKnuH4KfgLB/PNDSmZCyjVrgh8je6pkA cIs7Efd0oH3nSkr/6zjmNzrsfSWeuUVKL5IwOE18+PMy+057JDchLgFOLm1IxUtNZaDe 2IGUgGuSPdmqO+T5d1w1rMLnvY8e0bWDHDMYkd7XaCXzMD699xYV56LP6xFqrzq9yobl OFj1IB8Y848M+SqmidnrjXYivhalqc1TAHaV3Nn/WRvOm27YNUy7L0UApLMVe9N4QbdS VUyhhmTZxUmH98ohO8PEKJen1I/J88R64o2BqjVKFBQyDSMTBuasFFD3MBOkbJYCzMK7 xyIw== 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=er4kgAjF5Bnvdko8AH8Xqv+9e+IVQs2HN4Bq3BmVRuU=; b=j+a/GM4pi9waq71UEkc6QyzGh0zC+7Y0uphNlXLZ2kqziB9bp+FTcrf5eg3P/oNVDj CCE9i8vcCW7dyngXmsnyrXdiKHp56tjJNUzQljVkLkm8V635lgCziPIK4yRf+yht4D+E mAbt++rPNDe19KAiJD31bYWAEG+AEiBODzG2eGD+pVrkcyquKRi73dg3ui1WceadMOVE lJiHQCssXBJ95KwxGVbUZ67R0ksLBsQMrCY2wJJcjuyfTfKUemb9OwLNEJoRsCdwxxLN rgnAaVV4D56ImYrNAOccMSi5JCQ/YGtA3JuwnWc+daWB6FDFylvaO48cfn8XGyhX+Ib5 c9WQ== X-Gm-Message-State: AOAM531mQtFdw98bo8Y6VJ/Kt4y+P+xrsQ7TumXru5lRNoWVO1v+g5E4 1m0ohCr6ckUqXCf+gGjrRpmrLoWpvKVREmfEerBcffMF41Y= X-Google-Smtp-Source: ABdhPJwVdlQi7Abk5p1DIstmIkgPBgW+3/cSsOlwqynItpF3ySUIu/ENOuv12gpojMDAuKfnV3J2lpXgke7ObQY+UaQ= X-Received: by 2002:a67:6812:: with SMTP id d18mr4876671vsc.227.1593226896341; Fri, 26 Jun 2020 20:01:36 -0700 (PDT) MIME-Version: 1.0 References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> In-Reply-To: <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> From: Nevil Brownlee Date: Sat, 27 Jun 2020 15:01:09 +1200 Message-ID: To: Martin Thomson Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000033fd0205a9080bf1" Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 27 Jun 2020 03:01:39 -0000 --00000000000033fd0205a9080bf1 Content-Type: text/plain; charset="UTF-8" Hi Martin: I've updated my Internet Draft to include a suggestion of what an RSEB (RFC Series Editorial Board) could be structured. Take a look at https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html Of course, any suggestions for changes/improvements/etc to that draft are welcome :-) Cheers, Nevil On Thu, Jun 25, 2020 at 11:43 AM Martin Thomson wrote: > On Thu, Jun 25, 2020, at 07:09, Brian E Carpenter wrote: > > On 24-Jun-20 19:54, Martin Thomson wrote: > > > We don't need a single person (or contracted entity, if that includes > more than one person) to be given the task of determining strategy. If we > need a strategy to serve our community, then maybe that community should > setting and owning that strategy. Not indirectly, via an appointed > custodian, but directly. > > > > I don't understand how that would work in the absence of a group and a > > group leader to determine what the community is (since it's not the > > IETF) and what the community's rough consensus is. Who would they be? > > In my book, the RSE and the RFC Series Board. > > I don't think that is necessarily the case. > > The process that we're following has the same requirements and > challenges. It has leadership. Two leaders in fact, which is more than > twice as good as relying on a single person. It has open participation. > (I don't know what RFC Series Board is, but it implies a closed group, just > as RSE implies an individual.) > > Speaking strictly about strategy, the structure of what we have here is > just about as good as we will get in all the ways that matter. > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > -- ----------------------------------- Nevil Brownlee, Taupo, NZ --00000000000033fd0205a9080bf1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin:
I've updated my Internet Draft to i= nclude a suggestion of what an RSEB (RFC Series Editorial Board) could be s= tructured.=C2=A0 Take a look at https://www.ietf.org/id/draft-br= ownlee-rfc-series-and-rse-changes-01.html

Of c= ourse, any suggestions for changes/improvements/etc to that draft are welco= me :-)

Cheers, Nevil

On Thu, Jun 25, 2020 at 11:43 AM Martin Thomson <mt@lowentropy.net> wrote:
On Thu, Jun 25, 2020, at 07:09, Brian E = Carpenter wrote:
> On 24-Jun-20 19:54, Martin Thomson wrote:
> > We don't need a single person (or contracted entity, if that = includes more than one person) to be given the task of determining strategy= .=C2=A0 If we need a strategy to serve our community, then maybe that commu= nity should setting and owning that strategy.=C2=A0 Not indirectly, via an = appointed custodian, but directly.
>
> I don't understand how that would work in the absence of a group a= nd a
> group leader to determine what the community is (since it's not th= e
> IETF) and what the community's rough consensus is. Who would they = be?
> In my book, the RSE and the RFC Series Board.

I don't think that is necessarily the case.

The process that we're following has the same requirements and challeng= es.=C2=A0 It has leadership.=C2=A0 Two leaders in fact, which is more than = twice as good as relying on a single person.=C2=A0 It has open participatio= n.=C2=A0 (I don't know what RFC Series Board is, but it implies a close= d group, just as RSE implies an individual.)

Speaking strictly about strategy, the structure of what we have here is jus= t about as good as we will get in all the ways that matter.

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


--
-----------------------------------
Nevil Brownlee, Taupo, NZ
--00000000000033fd0205a9080bf1-- From nobody Fri Jun 26 21: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 2388F3A0B99 for ; Fri, 26 Jun 2020 21:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDYVc0gYcir2 for ; Fri, 26 Jun 2020 21:22:29 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 9C90D3A0B96 for ; Fri, 26 Jun 2020 21:22:29 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id d12so5045582ply.1 for ; Fri, 26 Jun 2020 21:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Ma07yGd2jq4+g4VRxrRKssYwwbfTo9R1QJcJZYaMMI0=; b=cl3cGSUhlxaMsCtEC+PSYpifR41B5DtKS+lClXvwOx8E2Scx/iQWWaZ/Czr3gVbklT jYRaM/rnY9qQ9CnjZQsKGviUSl6mzi9lY+hh4dZkTOiI/bgQSpQHqe7/TVR5oBVzKW6p Lfq4wBk2KgyT0IaNVXvlauDuE/ANs382obv7SeR8Mb7MrJrlvaSswcXPKY5pxdJfeAw0 NXUXrPJsT0aKGmrVEFj8NhhpMe/2nU5OLxtYYrBZfLCKGbvx9B23ZAGNBIzMKIuiwtHu FmMlE6dVOom4/HbXeBUrFzlg6Oe0A3/fL6CLVEoUywFXko+mSOPREoAJRoabgi7hOk1q AkaA== 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=Ma07yGd2jq4+g4VRxrRKssYwwbfTo9R1QJcJZYaMMI0=; b=DC+DSSPpuZ0CW3RM7ZNlsiG/S2kfD51d7QnnYW53By/6ZogLUSImo3w1c8+o356XXM 5d7R/a7TMv+i2odh0iDB1B9ssH0zS90jdfrg8cVUhNeyG8Vlf8QRhPbLtsiD1hfAaYAp CHKkWCJ80vdpwwmZ0tKUf6JzHCvG21DVDjHPCr9rcNoS61dkNHnWi+MQzduM5t41vAgB O/Rb3W/Vb2sZQA+y0BCFVZQKVWkggt2+MaqyziG1tLkEUjP12jnn+zsA102OEQ8nYz5w wxNqRc11m8UKv+3sTaa7mXgyemTIPBOoUCOsHSahigjyClWKfGbMADStTICtsJhPixU+ t4jg== X-Gm-Message-State: AOAM533CJkJpHIqNpVUAZqbEah9ZOrf8zi/6tfimSSKAjOgIWRTsfT+k xozfaSMlvVcqCT8JDlerML3Y+aycH40= X-Google-Smtp-Source: ABdhPJyqiutlU7iq9VZWZ1eYEPn/Agd8KibLT0+MsIkVbW6LO7Y87ETTPqfrL4EsrhknKnBuMqLYzA== X-Received: by 2002:a17:902:724a:: with SMTP id c10mr4915119pll.143.1593231748794; Fri, 26 Jun 2020 21:22:28 -0700 (PDT) Received: from [192.168.178.20] (203.90.69.111.dynamic.snap.net.nz. [111.69.90.203]) by smtp.gmail.com with ESMTPSA id d5sm12183783pfa.71.2020.06.26.21.22.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 21:22:28 -0700 (PDT) To: Nevil Brownlee , Martin Thomson Cc: rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> From: Brian E Carpenter Message-ID: Date: Sat, 27 Jun 2020 16:22:24 +1200 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] Scope and IETF 108 proposals 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, 27 Jun 2020 04:22:31 -0000 Hi Nevil, I noticed a few places where you typed "RSEB" instead of "RSAB"= =2E Apart from that I'm in general agreement with the proposal. Maybe it's too specific to define the community discussion venue as "the = rfc-interest list". For the breadth of community the RSAB would need to r= each, other methods of discussion may also be needed. Regards Brian On 27-Jun-20 15:01, Nevil Brownlee wrote: > Hi Martin: > I've updated my Internet Draft to include a suggestion of what an RSEB = (RFC Series Editorial Board) could be structured.=C2=A0 Take a look at ht= tps://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html >=20 > Of course, any suggestions for changes/improvements/etc to that draft a= re welcome :-) >=20 > Cheers, Nevil >=20 > On Thu, Jun 25, 2020 at 11:43 AM Martin Thomson > wrote: >=20 > On Thu, Jun 25, 2020, at 07:09, Brian E Carpenter wrote: > > On 24-Jun-20 19:54, Martin Thomson wrote: > > > We don't need a single person (or contracted entity, if that in= cludes more than one person) to be given the task of determining strategy= =2E.=C2=A0 If we need a strategy to serve our community, then maybe that = community should setting and owning that strategy.=C2=A0 Not indirectly, = via an appointed custodian, but directly. > > > > I don't understand how that would work in the absence of a group = and a > > group leader to determine what the community is (since it's not t= he > > IETF) and what the community's rough consensus is. Who would they= be? > > In my book, the RSE and the RFC Series Board. >=20 > I don't think that is necessarily the case. >=20 > The process that we're following has the same requirements and chal= lenges.=C2=A0 It has leadership.=C2=A0 Two leaders in fact, which is more= than twice as good as relying on a single person.=C2=A0 It has open part= icipation.=C2=A0 (I don't know what RFC Series Board is, but it implies a= closed group, just as RSE implies an individual.) >=20 > Speaking strictly about strategy, the structure of what we have her= e is just about as good as we will get in all the ways that matter. >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future >=20 >=20 >=20 > --=20 > ----------------------------------- > Nevil Brownlee, Taupo, NZ >=20 From nobody Sun Jun 28 16: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 18DA73A07E3 for ; Sun, 28 Jun 2020 16:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=L64r5Rgf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=G5RnZ4e5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-zUFpAkkLU8 for ; Sun, 28 Jun 2020 16:47:31 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72923A07D6 for ; Sun, 28 Jun 2020 16:47:31 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id A26488FE for ; Sun, 28 Jun 2020 19:47:30 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Sun, 28 Jun 2020 19:47:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=Uun5VwOlCfLc/O32GbG63L4R8mK/tyi srgW2lp5VeY8=; b=L64r5RgfX9vNeQGiClIYaIbZ1qlSq7i6vmD82VG8xADbjvR dSwHGZbiDsEORxtnk+G/JOMsaydQA+A48OmaTnm+f6cu7qFpkL6P0SHuFQfoaTJs XWp0r/VkW+MfylEt/BYANORss2IBVYomj3kJ3jzRKcoebdcwDeewpeZh7veFsVkZ Tfmfkw+A9ZFudMYmpuFmhSxoy6hfF9SDCgdkfUclOY1BXmosWU7AYfBLTrHPK9op RLa690amlQAsIwNS4A51mLuzI8JFXks2PlU6CvbHryPPrT0Tol/i62gWGr2VMGTe zZdzwkZpuTZ2yvolwg4MnBRHRy6MHcz2QM4ao9w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Uun5Vw OlCfLc/O32GbG63L4R8mK/tyisrgW2lp5VeY8=; b=G5RnZ4e5cooYLg/linq4VJ EBNkM0hAjRrF9qz6Le5qpVgLPcNfgIy7Yacu4yPbmjVR81JodVP2Zv+Y2nArrNsw Q0mEf6IR+Rx3D/t/HYDdLbeqdqhLETuaYLMqMVxPtPuOLnruNcnIe7MSNKhtzNKb 3WCEKSot+MYoZQ4p0q3y0dkBV+gbEJlz+xQ30kdmwuY8umLETqLa22PEZCHwbE1a S/tuokE5dAx37Hq6/WOZMIXPo4ltmn9HGGf6kB6chCxr5uRj0xIwFT4cqrI4e2qH /oXW4iwrJ/7KcMZXZXbNz60E3tt6/K8WtPeb7TLHaa28B5uvNNS/9KoTrUiaFijA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeljedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefhiedttdeviefhjeejgf evfeeuudfggfekveekheeugeegleevkeevkedthfeuieenucffohhmrghinhepihgvthhf rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E739BE00CE; Sun, 28 Jun 2020 19:47:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-543-gda70334-fm-20200618.004-gda703345 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> Date: Mon, 29 Jun 2020 09:47:08 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 28 Jun 2020 23:47:33 -0000 On Sat, Jun 27, 2020, at 13:01, Nevil Brownlee wrote: > I've updated my Internet Draft to include a suggestion of what an RSEB > (RFC Series Editorial Board) could be structured. Take a look at > https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html This is very much not what I had in mind. We should not insist on having a role that depends on finding an individual with a rare and difficult combination of attributes. And I don't think that you can support that function by taking a program with open participation and consensus processes and reduce that to 5 people (+stream manager ex officio) who are responsible for approving strategy. Perhaps you can start by explaining why you think we need to have an individual perform these functions. From nobody Sun Jun 28 16:50: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 43E973A0FBF for ; Sun, 28 Jun 2020 16:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK8QzxluoRHs for ; Sun, 28 Jun 2020 16:50:37 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E173A0F97 for ; Sun, 28 Jun 2020 16:50:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49w6nT08kbz6GD4m for ; Sun, 28 Jun 2020 16:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1593388237; bh=tVIViBvInXvmwINOo7Kv6i0AHdcoCUTRfxJcK6E74so=; h=Subject:To:References:From:Date:In-Reply-To:From; b=R3UICh2TCiIUZPIluFmxHvD2vT93xWa9DAWPQNmyfLrqvGgb8k8hBJzCcGv2NciKs TPd+Ecj3LdtGZbPP/4hx41HoNyrsDzidyAkONlNVym4KH2mD7w6NhIF5Cra5/Die7A CBr7mkArmRXt3J2YRwSLmXTLxTIpig82qprg7pMc= X-Quarantine-ID: <195ltK8_m5_E> X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (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 49w6nS4NZBz6GBpY for ; Sun, 28 Jun 2020 16:50:36 -0700 (PDT) To: rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> From: "Joel M. Halpern" Message-ID: Date: Sun, 28 Jun 2020 19:50:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 28 Jun 2020 23:50:38 -0000 In my view, the reason we need a person to do this is that leadership by committee is essential equivalent to a recipe for disaster. And I do think we want leadership. Yours, joel On 6/28/2020 7:47 PM, Martin Thomson wrote: > On Sat, Jun 27, 2020, at 13:01, Nevil Brownlee wrote: >> I've updated my Internet Draft to include a suggestion of what an RSEB >> (RFC Series Editorial Board) could be structured. Take a look at >> https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html > > This is very much not what I had in mind. We should not insist on having a role that depends on finding an individual with a rare and difficult combination of attributes. And I don't think that you can support that function by taking a program with open participation and consensus processes and reduce that to 5 people (+stream manager ex officio) who are responsible for approving strategy. > > Perhaps you can start by explaining why you think we need to have an individual perform these functions. > From nobody Sun Jun 28 17:14: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 67DF83A0FD6 for ; Sun, 28 Jun 2020 17:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 h2sN4uUARm-x for ; Sun, 28 Jun 2020 17:14:40 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 902003A0842 for ; Sun, 28 Jun 2020 17:14:40 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id x62so11654129qtd.3 for ; Sun, 28 Jun 2020 17:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=xUVbdheLe04IgAf4X1BFk6l3HbYrkn5UXi48UOPp2Ao=; b=WDtEPXgmYR+ElvjUvnCj9wyV+jAkoDGbkUzHaarmXPhDbvNmTN4z4Bl7iyfUTy1nkA 00mpCHamn027nxBf5IEFoVoGbtW83gUYBNJslha5iqLyVV3fkxgdd3v++7wqhDMU9TfN MXo+/a7L5/b0b+I2pnghMONJv5Z2KA8wJNzNUu5R4pL2dESBnKCLlAlkF0FC+E7igOQ2 PIQ70W/dWur8/iAnaonnPiwQ3RhOF8ShAqWW8N+96NTbUAq5QoUbp75PvF2MKimfmJ6P StfNVHLmlNSL84lZUXkEaQMeKwfQJHuR4s3cx7JTFiDDAkZhXd6+uwWo5eAyovYSCjQa fQ2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=xUVbdheLe04IgAf4X1BFk6l3HbYrkn5UXi48UOPp2Ao=; b=h0iJuwG4YQvFbkLG+Gwc4hTocN7bGYqC77fL/SGGD1ygxBR7qcj9/VydG4YLQqhKW3 6O6z9ARvGMlWUA1BW4855CZxywPt51rPxbLiZBl3HyG0OaWXpL1SIEczQWvB7PeI83fl YKEJgGX4+Vqvq2Xu7Hilv2Bn6huEadnPtcsXwrz9w3+lmLzMdVbcmOJxOoOAFCg7/tJl gfuOdWH69IwYnwDzql50dXh/49gNcuVD/afLuIYjkiSKNj8LxImn+bomq64UwzXxkXiq WyiQFpri2SNM/4syDj1aFhln/vJeBkV8AEbrV92Z8nbntjRLLsJW7xBJj8SnhmZx62CI yJNg== X-Gm-Message-State: AOAM533ZZE+cIMX8fs9VV7YV0Uj4zMfrv2o3KFxzGXQG9a995015W/GF uWHrHXw1PNhx66AeyvgBGY8pE9jqqBoBVA== X-Google-Smtp-Source: ABdhPJzVlM4McHUrjc1A3jSUVNuY9U2VBdPVQFnE3neo67kVhMcIYiyBqVBBJsOGikhdGjRE47DKoQ== X-Received: by 2002:ac8:134a:: with SMTP id f10mr13678917qtj.131.1593389679040; Sun, 28 Jun 2020 17:14:39 -0700 (PDT) Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id r49sm17642985qtr.11.2020.06.28.17.14.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 28 Jun 2020 17:14:38 -0700 (PDT) To: rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> From: Michael StJohns Message-ID: Date: Sun, 28 Jun 2020 20:14:37 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------48CEC9F068CC9443CC25CD3E" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 00:14:42 -0000 This is a multi-part message in MIME format. --------------48CEC9F068CC9443CC25CD3E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 6/28/2020 7:50 PM, Joel M. Halpern wrote: > In my view, the reason we need a person to do this is that leadership > by committee is essential equivalent to a recipe for disaster. And I > do think we want leadership. > > Yours, > joel Strong +1 here.   One of the reasons for having a senior person in this role is so that the attention paid to the strategic evolution of the series does not wax and wane based on the current hobbyhorses of the leadership or their companies,  or upon other loud voices.   I have no problems with those voices influencing strategy, but I have strong problems with those voices directing strategy - especially if they change directions every 6 months or a year. We've had at least 4 people with the "rare and difficult" [Aside: difficult?] combination of attributes so I'm not sure where Martin is coming from here.   It may be that he doesn't agree that those are the right attributes for the role, but that's a whole other discussion.  I would expect with some luck, and with an IETF that _*respects*_ what an expert can bring to the role, we will be able to find someone who won't run screaming into the night after they meet us. Mike > On 6/28/2020 7:47 PM, Martin Thomson wrote: >> On Sat, Jun 27, 2020, at 13:01, Nevil Brownlee wrote: >>> I've updated my Internet Draft to include a suggestion of what an RSEB >>> (RFC Series Editorial Board) could be structured. Take a look at >>> https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html >>> >> >> This is very much not what I had in mind.  We should not insist on >> having a role that depends on finding an individual with a rare and >> difficult combination of attributes.  And I don't think that you can >> support that function by taking a program with open participation and >> consensus processes and reduce that to 5 people (+stream manager ex >> officio) who are responsible for approving strategy. >> >> Perhaps you can start by explaining why you think we need to have an >> individual perform these functions. >> > --------------48CEC9F068CC9443CC25CD3E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/28/2020 7:50 PM, Joel M. Halpern wrote:
In my view, the reason we need a person to do this is that leadership by committee is essential equivalent to a recipe for disaster.  And I do think we want leadership.

Yours,
joel

Strong +1 here.   One of the reasons for having a senior person in this role is so that the attention paid to the strategic evolution of the series does not wax and wane based on the current hobbyhorses of the leadership or their companies,  or upon other loud voices.   I have no problems with those voices influencing strategy, but I have strong problems with those voices directing strategy - especially if they change directions every 6 months or a year.  

We've had at least 4 people with the "rare and difficult" [Aside: difficult?] combination of attributes so I'm not sure where Martin is coming from here.   It may be that he doesn't agree that those are the right attributes for the role, but that's a whole other discussion.  I would expect with some luck, and with an IETF that respects what an expert can bring to the role, we will be able to find someone who won't run screaming into the night after they meet us.

Mike


On 6/28/2020 7:47 PM, Martin Thomson wrote:
On Sat, Jun 27, 2020, at 13:01, Nevil Brownlee wrote:
I've updated my Internet Draft to include a suggestion of what an RSEB
(RFC Series Editorial Board) could be structured. Take a look at
https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html

This is very much not what I had in mind.  We should not insist on having a role that depends on finding an individual with a rare and difficult combination of attributes.  And I don't think that you can support that function by taking a program with open participation and consensus processes and reduce that to 5 people (+stream manager ex officio) who are responsible for approving strategy.

Perhaps you can start by explaining why you think we need to have an individual perform these functions.



--------------48CEC9F068CC9443CC25CD3E-- From nobody Sun Jun 28 17:23:53 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 D4F7C3A0FE4 for ; Sun, 28 Jun 2020 17:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=KXqkQ2ga; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Sc3iVq2L Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0D-5AFCONFyl for ; Sun, 28 Jun 2020 17:23:48 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F823A0FE3 for ; Sun, 28 Jun 2020 17:23:48 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 966A04BE; Sun, 28 Jun 2020 20:23:47 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 28 Jun 2020 20:23:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=b 5Bhn7M+y6c7ZbaqVbGY/5VR6Cc+1fKnUqjVaLolBaI=; b=KXqkQ2gafQjZGaIhs lEDxLgKU4hyaxOK92FcGlfcA0RFDzRUbYgzGnlGsKMwXySRrXLu3WB9T2OsM+bxY vWs+84jbjX2qu9L5yxG0sAqpQjgg/iK7P614Ova5s9B13KNQsLRbIkQ0MnBff/cl zzgo7zEwXpqC+guQJcnvAamMH9yjNKsZJPg90xUVxfSbYR7TQAHEDs+1CMOpprXH QaGWxc8YhfF0tsZGYrGssbLb9bZxwsXaYKzRVNMOV/jTyGJymU3jzzAYdVAAQLpq XL2oP7kCcnlfYg75b4swk7JEraCHFN/QrHar1fv3nQzwY1CLe/Meb8L2XRiNEGoi JfiuQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=b5Bhn7M+y6c7ZbaqVbGY/5VR6Cc+1fKnUqjVaLolB aI=; b=Sc3iVq2LLKRhUrnxekHL6BbP0GAj9SOowPH4qnluXvRfZXJ+TaPoQFOzN f9GpdZc6PD5YL3wNwAGpRhaiQjy80UUBtaSuhCQJ1yBaPbr8CkZfx7OAEkJlgg/1 iQdOaYqqj5GJLcP/mtXp/bb7d2E3lX+rj9TRK1fgrrgoel5i0+GLH+ftZEr/LJyp y94PTB6EIXLSE65M4xjaKNPT/B4TFL95wMp/yPf6soIGOh+wHmO5RwuzIqFKKKSM hnn9l/9iXjC5f/mJ0U0kHwxuWA+VZnfbaRfrn0EwvuM8QsMnFCbhGOxbb1F0wTnP 9I03gs0/itbks6iI7k8hi1KuD1poA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeljedgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehm nhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepieetudduvdduffettdduvdeghedtue ehheejgeeltdelkeevgfffheefffeffffgnecuffhomhgrihhnpehivghtfhdrohhrghdp ihgrsgdrohhrghdpmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehud enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhho thesmhhnohhtrdhnvght X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 30E4E3280059; Sun, 28 Jun 2020 20:23:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: Date: Mon, 29 Jun 2020 10:23:42 +1000 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <3EDDC9C7-BA91-4E18-AB1C-8E77E95627B2@mnot.net> References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> To: Michael StJohns X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 00:23:51 -0000 The suggestion was to have more than one more specialised role, not to = promote 'leadership by committee.' This has been discussed a number of = times previously, due to the very high bar created by the combination of = requirements we current place on the position (as Martin mentioned). > On 29 Jun 2020, at 10:14 am, Michael StJohns = wrote: >=20 > On 6/28/2020 7:50 PM, Joel M. Halpern wrote: >> In my view, the reason we need a person to do this is that leadership = by committee is essential equivalent to a recipe for disaster. And I do = think we want leadership.=20 >>=20 >> Yours,=20 >> joel=20 > Strong +1 here. One of the reasons for having a senior person in = this role is so that the attention paid to the strategic evolution of = the series does not wax and wane based on the current hobbyhorses of the = leadership or their companies, or upon other loud voices. I have no = problems with those voices influencing strategy, but I have strong = problems with those voices directing strategy - especially if they = change directions every 6 months or a year. =20 >=20 > We've had at least 4 people with the "rare and difficult" [Aside: = difficult?] combination of attributes so I'm not sure where Martin is = coming from here. It may be that he doesn't agree that those are the = right attributes for the role, but that's a whole other discussion. I = would expect with some luck, and with an IETF that respects what an = expert can bring to the role, we will be able to find someone who won't = run screaming into the night after they meet us. >=20 > Mike >=20 >=20 >=20 >> On 6/28/2020 7:47 PM, Martin Thomson wrote:=20 >>> On Sat, Jun 27, 2020, at 13:01, Nevil Brownlee wrote:=20 >>>> I've updated my Internet Draft to include a suggestion of what an = RSEB=20 >>>> (RFC Series Editorial Board) could be structured. Take a look at=20 >>>> = https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html=20= >>>=20 >>> This is very much not what I had in mind. We should not insist on = having a role that depends on finding an individual with a rare and = difficult combination of attributes. And I don't think that you can = support that function by taking a program with open participation and = consensus processes and reduce that to 5 people (+stream manager ex = officio) who are responsible for approving strategy.=20 >>>=20 >>> Perhaps you can start by explaining why you think we need to have an = individual perform these functions.=20 >>>=20 >>=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- Mark Nottingham https://www.mnot.net/ From nobody Sun Jun 28 17:28: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 F1DC13A0FEB for ; Sun, 28 Jun 2020 17:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=hR/Yhne8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tenfl57Q Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPgnLSKtBF5N for ; Sun, 28 Jun 2020 17:28:33 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975DC3A0FEA for ; Sun, 28 Jun 2020 17:28:33 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D88575C0062 for ; Sun, 28 Jun 2020 20:28:32 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Sun, 28 Jun 2020 20:28:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=B0wuN5zAFlyeqRx5tgOr/QnkfO4SRDm Q0eqJUVGwpYg=; b=hR/Yhne8X8I6REPc9WiKOdzdY9E9Ym9kjMRU9pgFjZakmEk WtR3HhEQStnhvuP6PT47glJWxINzIEozNv2SeYPtOSttsrgqFUpM/+OYTv/EToYz c2GqE4Vug8xAHGNbQisTA9qBP9ogkLMWmoq59PTG3/Rlvdm1ZlN2/SSbyVuR0V4J dn2PYl+GaE36fvJK9NMuVUqHNfVLbHWHOPI9vmixNnwWYFnMDwozMTTL10HFg5sR ak2xwDw0eRbAVDobmVsaqf3zHnJDrGYnNGr57wBFuD0z+hucsOw+L1KIJKXPxPZ5 y3hl7i0nOVNGEpgifnp/xdbIqISLISKeF9Xu2lQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=B0wuN5 zAFlyeqRx5tgOr/QnkfO4SRDmQ0eqJUVGwpYg=; b=tenfl57Qoh61hSqYR2lwKw lu1DR7l1mZhWsX4nOcLovMtwjMxH2fuNsSxs914FZqEgItVVFEeDWZw8FMW2OSZd UJaInHnYIkqsur1tw2hGLy3uxhofM4Zh1r8AVS2MHKEC4I/1M9du0Xbft0iUuHRz RDcKwdAylMIOlX/orKSljg0dOxHx1dwuWoIppdBqSJ7flQfX38gm8us/3nqRxCMC DiMjWIL3nkOSlq6fzeopwYOiR1MUICxeL0bMkMiJ9GC7Iz24wkNLtsWZe+H6ysry 6MtL8q+OAiQwVsJMh4BUCwQphhH0Agbr5lfl0+rP2SupDFc37FQoLCeRhbuAQiSQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeljedgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7996CE00CE; Sun, 28 Jun 2020 20:28:32 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-543-gda70334-fm-20200618.004-gda703345 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> Date: Mon, 29 Jun 2020 10:28:12 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 00:28:35 -0000 On Mon, Jun 29, 2020, at 10:14, Michael StJohns wrote: > We've had at least 4 people with the "rare and difficult" [Aside: > difficult?] Sorry, I meant to say "difficult to source". I said that because I understand that the number of people who have applied for the position in the past have been very small. And if you rule out those who happened to define the role, the number is very, very small. The great person theory of leadership is certainly appealing, but I want to be pragmatic. How much do we really need a permanent position for strategist here? And why is it that we think that a single person, complete with their own biases and bugaboos, is a necessary remedy for the problems we have? There is ample evidence that there is disagreement in the community on some relevant topics. You might think that a stern authoritative hand is what is needed to provide guidance and direction so that progress might be made. But now you are asking to add "benevolent dictator" to the set of already challenging attributes that such an individual might bring. From nobody Sun Jun 28 17:39:28 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 356DB3A0FF7 for ; Sun, 28 Jun 2020 17:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ZLcVw6jx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JndALyiZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2ZzvRvGFxWe for ; Sun, 28 Jun 2020 17:39:25 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3353A0FC0 for ; Sun, 28 Jun 2020 17:39:25 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 87B08861; Sun, 28 Jun 2020 20:39:24 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 28 Jun 2020 20:39:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=P s+2/2nfc/0/YR+oU2H/2oBT9XFp2k9Dyp1UrAW+RiE=; b=ZLcVw6jxYpbhI2GBg o2caeFgPHvSv4F1oCYZjgivVjNj5sRDjSsBMqLVvqgMGbHk/79QRQhS6U8JytI9E uN81mh0097NcD83926ZOFFIouINrmCj3EG5/cFvg6MFKEV3QDeRNpnQNq6xMXLcM ehu+1OETKrviAApjFINPENl6pS8QIvIW0ibASOAM/Qu82+5gLGVPneGM0aTGwo9m NZRP0rYXUBrLdoLxmD/hYGsr37knSKUt5XFHXF3XVepS7c35zY4/f91vzHhNsN8z PxyQ1Mr8RaYO4Zbt4VZyIdIff/kMTb98b6BRa/ThUt4gj3wyjtyP1yqL99vlD6r7 GfO9Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Ps+2/2nfc/0/YR+oU2H/2oBT9XFp2k9Dyp1UrAW+R iE=; b=JndALyiZDPQjgyxunORZvBbfpoeH2DLLqRJb3DC8WKAtqq+S8nIec09+8 04Fy5/SLtcXo+HET3yQLePlc0IlEexH46a2zpO25RIHhH1TdkB6YT15sUwt2EI6O G38y1vmEqzkwXUfzeD4hRCUVF4pj+iFMm/9JhOQfQrOetbj13/m9v0HRyhpcBzDS 2RmHL6WSI2DKrSVZd7WvD5wsaPHOEWN/WucqwdOxaug2QT2uFibZDb88/xZQsud/ Sn5n2R9xgBio2qRRXbcy78qkoKzuQbKRqbtU9TmZhFoIw+YyixpcuF2rE1mFgtso 9ExtmB/cLmRz2vWEFYZNfqRdb3qfQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeljedgfeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtdejnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehm nhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepgefguedvfeeugfdtudekkeekgfelgf eiieehfeehjeefuddtudeitdffgedtudetnecuffhomhgrihhnpehuphdrlhhinhhkpdhm nhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgv th X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 8493D328005E; Sun, 28 Jun 2020 20:39:22 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: Date: Mon, 29 Jun 2020 10:39:20 +1000 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> To: Brian Rosen X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 00:39:27 -0000 Belatedly giving my comments: > On 25 Jun 2020, at 1:17 am, Brian Rosen wrote: >=20 > We appreciate all the thoughtful comments we have seen so far. >=20 > Skipping, for the moment, the scope proposal and concentrating on the = questions: > 1. Should the RSE be a hired employee or a contracted entity? > Many commenters think this is a detail, but needs to be decided. We = can likely wrap this up quickly, and probably on-list. There are those = who just say =E2=80=9Ccontract=E2=80=9D, some that say =E2=80=9Coh, part = time employee is fine=E2=80=9D and others that say, =E2=80=9Cjust leave = it up to the entity in question 2=E2=80=9D. Please offer your thoughts = on this if you haven=E2=80=99t already. =20 I think that this is something we should leave up to the LLC. > 2. Who hires/contracts the RSE? > Also seems like we can likely wrap this up quickly on-list. I sense = the current direction is the LLC. Brian offered some options. If you = think it should be some entity other than the LLC, please speak up. Clearly, it's the LLC writing the contract. Who advises them (and who = they're required to listen to) when selecting one is a different = question, and one we need to explore (see C). > 3. For the purposes of day to day management, to whom does the RSE = report? > Most commenters seem to think this is not a good question because the = answer is: they don=E2=80=99t need day to day management. Bron thought = everyone needs =E2=80=9Csome=E2=80=9D management even if it=E2=80=99s = =E2=80=9CI=E2=80=99m sick and won=E2=80=99t be working for a few = days=E2=80=9D. Whatever the answer to 2 is, there is some management = there, but probably there is more to be considered. Let=E2=80=99s keep = discussing this a bit. The inclusion of "day to day" in this question has become distracting. I = think it's better to state this as an aspect of oversight in question 5. > 4. Is there some group that oversees the RSE? > This seems to be answered in the affirmative. If you disagree, please = speak up. Affirmative. > 5. If the answer to 4 is yes, how is the board constituted? > Most commenters liked Michael=E2=80=99s suggestion. If you disagree, = please speak up. Link? This seems to be one of our major tasks, so we should make this = decision deliberately. > 6. Who defines the process that the RSE follows? This group? The = Board? The RSE defines it themselves? > Here we have a lot of different opinions, and we probably need to = spend some time at the meeting discussing this. The question of = strategy before process came up which we also need to figure out. I think the output of this group should specify guidelines regarding how = the RSE takes input from the community and determines its consensus. = This might involve creating new WG-like bodies or other mechanisms. = Their primary characteristic should be openness and accountability -- = i.e. *not* a closed body of 'advisors' or the like. > 7. Can the RSE decide to not publish a document one of the stream = editors forwards to it? If so, on what grounds? > I sense that we=E2=80=99re close on this, but details matter. I sense = that there is support to allow the RSE to hold up a document if the RSE = doesn=E2=80=99t feel that it is readable, but that that control is = fairly limited. =20 I think that the RSE can query a document's publication to assure that = what they perceive as an inaccuracy, mistake or other issue is = intentional. Once that's clarified, they cannot block publication. > There were a couple of other suggested questions: > A. What do we want the RSE to do? =20 8. What authorities and responsibilities does the RSE have? > B. Is the RSE an individual or a group? 9. How do we map the identifies roles of the RSE into one or more = positions?=20 > C. Who recruits/interviews/selects/appoints the RSE? >=20 > D. What should the appointment length/renewal terms be? These seem pretty self-explanatory; why are they considered not = well-formed? -- Mark Nottingham https://www.mnot.net/ From nobody Sun Jun 28 17:56: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 95D3B3A089C for ; Sun, 28 Jun 2020 17:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlWX_Kk1RJRx; Sun, 28 Jun 2020 17:56:55 -0700 (PDT) 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 73A5B3A0887; Sun, 28 Jun 2020 17:56:54 -0700 (PDT) From: Jay Daley Message-Id: <419D1FE3-9879-4553-90EF-914FC23B5A12@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_FB4F1982-C090-4C8E-B959-8FAFDAF72CF1" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 29 Jun 2020 12:56:52 +1200 In-Reply-To: Cc: rfced-future@iab.org To: Nevil Brownlee References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 00:56:58 -0000 --Apple-Mail=_FB4F1982-C090-4C8E-B959-8FAFDAF72CF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 27/06/2020, at 3:01 PM, Nevil Brownlee = wrote: >=20 > Hi Martin: > I've updated my Internet Draft to include a suggestion of what an RSEB = (RFC Series Editorial Board) could be structured. Take a look at = https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html = >=20 > Of course, any suggestions for changes/improvements/etc to that draft = are welcome :-) Some questions: Conceptually there are the following layers at which the RSE needs to = operate: a. the long-term strategic level of where the series goes b. the medium-term managerial level of what tools are used, whether the = SVG implementation is rethought, what performance is expected of the = RPC, what the minimum standards are for a document to be accepted for = processing, etc c. the short-term operational level of whether X change should be made = the vocabulary, how Y should be rendered It is not clear to me what role you see for the RSE/RSEB at each of = these levels, specifically: q1. Am I correct in assuming from section 2 "RSE Responsibilities" that = you still see the role of the RSE as convening and managing the = community process that agrees the long-term strategy? q2. If so then is the only role of the RSEB to assist in calling = consensus or does the RSEB have a role in representing the community = view?=20 q3. How do you see the discussions/decisions for the managerial level = working between the RSE/RSEB/Community? (i.e. it=E2=80=99s not clear to = me from your document what role, if any, the community has in this) q4. Does the RSEB have any role at all in the operational level or is = that left to the RSE, working with whatever team/process they determine = is appropriate? It may be easier to answer those questions with your own definition of = the levels. thanks Jay >=20 > Cheers, Nevil >=20 > On Thu, Jun 25, 2020 at 11:43 AM Martin Thomson > wrote: > On Thu, Jun 25, 2020, at 07:09, Brian E Carpenter wrote: > > On 24-Jun-20 19:54, Martin Thomson wrote: > > > We don't need a single person (or contracted entity, if that = includes more than one person) to be given the task of determining = strategy.. If we need a strategy to serve our community, then maybe = that community should setting and owning that strategy. Not indirectly, = via an appointed custodian, but directly. > >=20 > > I don't understand how that would work in the absence of a group and = a=20 > > group leader to determine what the community is (since it's not the=20= > > IETF) and what the community's rough consensus is. Who would they = be?=20 > > In my book, the RSE and the RFC Series Board. >=20 > I don't think that is necessarily the case. >=20 > The process that we're following has the same requirements and = challenges. It has leadership. Two leaders in fact, which is more than = twice as good as relying on a single person. It has open participation. = (I don't know what RFC Series Board is, but it implies a closed group, = just as RSE implies an individual.) >=20 > Speaking strictly about strategy, the structure of what we have here = is just about as good as we will get in all the ways that matter. >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future = >=20 >=20 > --=20 > ----------------------------------- > Nevil Brownlee, Taupo, NZ > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_FB4F1982-C090-4C8E-B959-8FAFDAF72CF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 27/06/2020, at 3:01 PM, Nevil Brownlee <nevil.brownlee@gmail.com> wrote:

Hi = Martin:
I've updated my Internet Draft to include a = suggestion of what an RSEB (RFC Series Editorial Board) could be = structured.  Take a look at https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-chang= es-01.html

Of course, any suggestions for changes/improvements/etc to = that draft are welcome = :-)

Some questions:

Conceptually there are the following layers at = which the RSE needs to operate:

a. =  the long-term strategic level of where the series = goes
b.  the medium-term managerial level of what tools = are used, whether the SVG implementation is rethought, what performance = is expected of the RPC, what the minimum standards are for a document to = be accepted for processing, etc
c.  the short-term = operational level of whether X change should be made the vocabulary, how = Y should be rendered

It is not clear = to me what role you see for the RSE/RSEB at each of these levels, = specifically:

q1.  Am I correct = in assuming from section 2 "RSE Responsibilities" that you still see the = role of the RSE as convening and managing the community process that = agrees the long-term strategy?
q2.  If so then is the = only role of the RSEB to assist in calling consensus or does the RSEB = have a role in representing the community view? 
q3. =  How do you see the discussions/decisions for the managerial level = working between the RSE/RSEB/Community?  (i.e. it=E2=80=99s not = clear to me from your document what role, if any, the community has in = this)
q4.  Does the RSEB have any role at all in the = operational level or is that left to the RSE, working with whatever = team/process they determine is appropriate?

It may be easier to answer those questions with = your own definition of the levels.

thanks
Jay



Cheers, = Nevil

On Thu, Jun 25, 2020 at 11:43 AM Martin Thomson = <mt@lowentropy.net> wrote:
On Thu, Jun 25, 2020, at 07:09, Brian = E Carpenter wrote:
> On 24-Jun-20 19:54, Martin Thomson wrote:
> > We don't need a single person (or contracted entity, if that = includes more than one person) to be given the task of determining = strategy..  If we need a strategy to serve our community, then = maybe that community should setting and owning that strategy.  Not = indirectly, via an appointed custodian, but directly.
>
> I don't understand how that would work in the absence of a group = and a
> group leader to determine what the community is (since it's not the =
> IETF) and what the community's rough consensus is. Who would they = be?
> In my book, the RSE and the RFC Series Board.

I don't think that is necessarily the case.

The process that we're following has the same requirements and = challenges.  It has leadership.  Two leaders in fact, which is = more than twice as good as relying on a single person.  It has open = participation.  (I don't know what RFC Series Board is, but it = implies a closed group, just as RSE implies an individual.)
=
Speaking strictly about strategy, the structure of what we have here is = just about as good as we will get in all the ways that matter.

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


--
-----------------------------------
Nevil = Brownlee, Taupo, NZ
--
Rfced-future mailing list
Rfced-future@iab.org
https://www.iab.org/mailman/listinfo/rfced-future

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

= --Apple-Mail=_FB4F1982-C090-4C8E-B959-8FAFDAF72CF1-- From nobody Sun Jun 28 18:05:59 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 2F2963A1008 for ; Sun, 28 Jun 2020 18:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKV1CAGmkMGd for ; Sun, 28 Jun 2020 18:05:56 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 B1CFD3A0882 for ; Sun, 28 Jun 2020 18:05:55 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id h22so9003681lji.9 for ; Sun, 28 Jun 2020 18:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7AWJKrVzQ4sGI+HXJVUin0W6wnlglnZGZtQrSbT+3nA=; b=P+k5r0lPWd7kFfez+sJN4E2sbdC9QTZHsJnMJGLcWUEu/wJUWDaBrzYXBavJsNmGor TLLhfQUwF9o5RNw3S84xtegoZT1BklM8gdxnXjp9PaNWm8eWkh6KWSv+hxuXkURMYnor EpW49Liz8yWAx+P+KXdpNIFeNy7HnFT49JjVysye5ZOiw8CM4tetunTKfFVLH8k9X/5Y 53Nf7HKMapnOS/kEwjk+2YEKLvJw8yeN6zRWWxrE4/fqz1rc4D3gS8XZyEA9W1xQywpp /YgUnclYymLdjt0yK+pYPhZn+WXCTGIlqSNWbf19LasBDjy2rnWNFsygTc/L8vIcMz1u ItVA== 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=7AWJKrVzQ4sGI+HXJVUin0W6wnlglnZGZtQrSbT+3nA=; b=dK5Hu8ldPqtyUZd8RonsgY6vzH006wBXtGeZ72eoE8guWlhkOtgn3391pAt9ZTf9bj vdjzV80sytc/Cd4CQl03EhPhlPXKVvk+VmqNTftSf0oRcVcZNvDSWrBeJg8Z2MKYuqJM hqdywovc4bmqgAyIVe/lkcarCPRh5Abn0KTB3wLnOyXfOaR/0+ujVOWQxQQTK3AgdhtA cmdNF0y6g5ZIKm4pFHCXq06IKXF1rV/+pGAf6pymcDK6/hBEfrPW5F8ycdy45p8ZkPRf EQPeOG6qT51dcLo0IyxGOb/oEf2CTmwWbhNAJVDH41/Oju7EpKqYJYxkxdcK8XXX+pQX YntQ== X-Gm-Message-State: AOAM530Qo6tneAmrPlzbdHcV3hfUAtNE2TK6rX6zM8fymVlyX5mx0yuf sRO84dTxIO3VYHaXSjzyYI9B5OKkb4SHx3OSSAkDN21dHLw= X-Google-Smtp-Source: ABdhPJxK7WMhnPxFUej61s6KxXIeT1hEoAmztqZWoaWSW/8/mpj9lnHtbd7xfJV/y7Uco1kOl+Wl1jooEz3+zmlf1NY= X-Received: by 2002:a2e:2a42:: with SMTP id q63mr7208593ljq.265.1593392753742; Sun, 28 Jun 2020 18:05:53 -0700 (PDT) MIME-Version: 1.0 References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> <3EDDC9C7-BA91-4E18-AB1C-8E77E95627B2@mnot.net> In-Reply-To: <3EDDC9C7-BA91-4E18-AB1C-8E77E95627B2@mnot.net> From: Eric Rescorla Date: Sun, 28 Jun 2020 18:05:17 -0700 Message-ID: To: Mark Nottingham Cc: Michael StJohns , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000133d3605a92ea918" Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 01:05:58 -0000 --000000000000133d3605a92ea918 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 28, 2020 at 5:23 PM Mark Nottingham wrote: > The suggestion was to have more than one more specialised role, not to > promote 'leadership by committee.' This has been discussed a number of > times previously, due to the very high bar created by the combination of > requirements we current place on the position (as Martin mentioned). > This aside, I don't really understand the "leadership by committee" argument here. Here at the IETF we design protocols which will run on billions of nodes using a collaborative consensus-based process. I find it surprising that people think we can't use this process for the much lower stakes question of how our documents ought to be shaped. -Ekr > > On 29 Jun 2020, at 10:14 am, Michael StJohns > wrote: > > > > On 6/28/2020 7:50 PM, Joel M. Halpern wrote: > >> In my view, the reason we need a person to do this is that leadership > by committee is essential equivalent to a recipe for disaster. And I do > think we want leadership. > >> > >> Yours, > >> joel > > Strong +1 here. One of the reasons for having a senior person in this > role is so that the attention paid to the strategic evolution of the series > does not wax and wane based on the current hobbyhorses of the leadership or > their companies, or upon other loud voices. I have no problems with > those voices influencing strategy, but I have strong problems with those > voices directing strategy - especially if they change directions every 6 > months or a year. > > > > We've had at least 4 people with the "rare and difficult" [Aside: > difficult?] combination of attributes so I'm not sure where Martin is > coming from here. It may be that he doesn't agree that those are the > right attributes for the role, but that's a whole other discussion. I > would expect with some luck, and with an IETF that respects what an expert > can bring to the role, we will be able to find someone who won't run > screaming into the night after they meet us. > > > > Mike > > > > > > > >> On 6/28/2020 7:47 PM, Martin Thomson wrote: > >>> On Sat, Jun 27, 2020, at 13:01, Nevil Brownlee wrote: > >>>> I've updated my Internet Draft to include a suggestion of what an > RSEB > >>>> (RFC Series Editorial Board) could be structured. Take a look at > >>>> > https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html > >>> > >>> This is very much not what I had in mind. We should not insist on > having a role that depends on finding an individual with a rare and > difficult combination of attributes. And I don't think that you can > support that function by taking a program with open participation and > consensus processes and reduce that to 5 people (+stream manager ex > officio) who are responsible for approving strategy. > >>> > >>> Perhaps you can start by explaining why you think we need to have an > individual perform these functions. > >>> > >> > > > > > > -- > > Rfced-future mailing list > > Rfced-future@iab.org > > https://www.iab.org/mailman/listinfo/rfced-future > > -- > Mark Nottingham https://www.mnot.net/ > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000133d3605a92ea918 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jun 28, 2020 at 5:23 PM Mark = Nottingham <mnot@mnot.net> wrote= :
The suggestion= was to have more than one more specialised role, not to promote 'leade= rship by committee.' This has been discussed a number of times previous= ly, due to the very high bar created by the combination of requirements we = current place on the position (as Martin mentioned).
<= br>
This aside, I don't really understand the "leadershi= p by committee" argument here. Here at the IETF we design protocols wh= ich will run on billions of nodes using a collaborative consensus-based pro= cess. I find it surprising that people think we can't use this process = for the much lower stakes question of how our documents ought to be shaped.=
-Ekr

=C2=A0
> On 29 Jun 2020, at 10:14 am, Michael StJohns <msj@nthpermutation.com> wrote= :
>
> On 6/28/2020 7:50 PM, Joel M. Halpern wrote:
>> In my view, the reason we need a person to do this is that leaders= hip by committee is essential equivalent to a recipe for disaster.=C2=A0 An= d I do think we want leadership.
>>
>> Yours,
>> joel
> Strong +1 here.=C2=A0 =C2=A0One of the reasons for having a senior per= son in this role is so that the attention paid to the strategic evolution o= f the series does not wax and wane based on the current hobbyhorses of the = leadership or their companies,=C2=A0 or upon other loud voices.=C2=A0 =C2= =A0I have no problems with those voices influencing strategy, but I have st= rong problems with those voices directing strategy - especially if they cha= nge directions every 6 months or a year.=C2=A0 =C2=A0
>
> We've had at least 4 people with the "rare and difficult"= ; [Aside: difficult?] combination of attributes so I'm not sure where M= artin is coming from here.=C2=A0 =C2=A0It may be that he doesn't agree = that those are the right attributes for the role, but that's a whole ot= her discussion.=C2=A0 I would expect with some luck, and with an IETF that = respects what an expert can bring to the role, we will be able to find some= one who won't run screaming into the night after they meet us.
>
> Mike
>
>
>
>> On 6/28/2020 7:47 PM, Martin Thomson wrote:
>>> On Sat, Jun 27, 2020, at 13:01, Nevil Brownlee wrote:
>>>> I've updated my Internet Draft to include a suggestion= of what an RSEB
>>>> (RFC Series Editorial Board) could be structured. Take a l= ook at
>>>> https://ww= w.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html
>>>
>>> This is very much not what I had in mind.=C2=A0 We should not = insist on having a role that depends on finding an individual with a rare a= nd difficult combination of attributes.=C2=A0 And I don't think that yo= u can support that function by taking a program with open participation and= consensus processes and reduce that to 5 people (+stream manager ex offici= o) who are responsible for approving strategy.
>>>
>>> Perhaps you can start by explaining why you think we need to h= ave an individual perform these functions.
>>>
>>
>
>
> --
> Rfced-future mailing list
> Rfced-future= @iab.org
> https://www.iab.org/mailman/listinfo/rfced-fut= ure

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

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000133d3605a92ea918-- From nobody Sun Jun 28 18:56:06 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 88A883A1010 for ; Sun, 28 Jun 2020 18:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.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 TLqjdPeNoiJr for ; Sun, 28 Jun 2020 18:56:03 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 DA7FE3A0FA0 for ; Sun, 28 Jun 2020 18:56:02 -0700 (PDT) Received: (qmail 10952 invoked from network); 29 Jun 2020 01:56:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=2ac6.5ef94a30.k2006; bh=qxtT7v3Cf5RzxbkD21lYTx3QGTj/b1c7qPKybcRxqZU=; b=hYh4Kx3XEH07RSV2dxQUwoPC2vwiNtqOHotEUdzV7YZ1Hfc37b+PPUYgG6slyMLRQNjgnvXCPIK8jKa41Rmrrv7xWDTPO0PB1d+MUTN/wsMGefPwT2cqPYw4iuSS4+yBsQdVfbn7GqszTIpO/bwGCOH2fx2Ep0f3MmrVQSgRdk87ZxcX/D0cER6WbOy+cvoLS6ieXmARfsdlBI4PF8BT7CZ4bos2MmYKRx0zZ2qnFm4CYvFjFvGOgY06VOPTr87z Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 29 Jun 2020 01:56:00 -0000 Received: by ary.qy (Postfix, from userid 501) id 64A451BD0D2D; Sun, 28 Jun 2020 21:56:01 -0400 (EDT) Date: 28 Jun 2020 21:56:01 -0400 Message-Id: <20200629015601.64A451BD0D2D@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: ekr@rtfm.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 01:56:05 -0000 In article you write: >billions of nodes using a collaborative consensus-based process. I find it >surprising that people think we can't use this process for the much lower >stakes question of how our documents ought to be shaped. The hard bit is finding people who understand the publishing and archival issues and also understand the very unusual culture of the IETF. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Jun 28 19:01: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 D47763A1026 for ; Sun, 28 Jun 2020 19:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZestVnBpNJcw for ; Sun, 28 Jun 2020 19:01:02 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 44E303A1025 for ; Sun, 28 Jun 2020 19:01:02 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id g17so6462258plq.12 for ; Sun, 28 Jun 2020 19:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=AgmWZMlxtcZBlqFbfmiT4roqPf1iNsi4Br/THkAcxjU=; b=munIlhT0fLntZLyPcJ5h6isN4S/jaRseGwjsn8sPJ0fPoFP8DDvTHCMXq1DHzheXwJ OQdHFw5vCeKp4F2slgEPn2QWxDVdrh1n9MUbaQi+JTD0QpbVChC7VMZ9Enjl7NldNlD5 11H0Z5reH9351wajI2GLMktqr6DnnMry+w6nH4C597x4vOT9QfI+/K4NdBwy+IgygEo3 YoHVOivUxg0WTODB+pnV6XCKSzzTKX+dpe3vjX93Aw3tQXZLALRWugd/QATmE0qxuMgN G85SCNbmOohLVd5U2GDgp/I3kwyWIKqC0ManJAZwcIi59ZI9SpFvPy/EmG0JVduC2zHO AoFA== 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=AgmWZMlxtcZBlqFbfmiT4roqPf1iNsi4Br/THkAcxjU=; b=XheY4e+vI7U8GiiYVUvx4nL4QowfR429NURQsk6yIpp25qeRfUOc98q/T7F+iXnptE GJpVo+X/nJAJm0U9PV5VCKXVaPjs9SKIrlz7kgOLHZRse1pKfDfrk2DePw9c3F5Ydt26 QHJNdjIZyg5m1lc2Yj5/TV8t+YmA8Jw66FNi0kk4MbWyGTIkSCW3as/d6uQ2gBhR9yjn XRR/9sqROOQk/kLNSGX2LeSD7GGMGWoZ2LqanJZknSA69ZcFismJvrHN+3t1RATUI0co oAasxO0d8OP8kjQISqtAjNB8zCRsxGxmzLu54cOy3Hi4H/fnMkECZvz6GGojakM1cOww /cxA== X-Gm-Message-State: AOAM533mj5UcV7F+DVO24pbRG42ov3MpiBTfDxeH2T36rxu/0l2bHgQX VAj9EzSYPAVeFfjpWaHeBtkvxRlt2k4= X-Google-Smtp-Source: ABdhPJxGuY09ycLFrjJSQ9ayTrR52e/8bui73NxAxHKHxY75vYzmLl8PLinll6kjwiIyM5SKD/ym/A== X-Received: by 2002:a17:90b:488:: with SMTP id bh8mr12683008pjb.49.1593396060303; Sun, 28 Jun 2020 19:01:00 -0700 (PDT) Received: from [192.168.178.20] (203.90.69.111.dynamic.snap.net.nz. [111.69.90.203]) by smtp.gmail.com with ESMTPSA id m14sm28120286pgt.6.2020.06.28.19.00.58 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Jun 2020 19:00:59 -0700 (PDT) To: rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> <3EDDC9C7-BA91-4E18-AB1C-8E77E95627B2@mnot.net> From: Brian E Carpenter Message-ID: <065dd700-9666-6c88-5016-0668ed966884@gmail.com> Date: Mon, 29 Jun 2020 14:00:55 +1200 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: <3EDDC9C7-BA91-4E18-AB1C-8E77E95627B2@mnot.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 02:01:04 -0000 On 29-Jun-20 12:23, Mark Nottingham wrote: > The suggestion was to have more than one more specialised role, not to promote 'leadership by committee.' This has been discussed a number of times previously, due to the very high bar created by the combination of requirements we current place on the position (as Martin mentioned). Certainly splitting the IT project management role (a.k.a. xml2rfcv3) from the Series Editor role is very desirable. A no-brainer, in fact. But anyone with experience (even as an author) with journal publishing knows that the role of an Editor, aided by an editorial board, is essential. If we want the RFC Series to be more than a copy shop, we need such a person. The board may well be small, as Nevil suggests, but part of its role is to consult the community. We have lots of running code proof that the community on its own doesn't produce consensus; we need some focus point to extract a consensus, and the editorial board seems like a good solution for that. Regards Brian > > >> On 29 Jun 2020, at 10:14 am, Michael StJohns wrote: >> >> On 6/28/2020 7:50 PM, Joel M. Halpern wrote: >>> In my view, the reason we need a person to do this is that leadership by committee is essential equivalent to a recipe for disaster. And I do think we want leadership. >>> >>> Yours, >>> joel >> Strong +1 here. One of the reasons for having a senior person in this role is so that the attention paid to the strategic evolution of the series does not wax and wane based on the current hobbyhorses of the leadership or their companies, or upon other loud voices. I have no problems with those voices influencing strategy, but I have strong problems with those voices directing strategy - especially if they change directions every 6 months or a year. >> >> We've had at least 4 people with the "rare and difficult" [Aside: difficult?] combination of attributes so I'm not sure where Martin is coming from here. It may be that he doesn't agree that those are the right attributes for the role, but that's a whole other discussion. I would expect with some luck, and with an IETF that respects what an expert can bring to the role, we will be able to find someone who won't run screaming into the night after they meet us. >> >> Mike >> >> >> >>> On 6/28/2020 7:47 PM, Martin Thomson wrote: >>>> On Sat, Jun 27, 2020, at 13:01, Nevil Brownlee wrote: >>>>> I've updated my Internet Draft to include a suggestion of what an RSEB >>>>> (RFC Series Editorial Board) could be structured. Take a look at >>>>> https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html >>>> >>>> This is very much not what I had in mind. We should not insist on having a role that depends on finding an individual with a rare and difficult combination of attributes. And I don't think that you can support that function by taking a program with open participation and consensus processes and reduce that to 5 people (+stream manager ex officio) who are responsible for approving strategy. >>>> >>>> Perhaps you can start by explaining why you think we need to have an individual perform these functions. >>>> >>> >> >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Sun Jun 28 22:55:47 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 78CDB3A089C for ; Sun, 28 Jun 2020 22:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 e8uGdyN0ccjM for ; Sun, 28 Jun 2020 22:55:44 -0700 (PDT) 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 C458F3A08A5 for ; Sun, 28 Jun 2020 22:55:43 -0700 (PDT) Received: from xse368.mail2web.com ([66.113.197.114] helo=xse.mail2web.com) by mx166.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jpmlY-000yuv-1s for rfced-future@iab.org; Mon, 29 Jun 2020 07:55:40 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 49wGtg00p1z3Jfj for ; Sun, 28 Jun 2020 22:55:39 -0700 (PDT) Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jpmlW-0007Bs-SU for rfced-future@iab.org; Sun, 28 Jun 2020 22:55:38 -0700 Received: (qmail 14931 invoked from network); 29 Jun 2020 05:55:38 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.153]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 29 Jun 2020 05:55:38 -0000 To: Brian E Carpenter , rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> <3EDDC9C7-BA91-4E18-AB1C-8E77E95627B2@mnot.net> <065dd700-9666-6c88-5016-0668ed966884@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: <5c9262d8-c9f7-0599-8a65-3cf96c80b8dd@huitema.net> Date: Sun, 28 Jun 2020 22:55:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <065dd700-9666-6c88-5016-0668ed966884@gmail.com> Content-Type: multipart/alternative; boundary="------------B761E079493120C04D3D94A5" Content-Language: en-US X-Originating-IP: 66.113.197.114 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.10) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0f6LF1GdvkEexklpcFpSF5apSDasLI4SayDByyq9LIhVdCDjGa5oi+DG StFGV2b1A0TNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjRzgyua+oKUgQGcbmeu+KPhY RkpFG1KU35iPF8F1Y4g7RGH1FvHrn+/njL3LiOS0QVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEzBCgqe539x2oAbbqp81Hae42Vki7412dpbhrD2d47zbC3VvU djSCswikK/licfX+oIF6uBSWByrPG2Vxuo/vVPllrFEbCkMryfcYCsgMUJObfBQoU3roWy2GH1DY sAiH3gousbgNfxi2R3uFLvZP/HBXvrLBlKCVRjjdPbjQ4HnBNho1Lszw5OO01yYoll8q2UgzFF+j HNSbIoW1Q++Wvj3dKxLhoxcmaInYbR5vlqFg3eKzPG9E5MikC2dVXWcpK172i/E5sOgbaCtBiSIx 1XwCY8vmv+JqOVJamBHfOGVwjn7Xut/lXagsodd5qqODTFiwcpU4fyz75jxpU98RPGiH1Wgh6RAe nBR+licROGZNFSBymhtbd6ygEffuU1+3Lf6cmU/99wDQedNhMKpgrabRS07UAKIxw2LxGhgVPyLB H1fP3YU+2XWwKzL04bcfwzQZWnqpeh+UbGCVNeqba5Xked+P+aSZU/EB7YnRWs2LBDMrD7q/cJog wbqzsuokKfBIBCdSqYQ9HCoI0pvfjE7JPy9twDyaj6un7qWOkNdIFi0x8LS+a+vCX3de5Rt/F6pJ HTN5Wex+2bVZiOwGeePXdRjeeYOc4D1auWIFhSESRf1m7i4CdbB91f7MMMrMw6nIoDr0sXUZ7YZo Z/GZ+hXPnkLS9Oo2rnoDkPMmYws/jALIEk7e/m7I/2vCMQjvMFTIwLG5tR7EnM5HsSwoavLd14/y 82ebPziYNS9mrGfphl+Vcq8rhM3tJ8iXgDJaTYQ7ppmvpzmHp5jJAeLmE9zghLEjHJbHVHmv5sbq r/Q= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 05:55:46 -0000 This is a multi-part message in MIME format. --------------B761E079493120C04D3D94A5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/28/2020 7:00 PM, Brian E Carpenter wrote: > On 29-Jun-20 12:23, Mark Nottingham wrote: >> The suggestion was to have more than one more specialised role, not to= promote 'leadership by committee.' This has been discussed a number of t= imes previously, due to the very high bar created by the combination of r= equirements we current place on the position (as Martin mentioned). > Certainly splitting the IT project management role (a.k.a. xml2rfcv3) f= rom the Series Editor role is very desirable. A no-brainer, in fact. > > But anyone with experience (even as an author) with journal publishing = knows that the role of an Editor, aided by an editorial board, is essenti= al.=20 I think that's a very flawed analogy. The RSE does not operate as "an Editor, aided by an editorial board". Most of the classic editor function are delegated to the stream managers, and the discussion has pretty much established that the RSE has no say on the matter. In fact, it might be better to drop the E from the title, and call for something like an RFC Series Manager. > If we want the RFC Series to be more than a copy shop, we need such a p= erson. The board may well be small, as Nevil suggests, but part of its ro= le is to consult the community. We have lots of running code proof that t= he community on its own doesn't produce consensus; we need some focus poi= nt to extract a consensus, and the editorial board seems like a good solu= tion for that. We have yet to see conclusive attempts at defining this community. There may well be a need to gather feedback from the readers of the RFC, with an eye towards making the standards more "readable". But it takes a leap of faith to believe that a board will actually do that. If in fact the the standards are so hard to read that people don't use them or don't implement them, that seems a problem that the IETF itself must solve. If it did not, the IETF products would slowly become irrelevant, and the discussion of the future of the RFC series would become quite academic. -- Christian Huitema --------------B761E079493120C04D3D94A5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 6/28/2020 7:00 PM, Brian E Carpenter wrote:
On 29-Jun-20 12:23, Mark Nottingham wrote:

The suggestion was to have more than one more specialised role, not to promote 'leadership by committee.' This has been discussed a number of times previously, due to the very high bar created by the combination of requirements we current place on the position (as Martin mentioned).

Certainly splitting the IT project management role (a.k.a. xml2rfcv3) from the Series Editor role is very desirable. A no-brainer, in fact.

But anyone with experience (even as an author) with journal publishing knows that the role of an Editor, aided by an editorial board, is essential.
I think that's a very flawed analogy. The RSE does not operate as "an Editor, aided by an editorial board". Most of the classic editor function are delegated to the stream managers, and the discussion has pretty much established that the RSE has no say on the matter. In fact, it might be better to drop the E from the title, and call for something like an RFC Series Manager.
If we want the RFC Series to be more than a copy shop, we need such a person. The board may well be small, as Nevil suggests, but part of its role is to consult the community. We have lots of running code proof that the community on its own doesn't produce consensus; we need some focus point to extract a consensus, and the editorial board seems like a good solution for that.

We have yet to see conclusive attempts at defining this community. There may well be a need to gather feedback from the readers of the RFC, with an eye towards making the standards more "readable". But it takes a leap of faith to believe that a board will actually do that. If in fact the the standards are so hard to read that people don't use them or don't implement them, that seems a problem that the IETF itself must solve. If it did not, the IETF products would slowly become irrelevant, and the discussion of the future of the RFC series would become quite academic.

-- Christian Huitema

--------------B761E079493120C04D3D94A5-- From nobody Mon Jun 29 01:03: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 A1CE23A0BBE for ; Mon, 29 Jun 2020 01:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEWf5gxkkeAb for ; Mon, 29 Jun 2020 01:03:26 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 8327E3A0BD5 for ; Mon, 29 Jun 2020 01:03:21 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.82.21]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 05T8377T006559 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2020 01:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1593417799; x=1593504199; i=@elandsys.com; bh=HbbPY1rXuKjQv57bUNfZjclyBmXRPVnPkGzWpWbI6AM=; h=Date:To:From:Subject:In-Reply-To:References; b=DlcaKuNp/MOOVkmHsyXE7CvxpqKaM6iKEcRZbi8SgMmSvT2cPUAgp3PZFfzashu4Q p6+iDA/fD6h9/yLqVeIKZW/Bdz2IUiQez8Fll8WCn76Iy2fhzOW3+C3AuM3nOrS7a1 J8sg9fNh0cQJvmuKqMaIyA2RVXqfa1iv1WNy+N5g= Message-Id: <6.2.5.6.2.20200629004027.10558bc0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 29 Jun 2020 00:59:17 -0700 To: Martin Thomson , rfced-future@iab.org From: S Moonesamy In-Reply-To: References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 08:03:30 -0000 Hi Martin, At 04:47 PM 28-06-2020, Martin Thomson wrote: >This is very much not what I had in mind. We should not insist on >having a role that depends on finding an individual with a rare and >difficult combination of attributes. It is difficult to fill a role which require a rare combination of skills/expertise. The body might find a suitable candidate today. However, it might not be able to find a replacement. That is similar to the current situation. Regards, S. Moonesamy From nobody Mon Jun 29 02:29:46 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 58DFC3A0D3B for ; Mon, 29 Jun 2020 02:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvxszaH_DyUZ for ; Mon, 29 Jun 2020 02:29:31 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410138.outbound.protection.outlook.com [40.107.141.138]) (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 B3E2B3A0CFD for ; Mon, 29 Jun 2020 02:29:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CnVOgO4oY0VKkiDn8dYYt9BACCS+zxGSRo8dyja059OON2XbsffCidcsEMsnJt400wK0JA50CAF7npB1LiGsRgwDceSTYZxkYhgxvt1bnTk+mpSsttpRZeRTiMZYrnBl47JQJHWUtEWONUAZSwQU60tzbnf5Rm6Rl7fO/G5vnhYfRjh5bGSeoAKmbU5OhaUwDHPX/ikQFOw4io5OD8Af3fh2S9rrZfl77HcttcL8INaZyIDzWc20RWN0omZbbU7hwDLwHcgTvxPfvekvkS98t6F727g5bXm5EhfdQpZiPs7y7OA1X+Sny2ltcBu2FYLgW0nRMBOPkq1kaYCoN0oNpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w18REIbzN87aN8bqDpFF3nlxoU7mM3u5d3vf43STRoU=; b=GEX3+uDUxB44nR3RKQUzKgZbNoHebfu8MNi5B299Ugn00hcvdbBtKvLEFt7GHVNXj/oiDwy3MrYhkT6ppIJLcn1Eui1D6FqxwYUacGkyzto8BzQfwSXozqLt4knHristntB3oIwBOpx3vX6KWfC0ghsx81PvGL7UVFSOUnZF7D52gqcwEQ3ala9XsjmpJonbZsXJ5wJQnsf5mkjGYhaTbiU4GP3v3mjalWO/ZYDb/2NiclWWxGOzlzG/ZGKqd2kLjtfxg+FG3tftlsvbHI/2CPLN4BTAHOuisi7XLtWvamrm0CH8lSbR0lkEfQSs4ySQrvCr4z21uv8rBd85rTBiuA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w18REIbzN87aN8bqDpFF3nlxoU7mM3u5d3vf43STRoU=; b=X6zR4Gld0vci1Z5/KHoEenXNnOlh5c8/k5HvelggS2nzxY2zn0BBr4tbyQp/N0gmpLFp1m4O/1bvxWnR6sBHp7UEwpOlcTnphRYUTUyp7niln4AgZMOJS6WEHs5AekACy/Rn8zySooNq+rQ5vD8FhozcqsIBD1s5U0us9lo8abk= Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) by OSBPR01MB1736.jpnprd01.prod.outlook.com (2603:1096:603:7::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20; Mon, 29 Jun 2020 09:29:29 +0000 Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::d1a0:ea71:e6f9:9778]) by OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::d1a0:ea71:e6f9:9778%7]) with mapi id 15.20.3131.026; Mon, 29 Jun 2020 09:29:29 +0000 To: S Moonesamy , Martin Thomson , rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> <6.2.5.6.2.20200629004027.10558bc0@elandnews.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Mon, 29 Jun 2020 18:29:27 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: <6.2.5.6.2.20200629004027.10558bc0@elandnews.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TY1PR01CA0162.jpnprd01.prod.outlook.com (2603:1096:402::14) To OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.6] (125.203.82.4) by TY1PR01CA0162.jpnprd01.prod.outlook.com (2603:1096:402::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Mon, 29 Jun 2020 09:29:29 +0000 X-Originating-IP: [125.203.82.4] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 065726db-e720-48d6-bf93-08d81c0eec57 X-MS-TrafficTypeDiagnostic: OSBPR01MB1736: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-Forefront-PRVS: 044968D9E1 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Rz4G5ndej+EIZnn6Up3MgiWzwXEHwjUEtTs8g2GhKo3Q8FXVQ+y3hvS/ylD4Z0OYoP4vVSs1gercftaq6UZoiM6twqcv5vsDKqxyImBQfAE5YlDYKbbYXpmzFDrCGaa2WcQwRIE1wGg+Y0eK1TDpPh1RKKdb4V7UaNzytwZi7kvmxXUZm0esQAoJraFkcIBc/FKy74gtsbd6bt1zLpv4pdZpZzHkXcY6tZS+AoWqjQUb+q60ah6BFSe9fJ6kPb32L00LRqMw8ehg5qVlW27Xz80odCWSTryHXup1akLZBqI30SsvBeGCE4C7OyYp8d2lDI6qEfNFo9Ivsm3WQyPaMQfP3tkE0BbM2GCs5ZK9m4b4+out7XEVHmKnL7BmFKfn X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:OSBPR01MB2566.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(396003)(136003)(376002)(366004)(39840400004)(346002)(8936002)(66556008)(2906002)(16576012)(110136005)(66946007)(186003)(8676002)(66476007)(508600001)(786003)(316002)(16526019)(6486002)(31686004)(5660300002)(26005)(52116002)(31696002)(86362001)(2616005)(956004)(53546011)(36916002)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: LfQsCn6fbfm8BpAGEBDCk+Kl5gmnDWEPNv9SY7JNkZtgyeKXK6/jTeIYGZWEZUVMWO19O6sNzfvEJGHm1etM1X9yZ6RRBRWBITpnJVDdWERPMkitvcFRDKkUk8ImXXEb4cSW9BQbkSyMM6r0RHTsxJGCTTXPEO1jqSkmHmoX3kIVTsrx+Gvl3oiHGpRlEPCKstN45mchRIFbV9YAulLCp0FHeEEAgDhTDaE1Z/t9R3p5flTeqqTvhSCS4olDNLF4BO5Y0ja6c8YW5dgaC1XX+87SjvwaLPmDKNQKZR0JttZQjkf/uW1XvTTrmbOo8T+8nHqitPrZ0Xja7w+fa4Mt1edR2g2MPPnjwiABIp3qmuEHUKdmW/LQBJ+EkpihUsUi9K+VnS1Hl6WM7oUL3gkIluPDsQR3drktZ7LMyRceg7U7RuxQLZpwVmvRj1e+EQiMO+g3IuMJ+gzzPxDyRM4fQRvrUfpf1ec+DM6/4eigQbA= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 065726db-e720-48d6-bf93-08d81c0eec57 X-MS-Exchange-CrossTenant-AuthSource: OSBPR01MB2566.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jun 2020 09:29:29.4617 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: nKcArAQovLh/CA5wQMDf16Qbwxg2X/YCPm1kTy2W/vyPwnUOczfYRj3lBd8HyWYZ3Gg8hn99eGuP6FOXZTs5eQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB1736 Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 09:29:46 -0000 Hello everybody, On 29/06/2020 16:59, S Moonesamy wrote: > Hi Martin, > At 04:47 PM 28-06-2020, Martin Thomson wrote: >> This is very much not what I had in mind.  We should not insist on >> having a role that depends on finding an individual with a rare and >> difficult combination of attributes. It's very good to have different ideas. Can you be more specific, maybe even with a (short) draft? > It is difficult to fill a role which require a rare combination of > skills/expertise.  The body might find a suitable candidate today. Positions on the IESG and on the IAB (and some others) also require quite some combination of (of course different) skills. It's often not easy to find enough good candidates. And yet we have managed so far, with quite some success overall. > However, it might not be able to find a replacement.  That is similar to > the current situation. Yes indeed. With this in mind, we should try to make sure we do a better job than last time with respect to a very qualified holder of the position. I think to a large extent, that's what many of us are trying to achieve in this group. Regards, Martin. > Regards, > S. Moonesamy From nobody Mon Jun 29 03:18: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 0579F3A0D64 for ; Mon, 29 Jun 2020 03:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3HbWqW6KgmM for ; Mon, 29 Jun 2020 03:18:35 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 82B4D3A0C32 for ; Mon, 29 Jun 2020 03:18:35 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.82.21]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 05TAIJEn023523 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2020 03:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1593425914; x=1593512314; i=@elandsys.com; bh=CS0UfedwNrvA6po7owf2AZEglKQRFGxjPIDDlp+mbRE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=EyCzOyrpFDmxp9iWG2VF9Ppy4SYe6Mf+Q6Dg6gcK7aAJ5xBj9ziOw+nNZy+01/zHi edxHiGQQ+i7g+CXyW8VKrNwLEfEexn3O4q+NY+qaZ5ayAg/3QUmgdiAvwutzoNyDJY IjEnmzmMMsgtzDDAXFomtAz4X7enDZDVuaeEOaaI= Message-Id: <6.2.5.6.2.20200629024121.104a7908@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 29 Jun 2020 03:18:01 -0700 To: duerst@it.aoyama.ac.jp, rfced-future@iab.org From: S Moonesamy Cc: Martin Thomson In-Reply-To: References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> <6.2.5.6.2.20200629004027.10558bc0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 10:18:38 -0000 Hi Martin, At 02:29 AM 29-06-2020, Martin wrote: >It's very good to have different ideas. Can you be more specific, >maybe even with a (short) draft? I probably won't get around to write a short draft within the next two weeks as there is current an issue which I have to focus on. Someone mentioned "specialized" in the thread. The role would probably need a person with experience and expertise in technical publishing. Combining that with "good understanding of the IETF" is difficult unless there is an assumption that the candidates are already involved in the IETF/AMS. >Positions on the IESG and on the IAB (and some others) also require >quite some combination of (of course different) skills. It's often >not easy to find enough good candidates. And yet we have managed so >far, with quite some success overall. The persons appointed for the IAB/IESG positions are from within the IETF. That was not the case for the ex-RSE. The RSE is a paid position. The unique expertise/experience combination will have an impact on costs; that is not the case for IAB/IESG positions. Regards, S. Moonesamy From nobody Mon Jun 29 04:01: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 2012A3A0D1C for ; Mon, 29 Jun 2020 04:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WylydHjK2C3S for ; Mon, 29 Jun 2020 04:01:19 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400111.outbound.protection.outlook.com [40.107.140.111]) (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 711C93A0D0F for ; Mon, 29 Jun 2020 04:01:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ECF4WoHjmmVVnnLWgFJ9zy5IU/F+CpOs2Ho8PURzdEQfzgK8kwHd2DPPfp8llLe3zKOAB9jXgAdN8T96sV07xQu2yMYqHLRPYcxgDGuf74qk/P35PF306n0ySj0hStDTb/zgUy6hmLyWru54l9pHiyDtjV1GyG1OPGk1oawKPsq2nVEpz0ecUxmoKrqJJCtUinxIjp+j96wA8TRf9P0/iZjwI4SmikfLUFXkMc6YYq6JQeVRcagdQxbdjB0TH+mqLnK6mAsJnFDDpO1xvyhAkGUXaXxDFyL39AGAqQjGlhGH8XXN8DIw0evkZA3HHgWsglZv0y5WdTblBj1fgUWnwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mv7o9M+iYkzUMlP0d6gNk67reL+9g/0KJDdLORmTKIM=; b=Hoskf+8dggE+EWTtNM8SyY5xfqO5YWNCZ8SISbIbl4/PP9LG/Yn5L7Pwewkx/oetgqGVBfnWBgPlZOUOyS+PoAc633ZFOiOPMwTjbiC94Pk2pvvQXELm0u3CCTpa9YCTDsaxc7sA4Oj4cPAgFiWKv8ACLFV6fGu/n1Z4ght5rcS/f3YmRHNON+yYooQl7MBIZqgIwv069Fl37E2wjYMxUW41moAXPbilmECHJ1z7QSCjk6IverlBE3PrCcap0FLWe5a6fo80mkWhFTQcCXd49zTMVNCgIDe+5jManfZiSyvGDUODECXfZPelZaM6YZtIHo4DhTspcJPmrtSxS4jP+Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mv7o9M+iYkzUMlP0d6gNk67reL+9g/0KJDdLORmTKIM=; b=rPeZghXJo/95iVtcl3j61xOoEXrU3WW8uuKiqThLOJbnACxJen4NTrw2TgA8eiR422GKA6fZc65D9ZmhzA0uoi+Ydp0WKtCgqkA/dq3s7CadSfK0KOiSrt6m8Z/OLB/e2RV54bJzT3OYbajHnfkz1JVq5RMjyvRAONuGL0sdAfI= Authentication-Results: lowentropy.net; dkim=none (message not signed) header.d=none;lowentropy.net; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) by OSBPR01MB2565.jpnprd01.prod.outlook.com (2603:1096:604:13::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Mon, 29 Jun 2020 11:01:16 +0000 Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::d1a0:ea71:e6f9:9778]) by OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::d1a0:ea71:e6f9:9778%7]) with mapi id 15.20.3131.026; Mon, 29 Jun 2020 11:01:16 +0000 To: S Moonesamy , rfced-future@iab.org Cc: Martin Thomson References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> <6.2.5.6.2.20200629004027.10558bc0@elandnews.com> <6.2.5.6.2.20200629024121.104a7908@elandnews.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <7dd7a0d1-cf83-0ba8-4432-2f985034f8f5@it.aoyama.ac.jp> Date: Mon, 29 Jun 2020 20:01:14 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: <6.2.5.6.2.20200629024121.104a7908@elandnews.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TYAPR01CA0004.jpnprd01.prod.outlook.com (2603:1096:404::16) To OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.6] (125.203.82.4) by TYAPR01CA0004.jpnprd01.prod.outlook.com (2603:1096:404::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Mon, 29 Jun 2020 11:01:16 +0000 X-Originating-IP: [125.203.82.4] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 49894220-22b4-4ae8-41ba-08d81c1bbef1 X-MS-TrafficTypeDiagnostic: OSBPR01MB2565: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:3276; X-Forefront-PRVS: 044968D9E1 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: f+6AHT3H0rM7MK/cBxYQCIgXxWrBI3aJWwWbCeVJxKxNc3GPoIv5ji/8kkeWlfz8/j/oXN2jZ50VxKIwfw1X6IrzjdSMx21WhHq0Y/RcOkPGYK9yg0MurePft84F3E+HwrUtWzaV6RVjM+LMGZSR+wquGBDmU5ARcpsiU5aN+jmk/yxOdNa15ZLxRIsdH7Q+MgwGegxBOelGZkKVNVmVVq0F8/CyynO7UDc3UhTUMdYP8PbvgSddCEHGvu+x8lF9YUS0TdSAquj5WJcGKmb1zC5gARrXP7zlV/8UFHQzSLhXpxsojbuF5lJm1ouFYLLqSXAZSrFrRYl8kWwRnCVf7hJmx+zfbn6uj4vNplUPF917O8IsEkUC98+HxwSlKHWe X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:OSBPR01MB2566.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(39840400004)(346002)(376002)(396003)(136003)(2616005)(4326008)(2906002)(6486002)(8676002)(16576012)(8936002)(956004)(52116002)(36916002)(316002)(786003)(53546011)(31686004)(4744005)(66476007)(66946007)(86362001)(66556008)(26005)(186003)(16526019)(5660300002)(31696002)(508600001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: M7UhN+zJrVbryNjGCxbiaW4S4oREzBGF8K/zCPLE7wJOMRwp4drtBdQPG542Sm83WH3T9zBxQJttVqzVK8p6Aw4/G8kd42ncUZqhsNkLR9015Ws5I4HfpyN+eODPp/FizPrsCuJh+MFrkaF9JSVi1AGJoQt3Wyr5MDxfQ6Ymc1hwIPtcHD25Hj4b8Hd0gVKwcEB+08SJvEWaXSWNpa1jeWzEYip6PBkhOYbY5f6N+CgZrwy9aBdhn8l2e+F2C0M2I4gn6mxPANiGUGj+au14w2kblYVAp371H7HYIYx9g/6SK1nr+/UadTkru2tXa3elLXXStlgR7sjeLnstMjPk2lENO1rCFT48ts4WIIhqesDA5dIdhmVM40VgFwcGKuQHCvjfq1oGzq/cbKbN2EPnZpVUmenmvVCQnWBQX8g38r2QWoGzUdKMNMtNiMtus8HAFx+jJWxCxMukacfV8X3MPdhUQ/b1v7ap+Ddc27PXsuQ= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 49894220-22b4-4ae8-41ba-08d81c1bbef1 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jun 2020 11:01:16.7681 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: l2CL5PAWQU3Ol/HAc/zmnBrEIlTK3usSJVkV7uGQH/tqMT5P7ZE1C00LYm6yksnXyaVO8kNEbUf/Mc/WD80qng== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB2565 Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 11:01:21 -0000 On 29/06/2020 19:18, S Moonesamy wrote: > Hi Martin, > At 02:29 AM 29-06-2020, Martin wrote: >> It's very good to have different ideas. Can you be more specific, >> maybe even with a (short) draft? > > I probably won't get around to write a short draft within the next two > weeks as there is current an issue which I have to focus on. Sorry, that comment was directed to Martin (Thomson). Regards, Martin. From nobody Mon Jun 29 06:05: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 612C43A0EAC for ; Mon, 29 Jun 2020 06:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggUadMSarSRE for ; Mon, 29 Jun 2020 06:05:50 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 350B43A0EAB for ; Mon, 29 Jun 2020 06:05:50 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id h19so17893476ljg.13 for ; Mon, 29 Jun 2020 06:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6SKCcf6afCFUpEl17nEQAbm9sap2Ql1w+engOJPrbts=; b=TVH71ZpXQxn/OoMrV1StuXnldL1KJJ8d9T6n6VTBVN2qqYh54v9hokZMKw6AuGCPxr gtRRtkpg2o5lrRtocxtfLNIY8WKr4sV1qAUyJAl1YT2Ap1JTrZydceWP1sobjkmVY/Rc gowGLc46N9dOO/JUjhh0ywyWD3zZjU98iHxfBzillDs7W9b80ilj42vj6ZbSZXgI775B 0MW/qIceg0JrF5HzBwzmHBE7t4BP+napkgG8BLt0UsF8jWCf1YiiGxvoJ2tRJmcm52a3 r9kEwcgVN9P3HOUYb+TPDLh5LbrUkf3hiQyn25CWjnWy7c8fGyJq9XC65/hZI5z2HtuY pUMQ== 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=6SKCcf6afCFUpEl17nEQAbm9sap2Ql1w+engOJPrbts=; b=J/FPMbZhtqpcSD3jdFWyMhsTI7QungNUriCW2oVKff+IpD0VRdmuL09WB54PJ6KgT1 T7v8cMq/GY7L4B50fvG84hcTRwSHnbmnic3Y83U/cQR/I3NJFLfmXEVhoJG+zTGI2tmV DgylOW3Nd0yzxciCSvHaV/nxovZ10Nboaeodq4Ri2KxFMY97LFohKav43iUNxTwCwjQh BRLT7O8FryKuICfDBPYLAKgiDupgTlIFqFweGyNRJF7g20ZaY/a90C8AL5n9GWoKJThK QRbdiKLjKSgIcHU5Ag6UqPT09hqO0uARhiopPGGpQe6ZnQZN9nHAPbDdGdcguoTx/WYW UgJQ== X-Gm-Message-State: AOAM53291hpjwoqwtSi5OOM2NcjHVTLB5H6983/x0KoSZ0ySvivisX7X zjXpPgAWsJMWg95KMfOqLPZEIjFwjNITpaHkoy4XsA== X-Google-Smtp-Source: ABdhPJwBT6uJJaIBpouZfiG12gh14Wiu6crLjZrQv2BGXFGp0pO2KzmELj+9ervSjIkm2boe8VS4PHgdwDvnIpWC+S8= X-Received: by 2002:a2e:91c7:: with SMTP id u7mr2482864ljg.184.1593435948267; Mon, 29 Jun 2020 06:05:48 -0700 (PDT) MIME-Version: 1.0 References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> <3EDDC9C7-BA91-4E18-AB1C-8E77E95627B2@mnot.net> <065dd700-9666-6c88-5016-0668ed966884@gmail.com> In-Reply-To: <065dd700-9666-6c88-5016-0668ed966884@gmail.com> From: Eric Rescorla Date: Mon, 29 Jun 2020 06:05:11 -0700 Message-ID: To: Brian E Carpenter Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000ab4e2705a938b76b" Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 13:05:53 -0000 --000000000000ab4e2705a938b76b Content-Type: text/plain; charset="UTF-8" On Sun, Jun 28, 2020 at 7:01 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 29-Jun-20 12:23, Mark Nottingham wrote: > > The suggestion was to have more than one more specialised role, not to > promote 'leadership by committee.' This has been discussed a number of > times previously, due to the very high bar created by the combination of > requirements we current place on the position (as Martin mentioned). > > Certainly splitting the IT project management role (a.k.a. xml2rfcv3) from > the Series Editor role is very desirable. A no-brainer, in fact. > > But anyone with experience (even as an author) with journal publishing > knows that the role of an Editor, aided by an editorial board, is essential. Well, as it happens, I have journal publishing experience as an author, and I'm not sure I agree with this. Moreover, the function of Editor of a journal is really much more like the function of Program Committee chair in a conference. I.e., to select the material to be published. That is not the case here. If we want the RFC Series to be more than a copy shop, we need such a > person. Well, this seems like the place to start: what do we want the RFC Series to be. As I said earlier, I see the primary purpose to be publishing technical specifications. The requirements for the RFC Series to successfully fulfill that functin seem relatively modest. The board may well be small, as Nevil suggests, but part of its role is to > consult the community. We have lots of running code proof that the > community on its own doesn't produce consensus; we need some focus point to > extract a consensus, And yet, as I said, we have mechanisms for getting consensus on far more weighty decisions. The reason I might be in favor of having some kind of board is actually to *delegate* small decisions, not as a form of getting consensus. But that naturally produces a division of labor in which the board makes small decisions and the community makes big ones. -Ekr and the editorial board seems like a good solution for that. > > Regards > Brian > > > > > > >> On 29 Jun 2020, at 10:14 am, Michael StJohns > wrote: > >> > >> On 6/28/2020 7:50 PM, Joel M. Halpern wrote: > >>> In my view, the reason we need a person to do this is that leadership > by committee is essential equivalent to a recipe for disaster. And I do > think we want leadership. > >>> > >>> Yours, > >>> joel > >> Strong +1 here. One of the reasons for having a senior person in this > role is so that the attention paid to the strategic evolution of the series > does not wax and wane based on the current hobbyhorses of the leadership or > their companies, or upon other loud voices. I have no problems with > those voices influencing strategy, but I have strong problems with those > voices directing strategy - especially if they change directions every 6 > months or a year. > >> > >> We've had at least 4 people with the "rare and difficult" [Aside: > difficult?] combination of attributes so I'm not sure where Martin is > coming from here. It may be that he doesn't agree that those are the > right attributes for the role, but that's a whole other discussion. I > would expect with some luck, and with an IETF that respects what an expert > can bring to the role, we will be able to find someone who won't run > screaming into the night after they meet us. > >> > >> Mike > >> > >> > >> > >>> On 6/28/2020 7:47 PM, Martin Thomson wrote: > >>>> On Sat, Jun 27, 2020, at 13:01, Nevil Brownlee wrote: > >>>>> I've updated my Internet Draft to include a suggestion of what an > RSEB > >>>>> (RFC Series Editorial Board) could be structured. Take a look at > >>>>> > https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html > >>>> > >>>> This is very much not what I had in mind. We should not insist on > having a role that depends on finding an individual with a rare and > difficult combination of attributes. And I don't think that you can > support that function by taking a program with open participation and > consensus processes and reduce that to 5 people (+stream manager ex > officio) who are responsible for approving strategy. > >>>> > >>>> Perhaps you can start by explaining why you think we need to have an > individual perform these functions. > >>>> > >>> > >> > >> > >> -- > >> Rfced-future mailing list > >> Rfced-future@iab.org > >> https://www.iab.org/mailman/listinfo/rfced-future > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000ab4e2705a938b76b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jun 28, 2020 at 7:01 PM Brian= E Carpenter <brian.e.car= penter@gmail.com> wrote:
On 29-Jun-20 12:23, Mark Nottingham wrote:
> The suggestion was to have more than one more specialised role, not to= promote 'leadership by committee.' This has been discussed a numbe= r of times previously, due to the very high bar created by the combination = of requirements we current place on the position (as Martin mentioned).

Certainly splitting the IT project management role (a.k.a. xml2rfcv3) from = the Series Editor role is very desirable. A no-brainer, in fact.

But anyone with experience (even as an author) with journal publishing know= s that the role of an Editor, aided by an editorial board, is essential.

Well, as it happens, I have journal publishin= g experience as an author, and I'm not sure I agree with this.

Moreover, the function of Editor of a journal is reall= y much more like the function of Program Committee chair in a conference. I= .e., to select the material to be published. That is not the case here.
=


If we want the RFC Series to be more than a copy shop, we need = such a person.

Well, this seems like the p= lace to start: what do we want the RFC Series to be. As I said earlier, I s= ee the primary purpose to be publishing technical specifications. The requi= rements for the RFC Series to successfully fulfill that functin seem relati= vely modest.


The board may well be small, as Nevil suggests,= but part of its role is to consult the community. We have lots of running = code proof that the community on its own doesn't produce consensus; we = need some focus point to extract a consensus,

<= div>And yet, as I said, we have mechanisms for getting consensus on far mor= e weighty decisions. The reason I might be in favor of having some kind of = board is actually to *delegate* small decisions, not as a form of getting c= onsensus. But that naturally produces a division of labor in which the boar= d makes small decisions and the community makes big ones.
-Ekr



and the editorial board seems lik= e a good solution for that.

Regards
=C2=A0 =C2=A0Brian

>
>
>> On 29 Jun 2020, at 10:14 am, Michael StJohns <msj@nthpermutation.com> w= rote:
>>
>> On 6/28/2020 7:50 PM, Joel M. Halpern wrote:
>>> In my view, the reason we need a person to do this is that lea= dership by committee is essential equivalent to a recipe for disaster.=C2= =A0 And I do think we want leadership.
>>>
>>> Yours,
>>> joel
>> Strong +1 here.=C2=A0 =C2=A0One of the reasons for having a senior= person in this role is so that the attention paid to the strategic evoluti= on of the series does not wax and wane based on the current hobbyhorses of = the leadership or their companies,=C2=A0 or upon other loud voices.=C2=A0 = =C2=A0I have no problems with those voices influencing strategy, but I have= strong problems with those voices directing strategy - especially if they = change directions every 6 months or a year.=C2=A0 =C2=A0
>>
>> We've had at least 4 people with the "rare and difficult&= quot; [Aside: difficult?] combination of attributes so I'm not sure whe= re Martin is coming from here.=C2=A0 =C2=A0It may be that he doesn't ag= ree that those are the right attributes for the role, but that's a whol= e other discussion.=C2=A0 I would expect with some luck, and with an IETF t= hat respects what an expert can bring to the role, we will be able to find = someone who won't run screaming into the night after they meet us.
>>
>> Mike
>>
>>
>>
>>> On 6/28/2020 7:47 PM, Martin Thomson wrote:
>>>> On Sat, Jun 27, 2020, at 13:01, Nevil Brownlee wrote:
>>>>> I've updated my Internet Draft to include a sugges= tion of what an RSEB
>>>>> (RFC Series Editorial Board) could be structured. Take= a look at
>>>>> https:= //www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html >>>>
>>>> This is very much not what I had in mind.=C2=A0 We should = not insist on having a role that depends on finding an individual with a ra= re and difficult combination of attributes.=C2=A0 And I don't think tha= t you can support that function by taking a program with open participation= and consensus processes and reduce that to 5 people (+stream manager ex of= ficio) who are responsible for approving strategy.
>>>>
>>>> Perhaps you can start by explaining why you think we need = to have an individual perform these functions.
>>>>
>>>
>>
>>
>> --
>> Rfced-future mailing list
>> Rfced-fu= ture@iab.org
>> https://www.iab.org/mailman/listinfo/rfce= d-future
>
> --
> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000ab4e2705a938b76b-- From nobody Mon Jun 29 06:07:47 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 4D2473A0EB3 for ; Mon, 29 Jun 2020 06:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vncgYE-ThMhf for ; Mon, 29 Jun 2020 06:07:43 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 8C84A3A0EB0 for ; Mon, 29 Jun 2020 06:07:43 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id s9so17897439ljm.11 for ; Mon, 29 Jun 2020 06:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jO4jjNda+yzfbSapf5hMNUrxfTL+rAw1FZSayX+xXIM=; b=QcWS4kebSj1J8VyRQZjhgdx45aI7IvqOx42IOMb+4LK22XBYQQKDMYdC7m9I6gT2qb gRSJfJfrdHDicoDrxD6y0UsbHtj7IEXdQ/mQ9+TN88wCCTpSVRF+e/xU0vxesVTAUcgj zaJEyX39LOEVOR4TPG/kkwYMdLs2ihaXd2Pp1hyTRrgzDZKn581eV7ehBcWwT6jnkjyQ vY9hLsNcnglYuMsNpyNkMF5dFUt1bvpHJr48OTFhrW2eIX08sVLdcy5NNpiCEhNnt/6O NhWBijVeUp+1Kx4krS8OVcCFKflZen4AAy3lWohZkJ5s+qGBckvrpmQr5ZI5wCXsNH7d LCwA== 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=jO4jjNda+yzfbSapf5hMNUrxfTL+rAw1FZSayX+xXIM=; b=Fx2/AKUXX+LkDHcrj4QtjjzPlAa5il/+aZLBWU5Y0yCOc2QMx/k3qqRJzkEXul641Z /Vb8UMydayFkDnNKmzBxVJqgdp8Yj4EfIMAAUU4o2Je5Z/CxXril9b9TyObCWjUnvjAL VnJjFUxsXDt5rZ3Q6oHdIfL3p8FQyXwUvisa9J3bAD0Zr8SQco3r1h75dfe1c1wbjz7r GbRyWR4wpGfsIFWXhoHbbddNOzv9jGik6mLLosXzYCR+6HVPAl9XLBaMY8C25MEEg7ms 5tJiYBUAXKxlE88fVcufiYzF1yKcCrqLHCzUnW7MLdjZI6nyUEUVxZhBn3AFihiaTKDl 1ejQ== X-Gm-Message-State: AOAM5300Y3mfy05zO+xGmvZrrpuK4AGCRA1tV8g4eXhs96j7Ns1yi/UN 2vIY2P1z2C8GECo2grOzgXjDaU01i4L8pRVTUh2pN9MxWaw= X-Google-Smtp-Source: ABdhPJyS7SJSBNNfYQGns6KoJT7e9x64hkJhunOQ3cxG7f67zF+BFjxrIjJmuu2G3UfDVlS04FnOZtKjg3P6bxObsOY= X-Received: by 2002:a2e:2a42:: with SMTP id q63mr8459460ljq.265.1593436061819; Mon, 29 Jun 2020 06:07:41 -0700 (PDT) MIME-Version: 1.0 References: <20200629015601.64A451BD0D2D@ary.qy> In-Reply-To: <20200629015601.64A451BD0D2D@ary.qy> From: Eric Rescorla Date: Mon, 29 Jun 2020 06:07:05 -0700 Message-ID: To: John Levine Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000006ffc3605a938be21" Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 13:07:45 -0000 --0000000000006ffc3605a938be21 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 28, 2020 at 6:56 PM John Levine wrote: > In article OW-6m87067JCSSfnDPOP-uiA@mail.gmail.com> you write: > >billions of nodes using a collaborative consensus-based process. I find it > >surprising that people think we can't use this process for the much lower > >stakes question of how our documents ought to be shaped. > > The hard bit is finding people who understand the publishing and > archival issues and also understand the very unusual culture of the > IETF. > I've heard that said, but it's not clear to me it's true. It would perhaps be useful to start by stating what the unique archival and publishing issues/requirements *are*. -Ekr --0000000000006ffc3605a938be21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jun 28, 2020 at 6:56 PM John = Levine <johnl@iecc.c= om> wrote:
OW-6m87067JCSSfnDPOP-uiA@ma= il.gmail.com> you write:
>billions of nodes using a collaborative consensus-based process. I find= it
>surprising that people think we can't use this process for the much= lower
>stakes question of how our documents ought to be shaped.

The hard bit is finding people who understand the publishing and
archival issues and also understand the very unusual culture of the
IETF.

I've heard that said, but it&= #39;s not clear to me it's true. It would perhaps be useful to start by= stating what the unique archival and publishing issues/requirements *are*.=

-Ekr

--0000000000006ffc3605a938be21-- From nobody Mon Jun 29 06:46:56 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 A1A303A0EF1 for ; Mon, 29 Jun 2020 06:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=Ka1yJ+A9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ItcUje77 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnNeRUpiDn6d for ; Mon, 29 Jun 2020 06:46:53 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B84413A0EE1 for ; Mon, 29 Jun 2020 06:46:53 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1BA855C0120 for ; Mon, 29 Jun 2020 09:46:53 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Mon, 29 Jun 2020 09:46:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=A+f5eCsiv+6jx+ziJf5BqBnO2BQpO7O a9PYzzE8yimU=; b=Ka1yJ+A9P/oItU9z5huO04ZSd91fqcGJVvVmS0i3Xys1Joi 15oQ9uSR4takLD11FWiwSDqfv07uwILdVIYffVUSXuszPWZ8vtTco2DpR9rSwEyN AiX9EK+Qpm5I7vmjL0QCtrstMKD3yuh5quUn02J+gGBdA37Ro1nqO8MOvg/I71zV 8CsfoloWz1fwpF7pLzBrgyVZDWXy5njHbStzRGoH8+obgpagYu5b0ZIJfAZ83loa zf58Q9tOKOaPBCJf+vcETFsaUkb0DhldJ5flLOue2v2fwuuAv+eva2w2Z4uW7Vhb Em8uTBeaVjmhBTIlBR6+uAosZVrkkxpm57L3o2Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=A+f5eC siv+6jx+ziJf5BqBnO2BQpO7Oa9PYzzE8yimU=; b=ItcUje77TbTFC6D+NxlqWs xVNZNtYz4RJ7o7VRalckuOe4q/3ZICCsbFS2A2IBi/arHBNHojwzV+9ab4mNHTSJ d/bUVab1EjSshqrsDQiPZYfVUJOBGM0jl0qdNhsImY7XkgT3zD+X/fsotBaniUk9 fCW/oXFxBmGRJhKfrdQCrn7XbeRjeGB+aAzl5SEupmyPotfWbKO/O5dkjk9ngQ2F 0brciIZU5OxPLDOZcLljq4ZWsJYT7ombik8z1+0/cSRlEY64QuGob7H6eizfuWUv cKdLdYgIlvkNWb3qSXBv8UMcVi4FLXBuGGDQHboivl+mSb4zrTVZDN6Eewbu/dxg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudelkedgieekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpefgieetgfevud etheffleehieevgfelleelhedtkeelueeliefhffdugeekgfelfeenucffohhmrghinhep ihgvthhfrdhorhhgpdhirggsrdhorhhgpdhmnhhothdrnhgvthenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghi thhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A99AD3C00A1; Mon, 29 Jun 2020 09:46:52 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668 Mime-Version: 1.0 Message-Id: <91a4e537-dd46-43e4-958d-5c9811d62f63@www.fastmail.com> In-Reply-To: References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> <3EDDC9C7-BA91-4E18-AB1C-8E77E95627B2@mnot.net> <065dd700-9666-6c88-5016-0668ed966884@gmail.com> Date: Mon, 29 Jun 2020 06:46:32 -0700 From: "Christopher Wood" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 13:46:56 -0000 On Mon, Jun 29, 2020, at 6:05 AM, Eric Rescorla wrote: > > > On Sun, Jun 28, 2020 at 7:01 PM Brian E Carpenter > wrote: > > On 29-Jun-20 12:23, Mark Nottingham wrote: > > > The suggestion was to have more than one more specialised role, not to promote 'leadership by committee.' This has been discussed a number of times previously, due to the very high bar created by the combination of requirements we current place on the position (as Martin mentioned). > > > > Certainly splitting the IT project management role (a.k.a. xml2rfcv3) from the Series Editor role is very desirable. A no-brainer, in fact. > > > > But anyone with experience (even as an author) with journal publishing knows that the role of an Editor, aided by an editorial board, is essential. > > Well, as it happens, I have journal publishing experience as an author, > and I'm not sure I agree with this. > > Moreover, the function of Editor of a journal is really much more like > the function of Program Committee chair in a conference. I..e., to > select the material to be published. That is not the case here. +1 -- this matches my experience as a journal author, too. Best, Chris > > If we want the RFC Series to be more than a copy shop, we need such a person. > > Well, this seems like the place to start: what do we want the RFC > Series to be. As I said earlier, I see the primary purpose to be > publishing technical specifications. The requirements for the RFC > Series to successfully fulfill that functin seem relatively modest. > > > > The board may well be small, as Nevil suggests, but part of its role is to consult the community. We have lots of running code proof that the community on its own doesn't produce consensus; we need some focus point to extract a consensus, > > And yet, as I said, we have mechanisms for getting consensus on far > more weighty decisions. The reason I might be in favor of having some > kind of board is actually to *delegate* small decisions, not as a form > of getting consensus. But that naturally produces a division of labor > in which the board makes small decisions and the community makes big > ones. > > -Ekr > > > > > and the editorial board seems like a good solution for that. > > > > Regards > > Brian > > > > > > > > > > >> On 29 Jun 2020, at 10:14 am, Michael StJohns wrote: > > >> > > >> On 6/28/2020 7:50 PM, Joel M. Halpern wrote: > > >>> In my view, the reason we need a person to do this is that leadership by committee is essential equivalent to a recipe for disaster. And I do think we want leadership. > > >>> > > >>> Yours, > > >>> joel > > >> Strong +1 here. One of the reasons for having a senior person in this role is so that the attention paid to the strategic evolution of the series does not wax and wane based on the current hobbyhorses of the leadership or their companies, or upon other loud voices. I have no problems with those voices influencing strategy, but I have strong problems with those voices directing strategy - especially if they change directions every 6 months or a year. > > >> > > >> We've had at least 4 people with the "rare and difficult" [Aside: difficult?] combination of attributes so I'm not sure where Martin is coming from here. It may be that he doesn't agree that those are the right attributes for the role, but that's a whole other discussion. I would expect with some luck, and with an IETF that respects what an expert can bring to the role, we will be able to find someone who won't run screaming into the night after they meet us. > > >> > > >> Mike > > >> > > >> > > >> > > >>> On 6/28/2020 7:47 PM, Martin Thomson wrote: > > >>>> On Sat, Jun 27, 2020, at 13:01, Nevil Brownlee wrote: > > >>>>> I've updated my Internet Draft to include a suggestion of what an RSEB > > >>>>> (RFC Series Editorial Board) could be structured. Take a look at > > >>>>> https://www.ietf.org/id/draft-brownlee-rfc-series-and-rse-changes-01.html > > >>>> > > >>>> This is very much not what I had in mind. We should not insist on having a role that depends on finding an individual with a rare and difficult combination of attributes. And I don't think that you can support that function by taking a program with open participation and consensus processes and reduce that to 5 people (+stream manager ex officio) who are responsible for approving strategy. > > >>>> > > >>>> Perhaps you can start by explaining why you think we need to have an individual perform these functions. > > >>>> > > >>> > > >> > > >> > > >> -- > > >> Rfced-future mailing list > > >> Rfced-future@iab.org > > >> https://www.iab.org/mailman/listinfo/rfced-future > > > > > > -- > > > Mark Nottingham https://www.mnot.net/ > > > > > > > -- > > Rfced-future mailing list > > Rfced-future@iab.org > > https://www.iab.org/mailman/listinfo/rfced-future > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > From nobody Mon Jun 29 07:07: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 A7F2E3A0F22 for ; Mon, 29 Jun 2020 07:07:34 -0700 (PDT) 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 U3bEHt_RqI61 for ; Mon, 29 Jun 2020 07:07:33 -0700 (PDT) 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 86CD23A0F21 for ; Mon, 29 Jun 2020 07:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6909; q=dns/txt; s=iport; t=1593439652; x=1594649252; h=from:mime-version:subject:date:references:to:in-reply-to: message-id; bh=wa4EngO4lUIS7ArMemyCx4cuyh+sL60C96KJ6TlF/MM=; b=SL+9M76drAWYuYK191MVz0BJT5UJEJxrKQ1Je3eXUSz8bujMAafkLEqx dX5HLbHN4oB7lVEOKJ2fId/C440Rmop+DK62SUKl0Qahtq9jF5eZ2eNn4 RYwNsapmCpwvneCb+VDzdZSdAEWmHiq9LQT4INnDHTwPnBF+s5s2UPh0B M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C4BwBs9Ple/xbLJq1gHgEBCxIMgX8?= =?us-ascii?q?Lg20BIBKEXYkBiBSTbogVCwEBAQwBAS8EAQGERwKCKyU3Bg4CAwEBCwEBBQE?= =?us-ascii?q?BAQIBBgRthWeFbwEEASNFAxMLC0ICAlctgxKCXSCsA3aBMopngTiNAIIAgTg?= =?us-ascii?q?cgh8uPoEEhk8zgi0EkW6jCoJmgwWWNwMUCZEYjXysU4NQAgQGBQIVgWkjgVY?= =?us-ascii?q?zGggbFWUBgj89EhkNV41ejjE/A2cCBgEHAQEDCZECAQE?= X-IronPort-AV: E=Sophos; i="5.75,294,1589241600"; d="scan'208,217"; a="27522631" 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; 29 Jun 2020 14:07:28 +0000 Received: from [10.61.216.185] ([10.61.216.185]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 05TE7R8X013127 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 29 Jun 2020 14:07:28 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_9D930BEC-8E8F-4B43-9119-08F712D3AFD5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 29 Jun 2020 16:07:27 +0200 References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> <3EDDC9C7-BA91-4E18-AB1C-8E77E95627B2@mnot.net> <065dd700-9666-6c88-5016-0668ed966884@gmail.com> To: rfced-future@iab.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.216.185, [10.61.216.185] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 14:07:35 -0000 --Apple-Mail=_9D930BEC-8E8F-4B43-9119-08F712D3AFD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, > Moreover, the function of Editor of a journal is really much more like = the function of Program Committee chair in a conference. I..e., to = select the material to be published. That is not the case here. I observe that there are at least two distinct visions for the role of = RSE. I am hearing that some people want not much more than someone who = reports to the LLC, and that any changes should be initiated and managed = by the community or a committee, while others believe that the role = involves leadership and expertise. (There are other visions as well, = I=E2=80=99m sure). I think it would advance this group=E2=80=99s efforts if we all = acknowledged some facts on the ground. =20 The role that we are discussing is more that of the publisher than of = the editor you describe. A publisher sets standards for how copy = appears, provides for distribution channels, insures appropriate = cataloging, archiving, and similar services. The RSE has had a role in = all of the above over the past few years, under the auspices of RFC = 8728=E2=80=99s predecessors. Each of those aspects is likely to evolve = over time. This group could decide to hardcode all of those aspects. However, that = would require returning to the community for changes whose implications = we as a community may not be competent to understand. Along these same = lines, by way of example, do we want the RSE to have to come to the = community for an RFC to approve a web site redesign? I will hazard a = guess: probably not. None of us are UX people. While the RSE is one person or two might be an interesting question, = here is another one: might that change over time based on the scale of = the work?[*] If that is the case, I suggest that the entity ultimately = responsible for the series is the one who will be suited over time to = make that call, and will need appropriate authority to do so. I don=E2=80= =99t think this group wants to hard code that but I am willing to be = proved wrong. Let us also acknowledge the tussle here. At the end of the day, the = people in this room have to decide how much of their vision to encode = now versus how much to entrust to some representation, either in the = form of the RSE or the entities overseeing the RSE. Recognize that the = more we hard code now, the more will require review over time to keep = current. If you agree with the above, then we have but to create a structure to = manage evolving visions over time, and highlight a handful of points = that we wish to keep as invariants. Eliot [*] Indeed the scale of work increased enough that the RSE requested and = was given an increase in hours at least once in recent history. --Apple-Mail=_9D930BEC-8E8F-4B43-9119-08F712D3AFD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric,

Moreover, the function of Editor of a journal = is really much more like the function of Program Committee chair in a = conference. I..e., to select the material to be published. That is not = the case here.

I observe that there are at least two distinct visions for = the role of RSE.  I am hearing that some people want not much more = than someone who reports to the LLC, and that any changes should be = initiated and managed by the community or a committee, while others = believe that the role involves leadership and expertise. (There are = other visions as well, I=E2=80=99m sure).

I think it would advance this group=E2=80= =99s efforts if we all acknowledged some facts on the ground. =  

The = role that we are discussing is more that of the publisher than of the = editor you describe.  A publisher sets standards for how copy = appears, provides for distribution channels, insures appropriate = cataloging, archiving, and similar services.  The RSE has had a = role in all of the above over the past few years, under the auspices of = RFC 8728=E2=80=99s predecessors.  Each of those aspects is likely = to evolve over time.

This group could decide to hardcode all of those aspects. =  However, that would require returning to the community for changes = whose implications we as a community may not be competent to understand. =  Along these same lines, by way of example, do we want the RSE to = have to come to the community for an RFC to approve a web site redesign? =  I will hazard a guess: probably not.  None of us are UX = people.

While the RSE is one person or two might be an interesting = question, here is another one: might that change over time based on the = scale of the work?[*]  If that is the case, I suggest that the = entity ultimately responsible for the series is the one who will be = suited over time to make that call, and will need appropriate authority = to do so.  I don=E2=80=99t think this group wants to hard code that = but I am willing to be proved wrong.

Let us also acknowledge the tussle = here.  At the end of the day, the people in this room have to = decide how much of their vision to encode now versus = how much to entrust to some representation, either in the form of the = RSE or the entities overseeing the RSE.  Recognize that the more we = hard code now, the more will require review over time to keep = current.

If = you agree with the above, then we have but to create a structure to = manage evolving visions over time, and highlight a handful of points = that we wish to keep as invariants.

Eliot

[*] Indeed the scale of work increased = enough that the RSE requested and was given an increase in hours at = least once in recent history.


= --Apple-Mail=_9D930BEC-8E8F-4B43-9119-08F712D3AFD5-- From nobody Mon Jun 29 07:29: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 71D3A3A0F8A for ; Mon, 29 Jun 2020 07:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.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 EQWXwszZJb8K for ; Mon, 29 Jun 2020 07:29:11 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 9D8BB3A0F8F for ; Mon, 29 Jun 2020 07:29:10 -0700 (PDT) Received: (qmail 28615 invoked from network); 29 Jun 2020 14:29:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=6fc4.5ef9fab4.k2006; bh=tDYBnWaPMkmfnDKlB6gWNcSuY00uC9eXlVVdm/7TzT8=; b=haD9WqsEJP94QG69E2wq/HM33F0RAm1hEHurLCO5bT3qBYSIPje7fqzQgY1/rU8qO/RxOOrQII/WCtwTr6HAM13astCQLLCzncn+v5dSBueSij8L7Lw6QPGQJzGmxNVAYsMIz1pxz9XVFqouhWhOTsNPFGII0Wq8isu93GxckuRgLutwLtbzBoz0bbkh7eik0bubuyKUAocs2XDOeKT3hbxMdBNrKQbUUaJkD7XojRhMZJ58XnTIaAJCrsd31WiU Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 29 Jun 2020 14:29:08 -0000 Received: by ary.qy (Postfix, from userid 501) id 5500D1BD3CDD; Mon, 29 Jun 2020 10:29:10 -0400 (EDT) Date: 29 Jun 2020 10:29:10 -0400 Message-Id: <20200629142910.5500D1BD3CDD@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: caw@heapingbits.net In-Reply-To: <91a4e537-dd46-43e4-958d-5c9811d62f63@www.fastmail.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 14:29:13 -0000 In article <91a4e537-dd46-43e4-958d-5c9811d62f63@www.fastmail.com> you write: >> Well, as it happens, I have journal publishing experience as an author, >> and I'm not sure I agree with this. >> >> Moreover, the function of Editor of a journal is really much more like >> the function of Program Committee chair in a conference. I..e., to >> select the material to be published. That is not the case here. > >+1 -- this matches my experience as a journal author, too. There's a lot of different kind of editors. I've probably published at least as many books as anyone else here, and I've had acquisition editors, development editors, series editors, copy editors, and tech editors, often all of those for a single book. The RSE is somewhat like a series editor and development editor. In our scheme, the WG more or less maps onto the acquisition and devlopment editors, the RPC is the copy editors, and WG and IETF last call are the tech editors. Our processes are quite unusual and I don't think it's very useful to try to look for close analogies in different kinds of processing. R's, John From nobody Mon Jun 29 14:12:02 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 21AFF3A0D9F for ; Mon, 29 Jun 2020 14:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 Ky9f7GqY_K_1 for ; Mon, 29 Jun 2020 14:11:52 -0700 (PDT) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (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 E0F133A0D5D for ; Mon, 29 Jun 2020 14:11:52 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id 207so8242796pfu.3 for ; Mon, 29 Jun 2020 14:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=pOCsaxrPIZAid7xlD0PjmmYVBlhTsTWEWawQcJaatCA=; b=TMjwNDpoGkAz+Fcit0buxmsqKYudxItBDPxYWprOng82aaGkSKUlgctE8hn+eHqDxk VIBWPynbnGmAEKSUWa8BWztkshhCZLvJVeANh7hftUEYlt/gRg/fOIjnew7TwnYvjehE RIFzspbyl9gsgVsO/Kues8qTRi7IXgAP6++HNFT5eH/IptSsS2BMmwRep8EZqJcunyLI DUepm9LUoWkOgQIe1jfBFonEedSB6NwD0aKzGm27BmOIx7/t8YDVJKwpVUNlv1Z7yu0i VpYwJ9I6ql9tp3PgXiGonpkhD/WP+UDHoP7NLLzDQ+bkHi+4Prr3SJqlU2/JIXp1qiRE j2Iw== 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=pOCsaxrPIZAid7xlD0PjmmYVBlhTsTWEWawQcJaatCA=; b=fGPZkIKPel67R95WjTJhsgn/qPbbdBPtk215nMY70nSU22s2AXdZHCyFgGrjgKPFyq LptqNKUPnV/TQvCvf+n6ssUa/JgEqgVP0EDIlE7VHEgnjaBZm/c9mfBh1WQjNgCTDpy7 bJIev5uZgFDV+nelG88H+n/7UCnm591QHIQBBdI1n8y9nuXU3L3GVEL2vLq9elII0CwB 7yS+aS7tPXipIWT8OtT8sjmlSQMxlve074GBW/sZYljWZTQ+YaJKheKweB1tbOP78GjX aSHZcyR9xyoCdi8XK5prLf2ez6VYpH9oPNzOgdlFrNtnrvU2Ndcog/vZ9vzz1RfXgSSY wM8w== X-Gm-Message-State: AOAM530RcLfyITAsjyUQyICH+CVA455NyDuxQ2lp3RWdQtxzzumLl9MO 9jYMjp8CmEX4+A3gEDb8iLC6T7L21+E= X-Google-Smtp-Source: ABdhPJw7eE6v5pLHwFDG+GvMtx0I2EM38KM93M48LFMQDxRsvy3ftvVZ4EF1qP5/8PC/Gjx0kcajlQ== X-Received: by 2002:aa7:98c1:: with SMTP id e1mr16813637pfm.318.1593465112130; Mon, 29 Jun 2020 14:11:52 -0700 (PDT) Received: from [192.168.178.20] (203.90.69.111.dynamic.snap.net.nz. [111.69.90.203]) by smtp.gmail.com with ESMTPSA id y9sm517486pfr.184.2020.06.29.14.11.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 14:11:51 -0700 (PDT) To: Christian Huitema , rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> <3EDDC9C7-BA91-4E18-AB1C-8E77E95627B2@mnot.net> <065dd700-9666-6c88-5016-0668ed966884@gmail.com> <5c9262d8-c9f7-0599-8a65-3cf96c80b8dd@huitema.net> From: Brian E Carpenter Message-ID: Date: Tue, 30 Jun 2020 09:11:47 +1200 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: <5c9262d8-c9f7-0599-8a65-3cf96c80b8dd@huitema.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 21:12:00 -0000 On 29-Jun-20 17:55, Christian Huitema wrote: > > On 6/28/2020 7:00 PM, Brian E Carpenter wrote: >> On 29-Jun-20 12:23, Mark Nottingham wrote: >>> The suggestion was to have more than one more specialised role, not to promote 'leadership by committee.' This has been discussed a number of times previously, due to the very high bar created by the combination of requirements we current place on the position (as Martin mentioned). >> Certainly splitting the IT project management role (a.k.a. xml2rfcv3) from the Series Editor role is very desirable. A no-brainer, in fact. >> >> But anyone with experience (even as an author) with journal publishing knows that the role of an Editor, aided by an editorial board, is essential. > I think that's a very flawed analogy. The RSE does not operate as "an Editor, aided by an editorial board". True, the analogy is more with an Editor-in-Chief, with separate Editors in charge of different topics. I know people didn't like my analogy with a major newspaper, but actually a major newspaper has a Sports Editor, a Business Editor, a Local News Editor, an International News Editor, etc., all coordinated by the Editor-in-Chief. > Most of the classic editor function are delegated to the stream managers, and the discussion has pretty much established that the RSE has no say on the matter. In fact, it might be better to drop the E from the title, and call for something like an RFC Series Manager. There I disagree profoundly. If the RFC Series is to have overall consistency, it needs an Editor-in-Chief. It may also need a Production Manager and we've already seen that it needs an IT Manager. >> If we want the RFC Series to be more than a copy shop, we need such a person. The board may well be small, as Nevil suggests, but part of its role is to consult the community. We have lots of running code proof that the community on its own doesn't produce consensus; we need some focus point to extract a consensus, and the editorial board seems like a good solution for that. > > We have yet to see conclusive attempts at defining this community. You keep saying that, but we have defined it already: those who write RFCs plus those who use them (read them and implement them). How to *reach* that whole community is a real challenge, but not for this group IMHO. > There may well be a need to gather feedback from the readers of the RFC, with an eye towards making the standards more "readable". But it takes a leap of faith to believe that a board will actually do that. At the moment, nobody is clearly charged with that job. We can change that. > If in fact the the standards are so hard to read that people don't use them or don't implement them, that seems a problem that the IETF itself must solve. If it did not, the IETF products would slowly become irrelevant, and the discussion of the future of the RFC series would become quite academic. I agree that the IETF needs to solve that problem, but we are not here as part of the IETF. Regards Brian From nobody Mon Jun 29 14:13: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 104743A0D36 for ; Mon, 29 Jun 2020 14:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 VoFqPv4CCM2R for ; Mon, 29 Jun 2020 14:13:50 -0700 (PDT) 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 D9D5A3A0D2E for ; Mon, 29 Jun 2020 14:13:50 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id j4so7584852plk.3 for ; Mon, 29 Jun 2020 14:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vOIdP/w9yI2UYaOJbajZMOPNN4v4/seMNCMGzrQme+4=; b=WfEK8FpT/PAufbh0lNOUhjPfUnTjYUkjvD08nZL1OLGnBv76i2fTZZ102aHurzicbf yUALedel86d1nne/bV0VnvxIA5i8MVcOsrwYFSo6GXfDwzi8/G+8Jcqz7mPB2ld94+es lUQcI6eDCyLWcMBiSITYEqzRbH7W5qvtd5H2g+BoeveY1ZizIzXamiwwomY8RUhd6TO9 d4BAcdXFNs5x3EnAEtBWHgumCKUaPyyNeRI8t0BvllPoWkmJ9ID2B/dqkd6ypd5e6jyy 4W9P27fWSuU5w8DafufuLCGaiavt4n4usFrcV6S6KHZ61MQkzPeYq0hJpD+NjUWpQoi4 otHg== 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=vOIdP/w9yI2UYaOJbajZMOPNN4v4/seMNCMGzrQme+4=; b=omS73o8Bt7zIlgSs0Io4w/4HbfgsVmQk4RfXS6SEHLNMuCl0vIpnJaD/UrC5lauHeq 4EXkgnAWPQNSC8sDExSFiVNrze61nRsHn+yGO3k6KZKTy3e1MJD8MlVtFm1mweC8c2Rq 9sSETc3EBXwu7dFMnufjgr7v2+Rh/6NgInBcxWtOD/0VZf35u2+5XFBnZOy1xTKcOOA7 qcyYM0IExHMceN8NOAjVrEsqsUI+kjRB+Zx3QPp1m1PvK8Ue/Fr8Kbzxbjr3Cmag9ZF3 gtDRaN3Ql/wH+drCXarxLFc7z5tbH9KSTUz5p1HhOcIRSRDeI/UIgttB7jAA7NM0voqa 3gdw== X-Gm-Message-State: AOAM532fYxoTELcNf2qUzFtcd3wYzNF5WgIp++5qm5hFc1JdrXshpgSt loVJWUohtjH2tIsILrnjZbogrDrIrFQ= X-Google-Smtp-Source: ABdhPJyCjz2AWXyjNWflVHS69drg+8Pqq3sBAcjzDSvdMLByu0iKKc8o9VxdATFxrivuD/ivMDtUMw== X-Received: by 2002:a17:902:b40f:: with SMTP id x15mr14035682plr.164.1593465230108; Mon, 29 Jun 2020 14:13:50 -0700 (PDT) Received: from [192.168.178.20] (203.90.69.111.dynamic.snap.net.nz. [111.69.90.203]) by smtp.gmail.com with ESMTPSA id r16sm527717pfh.64.2020.06.29.14.13.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 14:13:49 -0700 (PDT) To: Eric Rescorla , John Levine Cc: rfced-future@iab.org References: <20200629015601.64A451BD0D2D@ary.qy> From: Brian E Carpenter Message-ID: Date: Tue, 30 Jun 2020 09:13:46 +1200 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: 7bit Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 21:13:52 -0000 On 30-Jun-20 01:07, Eric Rescorla wrote: > > > On Sun, Jun 28, 2020 at 6:56 PM John Levine > wrote: > > In article > you write: > >billions of nodes using a collaborative consensus-based process. I find it > >surprising that people think we can't use this process for the much lower > >stakes question of how our documents ought to be shaped. > > The hard bit is finding people who understand the publishing and > archival issues and also understand the very unusual culture of the > IETF. > > > I've heard that said, but it's not clear to me it's true. It would perhaps be useful to start by stating what the unique archival and publishing issues/requirements *are*. We had an expert on that topic until she resigned. Brian From nobody Mon Jun 29 14:20:10 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 6ED7F3A0D3D for ; Mon, 29 Jun 2020 14:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDyGs3ToHnnp for ; Mon, 29 Jun 2020 14:20:07 -0700 (PDT) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 DEB0B3A0D3A for ; Mon, 29 Jun 2020 14:20:07 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id b92so8553542pjc.4 for ; Mon, 29 Jun 2020 14:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8lVu9A9wnpEctHNzp4Hm1TwrGwXGJFD7JqmC/0eM2mo=; b=eVwFgFgFsZp2U/CRvrvHxYOS6h4iHODufvI9ofOplVhFnts8p45x3SOZQIScRiaiwz epH07ELhhKxw07xDIEp60t7SsSGQFwnK3bedkJhoS1/2nxmMiuKzLPVpLP/KvBqQv6Hh UPyFSHzO/3qAE1Btk4P5RV3Xy6Xm6rkjfuePtH2i6ikFKRqS2DlxIS4HPKRumtOUCB/2 D5j8GzldjvRZqLqz4QRCyu3KRLkw8BGCjYqvk+noxgr/O4UAGCnGwNIjFAUMsNzvNhyb j3xb9jrc2P4EXRL+JwgLeynWZj+yt1G9hqDW7W5cjraq+mGl7FYo1TyK59gcmkQLR2OX dvlA== 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=8lVu9A9wnpEctHNzp4Hm1TwrGwXGJFD7JqmC/0eM2mo=; b=mZlWxy7GhVV72ylwpKvCk2cQ/9JQpX8G6UfiTWjya3YAb0FAR1lJKfvgb2UZKJRgbN 831NnRdsQ8Y9g3suKNHLcdGoEJtfKk6XqK2GXQA08TgyCXdQaEpcgBUrBoccd0BhsQDI goz3ECzeYBm5HsLn0iBTJBX1DMxq1yAVDJmZcNUmPVqFbYvtN5bwWPJ2Lw5Au1z5Xjed uJ4UEeUVQyryNOFXWK+heUxN3yQjiaP+waKGJcuqId3cTndA8/8ROCi6CVYM561cee4b pKns5q+gN+Os1NEZnNj9aKnaRGn+xrltegGY36bRaul0WQsX0lylatjDb2b3wyKu8/c+ 4OHQ== X-Gm-Message-State: AOAM5309UnZGFOdvbYZn1m7Srv9nFFBxIK6yQfyI9vUW71htR3ic+Eap fHYNJHwzOpMdnjJQtJQxt+UQaq+a+9g= X-Google-Smtp-Source: ABdhPJzIHkW5C32bqQwYzztKjHdg6HPRu1VT+45emA0S/vxe4C7L2sowX4fXbzOtBJD0Mo+PheXKDw== X-Received: by 2002:a17:902:bd46:: with SMTP id b6mr3975011plx.187.1593465607402; Mon, 29 Jun 2020 14:20:07 -0700 (PDT) Received: from [192.168.178.20] (203.90.69.111.dynamic.snap.net.nz. [111.69.90.203]) by smtp.gmail.com with ESMTPSA id oc6sm374878pjb.43.2020.06.29.14.20.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 14:20:06 -0700 (PDT) To: John Levine , rfced-future@iab.org Cc: caw@heapingbits.net References: <20200629142910.5500D1BD3CDD@ary.qy> From: Brian E Carpenter Message-ID: Date: Tue, 30 Jun 2020 09:20:02 +1200 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: <20200629142910.5500D1BD3CDD@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 21:20:10 -0000 On 30-Jun-20 02:29, John Levine wrote: > In article <91a4e537-dd46-43e4-958d-5c9811d62f63@www.fastmail.com> you write: >>> Well, as it happens, I have journal publishing experience as an author, >>> and I'm not sure I agree with this. >>> >>> Moreover, the function of Editor of a journal is really much more like >>> the function of Program Committee chair in a conference. I..e., to >>> select the material to be published. That is not the case here. >> >> +1 -- this matches my experience as a journal author, too. > > There's a lot of different kind of editors. I've probably published at > least as many books as anyone else here, and I've had acquisition > editors, development editors, series editors, copy editors, and tech > editors, often all of those for a single book. > > The RSE is somewhat like a series editor and development editor. In > our scheme, the WG more or less maps onto the acquisition and > devlopment editors, the RPC is the copy editors, and WG and IETF last > call are the tech editors. > > Our processes are quite unusual and I don't think it's very useful to > try to look for close analogies in different kinds of processing. Agreed. There are no exact parallels. But it seems to me (somewhat as Eliot said) that there are two schools of thought here: people who think that the RFC Series is just a copy shop for whatever each stream wants to publish, or it is a genuine publishing house with consistent goals, standards and policies across the streams. And there are at least three distinct roles too: Editor-in-Chief/Publisher, IT Manager, Production Manager. Brian From nobody Mon Jun 29 14:27:28 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 A7F033A0D49 for ; Mon, 29 Jun 2020 14:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vkp6bhiLdtA for ; Mon, 29 Jun 2020 14:27:25 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 E41983A0BD8 for ; Mon, 29 Jun 2020 14:27:24 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id e4so19985153ljn.4 for ; Mon, 29 Jun 2020 14:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cZC2DFqVzFvV2m+hsZfUo73PJiak9ZeH9amYykv6ZZM=; b=t/NkQ1ECPvr2DoMAg9vTJXsGWOU7m16JoZuMved4VtXQGtwenK4JKEJwBf2TkOyiFL JQyOdzow0FW+tYuwty3vJIfLk5ZGqrOqv/7rCbCmwxneHJz+fCDltpIWWn1Vfs/xQKiS fGip9iCdREvjZNVVhP4U46QK0T2F/4hQmYETQ5AgHHrw/ZG5Xq3QorLw5Fpf7bVtxpvy wIIOOMCTj/fyXWmEgF1wI4S7ZmLg4pNUPBtoistePaTKQ5FrApnMygM4LolkiwQuM53O KW8kdmAMnW60TwIupOGlLJv2VHDGu8aIDPo49UOWXqkYPnIeMOJOfFaYPbzpsiYTRNTq HFLg== 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=cZC2DFqVzFvV2m+hsZfUo73PJiak9ZeH9amYykv6ZZM=; b=unGbo3WTaRjR7QKq9AD20tF3NvhVNX1Ix9YUiuow+tbTBx4vqeLWpEAqR+ZnxOqvXG 7wNmB1fbuscFLk53aYR1ypaL6ihOi1kq3kOfxtZkg7Us1ii3gMbd9IbOaz+StFXqDnaP uQYhZbIbFwG5mt7lg9Et96ebZqGbpVrz5QEbm9U4KLi4gYk63SSvP1DgWtp0UBJ7HrfT 5n+AwV5vYSM//qt+W4CUh1P/fukhwSIjtaJHM1ocSDTGF7l1K+srGN3mfuOj9MLSraUU Sx1XWG1uFvFGamKLXfD5u6OxrcCwYSTrBUQ2ziTIBu0trePdmrvBtuDR7QlUxBjQTIKz EYPA== X-Gm-Message-State: AOAM530GTblasHQQ/KFAzHrqhp6y5CYaodk0GXZPBfMPI91eu4WtyV5J soem3PR6DL0peo4um147/t08efWPHVnJVb8qQq69vQ== X-Google-Smtp-Source: ABdhPJyZYmhd798VZIAyeAzGKrEELoUT0JnzqEii/5mBkLoOi6GUXG8IdjWQzMA8TfO8jVQNEaQYor2C3j2UHc3UtlY= X-Received: by 2002:a2e:999a:: with SMTP id w26mr3611219lji.371.1593466043005; Mon, 29 Jun 2020 14:27:23 -0700 (PDT) MIME-Version: 1.0 References: <20200629015601.64A451BD0D2D@ary.qy> In-Reply-To: From: Eric Rescorla Date: Mon, 29 Jun 2020 14:26:46 -0700 Message-ID: To: Brian E Carpenter Cc: John Levine , rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000007491e405a93fb944" Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 21:27:27 -0000 --0000000000007491e405a93fb944 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 29, 2020 at 2:13 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 30-Jun-20 01:07, Eric Rescorla wrote: > > > > > > On Sun, Jun 28, 2020 at 6:56 PM John Levine johnl@iecc.com>> wrote: > > > > In article OW-6m87067JCSSfnDPOP-uiA@mail.gmail.com OW-6m87067JCSSfnDPOP-uiA@mail.gmail.com>> you write: > > >billions of nodes using a collaborative consensus-based process. I > find it > > >surprising that people think we can't use this process for the much > lower > > >stakes question of how our documents ought to be shaped. > > > > The hard bit is finding people who understand the publishing and > > archival issues and also understand the very unusual culture of the > > IETF. > > > > > > I've heard that said, but it's not clear to me it's true. It would > perhaps be useful to start by stating what the unique archival and > publishing issues/requirements *are*. > > We had an expert on that topic until she resigned. > Perhaps you have misunderstood me, but I am not talking about the details but rather about the overall requirements. For instance "this document needs to be readable for period X with technology cost Y". Those are areas which are informed by expertise perhaps but are requirements that we as a community need to set, not that can be deferred to experts. For instance, we might decide we don't care at all about documents being readable beyond 3 years from now (I think this would be foolish) in which case the situation would be simpler. -Ekr --0000000000007491e405a93fb944 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 29, 2020 at 2:13 PM Brian= E Carpenter <brian.e.car= penter@gmail.com> wrote:
On 30-Jun-20 01:07, Eric Rescorla wrote:
>
>
> On Sun, Jun 28, 2020 at 6:56 PM John Levine <johnl@iecc.com <mailto:johnl@iecc.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0In article <CABcZeBN57B409GY0uNOOSpn6v=3DOW-6m= 87067JCSSfnDPOP-uiA@mail.gmail.com <mailto:OW-6m87067JCSSfnDPOP-ui= A@mail.gmail.com>> you write:
>=C2=A0 =C2=A0 =C2=A0>billions of nodes using a collaborative consens= us-based process. I find it
>=C2=A0 =C2=A0 =C2=A0>surprising that people think we can't use t= his process for the much lower
>=C2=A0 =C2=A0 =C2=A0>stakes question of how our documents ought to b= e shaped.
>
>=C2=A0 =C2=A0 =C2=A0The hard bit is finding people who understand the p= ublishing and
>=C2=A0 =C2=A0 =C2=A0archival issues and also understand the very unusua= l culture of the
>=C2=A0 =C2=A0 =C2=A0IETF.
>
>
> I've heard that said, but it's not clear to me it's true. = It would perhaps be useful to start by stating what the unique archival and= publishing issues/requirements *are*.

We had an expert on that topic until she resigned.
Perhaps you have misunderstood me, but I am not talking about t= he details but rather about the overall requirements. For instance "th= is document needs to be readable for period X with technology cost Y".= Those are areas which are informed by expertise perhaps but are requiremen= ts that we as a community need to set, not that can be deferred to experts.= For instance, we might decide we don't care at all about documents bei= ng readable beyond 3 years from now (I think this would be foolish) in whic= h case the situation would be simpler.

-Ekr

--0000000000007491e405a93fb944-- From nobody Mon Jun 29 15:01: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 2DAF13A0D9A for ; Mon, 29 Jun 2020 15:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fm6BG6xV7Vs0 for ; Mon, 29 Jun 2020 15:01:32 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 654C13A0D99 for ; Mon, 29 Jun 2020 15:01:32 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id j12so8467060pfn.10 for ; Mon, 29 Jun 2020 15:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=OpuN2U4RWt0LMYBqoZPkrp3uHTVbW7bPqwBwcjDAo4Y=; b=EbwQMvKyG0B+/w0F6f9RTUSpG388dgHJBnGscbFUBgbz6dtV2TDq6s8fH7ku1axF85 EDQbIXJRz+gR8qjNHyjTRZ5igeF4eOojaUaueIso13M/svv0qnb9YoNdC2DBc6PTiU/N I/N0+ph06mMcwQmx/g18Ie9zyLjmljb9mdlJexCt/XvopQR+sQOPGEFcxWmlOcX0Hxdj Pgs/ih2l+1levEqSzZbTm+U8cRY29Vds/L5FOZ6A3L9GCUcDSOoAjF+4IWzXymHHPC/6 vUHSHZ1oaclJ6YxehzqLTVoKpe/7b8osRnSi9/dEi1RIFq6MPj0Esk24q4HEv0VK4Hs6 Qw4Q== 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=OpuN2U4RWt0LMYBqoZPkrp3uHTVbW7bPqwBwcjDAo4Y=; b=qYKJtt9Sx526HktDKt285Ql1LHVGDX/RsmKhpeCG4AK6O+sY63izWuVLunTR4ycWSK ohcAf2c4ydFwl4g7nd2Tqs28L0L4URKsPDOxlOTQRkP5o1Hea7Dhk1SK7eP0q5tt8N0F jxhbrzCnxGTkJLhzU5saZnoJ2Up3DA+TTxoWXp0LbgyPHYXmpM20dLtM16xbDWtMdk4G uPcsOuP0n/32eZDL6qrIA4I0lDVzwPSqzY7D8YHZTvaua1gkKHudUdWKI27Y30ENxcB6 bdR8IzXx9HwXBBIJCgYBmHJa1JloaGhmhRKISg6mswZof1nrJjpDpR7fAaM6fr7Emsx2 71AQ== X-Gm-Message-State: AOAM532kX8h2OXHp+frcDp1FVgW/ehITU2FvjRIFkcJc2oZ18XzlcN1L 5lU4WyIYG+AT8n4k0I1pzUtxc3OqsPg= X-Google-Smtp-Source: ABdhPJyUwI2wcz6fQKk3OQ3iQ3mrhOYyRS94keDGAubg1CUvSfSVNVuYlEvbk9elxGRTHsmsYruz2g== X-Received: by 2002:a62:2b96:: with SMTP id r144mr16066615pfr.272.1593468091420; Mon, 29 Jun 2020 15:01:31 -0700 (PDT) Received: from [192.168.178.20] (203.90.69.111.dynamic.snap.net.nz. [111.69.90.203]) by smtp.gmail.com with ESMTPSA id x9sm644011pgr.57.2020.06.29.15.01.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 15:01:30 -0700 (PDT) To: Eric Rescorla Cc: John Levine , rfced-future@iab.org References: <20200629015601.64A451BD0D2D@ary.qy> From: Brian E Carpenter Message-ID: <88e42e02-6266-18fc-2372-1c752c4f7b71@gmail.com> Date: Tue, 30 Jun 2020 10:01:27 +1200 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] Scope and IETF 108 proposals 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, 29 Jun 2020 22:01:35 -0000 On 30-Jun-20 09:26, Eric Rescorla wrote: >=20 >=20 > On Mon, Jun 29, 2020 at 2:13 PM Brian E Carpenter > wrote: >=20 > On 30-Jun-20 01:07, Eric Rescorla wrote: > > > > > > On Sun, Jun 28, 2020 at 6:56 PM John Levine >> wrote= : > > > >=C2=A0 =C2=A0 =C2=A0In article >> you write: > >=C2=A0 =C2=A0 =C2=A0>billions of nodes using a collaborative conse= nsus-based process. I find it > >=C2=A0 =C2=A0 =C2=A0>surprising that people think we can't use thi= s process for the much lower > >=C2=A0 =C2=A0 =C2=A0>stakes question of how our documents ought to= be shaped. > > > >=C2=A0 =C2=A0 =C2=A0The hard bit is finding people who understand = the publishing and > >=C2=A0 =C2=A0 =C2=A0archival issues and also understand the very u= nusual culture of the > >=C2=A0 =C2=A0 =C2=A0IETF. > > > > > > I've heard that said, but it's not clear to me it's true. It woul= d perhaps be useful to start by stating what the unique archival and publ= ishing issues/requirements *are*. >=20 > We had an expert on that topic until she resigned. >=20 >=20 > Perhaps you have misunderstood me, but I am not talking about the detai= ls but rather about the overall requirements. For instance "this document= needs to be readable for period X with technology cost Y". Those are are= as which are informed by expertise perhaps but are requirements that we a= s a community need to set, not that can be deferred to experts. For insta= nce, we might decide we don't care at all about documents being readable = beyond 3 years from now (I think this would be foolish) in which case the= situation would be simpler. Sure, of course the community has to establish requirements. But translat= ing that into archiving requirements as understood by archivists, nationa= l libraries, etc. is a different matter. And of course somebody has to ru= n the community process. Brian =20 From nobody Mon Jun 29 15:41:20 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 9D7663A0DCC for ; Mon, 29 Jun 2020 15:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 LSDp1YvoDqLk for ; Mon, 29 Jun 2020 15:41:18 -0700 (PDT) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E553A0DCB for ; Mon, 29 Jun 2020 15:41:18 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id b184so2109421pfa.6 for ; Mon, 29 Jun 2020 15:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=x1XRrzMsXrK5m7DyMOYDFlgwlY54Kn/ttC06paDGFuQ=; b=YB35KvCJ8MbovtPbgFMttXxTNm/drkul5x0ZJBMBK20i+TLyohuTPTIaRAV8FPqtIA coPlcM+OyRXJhcSwYmZGyNrRnvm4DDT+nh7dFrMTFczFhV5Fpur6mUe1+gyaMdbpx8GO ByfuLQNdJJxlUSzyqHX4FSskeBOfwy5RBot7M3he7SmTRdYXdeSm5gLAFyi7tdBp5EX9 EtUJoq+4jhKIkv0YdDY5RCh8a3yurr1E4ujX6ZZWM+Ua6ULrw/pziGNBGcBxdrzHCVb3 uthrVaQUc2E7GOCqIxmjs7KiYvbnIqPz7Oz7mkncw7/YvofmeECBse36DDSFOnz3xoPW m2tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:thread-index:content-language; bh=x1XRrzMsXrK5m7DyMOYDFlgwlY54Kn/ttC06paDGFuQ=; b=BLYtnzfYAzjkDuyTYEwVwZWuYptfUM/7AD6mi1BXiX1ysGRYIG0lS7uDx59UBfXm4m 1mp+oyw1g2+F4Z6YpNaSEuVeyR32TC5KDJTQrgVZYv/IM5t5vWiv1tkvq8Mq0mfHwmfR MHFU01ev0ZxO5mYuiUikMMe3KeKSJl4sPzuv0j6RnzYfnkq023id3m7WshzyTwny5S2V R01H+2ZZXfOFYR7jOXasadKtSI3AmX8SZaA2IeQlbj9gImejdcRNVeDeD9W3n/uP+9Rd g9AheKxqy25nz0BoWcriV3Lz/Hao67/GDibYF/Klf/IFtxEhVBKLZwe3y2ccePJlJApn ufrQ== X-Gm-Message-State: AOAM532GVlkZNvh6hoc0+/GVEdI8QKQ5cgg+/sYZLON7s6nRdelh/iog vU3WTLnJuCghUSA4u78onw8= X-Google-Smtp-Source: ABdhPJwordFzZ4Y8Ncspr1r2QngsVxqaCOA3JQWPSYlHPj3QntsCb0fDooiLybCBrFVi4f3dXNCdtA== X-Received: by 2002:a63:9d87:: with SMTP id i129mr12415534pgd.412.1593470477426; Mon, 29 Jun 2020 15:41:17 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id n37sm676175pgl.82.2020.06.29.15.41.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 15:41:16 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Eric Rescorla'" , "'Brian E Carpenter'" Cc: "'John Levine'" , References: <20200629015601.64A451BD0D2D@ary.qy> In-Reply-To: Date: Mon, 29 Jun 2020 15:41:16 -0700 Message-ID: <016101d64e66$66f17820$34d46860$@acm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0162_01D64E2B.BA931550" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLvI7tyZIX1X9Mv/VbUdB7xEH4onAFL3vHGAcWk0CICGBlrAQL9SA0Qpn1BgnA= Content-Language: en-us Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 22:41:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0162_01D64E2B.BA931550 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ekr wrote: =20 * I am not talking about the details but rather about the overall = requirements. For instance "this document needs to be readable for = period X with technology cost Y". Those are areas which are informed by = expertise perhaps but are requirements that we as a community need to = set, not that can be deferred to experts. For instance, we might decide = we don't care at all about documents being readable beyond 3 years from = now (I think this would be foolish) in which case the situation would be = simpler. =20 The archive requirements for RFCs are not so different than the archive = requirements for any other documents: avoid single points of failure, = and commit to detect and repair them over the lifetime of the series. =20 For document formats, choose those for which there are open, wide = availability of documentation and have multiple, independent, = interoperable implementations of every feature used.=20 Documents also need to be self-contained, in that their interpretation = and use shouldn=E2=80=99t depend on external resources not part of the = document,=20 =20 Text or XML with obscure Unicode used in normative segments, some = non-tiny SVG features, non-PDF/A features would be areas of concern=20 -- https://LarryMasinter.net ------=_NextPart_000_0162_01D64E2B.BA931550 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Ekr wrote:

 

  • I am not talking = about the details but rather about the overall requirements. For = instance "this document needs to be readable for period X with = technology cost Y". Those are areas which are informed by expertise = perhaps but are requirements that we as a community need to set, not = that can be deferred to experts. For instance, we might decide we don't = care at all about documents being readable beyond 3 years from now (I = think this would be foolish) in which case the situation would be = simpler.

 

The archive = requirements for RFCs are not so different than the archive requirements = for any other documents: avoid single points of failure, and commit to = detect and repair them over the lifetime of the series.

 

For = document formats, choose those for which there are open, wide = availability of documentation and have multiple, independent, = interoperable implementations =C2=A0of every feature used. =

Documents also need to be = self-contained, in that their interpretation and use shouldn=E2=80=99t = depend on external resources not part of the document,

 

Text or XML = with obscure Unicode used in normative segments, some non-tiny SVG = features, non-PDF/A features would be areas of concern

--

https://LarryMasinter.net

------=_NextPart_000_0162_01D64E2B.BA931550-- From nobody Mon Jun 29 15:49:06 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 2D13F3A0E25 for ; Mon, 29 Jun 2020 15:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMHjTx_x5tlr for ; Mon, 29 Jun 2020 15:48:56 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4B73A0E10 for ; Mon, 29 Jun 2020 15:48:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49wjMr0cKkz6GJjq; Mon, 29 Jun 2020 15:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1593470936; bh=mKOQPMfRV8eHoBOAn7TcXdo8BEPUnANLmkA3q/fbHHc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Pg1O3Ryrb/5e7XTZ1qaT/nU3jtrumt9h1ftRTDmDs4UFpJerS/gVACmPDGHeiuLzL ozBt1SnVZs0IQqTJkjagFgU40VnkzDP4fpXP9qRX3+HBAjVfgTbId4jLueQoCBVXKU pL4q4m4QbrczftGc8UoOO47mXgg/KD6lJPb8dBZM= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (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 49wjMq0K96z6GJgd; Mon, 29 Jun 2020 15:48:54 -0700 (PDT) To: Larry Masinter , 'Eric Rescorla' , 'Brian E Carpenter' Cc: 'John Levine' , rfced-future@iab.org References: <20200629015601.64A451BD0D2D@ary.qy> <016101d64e66$66f17820$34d46860$@acm.org> From: "Joel M. Halpern" Message-ID: <9ec74f34-3a43-1797-962b-7d2713f3500b@joelhalpern.com> Date: Mon, 29 Jun 2020 18:48:53 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <016101d64e66$66f17820$34d46860$@acm.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 22:49:06 -0000 Actually, the archive requirements that we strove to meet were much stricter than that. Whether that was strictly the requirement, or merely the understanding of the RSE, the RSOC, and the RSAG, I leave to others to deal with. Yours, Joel On 6/29/2020 6:41 PM, Larry Masinter wrote: > Ekr wrote: > > * I am not talking about the details but rather about the overall > requirements. For instance "this document needs to be readable for > period X with technology cost Y". Those are areas which are informed > by expertise perhaps but are requirements that we as a community > need to set, not that can be deferred to experts. For instance, we > might decide we don't care at all about documents being readable > beyond 3 years from now (I think this would be foolish) in which > case the situation would be simpler. > > The archive requirements for RFCs are not so different than the archive > requirements for any other documents: avoid single points of failure, > and commit to detect and repair them over the lifetime of the series. > > For document formats, choose those for which there are open, wide > availability of documentation and have multiple, independent, > interoperable implementations  of every feature used. > > Documents also need to be self-contained, in that their interpretation > and use shouldn’t depend on external resources not part of the document, > > Text or XML with obscure Unicode used in normative segments, some > non-tiny SVG features, non-PDF/A features would be areas of concern > > -- > > https://LarryMasinter.net > > From nobody Mon Jun 29 16:17: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 F40D43A0E1D for ; Mon, 29 Jun 2020 16:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTmt4ClzkXpH for ; Mon, 29 Jun 2020 16:17:29 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 0B6223A0E18 for ; Mon, 29 Jun 2020 16:17:29 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id 9so20259285ljc.8 for ; Mon, 29 Jun 2020 16:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K03lH/GWYRiDc3YZXuCiChRfW3GC6diCBsnU/4k6RbU=; b=Z90mNy4J9n30Q0jAnhVc6BlnLGaS6tr2sISfN9n7g+fOCiOvyMWHWi5TA7iLSnQOND Mxd2L9aD3qR0QFIg/VWcXzKbjamwh2J8Pz4liAknVkr5EJqSoBQH3Esr+VgfFzFadSwr 3QH9l8Amniw2GOnTpQB3rQ7ngnW47je2N/mO7pkTVEfrN8osh5ePprnYj8ZltUWlZnrb ncfISR/45Y6HwyybNITYIePTOl7M9fGcv0wHSRD8+n8OPSxfqGDWTz/+Upj7STszAyc8 zUmlbvoYutqOMXFSzCraPup4OkTIUGHbik895nCukugPMCl9XVuRib65+sQqvdkQ7lKz b08A== 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=K03lH/GWYRiDc3YZXuCiChRfW3GC6diCBsnU/4k6RbU=; b=hptK8j/hMjdcUuCaWX1PSTOZHm08hax37BATjeQOkISpWLOg1Q1mdL84iinKX45Ioh bVoCVpco/R58Cp2wTARa+bgEcHF9fHnfQmLEAZASXjyK3AFGQh43VwMa15Opz9yDmUxU WiqKIyasEBO7hGvkjB8BjZOMn1LBmFqJJ4EwH1VmbQ8tXfgQXEWJHmVMghgFfQXzFxs2 wBSSIWzyIRWaq+E3MPo/kTLvuo4uKBJQWY+DjXIZVFJAlLXzm2T4I+rRMDal2w+9IBAR EO6Rq+DMznmkerzZsv9ufaN+TSxSzm9F+5ERDHMZw9w8gqW7Qg17uHAg2ST7tuUgt4LF fo8Q== X-Gm-Message-State: AOAM531/VANMMvKf7uqsTmo7OXYZelpz5O0muwAyYNNRyx5zdHlWlNQy JNt6EIPxo3Xgh0kqVwRR2ffHNx/xFzzE6AL86fY4YQ== X-Google-Smtp-Source: ABdhPJxVncSg7GeXU6SR9b1WkMK6mdEnQmJwR5U3OPvv8AuOwCt/oIAkBruFf3xwunyaTGV410p9GMwzYy3eFsiJ1sI= X-Received: by 2002:a2e:3311:: with SMTP id d17mr7210962ljc.13.1593472647092; Mon, 29 Jun 2020 16:17:27 -0700 (PDT) MIME-Version: 1.0 References: <20200629015601.64A451BD0D2D@ary.qy> <88e42e02-6266-18fc-2372-1c752c4f7b71@gmail.com> In-Reply-To: <88e42e02-6266-18fc-2372-1c752c4f7b71@gmail.com> From: Eric Rescorla Date: Mon, 29 Jun 2020 16:16:50 -0700 Message-ID: To: Brian E Carpenter Cc: John Levine , rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000016f48105a94143c2" Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 29 Jun 2020 23:17:31 -0000 --00000000000016f48105a94143c2 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 29, 2020 at 3:01 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 30-Jun-20 09:26, Eric Rescorla wrote: > > > > > > On Mon, Jun 29, 2020 at 2:13 PM Brian E Carpenter < > brian.e.carpenter@gmail.com > wrote: > > > > On 30-Jun-20 01:07, Eric Rescorla wrote: > > > > > > > > > On Sun, Jun 28, 2020 at 6:56 PM John Levine >> > wrote: > > > > > > In article OW-6m87067JCSSfnDPOP-uiA@mail.gmail.com OW-6m87067JCSSfnDPOP-uiA@mail.gmail.com> OW-6m87067JCSSfnDPOP-uiA@mail.gmail.com OW-6m87067JCSSfnDPOP-uiA@mail.gmail.com>>> you write: > > > >billions of nodes using a collaborative consensus-based > process. I find it > > > >surprising that people think we can't use this process for > the much lower > > > >stakes question of how our documents ought to be shaped. > > > > > > The hard bit is finding people who understand the publishing > and > > > archival issues and also understand the very unusual culture > of the > > > IETF. > > > > > > > > > I've heard that said, but it's not clear to me it's true. It would > perhaps be useful to start by stating what the unique archival and > publishing issues/requirements *are*. > > > > We had an expert on that topic until she resigned. > > > > > > Perhaps you have misunderstood me, but I am not talking about the > details but rather about the overall requirements. For instance "this > document needs to be readable for period X with technology cost Y". Those > are areas which are informed by expertise perhaps but are requirements that > we as a community need to set, not that can be deferred to experts. For > instance, we might decide we don't care at all about documents being > readable beyond 3 years from now (I think this would be foolish) in which > case the situation would be simpler. > > Sure, of course the community has to establish requirements. But > translating that into archiving requirements as understood by archivists, > national libraries, etc. is a different matter. Sure. But we first need to understand what those requirements are and then we will understand the extent to which they in fact need to be translated into requirements which are understood by archivists, national libraries, etc. > And of course somebody has to run the community process. > Yes. In other context we call that a WG chair. -Ekr > Brian > > > --00000000000016f48105a94143c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 29, 2020 at 3:01 PM Brian= E Carpenter <brian.e.car= penter@gmail.com> wrote:
On 30-Jun-20 09:26, Eric Rescorla wrote:
>
>
> On Mon, Jun 29, 2020 at 2:13 PM Brian E Carpenter <brian.e.carpenter@gmail.co= m <mailto:brian.e.carpenter@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 30-Jun-20 01:07, Eric Rescorla wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Sun, Jun 28, 2020 at 6:56 PM John Levine &l= t;johnl@iecc.com &l= t;mailto:johnl@iecc.com= > <mailto:joh= nl@iecc.com <mailto:johnl@iecc.com>>> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0In article <CABcZeBN57B4= 09GY0uNOOSpn6v=3DOW-6m87067JCSSfnDPOP-uiA@mail.gmail.com <mailto:<= a href=3D"mailto:OW-6m87067JCSSfnDPOP-uiA@mail.gmail.com" target=3D"_blank"= >OW-6m87067JCSSfnDPOP-uiA@mail.gmail.com> <mailto:OW-6m87067JCS= SfnDPOP-uiA@mail.gmail.com <mailto:OW-6m87067JCSSfnDPOP-uiA@mail.g= mail.com>>> you write:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>billions of nodes using= a collaborative consensus-based process. I find it
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>surprising that people = think we can't use this process for the much lower
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>stakes question of how = our documents ought to be shaped.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0The hard bit is finding peo= ple who understand the publishing and
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0archival issues and also un= derstand the very unusual culture of the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0IETF.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I've heard that said, but it's not cle= ar to me it's true. It would perhaps be useful to start by stating what= the unique archival and publishing issues/requirements *are*.
>
>=C2=A0 =C2=A0 =C2=A0We had an expert on that topic until she resigned.<= br> >
>
> Perhaps you have misunderstood me, but I am not talking about the deta= ils but rather about the overall requirements. For instance "this docu= ment needs to be readable for period X with technology cost Y". Those = are areas which are informed by expertise perhaps but are requirements that= we as a community need to set, not that can be deferred to experts. For in= stance, we might decide we don't care at all about documents being read= able beyond 3 years from now (I think this would be foolish) in which case = the situation would be simpler.

Sure, of course the community has to establish requirements. But translatin= g that into archiving requirements as understood by archivists, national li= braries, etc. is a different matter.

Sure. = But we first need to understand what those requirements are and then we wil= l understand the extent to which they in fact need to be translated into re= quirements which are understood by archivists, national libraries, etc.

=C2=A0
And of course somebody has to run the community process.
=

Yes. In other context we call that a WG ch= air.

-Ekr


=C2=A0 =C2=A0 Brian


--00000000000016f48105a94143c2-- From nobody Mon Jun 29 18:12: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 4CB603A0EF9 for ; Mon, 29 Jun 2020 18:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.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 GP7JEJIz9BfW for ; Mon, 29 Jun 2020 18:12:25 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 7DA923A0EF6 for ; Mon, 29 Jun 2020 18:12:25 -0700 (PDT) Received: (qmail 74455 invoked from network); 30 Jun 2020 01:12:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=122d5.5efa9177.k2006; i=johnl-iecc.com@submit.iecc.com; bh=TLh324cm8KxieHyUZ5UzW99Iq3w8u9y0g24xaKZVnWg=; b=sY0Toql+6sRuNw0ZNUFgFV2WotmpayEzJxz/L53pm7BIG6BSKRF42kCm51tahmvmSf3QWbFIFHfzFMjMw6fBTQCn/JGb9aiSjN3uIIWLPbBrgm2tgomlRj75/QUbk3nwUasrBGe3sPpf3F7iqu/xpF+bMa2KVenfiQ2rcQ+n1uhPrwHBHIKhqIs3BE4jtpeZHYX/emuxLqp5kMlU6GDurmsQuJ4AJZCpQmEZB6jWlyDL53f4PjQLTryvXZE2h4ha Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 30 Jun 2020 01:12:23 -0000 Date: 29 Jun 2020 21:12:26 -0400 Message-ID: From: "John R. Levine" To: "Eric Rescorla" , "Brian E Carpenter" Cc: rfced-future@iab.org In-Reply-To: References: <20200629015601.64A451BD0D2D@ary.qy> <88e42e02-6266-18fc-2372-1c752c4f7b71@gmail.com> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 30 Jun 2020 01:12:27 -0000 >>> > I've heard that said, but it's not clear to me it's true. It would >> perhaps be useful to start by stating what the unique archival and >> publishing issues/requirements *are*. We went through a rather long process to come up with RFC 7990 which describes the current plan for XML and output formats and such. We still have some work to do to get to the place that 7990 describes but I think this particular part of the ocean does not need reboiling. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Jun 29 18:46:59 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 593E83A0F0C for ; Mon, 29 Jun 2020 18:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=XgJJwdtg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gJsUVzJ/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUPTAGCVSD-L for ; Mon, 29 Jun 2020 18:46:54 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3443A0F07 for ; Mon, 29 Jun 2020 18:46:54 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 70F805C019E; Mon, 29 Jun 2020 21:46:53 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 29 Jun 2020 21:46:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=X CY7OwAlEVp7h7h+u4YEAS/THSW6cMnanPywZirVgVA=; b=XgJJwdtg1tFt/znV3 tJUQoUcasr1a4bM9b3xXT6SuW+yY65vKQIVOj8Y+hHvv553fxnLwkqn7SZBRFlL0 p+6lVzYl/YVb5MUCSWtOvhLqMMpGd6gJX1yGrvzMy5DxmqMG5hkclFJFMhJEZAb/ 9RXZMNZO4C012Hr1uhawNUiR85g/boDsP4+WWVZY+zU/jvqL/mlHCVF7uDdwgASU gTo8RtMXygGEjLAKIf6GghzctM6v+bVCeXvm8UXKSmjFeIQucYPyPtn1te6fQ1+S hIlusLPds2pI/nQ06QRZa/j+vL0CyCAXFHUznBs4QBED/42V7M+33g9qrUs+DoKY yxREw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=XCY7OwAlEVp7h7h+u4YEAS/THSW6cMnanPywZirVg VA=; b=gJsUVzJ/HU5yJEpJOnIzCBSHjIyOYgo12Lv0w6m6NmUwJHOzI3puSnDq+ YscvqMXplvFL6nVcQAQmBCMF1Z25kt6hjlljpmECpaqzYKmOR+36Ij3zOw4Im40F kWlvnFRJXtNSqZzUxTLKuDtB9S6Ja1e4/N7/O8WxUZxiXZECh6JS6MRNupkgPBK5 gHmc7JDSjAaHAqnQeKUMDFEeF5tsVPqbMdB9VxCHpeO4/j4TvdIiIOTNpEof5kd2 PXU3RrncJgv/I6IfG45yWDvTXQUbnc/gRfgrtVXaBDiAWB+qRRdEVlEo9U43Z16E RQSsJMUhIHbm+y0A/Wrzrk0ccXyUA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrvddttddgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeetfeelffejfffhheehfeefgedulefgueejudekieegvdeghefffedvheffieel keenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvd ehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 63A4D306005F; Mon, 29 Jun 2020 21:46:51 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: Date: Tue, 30 Jun 2020 11:46:48 +1000 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <5964B848-AA04-43F4-AF39-06126721A686@mnot.net> References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> <3EDDC9C7-BA91-4E18-AB1C-8E77E95627B2@mnot.net> <065dd700-9666-6c88-5016-0668ed966884@gmail.com> To: Eliot Lear X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 30 Jun 2020 01:46:57 -0000 Hi Eliot, > On 30 Jun 2020, at 12:07 am, Eliot Lear = wrote: >=20 > Hi Eric, >=20 >> Moreover, the function of Editor of a journal is really much more = like the function of Program Committee chair in a conference. I..e., to = select the material to be published. That is not the case here. >=20 > I observe that there are at least two distinct visions for the role of = RSE. I am hearing that some people want not much more than someone who = reports to the LLC, and that any changes should be initiated and managed = by the community or a committee, while others believe that the role = involves leadership and expertise. (There are other visions as well, = I=E2=80=99m sure). >=20 > I think it would advance this group=E2=80=99s efforts if we all = acknowledged some facts on the ground. =20 >=20 > The role that we are discussing is more that of the publisher than of = the editor you describe. A publisher sets standards for how copy = appears, provides for distribution channels, insures appropriate = cataloging, archiving, and similar services. The RSE has had a role in = all of the above over the past few years, under the auspices of RFC = 8728=E2=80=99s predecessors. Each of those aspects is likely to evolve = over time. I think the analogies we're using have reached the end of their = usefulness; it would be better to make a clean break from them, and talk = about the concrete responsibilities at hand. > This group could decide to hardcode all of those aspects. However, = that would require returning to the community for changes whose = implications we as a community may not be competent to understand. = Along these same lines, by way of example, do we want the RSE to have to = come to the community for an RFC to approve a web site redesign? I will = hazard a guess: probably not. None of us are UX people. You're presuming a lot about the breadth of the community there. And, = even if a particular skill is relatively rare in our community, it = doesn't mean that we should design things to shut out their input. > While the RSE is one person or two might be an interesting question, = here is another one: might that change over time based on the scale of = the work?[*] If that is the case, I suggest that the entity ultimately = responsible for the series is the one who will be suited over time to = make that call, and will need appropriate authority to do so. I don=E2=80= =99t think this group wants to hard code that but I am willing to be = proved wrong. To me, that suggests that we want the 'top' entity to be someone who's = responsible, but willing to delegate; i.e., a position that is likely = elected (or otherwise community selected) and NOT compensated. They can = then source the expertise which needs to be compensated as appropriate. > Let us also acknowledge the tussle here. At the end of the day, the = people in this room have to decide how much of their vision to encode = now versus how much to entrust to some representation, either in the = form of the RSE or the entities overseeing the RSE. Recognize that the = more we hard code now, the more will require review over time to keep = current. >=20 > If you agree with the above, then we have but to create a structure to = manage evolving visions over time, and highlight a handful of points = that we wish to keep as invariants. Agreed. We really need to stop fixating on the minutia of the series and = look at the big picture here. -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jun 30 20:03: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 3F1183A09E8 for ; Tue, 30 Jun 2020 20:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 1__QGgtNftjT for ; Tue, 30 Jun 2020 20:03:24 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 6CCA23A09E4 for ; Tue, 30 Jun 2020 20:03:24 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id o13so7998896pgf.0 for ; Tue, 30 Jun 2020 20:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=gaHQ7IRv2BAGq8p86ktStRMJq2mK0GlPaY5wlDfT0Jo=; b=GX/wWDbH962SS07p8vQpCz8EiRmSPcfS2XgkzODp+d48axYaQ7SXpFfqIk688QXjMf 4nG3gO3pN+PSZlrN36VjS0ceZGngkDNPtBdoh9IyAF8vNySNPYGivDxzyb83O2A6NNkc 5MrvTdNROP1Vx4Vf/Ta0k19HchfYmFV/IQLx5RpPTun2oh6uOnKHEg4ovYX/kGTUCx+6 c9lFBxET36M5lYmxglU+39laFxA3KifYP5eLC1zFaaCPVsXscPOG4wbXSUu5CxNsFKjb CuKH1mDk6BL1ecJVVf6Fgr59w7RwtID9sPnyGJmf20KeQWjrPBrfPwp47sD+HXXbaHeq VNAQ== 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=gaHQ7IRv2BAGq8p86ktStRMJq2mK0GlPaY5wlDfT0Jo=; b=LcGSo/wUYD7iiWWrYxO6YC34cHULtcQrPzajsKoKZcZQKXmAzvGV/OLD/tBswvv6vs qflUkJGMhMQO7hasLRKe+8h7qc4jaB4new5ViK1L4ivI2QlbYHBE2/fS/mqatPdnAQSG Q3g59g3dsK2BDDf3+LsJ2wLz3YBUOFKklsFRsDmjAC9pRr9fav+RLDKJNGMMAwoil1tw MvA5xS73rZ0a6HzwLxmhDMn7R8PNt0nDv59Pq5mVzIa3+8UIxwwVJL8wM9+C7r1iXHdq pmyXcGVhz4Pqh6160MDmy7vJ3uidS1qtiYBTpzVkYuNJIDcQMzRVwm+CT2KESIzPJAV4 9hvQ== X-Gm-Message-State: AOAM531hye770BDdOx2TeE+8zKxoc/2Mthi9eDFmasm48d1NCA4H28gS 1lief1oJx8kAaDoRlC5/cOmro6CV X-Google-Smtp-Source: ABdhPJx7PwwnJVwjLTDwTn6DX8/ZP6V1sIDwwPXSSIwRHeBODbcqKSY+XGkxxQ8e6s5MZEJYY97gLw== X-Received: by 2002:a62:55c3:: with SMTP id j186mr21864674pfb.237.1593572603638; Tue, 30 Jun 2020 20:03:23 -0700 (PDT) Received: from [192.168.178.20] (102.124.69.111.dynamic.snap.net.nz. [111.69.124.102]) by smtp.gmail.com with ESMTPSA id o8sm3721729pgb.23.2020.06.30.20.03.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2020 20:03:23 -0700 (PDT) To: Mark Nottingham , Eliot Lear Cc: rfced-future@iab.org References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> <1b6cf5e6-2c16-d839-08dd-d005d4fdbc60@gmail.com> <3678427d-6496-45c7-bd1b-14d7f860c971@www.fastmail.com> <3EDDC9C7-BA91-4E18-AB1C-8E77E95627B2@mnot.net> <065dd700-9666-6c88-5016-0668ed966884@gmail.com> <5964B848-AA04-43F4-AF39-06126721A686@mnot.net> From: Brian E Carpenter Message-ID: <7e8407c8-5d9b-a256-b115-4e4e18643e5d@gmail.com> Date: Wed, 1 Jul 2020 15:03:20 +1200 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: <5964B848-AA04-43F4-AF39-06126721A686@mnot.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Scope and IETF 108 proposals 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, 01 Jul 2020 03:03:26 -0000 On 30-Jun-20 13:46, Mark Nottingham wrote: > Hi Eliot, >=20 >> On 30 Jun 2020, at 12:07 am, Eliot Lear wrote: >> >> Hi Eric, >> >>> Moreover, the function of Editor of a journal is really much more lik= e the function of Program Committee chair in a conference. I..e., to sele= ct the material to be published. That is not the case here. >> >> I observe that there are at least two distinct visions for the role of= RSE. I am hearing that some people want not much more than someone who = reports to the LLC, and that any changes should be initiated and managed = by the community or a committee, while others believe that the role invol= ves leadership and expertise. (There are other visions as well, I=E2=80=99= m sure). >> >> I think it would advance this group=E2=80=99s efforts if we all acknow= ledged some facts on the ground. =20 >> >> The role that we are discussing is more that of the publisher than of = the editor you describe. A publisher sets standards for how copy appears= , provides for distribution channels, insures appropriate cataloging, arc= hiving, and similar services. The RSE has had a role in all of the above= over the past few years, under the auspices of RFC 8728=E2=80=99s predec= essors. Each of those aspects is likely to evolve over time. >=20 > I think the analogies we're using have reached the end of their usefuln= ess; it would be better to make a clean break from them, and talk about t= he concrete responsibilities at hand. Agreed. My strawman is at https://tools.ietf.org/id/draft-carpenter-rfc-principles-01.html#name-the= -rfc-series-editor Brian >=20 >> This group could decide to hardcode all of those aspects. However, th= at would require returning to the community for changes whose implication= s we as a community may not be competent to understand. Along these same= lines, by way of example, do we want the RSE to have to come to the comm= unity for an RFC to approve a web site redesign? I will hazard a guess: = probably not. None of us are UX people. >=20 > You're presuming a lot about the breadth of the community there. And, e= ven if a particular skill is relatively rare in our community, it doesn't= mean that we should design things to shut out their input. >=20 >> While the RSE is one person or two might be an interesting question, h= ere is another one: might that change over time based on the scale of the= work?[*] If that is the case, I suggest that the entity ultimately resp= onsible for the series is the one who will be suited over time to make th= at call, and will need appropriate authority to do so. I don=E2=80=99t t= hink this group wants to hard code that but I am willing to be proved wro= ng. >=20 > To me, that suggests that we want the 'top' entity to be someone who's = responsible, but willing to delegate; i.e., a position that is likely ele= cted (or otherwise community selected) and NOT compensated. They can then= source the expertise which needs to be compensated as appropriate. >=20 >> Let us also acknowledge the tussle here. At the end of the day, the p= eople in this room have to decide how much of their vision to encode now = versus how much to entrust to some representation, either in the form of = the RSE or the entities overseeing the RSE. Recognize that the more we h= ard code now, the more will require review over time to keep current. >> >> If you agree with the above, then we have but to create a structure to= manage evolving visions over time, and highlight a handful of points tha= t we wish to keep as invariants. >=20 > Agreed. We really need to stop fixating on the minutia of the series an= d look at the big picture here. >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 From nobody Tue Jun 30 20:30: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 D04193A0AA3 for ; Tue, 30 Jun 2020 20:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7epEurlIh5I; Tue, 30 Jun 2020 20:30:04 -0700 (PDT) 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 BFEAF3A0A9D; Tue, 30 Jun 2020 20:30:03 -0700 (PDT) From: Jay Daley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <71334F08-17C0-4048-9238-45632145C86A@ietf.org> Date: Wed, 1 Jul 2020 15:30:01 +1200 Cc: rfced-future@iab.org To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Rfced-future] Defining the relevant community 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, 01 Jul 2020 03:30:06 -0000 Brian In your draft [1] you write: "The exact definition of the relevant community is open for debate.=20= One definition is: the IETF, the IRTF, the IAB and the many other=20= people who have contributed to, or made use of, the RFC Series=20 over the last fifty years. In particular, many users of the RFC = series,=20 ranging for example from junior hardware or software engineers to=20= senior executives overseeing procurement decisions, will never=20 participate directly in the IETF or IRTF." The problem with that is twofold - it=E2=80=99s too nebulous to pin down = and there=E2=80=99s no connection between those who produce the = documents and the community the documents are used by.=20 Another definition of the relevant community for RFCs is possible that = provides a practical path to pinning it down and fits with the current = split of responsibilities between the streams and the RSE:=20 "As each of the streams is responsible for the technical content of = their RFCs, so too are they responsible for defining the community = around that content, including those who contribute to an RFC and those = who are solely consumers of the RFC. In addition there is a community = that views the series as a whole, including archivists, librarians and = other standards organisations, which the RSE defines. The relevant = community for the RFC Series is defined as the superset of all of these = communities." Jay [1] = https://tools.ietf.org/id/draft-carpenter-rfc-principles-01.html#name-the-= rfc-series-as-a-whole section list item 5, bullet 1 --=20 Jay Daley IETF Executive Director jay@ietf.org From nobody Tue Jun 30 20:44: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 DB6483A0AE3 for ; Tue, 30 Jun 2020 20:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6cmIfC1_2Ou for ; Tue, 30 Jun 2020 20:44:09 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3DC3A0AA9 for ; Tue, 30 Jun 2020 20:44:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49xRt11vJnz6GD8b; Tue, 30 Jun 2020 20:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1593575049; bh=3kgY0FwzqjzhmubWZYiHU0u8En1bXvY/e9gC3xWgRZ8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=lVtEe52+ie1i0y0+HcmJSQc9dHeoc6fJ8cOAxLjnJVstC0TeAltVskwW2A4EWzRTt Ztk9T1QknjkZ0kNgi4E0LEt0VcRhk/AP2eMRvlnICzrArJuK8VMnwdWa8HwFuXfZHY 5b7UkaxrgkqSW7M1qMhV/Evdu03fARcOrw6to+Bc= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (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 49xRt04mv6z6G88Q; Tue, 30 Jun 2020 20:44:08 -0700 (PDT) To: Jay Daley Cc: rfced-future@iab.org References: <71334F08-17C0-4048-9238-45632145C86A@ietf.org> From: "Joel M. Halpern" Message-ID: <76203deb-44de-e9c8-78f1-036fbf14a060@joelhalpern.com> Date: Tue, 30 Jun 2020 23:44:07 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <71334F08-17C0-4048-9238-45632145C86A@ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Defining the relevant community 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, 01 Jul 2020 03:44:11 -0000 Jey, you put quotes around your proposed definition. Is that because it is a quote from somewhere, or merely to mark it as an intended proposal? I do not believe any of the streams have historically claimed to represent their readers, although they all do try to take into account the needs of the various kinds of readers. The IETF, at least, in practice only represents those who participate in the IETF processes. The ISE has not even claimed to represent the authors who contribute to that stream, much less the readers of documents from that stream. So I have trouble seeing how your proposal matches the facts on the ground. We could try to give the streams that responsibility, but that would be an interesting and complex undertaking. Historically, part of the point of the RFC Series leadership has been to make sure that the interests that are not at the table still get taken into account. That is explicit in the current model text. Yours, Joel On 6/30/2020 11:30 PM, Jay Daley wrote: > Brian > > In your draft [1] you write: > > "The exact definition of the relevant community is open for debate. > One definition is: the IETF, the IRTF, the IAB and the many other > people who have contributed to, or made use of, the RFC Series > over the last fifty years. In particular, many users of the RFC series, > ranging for example from junior hardware or software engineers to > senior executives overseeing procurement decisions, will never > participate directly in the IETF or IRTF." > > The problem with that is twofold - it’s too nebulous to pin down and there’s no connection between those who produce the documents and the community the documents are used by. > > Another definition of the relevant community for RFCs is possible that provides a practical path to pinning it down and fits with the current split of responsibilities between the streams and the RSE: > > "As each of the streams is responsible for the technical content of their RFCs, so too are they responsible for defining the community around that content, including those who contribute to an RFC and those who are solely consumers of the RFC. In addition there is a community that views the series as a whole, including archivists, librarians and other standards organisations, which the RSE defines. The relevant community for the RFC Series is defined as the superset of all of these communities." > > Jay > > [1] https://tools.ietf.org/id/draft-carpenter-rfc-principles-01.html#name-the-rfc-series-as-a-whole section list item 5, bullet 1 > From nobody Tue Jun 30 20:55: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 20D123A0AFD for ; Tue, 30 Jun 2020 20:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYET99qyTUhm; Tue, 30 Jun 2020 20:55:09 -0700 (PDT) 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 A21443A0A79; Tue, 30 Jun 2020 20:55:08 -0700 (PDT) From: Jay Daley Message-Id: <23A226A7-D7D7-4B10-A3EA-EE1A32EC375E@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_D4C80CD4-7945-40CB-AA99-E25AB90AA87D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 1 Jul 2020 15:55:06 +1200 In-Reply-To: <76203deb-44de-e9c8-78f1-036fbf14a060@joelhalpern.com> Cc: rfced-future@iab.org To: "Joel M. Halpern" References: <71334F08-17C0-4048-9238-45632145C86A@ietf.org> <76203deb-44de-e9c8-78f1-036fbf14a060@joelhalpern.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Defining the relevant community 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, 01 Jul 2020 03:55:11 -0000 --Apple-Mail=_D4C80CD4-7945-40CB-AA99-E25AB90AA87D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Joel > On 1/07/2020, at 3:44 PM, Joel M. Halpern wrote: >=20 > Jey, you put quotes around your proposed definition. Is that because = it is a quote from somewhere, or merely to mark it as an intended = proposal? A strawman. >=20 > I do not believe any of the streams have historically claimed to = represent their readers, although they all do try to take into account = the needs of the various kinds of readers. The IETF, at least, in = practice only represents those who participate in the IETF processes. = The ISE has not even claimed to represent the authors who contribute to = that stream, much less the readers of documents from that stream. I wasn=E2=80=99t suggesting representation, only definition. = Representation is very different. =20 >=20 > So I have trouble seeing how your proposal matches the facts on the = ground. We could try to give the streams that responsibility, but that = would be an interesting and complex undertaking. Historically, part of = the point of the RFC Series leadership has been to make sure that the = interests that are not at the table still get taken into account. That = is explicit in the current model text. My strawman gives the role for defining those who have no seat at the = table ("solely consumers") to the streams on the basis that the RSE is = one-step further removed from those people than the streams are. Thanks. Jay >=20 > Yours, > Joel >=20 > On 6/30/2020 11:30 PM, Jay Daley wrote: >> Brian >> In your draft [1] you write: >> "The exact definition of the relevant community is open for = debate. >> One definition is: the IETF, the IRTF, the IAB and the many = other >> people who have contributed to, or made use of, the RFC Series >> over the last fifty years. In particular, many users of the RFC = series, >> ranging for example from junior hardware or software engineers = to >> senior executives overseeing procurement decisions, will never >> participate directly in the IETF or IRTF." >> The problem with that is twofold - it=E2=80=99s too nebulous to pin = down and there=E2=80=99s no connection between those who produce the = documents and the community the documents are used by. >> Another definition of the relevant community for RFCs is possible = that provides a practical path to pinning it down and fits with the = current split of responsibilities between the streams and the RSE: >> "As each of the streams is responsible for the technical content of = their RFCs, so too are they responsible for defining the community = around that content, including those who contribute to an RFC and those = who are solely consumers of the RFC. In addition there is a community = that views the series as a whole, including archivists, librarians and = other standards organisations, which the RSE defines. The relevant = community for the RFC Series is defined as the superset of all of these = communities." >> Jay >> [1] = https://tools.ietf.org/id/draft-carpenter-rfc-principles-01.html#name-the-= rfc-series-as-a-whole section list item 5, bullet 1 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future = --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_D4C80CD4-7945-40CB-AA99-E25AB90AA87D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Joel

On 1/07/2020, at 3:44 PM, Joel = M. Halpern <jmh@joelhalpern.com> wrote:

Jey, you put quotes around your = proposed definition.  Is that because it is a quote from somewhere, = or merely to mark it as an intended proposal?

A = strawman.


I do not believe any of the streams have historically claimed = to represent their readers, although they all do try to take into = account the needs of the various kinds of readers.  The IETF, at = least, in practice only represents those who participate in the IETF = processes. The ISE has not even claimed to represent the authors who = contribute to that stream, much less the readers of documents from that = stream.

I = wasn=E2=80=99t suggesting representation, only definition. =  Representation is very different.  


So  I have trouble seeing = how your proposal matches the facts on the ground.  We could try to = give the streams that responsibility, but that would be an interesting = and complex undertaking. Historically, part of the point of the RFC = Series leadership has been to make sure that the interests that are not = at the table still get taken into account.  That is explicit in the = current model text.

My strawman gives the role for defining those who = have no seat at the table ("solely consumers") to the streams on the = basis that the RSE is one-step further removed from those people than = the streams are.

Thanks.
Jay


Yours,
Joel

On 6/30/2020 11:30 PM, Jay Daley wrote:
Brian
In your draft [1] you write:
    "The exact definition of the relevant = community is open for debate.
     One definition is: the IETF, = the IRTF, the IAB and the many other
     people who have contributed to, = or made use of, the RFC Series
     over the last fifty years. In = particular, many users of the RFC series,
     ranging for example from junior = hardware or software engineers to
     senior executives overseeing = procurement decisions, will never
     participate directly in the = IETF or IRTF."
The problem with that is twofold - it=E2=80=99= s too nebulous to pin down and there=E2=80=99s no connection between = those who produce the documents and the community the documents are used = by.
Another definition of the relevant community for RFCs = is possible that provides a practical path to pinning it down and fits = with the current split of responsibilities between the streams and the = RSE:
"As each of the streams is responsible for the = technical content of their RFCs, so too are they responsible for = defining the community around that content, including those who = contribute to an RFC and those who are solely consumers of the RFC. =  In addition there is a community that views the series as a whole, = including archivists, librarians and other standards organisations, = which the RSE defines. The relevant community for the RFC Series is = defined as the superset of all of these communities."
Jay[1] https://tools.ietf.org/id/draft-carpenter-rfc-principles-01.htm= l#name-the-rfc-series-as-a-whole section list item 5, bullet 1

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

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

= --Apple-Mail=_D4C80CD4-7945-40CB-AA99-E25AB90AA87D-- From nobody Tue Jun 30 21:07:26 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 9BDF43A0B58 for ; Tue, 30 Jun 2020 21:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isCbcZ-_qCnC for ; Tue, 30 Jun 2020 21:07:23 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299C03A0B51 for ; Tue, 30 Jun 2020 21:07:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49xSNq0KqZz6GGWH; Tue, 30 Jun 2020 21:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1593576443; bh=X1QTuodMlYCBa7jc9/MAlp0mAt3P6hc9SZ+jcEIsVHI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=SMUGDFJYnwBe7Qch1mYXGxrs79+9V2u2f9roatFDAzrfy/nYXlvhRFtgrQjGX2iK1 xSEW0ihti5bxfbqdhNfOd25HrIHqAFc4vZE7AcMIo1o6SEkhJ1bRt99yjhk3xl0w1P ckRtdo/PPYxVsLO8w9ehcyJzCSWYih5StTNYloT8= X-Quarantine-ID: <70i8RjzbSxrp> X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (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 49xSNp3vmmz6G7JD; Tue, 30 Jun 2020 21:07:22 -0700 (PDT) To: Jay Daley Cc: rfced-future@iab.org References: <71334F08-17C0-4048-9238-45632145C86A@ietf.org> <76203deb-44de-e9c8-78f1-036fbf14a060@joelhalpern.com> <23A226A7-D7D7-4B10-A3EA-EE1A32EC375E@ietf.org> From: "Joel M. Halpern" Message-ID: <2805d109-7ef2-e786-14e1-4355d55e4dc2@joelhalpern.com> Date: Wed, 1 Jul 2020 00:07:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <23A226A7-D7D7-4B10-A3EA-EE1A32EC375E@ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Defining the relevant community 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, 01 Jul 2020 04:07:25 -0000 While there is certainly room for disagreement, historically it has seemed that the RSE and RPC are closer to the consumers of the material than the IETF / IRTF are. (IAB documents of one kind or another frequently have more specific targets, and so may have different issues.) Adrian can correct me of course, but as far as I know the ISE has no channel to the consumers of Independent stream RFCs. Yours, Joel On 6/30/2020 11:55 PM, Jay Daley wrote: > Joel > >> On 1/07/2020, at 3:44 PM, Joel M. Halpern > > wrote: >> >> Jey, you put quotes around your proposed definition.  Is that because >> it is a quote from somewhere, or merely to mark it as an intended >> proposal? > > A strawman. > >> >> I do not believe any of the streams have historically claimed to >> represent their readers, although they all do try to take into account >> the needs of the various kinds of readers.  The IETF, at least, in >> practice only represents those who participate in the IETF processes. >> The ISE has not even claimed to represent the authors who contribute >> to that stream, much less the readers of documents from that stream. > > I wasn’t suggesting representation, only definition.  Representation is > very different. > >> >> So  I have trouble seeing how your proposal matches the facts on the >> ground.  We could try to give the streams that responsibility, but >> that would be an interesting and complex undertaking. Historically, >> part of the point of the RFC Series leadership has been to make sure >> that the interests that are not at the table still get taken into >> account.  That is explicit in the current model text. > > My strawman gives the role for defining those who have no seat at the > table ("solely consumers") to the streams on the basis that the RSE is > one-step further removed from those people than the streams are. > > Thanks. > > Jay > >> >> Yours, >> Joel >> >> On 6/30/2020 11:30 PM, Jay Daley wrote: >>> Brian >>> In your draft [1] you write: >>>     "The exact definition of the relevant community is open for debate. >>>      One definition is: the IETF, the IRTF, the IAB and the many other >>>      people who have contributed to, or made use of, the RFC Series >>>      over the last fifty years. In particular, many users of the RFC >>> series, >>>      ranging for example from junior hardware or software engineers to >>>      senior executives overseeing procurement decisions, will never >>>      participate directly in the IETF or IRTF." >>> The problem with that is twofold - it’s too nebulous to pin down and >>> there’s no connection between those who produce the documents and the >>> community the documents are used by. >>> Another definition of the relevant community for RFCs is possible >>> that provides a practical path to pinning it down and fits with the >>> current split of responsibilities between the streams and the RSE: >>> "As each of the streams is responsible for the technical content of >>> their RFCs, so too are they responsible for defining the community >>> around that content, including those who contribute to an RFC and >>> those who are solely consumers of the RFC.  In addition there is a >>> community that views the series as a whole, including archivists, >>> librarians and other standards organisations, which the RSE defines. >>> The relevant community for the RFC Series is defined as the superset >>> of all of these communities." >>> Jay >>> [1] >>> https://tools.ietf.org/id/draft-carpenter-rfc-principles-01.html#name-the-rfc-series-as-a-whole >>> section list item 5, bullet 1 >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > > -- > Jay Daley > IETF Executive Director > jay@ietf.org > From nobody Tue Jun 30 21:12:09 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 C76A03A0BA7 for ; Tue, 30 Jun 2020 21:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DROywXDa5usJ for ; Tue, 30 Jun 2020 21:12:07 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29ABB3A0B96 for ; Tue, 30 Jun 2020 21:12:07 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id b16so10383581pfi.13 for ; Tue, 30 Jun 2020 21:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7zOo1jYQQ5Nz/iuMinwuGLx4t+s6FSBrifTZ4WSfYyk=; b=m/fCYgW+JRFCarOo167zRpqF41P7Xh3U/N0mipCgIUzGsfGBS7QSxOfkQ8Yi6xgSk9 eMxAu1kpVxxIx2F6zYWmz3L2izZm7cxqP4uDU8/NaLUgp9KVh/iXFXvNRfIBe/6uAx4I EmCJf32SMi0AGqu2qxpGsZN9Dc4ccGYWh/+a+o1CLLF0TIXJ/lS3c+rgyA4icCQouy6D Gp2h7RmhEUfeKvSWqdZI55j+UB9dgSuvZlBfLPnWYp4wgyc0btANgY2O3RHH9bnoDrsC xTIBVySvDS3NM9Ux/gA/87Tvnu/N5PmLr0cpdbsglYt1X9yq4qhfbJsiqxzrBLEsT+eu tDrQ== 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=7zOo1jYQQ5Nz/iuMinwuGLx4t+s6FSBrifTZ4WSfYyk=; b=Ue8un8QaqEEgfi6oqyKGs122voJiI6MWbc4X8e3CXGxECJu88aBzQgJ5uI3aNjVBLL 2vLQXsjF/tM7o83vl0jXpvulATGcLnbczvPCdh5BbNKlkG7FtTA5YZesa3YlFwaZNMha SLTjQfkFGbMFw7ECd+oeTsg8W7woqH5Wkru6A/1foantBxuwdQS+QgpY3gG5tjuOhiQn LGSG2u4h8t/1R6dcXfUdCraOSKigDva2/xdmKBb6sFKWQYdb5XgDNwcyg5dM9/+h5ISP Lruosy9TNTRdsOFaDtydWA2DXhVs9/wEwelh8K1fTXuL7wEvlXhGnrTm4GFuLMXCfyFq lagQ== X-Gm-Message-State: AOAM530uBqC1PcJEsJijtmGOifpLD2fcQrYbKh3xrSXV1aaxrW0q82q0 x1BBsx3azyfRVxjvDtz6Rp+VBXZK X-Google-Smtp-Source: ABdhPJxduReiYR7pzQ4howN0/H/6eUGK4rHYQuDC+g8E92YujYy6bR4OMcCrk9h6OtV79woErNGfCQ== X-Received: by 2002:a62:15c3:: with SMTP id 186mr22364525pfv.30.1593576726270; Tue, 30 Jun 2020 21:12:06 -0700 (PDT) Received: from [192.168.178.20] (102.124.69.111.dynamic.snap.net.nz. [111.69.124.102]) by smtp.gmail.com with ESMTPSA id x7sm4161071pfq.197.2020.06.30.21.12.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2020 21:12:05 -0700 (PDT) To: Jay Daley , "Joel M. Halpern" Cc: rfced-future@iab.org References: <71334F08-17C0-4048-9238-45632145C86A@ietf.org> <76203deb-44de-e9c8-78f1-036fbf14a060@joelhalpern.com> <23A226A7-D7D7-4B10-A3EA-EE1A32EC375E@ietf.org> From: Brian E Carpenter Message-ID: <024b8a57-7d01-ebcd-53a5-929e93ac9afd@gmail.com> Date: Wed, 1 Jul 2020 16:12:03 +1200 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: <23A226A7-D7D7-4B10-A3EA-EE1A32EC375E@ietf.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Defining the relevant community 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, 01 Jul 2020 04:12:09 -0000 On 01-Jul-20 15:55, Jay Daley wrote: > Joel >=20 >> On 1/07/2020, at 3:44 PM, Joel M. Halpern > wrote: >> >> Jey, you put quotes around your proposed definition. =C2=A0Is that bec= ause it is a quote from somewhere, or merely to mark it as an intended pr= oposal? >=20 > A strawman. >=20 >> >> I do not believe any of the streams have historically claimed to repre= sent their readers, although they all do try to take into account the nee= ds of the various kinds of readers. =C2=A0The IETF, at least, in practice= only represents those who participate in the IETF processes. The ISE has= not even claimed to represent the authors who contribute to that stream,= much less the readers of documents from that stream. >=20 > I wasn=E2=80=99t suggesting representation, only definition. =C2=A0Repr= esentation is very different. =C2=A0 >=20 >> >> So =C2=A0I have trouble seeing how your proposal matches the facts on = the ground. =C2=A0We could try to give the streams that responsibility, b= ut that would be an interesting and complex undertaking. Historically, pa= rt of the point of the RFC Series leadership has been to make sure that t= he interests that are not at the table still get taken into account. =C2=A0= That is explicit in the current model text. >=20 > My strawman gives the role for defining those who have no seat at the t= able ("solely consumers") to the streams on the basis that the RSE is one= -step further removed from those people than the streams are. Is that necessarily true? Actually a person with contacts in the technica= l publishing world and/or in the product management world and/or the neto= ps world might be less removed than those of us in the IETF ivory tower. Which really is why I don't see that this group can figure out a definiti= ve answer. We can frame the problem, of course. Rgds Brian >=20 > Thanks. >=20 > Jay >=20 >> >> Yours, >> Joel >> >> On 6/30/2020 11:30 PM, Jay Daley wrote: >>> Brian >>> In your draft [1] you write: >>> =C2=A0=C2=A0=C2=A0=C2=A0"The exact definition of the relevant communi= ty is open for debate. >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0One definition is: the IETF, the IRTF, = the IAB and the many other >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0people who have contributed to, or made= use of, the RFC Series >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0over the last fifty years. In particula= r, many users of the RFC series, >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ranging for example from junior hardwar= e or software engineers to >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0senior executives overseeing procuremen= t decisions, will never >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0participate directly in the IETF or IRT= F." >>> The problem with that is twofold - it=E2=80=99s too nebulous to pin d= own and there=E2=80=99s no connection between those who produce the docum= ents and the community the documents are used by. >>> Another definition of the relevant community for RFCs is possible tha= t provides a practical path to pinning it down and fits with the current = split of responsibilities between the streams and the RSE: >>> "As each of the streams is responsible for the technical content of t= heir RFCs, so too are they responsible for defining the community around = that content, including those who contribute to an RFC and those who are = solely consumers of the RFC. =C2=A0In addition there is a community that = views the series as a whole, including archivists, librarians and other s= tandards organisations, which the RSE defines. The relevant community for= the RFC Series is defined as the superset of all of these communities." >>> Jay >>> [1] https://tools.ietf.org/id/draft-carpenter-rfc-principles-01.html#= name-the-rfc-series-as-a-whole section list item 5, bullet 1 >> >> --=C2=A0 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 > --=C2=A0 > Jay Daley > IETF Executive Director > jay@ietf.org >=20 >=20 From nobody Tue Jun 30 21:18: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 F10F83A0C69 for ; Tue, 30 Jun 2020 21:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gdx48d8dnxE; Tue, 30 Jun 2020 21:17:49 -0700 (PDT) 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 58BAE3A0C73; Tue, 30 Jun 2020 21:17:48 -0700 (PDT) From: Jay Daley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0E697A93-5614-41A4-AF9E-E117BCAD52E7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 1 Jul 2020 16:17:46 +1200 In-Reply-To: <2805d109-7ef2-e786-14e1-4355d55e4dc2@joelhalpern.com> Cc: rfced-future@iab.org To: "Joel M. Halpern" References: <71334F08-17C0-4048-9238-45632145C86A@ietf.org> <76203deb-44de-e9c8-78f1-036fbf14a060@joelhalpern.com> <23A226A7-D7D7-4B10-A3EA-EE1A32EC375E@ietf.org> <2805d109-7ef2-e786-14e1-4355d55e4dc2@joelhalpern.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Rfced-future] Defining the relevant community 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, 01 Jul 2020 04:17:59 -0000 --Apple-Mail=_0E697A93-5614-41A4-AF9E-E117BCAD52E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 1/07/2020, at 4:07 PM, Joel M. Halpern wrote: >=20 > While there is certainly room for disagreement, historically it has = seemed that the RSE and RPC are closer to the consumers of the material = than the IETF / IRTF are. (IAB documents of one kind or another = frequently have more specific targets, and so may have different = issues.) Adrian can correct me of course, but as far as I know the ISE = has no channel to the consumers of Independent stream RFCs. I don=E2=80=99t disagree, but again that=E2=80=99s about = representation/engagement not identification. Currently the RSE has to = both identify and to engage/consult/listen to. I am suggesting that the = two parts can be split with the first part, identification, having much = more direct involvement from the streams. And to be clear, the reason = I=E2=80=99m suggesting that is because the current situation of = expecting the RSE to define seems intractable - or have I misunderstood = and is the "relevant community" well defined? Jay=20 >=20 > Yours, > Joel >=20 > On 6/30/2020 11:55 PM, Jay Daley wrote: >> Joel >>> On 1/07/2020, at 3:44 PM, Joel M. Halpern > wrote: >>>=20 >>> Jey, you put quotes around your proposed definition. Is that = because it is a quote from somewhere, or merely to mark it as an = intended proposal? >> A strawman. >>>=20 >>> I do not believe any of the streams have historically claimed to = represent their readers, although they all do try to take into account = the needs of the various kinds of readers. The IETF, at least, in = practice only represents those who participate in the IETF processes. = The ISE has not even claimed to represent the authors who contribute to = that stream, much less the readers of documents from that stream. >> I wasn=E2=80=99t suggesting representation, only definition. = Representation is very different. >>>=20 >>> So I have trouble seeing how your proposal matches the facts on the = ground. We could try to give the streams that responsibility, but that = would be an interesting and complex undertaking. Historically, part of = the point of the RFC Series leadership has been to make sure that the = interests that are not at the table still get taken into account. That = is explicit in the current model text. >> My strawman gives the role for defining those who have no seat at the = table ("solely consumers") to the streams on the basis that the RSE is = one-step further removed from those people than the streams are. >> Thanks. >> Jay >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 6/30/2020 11:30 PM, Jay Daley wrote: >>>> Brian >>>> In your draft [1] you write: >>>> "The exact definition of the relevant community is open for = debate. >>>> One definition is: the IETF, the IRTF, the IAB and the many = other >>>> people who have contributed to, or made use of, the RFC Series >>>> over the last fifty years. In particular, many users of the = RFC series, >>>> ranging for example from junior hardware or software engineers = to >>>> senior executives overseeing procurement decisions, will never >>>> participate directly in the IETF or IRTF." >>>> The problem with that is twofold - it=E2=80=99s too nebulous to pin = down and there=E2=80=99s no connection between those who produce the = documents and the community the documents are used by. >>>> Another definition of the relevant community for RFCs is possible = that provides a practical path to pinning it down and fits with the = current split of responsibilities between the streams and the RSE: >>>> "As each of the streams is responsible for the technical content of = their RFCs, so too are they responsible for defining the community = around that content, including those who contribute to an RFC and those = who are solely consumers of the RFC. In addition there is a community = that views the series as a whole, including archivists, librarians and = other standards organisations, which the RSE defines. The relevant = community for the RFC Series is defined as the superset of all of these = communities." >>>> Jay >>>> [1] = https://tools.ietf.org/id/draft-carpenter-rfc-principles-01.html#name-the-= rfc-series-as-a-whole section list item 5, bullet 1 >>>=20 >>> -- >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >> --=20 >> Jay Daley >> IETF Executive Director >> jay@ietf.org >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_0E697A93-5614-41A4-AF9E-E117BCAD52E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 1/07/2020, at 4:07 PM, Joel M. Halpern <jmh@joelhalpern.com>= wrote:

While there is certainly room for disagreement, historically = it has seemed that the RSE and RPC are closer to the consumers of the = material than the IETF / IRTF are.  (IAB documents of one kind or = another frequently have more specific targets, and so may have different = issues.)  Adrian can correct me of course, but as far as I know the = ISE has no channel to the consumers of Independent stream RFCs.

I = don=E2=80=99t disagree, but again that=E2=80=99s about = representation/engagement not identification.  Currently the RSE = has to both identify and to engage/consult/listen to.  I am = suggesting that the two parts can be split with the first part, = identification, having much more direct involvement from the streams. =  And to be clear, the reason I=E2=80=99m suggesting that is because = the current situation of expecting the RSE to define seems intractable - = or have I misunderstood and is the "relevant community" well = defined?

Jay 


Yours,
Joel

On 6/30/2020 11:55 PM, Jay Daley wrote:
Joel
On 1/07/2020, at 3:44 = PM, Joel M. Halpern <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> wrote:
Jey, you put quotes around your proposed definition. =  Is that because it is a quote from somewhere, or merely to mark it = as an intended proposal?
A strawman.

I do not = believe any of the streams have historically claimed to represent their = readers, although they all do try to take into account the needs of the = various kinds of readers.  The IETF, at least, in practice only = represents those who participate in the IETF processes. The ISE has not = even claimed to represent the authors who contribute to that stream, = much less the readers of documents from that stream.
I wasn=E2=80=99t suggesting representation, only = definition.  Representation is very different.

So =  I have trouble seeing how your proposal matches the facts on the = ground.  We could try to give the streams that responsibility, but = that would be an interesting and complex undertaking. Historically, part = of the point of the RFC Series leadership has been to make sure that the = interests that are not at the table still get taken into account. =  That is explicit in the current model text.
My strawman gives the role for defining those = who have no seat at the table ("solely consumers") to the streams on the = basis that the RSE is one-step further removed from those people than = the streams are.
Thanks.
Jay

Yours,
Joel

On 6/30/2020 11:30 PM, Jay = Daley wrote:
Brian
In your draft [1] you write:
    "The exact definition of the relevant = community is open for debate.
     One definition is: the IETF, = the IRTF, the IAB and the many other
     people who have contributed to, = or made use of, the RFC Series
     over the last fifty years. In = particular, many users of the RFC series,
     ranging for example from junior = hardware or software engineers to
     senior executives overseeing = procurement decisions, will never
     participate directly in the = IETF or IRTF."
The problem with that is twofold - it=E2=80=99= s too nebulous to pin down and there=E2=80=99s no connection between = those who produce the documents and the community the documents are used = by.
Another definition of the relevant community for RFCs = is possible that provides a practical path to pinning it down and fits = with the current split of responsibilities between the streams and the = RSE:
"As each of the streams is responsible for the = technical content of their RFCs, so too are they responsible for = defining the community around that content, including those who = contribute to an RFC and those who are solely consumers of the RFC. =  In addition there is a community that views the series as a whole, = including archivists, librarians and other standards organisations, = which the RSE defines. The relevant community for the RFC Series is = defined as the superset of all of these communities."
Jay[1] https://tools.ietf.org/id/draft-carpenter-rfc-principles-01.htm= l#name-the-rfc-series-as-a-whole section list item 5, bullet 1

--
Rfced-future = mailing list
Rfced-future@iab.org <mailto:Rfced-future@iab.org>
https://www.iab.org/mailman/listinfo/rfced-future
--
Jay Daley
IETF = Executive Director
jay@ietf.org <mailto:jay@ietf.org>

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

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

= --Apple-Mail=_0E697A93-5614-41A4-AF9E-E117BCAD52E7-- From nobody Tue Jun 30 22:34: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 C5A503A00B2 for ; Tue, 30 Jun 2020 22:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 Komas1hmRSpv for ; Tue, 30 Jun 2020 22:34:47 -0700 (PDT) Received: from dragonfly.birch.relay.mailchannels.net (dragonfly.birch.relay.mailchannels.net [23.83.209.51]) (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 1ECDB3A00AE for ; Tue, 30 Jun 2020 22:34:46 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id B5F9C36160C; Wed, 1 Jul 2020 05:34:45 +0000 (UTC) Received: from pdx1-sub0-mail-a97.g.dreamhost.com (100-96-9-10.trex.outbound.svc.cluster.local [100.96.9.10]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 378ED36138B; Wed, 1 Jul 2020 05:34:45 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a97.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Wed, 01 Jul 2020 05:34:45 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Fearful-Daffy: 2a38065440778b30_1593581685503_2476699954 X-MC-Loop-Signature: 1593581685503:199636283 X-MC-Ingress-Time: 1593581685503 Received: from pdx1-sub0-mail-a97.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a97.g.dreamhost.com (Postfix) with ESMTP id EC248B47E7; Tue, 30 Jun 2020 22:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=lVRBiRghg2rbMB IDk83s68QjeuM=; b=KRR9eF5HtZxjNstjY9cqe/QGz9HJz+1xCIUXY6nJSavaGG wtj+VP9E3gEfHDqJvW4xIS9PwprBxMMvbsgwFMWfCyRPfPWAgT9NGzglKLcoqr1i spbsr+kPGTlx3uegnbUZjWv15FugK6f9C/E7S3NdcxpYS3OiTR8dBjmospOLY= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 3CF50B47E2; Tue, 30 Jun 2020 22:34:42 -0700 (PDT) Date: Wed, 1 Jul 2020 00:34:39 -0500 X-DH-BACKEND: pdx1-sub0-mail-a97 From: Nico Williams To: Brian E Carpenter Cc: Peter Saint-Andre , Brian Rosen , rfced-future@iab.org Message-ID: <20200701053437.GD3100@localhost> References: <62A4C70D-419A-4DE3-8A54-60EB2B064EF2@brianrosen.net> <8c626e3e-1700-46fe-90b3-26b9c1296788@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedrtddugdelkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuggftrfgrthhtvghrnhepffdtkeethfeuteeviefgfeegjeetjedvhfehgfdvtdefueejheelgeeuhffghffgnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: Subject: Re: [Rfced-future] "oversees" [was Scope and IETF 108 proposals] 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, 01 Jul 2020 05:34:49 -0000 On Thu, Jun 25, 2020 at 11:14:48AM +1200, Brian E Carpenter wrote: > On 25-Jun-20 09:21, Peter Saint-Andre wrote: > > On 6/24/20 2:52 PM, Brian E Carpenter wrote: > >> On 25-Jun-20 03:17, Brian Rosen wrote: > >> .... > >>> 4. Is there some group that oversees the RSE? > >>> This seems to be answered in the affirmative. If you disagree, please speak up. > >> > >> I'm allergic to "oversees" and "oversight" since we have running > >> code proof that we are incompetent at it, and our attempts have > >> decayed into micro-management. > > > > I've seen this claim several times; can you provide evidence for it? > > Just the entire history of IASA version 1 and the IAOC doing the work > itself instead of overseeing the execution of the work. So far, the > LLC Board is doing much better, because it's constituted as a Board. > Also of course the recent history of the RSOC that led to Heather's > resignation. Engineers are bad at overseeing non-engineering > activities; we meddle in things we are no good at. (I don't except > myself from that statement, since I was IETF Chair at the time that > IASA was set up, and I know that I got far too interested in stuff > that shouldn't have been my business.) This entire list's traffic feels like engineers doing things we're not good at. Judging by just some of the posts I've read, we're having trouble: - defining the community the RSE is to be responsive to (this feels surprising, but then it's not) - defining the business relationship between the RSE and the LLC (employee vs contractor) - defining the management structure for the RSE (who do they report to) Perhaps we should step back a bit. Regarding the business issues, can the LLC make a proposal in I-D form that we can review and debate? Would that help? FWIW, I believe that the employment nature of the RSE is not for us to decide, but for the LLC to decide, possibly based on the circumstances surrounding the individual selected as RSE (someone else stated a similar opinion, and I agree with them). The LLC board should figure out who is to manage the RSE. Definitely, *we* (IETF/IRTF/IAB) should define the community that the RSE is responsive to, though I agree it's difficult to define a community of RFC consumers who do not participate here. Perhaps we need to make it easier for users to give us (or the RSE) feedback -- if mailing lists won't do, then maybe we need to find a better way for our users to communicate with us. Looking at RFC5620's definition of the RSE role, I wonder how many of the RSE's responsibilities can be completed, then needing only maintenance. E.g., the RFC Style Manual, can it be "done", and how much maintenance does it require? Is the RSE a full-time job, or a part-time one? If part-time, what eventualities might cause it to become a full-time one? If we couldn't get an RSE appointed for a year or two, what would break, go wrong, or go undone? Might we eventually not need an RSE, or might we find more responsibilities for the RSE? The ISE role feels much more like a full-time role in the long term than the RSE. FYI, I've stayed out of a lot of this, so I'm probably out of my depth here; it probably shows, and if so, well, sorry for the noise. Nico --